From andrea.antonello at gmail.com Tue Jan 19 01:25:47 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Tue, 19 Jan 2010 09:25:47 +0100 Subject: [CF-metadata] standard way to store lookuptables In-Reply-To: <20091002161701.GA10917@met.reading.ac.uk> References: <20091002161701.GA10917@met.reading.ac.uk> Message-ID: <116eb44a1001190025n58ddaf37wb6c269d808da0c24@mail.gmail.com> Dear Jonathan, I finally came to that section and went after your advice. I am trying to implement the timeseries as explained in 5.4, but I run into what I feel gives memory overload, so I think I might be doing something wrong. Assuming that I have different stations that serve temperature, I would: Dimensions: - create a dimension for the stations - create the time dimension Variables: - create the lat, lon, time variables - create the temperature variable When the moment comes to fill in the temperature, I create an ArrayDouble.D2 depending on timeDim and stationDim. At that point I am asked to insert the size of this array, which is timeSIze and... here I would like to insert only the number of stations that serve temperature, instead I have to insert the number of all the stations that I have (else indexes will fail). In that case assuming that I have 100 stations and only two serve temperature, I will create anyways an array of timeSize*100 instead of timeSize*2. I hope I have been able to explain this properly. Any help would be very apreciated. Best regards, Andrea On Fri, Oct 2, 2009 at 5:17 PM, Jonathan Gregory wrote: > Dear Andrea > > I think some of your conversation has been off the list, so I'm not sure > exactly what has been said. Anyway, here are some remarks. > >> >? If so these would be easily encoded using netCDF >> > variables that all depend upon a dimension "numberOfSoilTypes".? Having said >> > this I'd add that while this is a natural encoding in netCDF there is no >> > explicit convention for it. > > It would be fine in CF to have a data variable e.g. of hydraulic conductivity > with a dimension for soiltypes. This data variable could have a string-valued > auxiliary coordinate variable to identify the soil types by name. This idea > is described in CF 6.1. > > In your lat-lon field which gives the geographical > distribution of soil types, you can use some encoding e.g. as integers, > and attach flag_values and flag_meanings attributes to give the translation > of these integers into soil type names. This is in CF 3.5. > > There is an example of precipitation timeseries from stations in CF 5.4. > Again, they could be given names, like in CF 6.1. > > Cheers > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > From j.m.gregory at reading.ac.uk Tue Jan 19 01:58:02 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 19 Jan 2010 08:58:02 +0000 Subject: [CF-metadata] standard way to store lookuptables In-Reply-To: <116eb44a1001190025n58ddaf37wb6c269d808da0c24@mail.gmail.com> References: <20091002161701.GA10917@met.reading.ac.uk> <116eb44a1001190025n58ddaf37wb6c269d808da0c24@mail.gmail.com> Message-ID: <20100119085802.GA23910@met.reading.ac.uk> Dear Andrea I don't know whether the problem is lack of memory. That would depend on the software you are using, rather than on netCDF or the CF convention, so I'm not sure what to suggest really. You could try creating an empty file of the right size by writing it in CDL and using ncgen, to test that it can be done. Sorry not to be more helpful. Best wishes Jonathan From andrea.antonello at gmail.com Tue Jan 19 02:04:49 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Tue, 19 Jan 2010 10:04:49 +0100 Subject: [CF-metadata] standard way to store lookuptables In-Reply-To: <20100119085802.GA23910@met.reading.ac.uk> References: <20091002161701.GA10917@met.reading.ac.uk> <116eb44a1001190025n58ddaf37wb6c269d808da0c24@mail.gmail.com> <20100119085802.GA23910@met.reading.ac.uk> Message-ID: <116eb44a1001190104nd720035p2d5fb814e33d9f2@mail.gmail.com> Dear Jonathan, thanks for your reply. > I don't know whether the problem is lack of memory. That would depend on > the software you are using, rather than on netCDF or the CF convention, so > I'm not sure what to suggest really. You could try creating an empty file > of the right size by writing it in CDL and using ncgen, to test that it > can be done. Sorry not to be more helpful. At the moment I have no problem with the memory overload really. I just would like to understand if I am implementing the proposed CF way properly. Can you confirm me that in the above example with 2 stations of interest for the temperature variable (from 100) I am right in creating a variable with timeSize*100 instead of timeSize*2, which brings an 80% of 0.0 values of overload? Where overload here really means never used. And if yes, should those unused values stay 0.0 or be somehow flagged? I would love to do this the CF way and I am just wondering if someone stumbled into this doubt also. Best regards, Andrea > > Best wishes > > Jonathan > From caron at unidata.ucar.edu Tue Jan 19 07:48:19 2010 From: caron at unidata.ucar.edu (John Caron) Date: Tue, 19 Jan 2010 07:48:19 -0700 Subject: [CF-metadata] standard way to store lookuptables In-Reply-To: <116eb44a1001190104nd720035p2d5fb814e33d9f2@mail.gmail.com> References: <20091002161701.GA10917@met.reading.ac.uk> <116eb44a1001190025n58ddaf37wb6c269d808da0c24@mail.gmail.com> <20100119085802.GA23910@met.reading.ac.uk> <116eb44a1001190104nd720035p2d5fb814e33d9f2@mail.gmail.com> Message-ID: <4B55C633.2000001@unidata.ucar.edu> Hi Andrea: To figure out if you are using the right form, its best to send CDL to this group. To debug your use of the netcdf-java library, its best to send code, error messages and a sample file to netcdf-java at unidata.ucar.edu. Regards, John andrea antonello wrote: > Dear Jonathan, > thanks for your reply. > > >> I don't know whether the problem is lack of memory. That would depend on >> the software you are using, rather than on netCDF or the CF convention, so >> I'm not sure what to suggest really. You could try creating an empty file >> of the right size by writing it in CDL and using ncgen, to test that it >> can be done. Sorry not to be more helpful. >> > > At the moment I have no problem with the memory overload really. I > just would like to understand if I am implementing the proposed CF way > properly. > Can you confirm me that in the above example with 2 stations of > interest for the temperature variable (from 100) I am right in > creating a variable with timeSize*100 instead of > timeSize*2, which brings an 80% of 0.0 values of overload? Where > overload here really means never used. And if yes, should those unused > values stay 0.0 or be somehow flagged? > I would love to do this the CF way and I am just wondering if someone > stumbled into this doubt also. > > Best regards, > Andrea > > >> Best wishes >> >> Jonathan >> >> > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > From r.muetzelfeldt at ed.ac.uk Tue Jan 19 10:10:10 2010 From: r.muetzelfeldt at ed.ac.uk (Robert Muetzelfeldt) Date: Tue, 19 Jan 2010 17:10:10 +0000 Subject: [CF-metadata] Keyword-centred list of Standard Names Message-ID: <4B55E772.4060409@ed.ac.uk> As part of an exercise looking at the grammatical structure of CF-metadata Standard Names, I have produced a list of all occurrences of all keywords, with the full Standard Name arranged to the left and right of the page-centred keyword. All the remaining words in each Standard Name are hyperlinks, so it is easy to navigate around the list by clicking on individual words. This keyword-centred format makes it easy to see the pattern of the terms which precede and succeed each keyword. The current version can be found at http://www.similette.com/cfmetadata/centred_list.html So far, tested only in Firefox. Please note that this is a working prototype, developed for my own use. I just thought that others might be interested in this way of browsing through the Standard Names. Please also note that the list of Standard Names it uses was downloaded in Oct 2008, so is well out of date. If this is considered to be a useful resource, I would be happy to discuss (offline) options for improving the formatting and keeping the list up to date. Best wishes, Robert -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From caron at unidata.ucar.edu Tue Jan 19 11:21:13 2010 From: caron at unidata.ucar.edu (John Caron) Date: Tue, 19 Jan 2010 11:21:13 -0700 Subject: [CF-metadata] Keyword-centred list of Standard Names In-Reply-To: <4B55E772.4060409@ed.ac.uk> References: <4B55E772.4060409@ed.ac.uk> Message-ID: <4B55F819.6070607@unidata.ucar.edu> Robert Muetzelfeldt wrote: > As part of an exercise looking at the grammatical structure of > CF-metadata Standard Names, I have produced a list of all occurrences > of all keywords, with the full Standard Name arranged to the left and > right of the page-centred keyword. All the remaining words in each > Standard Name are hyperlinks, so it is easy to navigate around the > list by clicking on individual words. > This keyword-centred format makes it easy to see the pattern of the > terms which precede and succeed each keyword. > > The current version can be found at > http://www.similette.com/cfmetadata/centred_list.html So far, tested > only in Firefox. > > Please note that this is a working prototype, developed for my own > use. I just thought that others might be interested in this way of > browsing through the Standard Names. Please also note that the list > of Standard Names it uses was downloaded in Oct 2008, so is well out > of date. > If this is considered to be a useful resource, I would be happy to > discuss (offline) options for improving the formatting and keeping the > list up to date. > > Best wishes, > Robert > > this is very cool. one thing i noticed is that on the web page, you have an embedded blank (or something) after the "_", which makes it harder to cut and paste the name. *bolus*_ northward _ sea _ water _ velocity From r.muetzelfeldt at ed.ac.uk Tue Jan 19 12:56:05 2010 From: r.muetzelfeldt at ed.ac.uk (Robert Muetzelfeldt) Date: Tue, 19 Jan 2010 19:56:05 +0000 Subject: [CF-metadata] Keyword-centred list of Standard Names In-Reply-To: <4B55F819.6070607@unidata.ucar.edu> References: <4B55E772.4060409@ed.ac.uk> <4B55F819.6070607@unidata.ucar.edu> Message-ID: <4B560E55.60601@ed.ac.uk> Thanks for your comments, John. I think the white space you mention results from some extra formatting (newlines etc) I inserted into the generated HTML source, in order to make that more readable for anyone who wants to View Source. I've now taken that out, and updated the published version. The only white space that I get now when I copy-and-paste a line is a tab character just before the centred keyword. I guess that results from the fact that that is the boundary between two cells ( elements), which is what I use in order to get all the centred keywords aligned vertically. So there's nothing I can do about that. Whatever, I don't actually envisage that many people will actually be wanting to cut-and-paste from the keyword-centred list - it's not really the point of the exercise. What I could do is to provide a link on each row to the corresponding row in the HTML Standard Name table on the CF Metadata web site - would that be useful? Amongst other benefits, anyone who wanted to cut-and-paste the name could get it from there. Cheers, Robert John Caron wrote: > Robert Muetzelfeldt wrote: >> As part of an exercise looking at the grammatical structure of >> CF-metadata Standard Names, I have produced a list of all occurrences >> of all keywords, with the full Standard Name arranged to the left and >> right of the page-centred keyword. All the remaining words in each >> Standard Name are hyperlinks, so it is easy to navigate around the >> list by clicking on individual words. This keyword-centred format >> makes it easy to see the pattern of the terms which precede and >> succeed each keyword. >> >> The current version can be found at >> http://www.similette.com/cfmetadata/centred_list.html So far, >> tested only in Firefox. >> >> Please note that this is a working prototype, developed for my own >> use. I just thought that others might be interested in this way of >> browsing through the Standard Names. Please also note that the list >> of Standard Names it uses was downloaded in Oct 2008, so is well out >> of date. If this is considered to be a useful resource, I would be >> happy to discuss (offline) options for improving the formatting and >> keeping the list up to date. >> >> Best wishes, >> Robert >> >> > this is very cool. > > one thing i noticed is that on the web page, you have an embedded > blank (or something) after the "_", which makes it harder to cut and > paste the name. > > *bolus*_ > northward > _ > sea _ > water _ > velocity > > > > > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From caron at unidata.ucar.edu Tue Jan 19 13:44:36 2010 From: caron at unidata.ucar.edu (John Caron) Date: Tue, 19 Jan 2010 13:44:36 -0700 Subject: [CF-metadata] Keyword-centred list of Standard Names In-Reply-To: <4B560E55.60601@ed.ac.uk> References: <4B55E772.4060409@ed.ac.uk> <4B55F819.6070607@unidata.ucar.edu> <4B560E55.60601@ed.ac.uk> Message-ID: <4B5619B4.1040900@unidata.ucar.edu> Robert Muetzelfeldt wrote: > Thanks for your comments, John. > > I think the white space you mention results from some extra formatting > (newlines etc) I inserted into the generated HTML source, in order to > make that more readable for anyone who wants to View Source. I've > now taken that out, and updated the published version. The only white > space that I get now when I copy-and-paste a line is a tab character > just before the centred keyword. I guess that results from the fact > that that is the boundary between two cells ( elements), which is > what I use in order to get all the centred keywords aligned > vertically. So there's nothing I can do about that. > > Whatever, I don't actually envisage that many people will actually be > wanting to cut-and-paste from the keyword-centred list - it's not > really the point of the exercise. > What I could do is to provide a link on each row to the corresponding > row in the HTML Standard Name table on the CF Metadata web site - > would that be useful? Amongst other benefits, anyone who wanted to > cut-and-paste the name could get it from there. yes, thats what i was using it for, so a link would be great. > > Cheers, > Robert > > John Caron wrote: >> Robert Muetzelfeldt wrote: >>> As part of an exercise looking at the grammatical structure of >>> CF-metadata Standard Names, I have produced a list of all >>> occurrences of all keywords, with the full Standard Name arranged to >>> the left and right of the page-centred keyword. All the remaining >>> words in each Standard Name are hyperlinks, so it is easy to >>> navigate around the list by clicking on individual words. This >>> keyword-centred format makes it easy to see the pattern of the terms >>> which precede and succeed each keyword. >>> >>> The current version can be found at >>> http://www.similette.com/cfmetadata/centred_list.html So far, >>> tested only in Firefox. >>> >>> Please note that this is a working prototype, developed for my own >>> use. I just thought that others might be interested in this way of >>> browsing through the Standard Names. Please also note that the list >>> of Standard Names it uses was downloaded in Oct 2008, so is well out >>> of date. If this is considered to be a useful resource, I would be >>> happy to discuss (offline) options for improving the formatting and >>> keeping the list up to date. >>> >>> Best wishes, >>> Robert >>> >>> >> this is very cool. >> >> one thing i noticed is that on the web page, you have an embedded >> blank (or something) after the "_", which makes it harder to cut and >> paste the name. >> >> *bolus*_ >> northward >> _ >> sea _ >> water >> _ >> velocity >> >> >> >> >> > > From andrea.antonello at gmail.com Wed Jan 20 01:20:40 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Wed, 20 Jan 2010 09:20:40 +0100 Subject: [CF-metadata] standard way to store lookuptables In-Reply-To: <4B55E452.6090405@ucar.edu> References: <20091002161701.GA10917@met.reading.ac.uk> <116eb44a1001190025n58ddaf37wb6c269d808da0c24@mail.gmail.com> <20100119085802.GA23910@met.reading.ac.uk> <116eb44a1001190104nd720035p2d5fb814e33d9f2@mail.gmail.com> <4B55E452.6090405@ucar.edu> Message-ID: <116eb44a1001200020x422ae2adlc2f3a52e08bb127@mail.gmail.com> Hi Janine, thanks for the reply. > I am very familiar with the problem you are having and have run into this > many times, and yes, you have to create timeSize*100, not timeSize*2. I > would use the _fillValue attribute to set a value to fill all the missing > temperatures. That way there will be no confusion that 0.0 is a measurement > value. > > If I understand correctly, the missing stations will be compressed in memory > to a value (0.0) and a repetition (100), so it doesn't take as much memory > as you think. But check the online documentation to confirm that. That is one of the things I was guessing. In my understanding that helps to save disk space. Another issue would be heap memory. I assume that when the ArrayDoubles are read into memory, the are uncompressed. Is there any documentation that coveres that kind of doubts or is it something more to be looked in the javadoc? Any link would be appreciated. Thanks, Andrea > > Janine > > andrea antonello wrote: >> >> Dear Jonathan, >> thanks for your reply. >> >> >>> >>> I don't know whether the problem is lack of memory. That would depend on >>> the software you are using, rather than on netCDF or the CF convention, >>> so >>> I'm not sure what to suggest really. You could try creating an empty file >>> of the right size by writing it in CDL and using ncgen, to test that it >>> can be done. Sorry not to be more helpful. >>> >> >> At the moment I have no problem with the memory overload really. I >> just would like to understand if I am implementing the proposed CF way >> properly. >> Can you confirm me that in the above example with 2 stations of >> interest for the temperature variable (from 100) I am right in >> creating a variable with ?timeSize*100 instead of >> timeSize*2, which brings an 80% of 0.0 values of overload? Where >> overload here really means never used. And if yes, should those unused >> values stay 0.0 or be somehow flagged? >> I would love to do this the CF way and I am just wondering if someone >> stumbled into this doubt also. >> >> Best regards, >> Andrea >> >> >>> >>> Best wishes >>> >>> Jonathan >>> >>> >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> > > > -- > Janine Aquino (Goldstein) > > ?"Life is a comedy for those who think... and a tragedy for > ?those who feel." - Horace Walpole > > From taylor13 at llnl.gov Wed Jan 20 06:29:45 2010 From: taylor13 at llnl.gov (Karl Taylor) Date: Wed, 20 Jan 2010 05:29:45 -0800 Subject: [CF-metadata] standard way to store lookuptables In-Reply-To: <116eb44a1001200020x422ae2adlc2f3a52e08bb127@mail.gmail.com> References: <20091002161701.GA10917@met.reading.ac.uk> <116eb44a1001190025n58ddaf37wb6c269d808da0c24@mail.gmail.com> <20100119085802.GA23910@met.reading.ac.uk> <116eb44a1001190104nd720035p2d5fb814e33d9f2@mail.gmail.com> <4B55E452.6090405@ucar.edu> <116eb44a1001200020x422ae2adlc2f3a52e08bb127@mail.gmail.com> Message-ID: <4B570549.30405@llnl.gov> Dear all, Note that if you use the new netCDF4 library, there is a compression option that allows for efficient automatic compression of data in the files containing lots of contiguous common numbers (like "missing" or 0.). If you stick to the so-called classical data model (and with CF there is no reason not to), then most software can be easily built with netCDF4, so reading these files is not impaired. Best regards, Karl On 20-Jan-10 12:20 AM, andrea antonello wrote: > Hi Janine, > thanks for the reply. > > >> I am very familiar with the problem you are having and have run into this >> many times, and yes, you have to create timeSize*100, not timeSize*2. I >> would use the _fillValue attribute to set a value to fill all the missing >> temperatures. That way there will be no confusion that 0.0 is a measurement >> value. >> >> If I understand correctly, the missing stations will be compressed in memory >> to a value (0.0) and a repetition (100), so it doesn't take as much memory >> as you think. But check the online documentation to confirm that. >> > That is one of the things I was guessing. In my understanding that > helps to save disk space. Another issue would be heap memory. I assume > that when the ArrayDoubles are read into memory, the are uncompressed. > Is there any documentation that coveres that kind of doubts or is it > something more to be looked in the javadoc? Any link would be > appreciated. > > Thanks, > Andrea > > > > >> Janine >> >> andrea antonello wrote: >> >>> Dear Jonathan, >>> thanks for your reply. >>> >>> >>> >>>> I don't know whether the problem is lack of memory. That would depend on >>>> the software you are using, rather than on netCDF or the CF convention, >>>> so >>>> I'm not sure what to suggest really. You could try creating an empty file >>>> of the right size by writing it in CDL and using ncgen, to test that it >>>> can be done. Sorry not to be more helpful. >>>> >>>> >>> At the moment I have no problem with the memory overload really. I >>> just would like to understand if I am implementing the proposed CF way >>> properly. >>> Can you confirm me that in the above example with 2 stations of >>> interest for the temperature variable (from 100) I am right in >>> creating a variable with timeSize*100 instead of >>> timeSize*2, which brings an 80% of 0.0 values of overload? Where >>> overload here really means never used. And if yes, should those unused >>> values stay 0.0 or be somehow flagged? >>> I would love to do this the CF way and I am just wondering if someone >>> stumbled into this doubt also. >>> >>> Best regards, >>> Andrea >>> >>> >>> >>>> Best wishes >>>> >>>> Jonathan >>>> >>>> >>>> >>> _______________________________________________ >>> CF-metadata mailing list >>> CF-metadata at cgd.ucar.edu >>> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>> >>> >> >> -- >> Janine Aquino (Goldstein) >> >> "Life is a comedy for those who think... and a tragedy for >> those who feel." - Horace Walpole >> >> >> > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > From egil.storen at met.no Fri Jan 22 02:57:44 2010 From: egil.storen at met.no (=?ISO-8859-1?Q?Egil_St=F8ren?=) Date: Fri, 22 Jan 2010 10:57:44 +0100 Subject: [CF-metadata] The Conventions attribute Message-ID: <4B597698.7060601@met.no> Hi all, There seem to be a need for upgrading the text in the CF Conventions documents about the global "Conventions" attribute. I am thinking of paragraph 2.6.1 "Identification of Conventions", which seems to have remained unchanged (except for different Conventions version numbers) throughout the history of CF. The text in the CF 1.4 document says: 'We recommend that netCDF files that follow these conventions indicate this by setting the NUG defined global attribute Conventions to the string value "CF-1.4" .' According to the Unidata web page on NetCDF Conventions (http://www.unidata.ucar.edu/software/netcdf/conventions.html), specifying multiple conventions (either space separated or comma separated) in this attribute is allowed. But the text above seems to indicate that "CF-1.4" should be the only "recommended" value. My impression, by sporadically following this mail list, is that this restriction has never been intended, and that other additional conventions are allowed in the Conventions attribute. The reason I am raising this issue is an E-mail exchange on the THREDDS E-mail list (subject "NcML and the element", http://www.unidata.ucar.edu/mailing_lists/archives/thredds/2010/subject.html). See specifically the discussion from January 21 and on. Some confusion obviously exist on what actually are required by CF. Further down in the same 2.6.1 paragraph I discovered another problem. From the document: "The string is interpreted as a directory name relative to a directory that is a repository of documents describing sets of discipline-specific conventions. The conventions directory name is currently interpreted relative to the directory pub/netcdf/Conventions/ on the host machine ftp.unidata.ucar.edu." There is no reference to CF on ftp://ftp.unidata.ucar.edu/pub/netcdf/Conventions/. Best regards, Egil St?ren From Heiko.Klein at met.no Fri Jan 22 03:34:32 2010 From: Heiko.Klein at met.no (Heiko Klein) Date: Fri, 22 Jan 2010 11:34:32 +0100 Subject: [CF-metadata] Discovery metadata for CF? Message-ID: <4B597F38.2030500@met.no> CF does a great job on describing datasets for general usage. But CF leaves a gap on discovery metadata for data catalogs. Chapter 2.6.2 describes some, but not all parameters required by popular Discovery Metadata-specifications like ISO19115 or DIF. This lead to several CF-extensions, e.g. * John Carons: Dataset Inventory Catalog Specification Version: http://www.unidata.ucar.edu/projects/THREDDS/tech/catalog/InvCatalogSpec.html#controlledVocabulary * Ethan Davis': NetCDF Attribute Convention for Dataset Discovery http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html * Damocles (IPY) File specification http://damocles.met.no/dokuwiki/lib/exe/fetch.php?id=documentation:start&cache=cache&media=documentation:deliverable_6_1_02b-metno.pdf (chapter 6) * others, e.g. adding a global attribute containing a ISO19115 metadata xml-string. The Dataset Inventory Catalog tells us to add discovery metadata to external files, which is a bit against the netcdf-philosophy of bundling metadata with the files. The other two examples add additional global attributes to the files, which might lead to conflicts between (future) CF versions and the added attributes. CF should either include those attributes, or allow for a namespace for an external document, i.e. following the NetCDF Attribute Convention for DatasetDiscovery, adding a global attribute 'Metadata_Conventions' = '...', and then all attribute starting with i.e. with 'MC_' should be directed to the Metadata_Conventions parser. Best regards, Heiko -- 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 From j.m.gregory at reading.ac.uk Fri Jan 22 07:05:50 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 22 Jan 2010 14:05:50 +0000 Subject: [CF-metadata] CF conventions and metadata conventions In-Reply-To: <4B597F38.2030500@met.no> References: <4B597F38.2030500@met.no> Message-ID: <20100122140550.GA11696@met.reading.ac.uk> Dear Egil and Heiko Both of your discussions are somewhat related to CF trac ticket 27 https://cf-pcmdi.llnl.gov/trac/ticket/27 In the latter part of that, there is generally agreement that we should allow other conventions to provide attributes which are labelled with a prefix, as Heiko suggests for including a discovery metadata convention. There seems to be no problem with that, so long as the other convention is not providing the same kind of metadata as CF, so there will not be any contradiction. There has been other discussion recently on this email list concerning the issue of naming other conventions in the Conventions attribute. I don't think the original intention was to exclude that possibility. It's just not recognised in the CF standard and it should be. However, no-one's had time propose an amendment. Personally, I think it's OK so long as the extra conventions accept all of CF, and just add more conventions which do not conflict. If they overlap, this has to be thought about carefully, and in that case I would say that the CF standard would have to be amended to describe how the overlaps should be resolved. Perhaps you'd like to have a look at and contribute to trac ticket 27. Best wishes Jonathan From davidf at dfanning.com Fri Jan 22 10:49:53 2010 From: davidf at dfanning.com (David Fanning) Date: Fri, 22 Jan 2010 10:49:53 -0700 Subject: [CF-metadata] Description of Map Projection Grid Message-ID: <20100122175027.CEF9ED90C6@smtp02.frii.com> Folks, I have searched the list archives, but have not found a solution to my problem. I have map projected images I wish to package in a netCDF file. Along with other map projection information, I would like to describe the extent of the map projection grid that is associated with the image. This is an XY grid, normally expressed in meters. Knowing the extent of this grid is important for navigating the image, adding image annotations, and other things. In GDAL the grid extent is sometimes expressed as the Northernmost_Northing, the Southernmost_Northing, the Easternmost_Easting, and the Westernmost_Easting. These names would mean something if my map projection was, for example, a Mercator projection of the entire Earth. But my map projections are polar projections, and so this terminology is misleading, to say the least. If the image in is the southern hemisphere, the terminology is bizarre. What I am looking for are standard names to define the extent of this XY grid. I have found in the CF 1.4 standard the names "projection_x_coordinate" and "projection_y_coordinate". This is getting to what I am looking for, but there is no supporting documentation to tell me exactly which point on my projection grid these names are describing. (I would guess this could describe the upper-left corner of the grid, or what would be called the "tie-point" in a GeoTIFF file, for example, but I am not sure.) Does anyone have any experience describing this XY grid? Or can anyone suggest a standard name I have overlooked? I think these names could be possibilities: projection_x_coordinate_minimum projection_x_coordinate_maximum projection_y_coordinate_minimum projection_y_coordinate_maximum Thank you for your help. Cheers, David -------- David W. Fanning Scientific Programmer NSIDC/CIRES, Univ. of Colorado E-Mail: fanning at nsidc.org From philip.bentley at metoffice.gov.uk Mon Jan 25 03:27:33 2010 From: philip.bentley at metoffice.gov.uk (Bentley, Philip) Date: Mon, 25 Jan 2010 10:27:33 -0000 Subject: [CF-metadata] Description of Map Projection Grid In-Reply-To: <20100122175027.CEF9ED90C6@smtp02.frii.com> References: <20100122175027.CEF9ED90C6@smtp02.frii.com> Message-ID: Hi David, A while back there was discussion on the mailing list regarding the addition of two new attributes to the CF convention to record the min/max values of a variable in a generic way. See http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2008/002191.html I have a vague recollection that this proposal made it through to a CF trac ticket. However, I don't see the new attributes in the latest CF conventions document, and unfortunately I'm not currently able to check the CF trac site because it's throwing an 'invalid security certificate' error in my browser. You may have more luck. But, in principle, I reckon those two new attributes, if/when added to CF, would provide you with a workable solution, e.g. something like... double x(x); x:standard_name = "projection_x_coordinate"; x:units = "m"; x:actual_min = 0.0; // or whatever value is appropriate x:actual_max = 12345678.0; // ditto ... Similarly for y. HTH, Phil Bentley > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu > [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of David Fanning > Sent: 22 January 2010 17:50 > To: cf-metadata at cgd.ucar.edu > Subject: [CF-metadata] Description of Map Projection Grid > > Folks, > > I have searched the list archives, but have not found a > solution to my problem. > > I have map projected images I wish to package in a netCDF > file. Along with other map projection information, I would > like to describe the extent of the map projection grid that > is associated with the image. This is an XY grid, normally > expressed in meters. Knowing the extent of this grid is > important for navigating the image, adding image annotations, > and other things. > > In GDAL the grid extent is sometimes expressed as the > Northernmost_Northing, the Southernmost_Northing, the > Easternmost_Easting, and the Westernmost_Easting. > These names would mean something if my map projection was, > for example, a Mercator projection of the entire Earth. But > my map projections are polar projections, and so this > terminology is misleading, to say the least. If the image in > is the southern hemisphere, the terminology is bizarre. > > What I am looking for are standard names to define the extent > of this XY grid. I have found in the CF 1.4 standard the > names "projection_x_coordinate" > and "projection_y_coordinate". This is getting to what I am > looking for, but there is no supporting documentation to tell > me exactly which point on my projection grid these names are > describing. (I would guess this could describe the upper-left > corner of the grid, or what would be called the "tie-point" > in a GeoTIFF file, for example, but I am not sure.) > > Does anyone have any experience describing this XY grid? Or > can anyone suggest a standard name I have overlooked? > > I think these names could be possibilities: > > projection_x_coordinate_minimum > projection_x_coordinate_maximum > projection_y_coordinate_minimum > projection_y_coordinate_maximum > > Thank you for your help. > > Cheers, > > David > > -------- > David W. Fanning > Scientific Programmer > NSIDC/CIRES, Univ. of Colorado > E-Mail: fanning at nsidc.org > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > From Jeff.deLaBeaujardiere at noaa.gov Tue Jan 26 15:21:38 2010 From: Jeff.deLaBeaujardiere at noaa.gov (Jeff deLaBeaujardiere) Date: Tue, 26 Jan 2010 17:21:38 -0500 Subject: [CF-metadata] seeking CF name for total water column height Message-ID: <4B5F6AF2.9030301@noaa.gov> Hello- I am a new subscriber. We are hoping to adopt CF names wherever possible in the context of the Integrated Ocean Observing System (IOOS) Sensor Observation Services (SOS). Not all phenomena we measure have immediately apparent CF names, however. We are using this URL as a reference: http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/current/cf-standard-name-table.html The first example is total water column height as derived from a bottom pressure recorder associated with a tsunami warning buoy. This is not sea_surface_height_above_reference_ellipsoid or _above_sea_level. It might be height_above_sea_floor but we're not really sure what that refers to (height of what?). Is there a standard name present or planned that is equivalent to total_water_column_height? Thanks for any information, Jeff DLB -- Jeff de La Beaujardi?re, PhD Senior Systems Architect, Data Integration Framework Integrated Ocean Observing System (IOOS) Program Office National Oceanic and Atmospheric Administration 1100 Wayne Ave #1225, Silver Spring MD 20910 USA +1 301 427 2427 Jeff.deLaBeaujardiere at noaa.gov From rkl at bodc.ac.uk Wed Jan 27 01:58:19 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Wed, 27 Jan 2010 08:58:19 +0000 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <4B5F6AF2.9030301@noaa.gov> References: <4B5F6AF2.9030301@noaa.gov> Message-ID: <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> Dear All, I think a new Standard Name 'sea_floor_depth_below_sea_surface' is what's needed here. My definition for this would be 'The vertical distance between the sea surface and the seabed at a given point in space and at a given instant in time or averaged over a time interval that is significantly less than a tidal cycle (1 hour or less).' This may seem complicated, but is needed to cover BPRs which do some averaging to smooth out waves. My take on 'height_above_sea_floor' would be as the z co-ordinate for something inside a water body. May be worth pointing out to Jeff that there is already 'sea_water_pressure_at_sea_floor' for BPR data that haven't been converted to depth. I've expressed this as a depth rather than as a height to be consistent with 'sea_floor_depth_below_sea_level' and so we don't end up with different terms for the same quantity depending upon whether one is looking upwards or downwards. Cheers, Roy. -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jeff deLaBeaujardiere Sent: 26 January 2010 22:22 To: cf-metadata at cgd.ucar.edu Cc: Mike Garcia Subject: [CF-metadata] seeking CF name for total water column height Hello- I am a new subscriber. We are hoping to adopt CF names wherever possible in the context of the Integrated Ocean Observing System (IOOS) Sensor Observation Services (SOS). Not all phenomena we measure have immediately apparent CF names, however. We are using this URL as a reference: http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/current/cf-standard-name-table.html The first example is total water column height as derived from a bottom pressure recorder associated with a tsunami warning buoy. This is not sea_surface_height_above_reference_ellipsoid or _above_sea_level. It might be height_above_sea_floor but we're not really sure what that refers to (height of what?). Is there a standard name present or planned that is equivalent to total_water_column_height? Thanks for any information, Jeff DLB -- Jeff de La Beaujardi?re, PhD Senior Systems Architect, Data Integration Framework Integrated Ocean Observing System (IOOS) Program Office National Oceanic and Atmospheric Administration 1100 Wayne Ave #1225, Silver Spring MD 20910 USA +1 301 427 2427 Jeff.deLaBeaujardiere at noaa.gov _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From olauret at cls.fr Wed Jan 27 02:20:09 2010 From: olauret at cls.fr (olivier lauret) Date: Wed, 27 Jan 2010 10:20:09 +0100 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> Message-ID: <1240F43731C2EB4F8CC9BF70D233B5110172EB3A@SRV-XCHANGE-2K3.pc.cls.fr> Hello Roy, Hello Jeff, Just to feed the debate: that in CF table there is also the quantity 'sea_surface_height_above_geoid'. That could be a possibility too, I think? Cheers, Olivier. -----Message d'origine----- De?: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] De la part de Lowry, Roy K Envoy??: mercredi 27 janvier 2010 09:58 ??: Jeff deLaBeaujardiere; cf-metadata at cgd.ucar.edu Cc?: Mike Garcia Objet?: Re: [CF-metadata] seeking CF name for total water column height Dear All, I think a new Standard Name 'sea_floor_depth_below_sea_surface' is what's needed here. My definition for this would be 'The vertical distance between the sea surface and the seabed at a given point in space and at a given instant in time or averaged over a time interval that is significantly less than a tidal cycle (1 hour or less).' This may seem complicated, but is needed to cover BPRs which do some averaging to smooth out waves. My take on 'height_above_sea_floor' would be as the z co-ordinate for something inside a water body. May be worth pointing out to Jeff that there is already 'sea_water_pressure_at_sea_floor' for BPR data that haven't been converted to depth. I've expressed this as a depth rather than as a height to be consistent with 'sea_floor_depth_below_sea_level' and so we don't end up with different terms for the same quantity depending upon whether one is looking upwards or downwards. Cheers, Roy. -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jeff deLaBeaujardiere Sent: 26 January 2010 22:22 To: cf-metadata at cgd.ucar.edu Cc: Mike Garcia Subject: [CF-metadata] seeking CF name for total water column height Hello- I am a new subscriber. We are hoping to adopt CF names wherever possible in the context of the Integrated Ocean Observing System (IOOS) Sensor Observation Services (SOS). Not all phenomena we measure have immediately apparent CF names, however. We are using this URL as a reference: http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/current/cf-standard-name-table.html The first example is total water column height as derived from a bottom pressure recorder associated with a tsunami warning buoy. This is not sea_surface_height_above_reference_ellipsoid or _above_sea_level. It might be height_above_sea_floor but we're not really sure what that refers to (height of what?). Is there a standard name present or planned that is equivalent to total_water_column_height? Thanks for any information, Jeff DLB -- Jeff de La Beaujardi?re, PhD Senior Systems Architect, Data Integration Framework Integrated Ocean Observing System (IOOS) Program Office National Oceanic and Atmospheric Administration 1100 Wayne Ave #1225, Silver Spring MD 20910 USA +1 301 427 2427 Jeff.deLaBeaujardiere at noaa.gov _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata Cliquez sur l'url suivante https://www.mailcontrol.com/sr/XSF3ayfb92zTndxI!oX7UtTXwRoU2H8X9MZg!!X+6h5uo0A89Yts6hMrboLqIZ6d9r4ZDktgx4ejfskgLULbMA== si ce message est ind?sirable (pourriel). From rkl at bodc.ac.uk Wed Jan 27 03:05:33 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Wed, 27 Jan 2010 10:05:33 +0000 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <1240F43731C2EB4F8CC9BF70D233B5110172EB3A@SRV-XCHANGE-2K3.pc.cls.fr> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <1240F43731C2EB4F8CC9BF70D233B5110172EB3A@SRV-XCHANGE-2K3.pc.cls.fr> Message-ID: <40829B0E077C1145A6DE44D39B3830A90886F59EBF@nerckwmb1.ad.nerc.ac.uk> Hello Olivier, The geoid is defined as 'a surface of constant geopotential with which mean sea level would coincide if the ocean were at rest', so to my thinking 'sea_surface_height_above_geoid' is approximately the distance between the actual sea surface and mean sea level, whereas what Jeff is after is the distance between the actual sea surface and the seafloor, which APPROXIMATES to 'sea_floor_depth_below_sea_level' plus 'sea_surface_height_above_geoid'. Cheers, Roy. -----Original Message----- From: olivier lauret [mailto:olauret at cls.fr] Sent: 27 January 2010 09:20 To: Lowry, Roy K; Jeff deLaBeaujardiere; cf-metadata at cgd.ucar.edu Cc: Mike Garcia Subject: RE: [CF-metadata] seeking CF name for total water column height Hello Roy, Hello Jeff, Just to feed the debate: that in CF table there is also the quantity 'sea_surface_height_above_geoid'. That could be a possibility too, I think? Cheers, Olivier. -----Message d'origine----- De?: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] De la part de Lowry, Roy K Envoy??: mercredi 27 janvier 2010 09:58 ??: Jeff deLaBeaujardiere; cf-metadata at cgd.ucar.edu Cc?: Mike Garcia Objet?: Re: [CF-metadata] seeking CF name for total water column height Dear All, I think a new Standard Name 'sea_floor_depth_below_sea_surface' is what's needed here. My definition for this would be 'The vertical distance between the sea surface and the seabed at a given point in space and at a given instant in time or averaged over a time interval that is significantly less than a tidal cycle (1 hour or less).' This may seem complicated, but is needed to cover BPRs which do some averaging to smooth out waves. My take on 'height_above_sea_floor' would be as the z co-ordinate for something inside a water body. May be worth pointing out to Jeff that there is already 'sea_water_pressure_at_sea_floor' for BPR data that haven't been converted to depth. I've expressed this as a depth rather than as a height to be consistent with 'sea_floor_depth_below_sea_level' and so we don't end up with different terms for the same quantity depending upon whether one is looking upwards or downwards. Cheers, Roy. -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jeff deLaBeaujardiere Sent: 26 January 2010 22:22 To: cf-metadata at cgd.ucar.edu Cc: Mike Garcia Subject: [CF-metadata] seeking CF name for total water column height Hello- I am a new subscriber. We are hoping to adopt CF names wherever possible in the context of the Integrated Ocean Observing System (IOOS) Sensor Observation Services (SOS). Not all phenomena we measure have immediately apparent CF names, however. We are using this URL as a reference: http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/current/cf-standard-name-table.html The first example is total water column height as derived from a bottom pressure recorder associated with a tsunami warning buoy. This is not sea_surface_height_above_reference_ellipsoid or _above_sea_level. It might be height_above_sea_floor but we're not really sure what that refers to (height of what?). Is there a standard name present or planned that is equivalent to total_water_column_height? Thanks for any information, Jeff DLB -- Jeff de La Beaujardi?re, PhD Senior Systems Architect, Data Integration Framework Integrated Ocean Observing System (IOOS) Program Office National Oceanic and Atmospheric Administration 1100 Wayne Ave #1225, Silver Spring MD 20910 USA +1 301 427 2427 Jeff.deLaBeaujardiere at noaa.gov _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata Cliquez sur l'url suivante https://www.mailcontrol.com/sr/XSF3ayfb92zTndxI!oX7UtTXwRoU2H8X9MZg!!X+6h5uo0A89Yts6hMrboLqIZ6d9r4ZDktgx4ejfskgLULbMA== si ce message est ind?sirable (pourriel). -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From Jeff.deLaBeaujardiere at noaa.gov Wed Jan 27 07:28:51 2010 From: Jeff.deLaBeaujardiere at noaa.gov (Jeff deLaBeaujardiere) Date: Wed, 27 Jan 2010 09:28:51 -0500 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> Message-ID: <4B604DA3.2030504@noaa.gov> 'sea_floor_depth_below_sea_surface' would be fine. Is there a vote or process for adding it? Thanks for the note about pressure--we do not currently report it from this server, but could add it in future. -Jeff Lowry, Roy K wrote: > Dear All, > > I think a new Standard Name 'sea_floor_depth_below_sea_surface' is what's needed here. My definition for this would be 'The vertical distance between the sea surface and the seabed at a given point in space and at a given instant in time or averaged over a time interval that is significantly less than a tidal cycle (1 hour or less).' This may seem complicated, but is needed to cover BPRs which do some averaging to smooth out waves. My take on 'height_above_sea_floor' would be as the z co-ordinate for something inside a water body. > > May be worth pointing out to Jeff that there is already 'sea_water_pressure_at_sea_floor' for BPR data that haven't been converted to depth. > > I've expressed this as a depth rather than as a height to be consistent with 'sea_floor_depth_below_sea_level' and so we don't end up with different terms for the same quantity depending upon whether one is looking upwards or downwards. > > Cheers, Roy. > > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jeff deLaBeaujardiere > Sent: 26 January 2010 22:22 > To: cf-metadata at cgd.ucar.edu > Cc: Mike Garcia > Subject: [CF-metadata] seeking CF name for total water column height > > Hello- > > I am a new subscriber. We are hoping to adopt CF names wherever possible in the context of the Integrated Ocean Observing System (IOOS) Sensor Observation Services (SOS). Not all phenomena we measure have immediately apparent CF names, however. We are using this URL as a reference: > http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/current/cf-standard-name-table.html > > The first example is total water column height as derived from a bottom pressure recorder associated with a tsunami warning buoy. This is not sea_surface_height_above_reference_ellipsoid or _above_sea_level. It might be height_above_sea_floor but we're not really sure what that refers to (height of what?). > > Is there a standard name present or planned that is equivalent to total_water_column_height? > > Thanks for any information, > Jeff DLB > -- Jeff de La Beaujardi?re, PhD Senior Systems Architect, Data Integration Framework Integrated Ocean Observing System (IOOS) Program Office National Oceanic and Atmospheric Administration 1100 Wayne Ave #1225, Silver Spring MD 20910 USA +1 301 427 2427 Jeff.deLaBeaujardiere at noaa.gov From jbgraybeal at mindspring.com Wed Jan 27 09:41:58 2010 From: jbgraybeal at mindspring.com (John Graybeal) Date: Wed, 27 Jan 2010 08:41:58 -0800 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> Message-ID: <5F29FB36-8366-4976-80FE-5F78B105E2DF@mindspring.com> Any particular reason that you are biased for this name representing only a short-term value? Seems to me there is equally the need for a (measured or modeled) value that would be defined exactly the same way, but without the time qualifiers. In general, when CF has a measured observable, the name makes no statement about whether the variable has been measured instantaneously, or for 1 hour, or for one month. It's time-neutral. This has several advantages. I suggest either the same principle be applied here, or that the possibility of the longer-time-frame name be accommodated by adding a qualifier to the name associated with this definition. John On Jan 27, 2010, at 00:58, Lowry, Roy K wrote: > Dear All, > > I think a new Standard Name 'sea_floor_depth_below_sea_surface' is > what's needed here. My definition for this would be 'The vertical > distance between the sea surface and the seabed at a given point in > space and at a given instant in time or averaged over a time > interval that is significantly less than a tidal cycle (1 hour or > less).' This may seem complicated, but is needed to cover BPRs which > do some averaging to smooth out waves. My take on > 'height_above_sea_floor' would be as the z co-ordinate for something > inside a water body. > > May be worth pointing out to Jeff that there is already > 'sea_water_pressure_at_sea_floor' for BPR data that haven't been > converted to depth. > > I've expressed this as a depth rather than as a height to be > consistent with 'sea_floor_depth_below_sea_level' and so we don't > end up with different terms for the same quantity depending upon > whether one is looking upwards or downwards. > > Cheers, Roy. > > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu > ] On Behalf Of Jeff deLaBeaujardiere > Sent: 26 January 2010 22:22 > To: cf-metadata at cgd.ucar.edu > Cc: Mike Garcia > Subject: [CF-metadata] seeking CF name for total water column height > > Hello- > > I am a new subscriber. We are hoping to adopt CF names wherever > possible in the context of the Integrated Ocean Observing System > (IOOS) Sensor Observation Services (SOS). Not all phenomena we > measure have immediately apparent CF names, however. We are using > this URL as a reference: > http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/current/cf-standard-name-table.html > > The first example is total water column height as derived from a > bottom pressure recorder associated with a tsunami warning buoy. > This is not sea_surface_height_above_reference_ellipsoid or > _above_sea_level. It might be height_above_sea_floor but we're not > really sure what that refers to (height of what?). > > Is there a standard name present or planned that is equivalent to > total_water_column_height? > > Thanks for any information, > Jeff DLB > > -- > Jeff de La Beaujardi?re, PhD > Senior Systems Architect, Data Integration Framework > Integrated Ocean Observing System (IOOS) Program Office > National Oceanic and Atmospheric Administration > 1100 Wayne Ave #1225, Silver Spring MD 20910 USA > +1 301 427 2427 > Jeff.deLaBeaujardiere at noaa.gov > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > -- > This message (and any attachments) is for the recipient only. NERC > is subject to the Freedom of Information Act 2000 and the contents > of this email and any reply you make may be disclosed by NERC unless > it is exempt from release under the Act. Any material supplied to > NERC may be stored in an electronic records management system. > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -------------- I have my new work email address: jgraybeal at ucsd.edu -------------- John Graybeal phone: 858-534-2162 System Development Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org From rkl at bodc.ac.uk Wed Jan 27 13:54:55 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Wed, 27 Jan 2010 20:54:55 +0000 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <5F29FB36-8366-4976-80FE-5F78B105E2DF@mindspring.com> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk>, <5F29FB36-8366-4976-80FE-5F78B105E2DF@mindspring.com> Message-ID: <40829B0E077C1145A6DE44D39B3830A90886AB722D@nerckwmb1.ad.nerc.ac.uk> Hi John, Simple pragmatism. It's what a BPR data stream tends to contain and so it needs labelling. Cheers, Roy. ________________________________________ From: John Graybeal [jbgraybeal at mindspring.com] Sent: 27 January 2010 16:41 To: Lowry, Roy K Cc: Jeff deLaBeaujardiere; cf-metadata at cgd.ucar.edu; Mike Garcia Subject: Re: [CF-metadata] seeking CF name for total water column height Any particular reason that you are biased for this name representing only a short-term value? Seems to me there is equally the need for a (measured or modeled) value that would be defined exactly the same way, but without the time qualifiers. In general, when CF has a measured observable, the name makes no statement about whether the variable has been measured instantaneously, or for 1 hour, or for one month. It's time-neutral. This has several advantages. I suggest either the same principle be applied here, or that the possibility of the longer-time-frame name be accommodated by adding a qualifier to the name associated with this definition. John On Jan 27, 2010, at 00:58, Lowry, Roy K wrote: > Dear All, > > I think a new Standard Name 'sea_floor_depth_below_sea_surface' is > what's needed here. My definition for this would be 'The vertical > distance between the sea surface and the seabed at a given point in > space and at a given instant in time or averaged over a time > interval that is significantly less than a tidal cycle (1 hour or > less).' This may seem complicated, but is needed to cover BPRs which > do some averaging to smooth out waves. My take on > 'height_above_sea_floor' would be as the z co-ordinate for something > inside a water body. > > May be worth pointing out to Jeff that there is already > 'sea_water_pressure_at_sea_floor' for BPR data that haven't been > converted to depth. > > I've expressed this as a depth rather than as a height to be > consistent with 'sea_floor_depth_below_sea_level' and so we don't > end up with different terms for the same quantity depending upon > whether one is looking upwards or downwards. > > Cheers, Roy. > > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu > ] On Behalf Of Jeff deLaBeaujardiere > Sent: 26 January 2010 22:22 > To: cf-metadata at cgd.ucar.edu > Cc: Mike Garcia > Subject: [CF-metadata] seeking CF name for total water column height > > Hello- > > I am a new subscriber. We are hoping to adopt CF names wherever > possible in the context of the Integrated Ocean Observing System > (IOOS) Sensor Observation Services (SOS). Not all phenomena we > measure have immediately apparent CF names, however. We are using > this URL as a reference: > http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/current/cf-standard-name-table.html > > The first example is total water column height as derived from a > bottom pressure recorder associated with a tsunami warning buoy. > This is not sea_surface_height_above_reference_ellipsoid or > _above_sea_level. It might be height_above_sea_floor but we're not > really sure what that refers to (height of what?). > > Is there a standard name present or planned that is equivalent to > total_water_column_height? > > Thanks for any information, > Jeff DLB > > -- > Jeff de La Beaujardi?re, PhD > Senior Systems Architect, Data Integration Framework > Integrated Ocean Observing System (IOOS) Program Office > National Oceanic and Atmospheric Administration > 1100 Wayne Ave #1225, Silver Spring MD 20910 USA > +1 301 427 2427 > Jeff.deLaBeaujardiere at noaa.gov > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > -- > This message (and any attachments) is for the recipient only. NERC > is subject to the Freedom of Information Act 2000 and the contents > of this email and any reply you make may be disclosed by NERC unless > it is exempt from release under the Act. Any material supplied to > NERC may be stored in an electronic records management system. > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -------------- I have my new work email address: jgraybeal at ucsd.edu -------------- John Graybeal phone: 858-534-2162 System Development Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From jbgraybeal at mindspring.com Wed Jan 27 16:00:40 2010 From: jbgraybeal at mindspring.com (John Graybeal) Date: Wed, 27 Jan 2010 15:00:40 -0800 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <40829B0E077C1145A6DE44D39B3830A90886AB722D@nerckwmb1.ad.nerc.ac.uk> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk>, <5F29FB36-8366-4976-80FE-5F78B105E2DF@mindspring.com> <40829B0E077C1145A6DE44D39B3830A90886AB722D@nerckwmb1.ad.nerc.ac.uk> Message-ID: <6DAEEA19-0CB8-4A81-8D4C-E99495BBA2D2@mindspring.com> I have no concern about whether this stream needs labeling. My concern is whether you are defining something in the definition which is in no way described by the label, and which will prevent that label being used for other variables in other streams. Put another way, what should the models that calculate the nominal sea_floor_depth_below_sea_surface -- or an averaged value longer than 1 hour -- call their values? John On Jan 27, 2010, at 12:54, Lowry, Roy K wrote: > Hi John, > > Simple pragmatism. It's what a BPR data stream tends to contain and > so it needs labelling. > > Cheers, Roy. > > ________________________________________ > From: John Graybeal [jbgraybeal at mindspring.com] > Sent: 27 January 2010 16:41 > To: Lowry, Roy K > Cc: Jeff deLaBeaujardiere; cf-metadata at cgd.ucar.edu; Mike Garcia > Subject: Re: [CF-metadata] seeking CF name for total water column > height > > Any particular reason that you are biased for this name representing > only a short-term value? Seems to me there is equally the need for a > (measured or modeled) value that would be defined exactly the same > way, but without the time qualifiers. > > In general, when CF has a measured observable, the name makes no > statement about whether the variable has been measured > instantaneously, or for 1 hour, or for one month. It's time-neutral. > This has several advantages. > > I suggest either the same principle be applied here, or that the > possibility of the longer-time-frame name be accommodated by adding a > qualifier to the name associated with this definition. > > John > > > On Jan 27, 2010, at 00:58, Lowry, Roy K wrote: > >> Dear All, >> >> I think a new Standard Name 'sea_floor_depth_below_sea_surface' is >> what's needed here. My definition for this would be 'The vertical >> distance between the sea surface and the seabed at a given point in >> space and at a given instant in time or averaged over a time >> interval that is significantly less than a tidal cycle (1 hour or >> less).' This may seem complicated, but is needed to cover BPRs which >> do some averaging to smooth out waves. My take on >> 'height_above_sea_floor' would be as the z co-ordinate for something >> inside a water body. >> >> May be worth pointing out to Jeff that there is already >> 'sea_water_pressure_at_sea_floor' for BPR data that haven't been >> converted to depth. >> >> I've expressed this as a depth rather than as a height to be >> consistent with 'sea_floor_depth_below_sea_level' and so we don't >> end up with different terms for the same quantity depending upon >> whether one is looking upwards or downwards. >> >> Cheers, Roy. >> >> -----Original Message----- >> From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu >> ] On Behalf Of Jeff deLaBeaujardiere >> Sent: 26 January 2010 22:22 >> To: cf-metadata at cgd.ucar.edu >> Cc: Mike Garcia >> Subject: [CF-metadata] seeking CF name for total water column height >> >> Hello- >> >> I am a new subscriber. We are hoping to adopt CF names wherever >> possible in the context of the Integrated Ocean Observing System >> (IOOS) Sensor Observation Services (SOS). Not all phenomena we >> measure have immediately apparent CF names, however. We are using >> this URL as a reference: >> http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/current/cf-standard-name-table.html >> >> The first example is total water column height as derived from a >> bottom pressure recorder associated with a tsunami warning buoy. >> This is not sea_surface_height_above_reference_ellipsoid or >> _above_sea_level. It might be height_above_sea_floor but we're not >> really sure what that refers to (height of what?). >> >> Is there a standard name present or planned that is equivalent to >> total_water_column_height? >> >> Thanks for any information, >> Jeff DLB >> >> -- >> Jeff de La Beaujardi?re, PhD >> Senior Systems Architect, Data Integration Framework >> Integrated Ocean Observing System (IOOS) Program Office >> National Oceanic and Atmospheric Administration >> 1100 Wayne Ave #1225, Silver Spring MD 20910 USA >> +1 301 427 2427 >> Jeff.deLaBeaujardiere at noaa.gov >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> -- >> This message (and any attachments) is for the recipient only. NERC >> is subject to the Freedom of Information Act 2000 and the contents >> of this email and any reply you make may be disclosed by NERC unless >> it is exempt from release under the Act. Any material supplied to >> NERC may be stored in an electronic records management system. >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > -------------- > I have my new work email address: jgraybeal at ucsd.edu > -------------- > > John Graybeal > phone: 858-534-2162 > System Development Manager > Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org > Marine Metadata Interoperability Project: http://marinemetadata.org > -- > This message (and any attachments) is for the recipient only. NERC > is subject to the Freedom of Information Act 2000 and the contents > of this email and any reply you make may be disclosed by NERC unless > it is exempt from release under the Act. Any material supplied to > NERC may be stored in an electronic records management system. > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -------------- I have my new work email address: jgraybeal at ucsd.edu -------------- John Graybeal phone: 858-534-2162 System Development Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org From rkl at bodc.ac.uk Thu Jan 28 01:32:24 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Thu, 28 Jan 2010 08:32:24 +0000 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <6DAEEA19-0CB8-4A81-8D4C-E99495BBA2D2@mindspring.com> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk>, <5F29FB36-8366-4976-80FE-5F78B105E2DF@mindspring.com> <40829B0E077C1145A6DE44D39B3830A90886AB722D@nerckwmb1.ad.nerc.ac.uk> <6DAEEA19-0CB8-4A81-8D4C-E99495BBA2D2@mindspring.com> Message-ID: <40829B0E077C1145A6DE44D39B3830A90886F5A660@nerckwmb1.ad.nerc.ac.uk> Hi John, Ah, I thought you were objecting to having different names for different averaging intervals. Let's see if I can improve the definition. There are three varieties of water depth (sea_floor_depth_below_sea_surface) that I've encountered. 1 Instantaneous measurements collected at high frequency over a short time interval designed to quantify waves. These are normally reduced to a raft of wave statistics by processing on board the instrument and I've certainly never seen them as a stream and so didn't see any point in setting up a separate standard name. 2 Measurements averaged over a sampling interval (an hour or shorter) to filter out variance caused by normal waves but not tide (or unusually long period waves). This is Jeff's stream, and also pretty much what is measured by an echosounder mounted on all but the smallest ship. 3 Long-term averages or nominal calculations by models that filter out (or ignore in the case of models) the variances caused by waves and tide - which are covered by the existing Standard Name 'sea_floor_depth_below_mean_sea_level'. How about 'The vertical distance between the sea surface and the seabed as measured at a given point in space including the variance caused by tides and possibly waves'? Or can you do better? Cheers, Roy. -----Original Message----- From: John Graybeal [mailto:jbgraybeal at mindspring.com] Sent: 27 January 2010 23:01 To: Lowry, Roy K Cc: cf-metadata at cgd.ucar.edu; Mike Garcia Subject: Re: [CF-metadata] seeking CF name for total water column height I have no concern about whether this stream needs labeling. My concern is whether you are defining something in the definition which is in no way described by the label, and which will prevent that label being used for other variables in other streams. Put another way, what should the models that calculate the nominal sea_floor_depth_below_sea_surface -- or an averaged value longer than 1 hour -- call their values? John On Jan 27, 2010, at 12:54, Lowry, Roy K wrote: > Hi John, > > Simple pragmatism. It's what a BPR data stream tends to contain and > so it needs labelling. > > Cheers, Roy. > > ________________________________________ > From: John Graybeal [jbgraybeal at mindspring.com] > Sent: 27 January 2010 16:41 > To: Lowry, Roy K > Cc: Jeff deLaBeaujardiere; cf-metadata at cgd.ucar.edu; Mike Garcia > Subject: Re: [CF-metadata] seeking CF name for total water column > height > > Any particular reason that you are biased for this name representing > only a short-term value? Seems to me there is equally the need for a > (measured or modeled) value that would be defined exactly the same > way, but without the time qualifiers. > > In general, when CF has a measured observable, the name makes no > statement about whether the variable has been measured > instantaneously, or for 1 hour, or for one month. It's time-neutral. > This has several advantages. > > I suggest either the same principle be applied here, or that the > possibility of the longer-time-frame name be accommodated by adding a > qualifier to the name associated with this definition. > > John > > > On Jan 27, 2010, at 00:58, Lowry, Roy K wrote: > >> Dear All, >> >> I think a new Standard Name 'sea_floor_depth_below_sea_surface' is >> what's needed here. My definition for this would be 'The vertical >> distance between the sea surface and the seabed at a given point in >> space and at a given instant in time or averaged over a time >> interval that is significantly less than a tidal cycle (1 hour or >> less).' This may seem complicated, but is needed to cover BPRs which >> do some averaging to smooth out waves. My take on >> 'height_above_sea_floor' would be as the z co-ordinate for something >> inside a water body. >> >> May be worth pointing out to Jeff that there is already >> 'sea_water_pressure_at_sea_floor' for BPR data that haven't been >> converted to depth. >> >> I've expressed this as a depth rather than as a height to be >> consistent with 'sea_floor_depth_below_sea_level' and so we don't >> end up with different terms for the same quantity depending upon >> whether one is looking upwards or downwards. >> >> Cheers, Roy. >> >> -----Original Message----- >> From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu >> ] On Behalf Of Jeff deLaBeaujardiere >> Sent: 26 January 2010 22:22 >> To: cf-metadata at cgd.ucar.edu >> Cc: Mike Garcia >> Subject: [CF-metadata] seeking CF name for total water column height >> >> Hello- >> >> I am a new subscriber. We are hoping to adopt CF names wherever >> possible in the context of the Integrated Ocean Observing System >> (IOOS) Sensor Observation Services (SOS). Not all phenomena we >> measure have immediately apparent CF names, however. We are using >> this URL as a reference: >> http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/current/cf-standard-name-table.html >> >> The first example is total water column height as derived from a >> bottom pressure recorder associated with a tsunami warning buoy. >> This is not sea_surface_height_above_reference_ellipsoid or >> _above_sea_level. It might be height_above_sea_floor but we're not >> really sure what that refers to (height of what?). >> >> Is there a standard name present or planned that is equivalent to >> total_water_column_height? >> >> Thanks for any information, >> Jeff DLB >> >> -- >> Jeff de La Beaujardi?re, PhD >> Senior Systems Architect, Data Integration Framework >> Integrated Ocean Observing System (IOOS) Program Office >> National Oceanic and Atmospheric Administration >> 1100 Wayne Ave #1225, Silver Spring MD 20910 USA >> +1 301 427 2427 >> Jeff.deLaBeaujardiere at noaa.gov >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> -- >> This message (and any attachments) is for the recipient only. NERC >> is subject to the Freedom of Information Act 2000 and the contents >> of this email and any reply you make may be disclosed by NERC unless >> it is exempt from release under the Act. Any material supplied to >> NERC may be stored in an electronic records management system. >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > -------------- > I have my new work email address: jgraybeal at ucsd.edu > -------------- > > John Graybeal > phone: 858-534-2162 > System Development Manager > Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org > Marine Metadata Interoperability Project: http://marinemetadata.org > -- > This message (and any attachments) is for the recipient only. NERC > is subject to the Freedom of Information Act 2000 and the contents > of this email and any reply you make may be disclosed by NERC unless > it is exempt from release under the Act. Any material supplied to > NERC may be stored in an electronic records management system. > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -------------- I have my new work email address: jgraybeal at ucsd.edu -------------- John Graybeal phone: 858-534-2162 System Development Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From Jeff.deLaBeaujardiere at noaa.gov Thu Jan 28 07:05:30 2010 From: Jeff.deLaBeaujardiere at noaa.gov (Jeff deLaBeaujardiere) Date: Thu, 28 Jan 2010 09:05:30 -0500 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <40829B0E077C1145A6DE44D39B3830A90886F5A660@nerckwmb1.ad.nerc.ac.uk> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <5F29FB36-8366-4976-80FE-5F78B105E2DF@mindspring.com> <40829B0E077C1145A6DE44D39B3830A90886AB722D@nerckwmb1.ad.nerc.ac.uk> <6DAEEA19-0CB8-4A81-8D4C-E99495BBA2D2@mindspring.com> <40829B0E077C1145A6DE44D39B3830A90886F5A660@nerckwmb1.ad.nerc.ac.uk> Message-ID: <4B6199AA.0@noaa.gov> I should mention that there are other types of water level measurements for which we will want names. These are instruments such as tide gauges that measure water relative to a reference datum (such as mean lower low water, or highest astronomical tide), or stream gauges that measure relative to the station itself but not a formal datum. I spoke about this yesterday afternoon with some water-level experts at NOAA CO-OPS, and we felt that three new CF names like the following might suffice: sea_floor_depth_below_sea_surface[*] water_level_with_reference datum (or "above" instead of "with") water_level_without_reference datum [*] Looking at this one again, I wonder whether sea_surface_height_above_sea_floor would be more appropriate. NDBC had suggested total_water_column_height. -Jeff DLB Lowry, Roy K wrote: > Hi John, > > Ah, I thought you were objecting to having different names for different averaging intervals. Let's see if I can improve the definition. > > There are three varieties of water depth (sea_floor_depth_below_sea_surface) that I've encountered. > > 1 Instantaneous measurements collected at high frequency over a short time interval designed to quantify waves. These are normally reduced to a raft of wave statistics by processing on board the instrument and I've certainly never seen them as a stream and so didn't see any point in setting up a separate standard name. > > 2 Measurements averaged over a sampling interval (an hour or shorter) to filter out variance caused by normal waves but not tide (or unusually long period waves). This is Jeff's stream, and also pretty much what is measured by an echosounder mounted on all but the smallest ship. > > 3 Long-term averages or nominal calculations by models that filter out (or ignore in the case of models) the variances caused by waves and tide - which are covered by the existing Standard Name 'sea_floor_depth_below_mean_sea_level'. > > How about 'The vertical distance between the sea surface and the seabed as measured at a given point in space including the variance caused by tides and possibly waves'? Or can you do better? > > Cheers, Roy. > > -----Original Message----- > From: John Graybeal [mailto:jbgraybeal at mindspring.com] > Sent: 27 January 2010 23:01 > To: Lowry, Roy K > Cc: cf-metadata at cgd.ucar.edu; Mike Garcia > Subject: Re: [CF-metadata] seeking CF name for total water column height > > I have no concern about whether this stream needs labeling. My concern > is whether you are defining something in the definition which is in no > way described by the label, and which will prevent that label being > used for other variables in other streams. > > Put another way, what should the models that calculate the nominal > sea_floor_depth_below_sea_surface -- or an averaged value longer than > 1 hour -- call their values? > > John > > > On Jan 27, 2010, at 12:54, Lowry, Roy K wrote: > >> Hi John, >> >> Simple pragmatism. It's what a BPR data stream tends to contain and >> so it needs labelling. >> >> Cheers, Roy. >> >> ________________________________________ >> From: John Graybeal [jbgraybeal at mindspring.com] >> Sent: 27 January 2010 16:41 >> To: Lowry, Roy K >> Cc: Jeff deLaBeaujardiere; cf-metadata at cgd.ucar.edu; Mike Garcia >> Subject: Re: [CF-metadata] seeking CF name for total water column >> height >> >> Any particular reason that you are biased for this name representing >> only a short-term value? Seems to me there is equally the need for a >> (measured or modeled) value that would be defined exactly the same >> way, but without the time qualifiers. >> >> In general, when CF has a measured observable, the name makes no >> statement about whether the variable has been measured >> instantaneously, or for 1 hour, or for one month. It's time-neutral. >> This has several advantages. >> >> I suggest either the same principle be applied here, or that the >> possibility of the longer-time-frame name be accommodated by adding a >> qualifier to the name associated with this definition. >> >> John >> >> >> On Jan 27, 2010, at 00:58, Lowry, Roy K wrote: >> >>> Dear All, >>> >>> I think a new Standard Name 'sea_floor_depth_below_sea_surface' is >>> what's needed here. My definition for this would be 'The vertical >>> distance between the sea surface and the seabed at a given point in >>> space and at a given instant in time or averaged over a time >>> interval that is significantly less than a tidal cycle (1 hour or >>> less).' This may seem complicated, but is needed to cover BPRs which >>> do some averaging to smooth out waves. My take on >>> 'height_above_sea_floor' would be as the z co-ordinate for something >>> inside a water body. >>> >>> May be worth pointing out to Jeff that there is already >>> 'sea_water_pressure_at_sea_floor' for BPR data that haven't been >>> converted to depth. >>> >>> I've expressed this as a depth rather than as a height to be >>> consistent with 'sea_floor_depth_below_sea_level' and so we don't >>> end up with different terms for the same quantity depending upon >>> whether one is looking upwards or downwards. >>> >>> Cheers, Roy. >>> >>> -----Original Message----- >>> From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu >>> ] On Behalf Of Jeff deLaBeaujardiere >>> Sent: 26 January 2010 22:22 >>> To: cf-metadata at cgd.ucar.edu >>> Cc: Mike Garcia >>> Subject: [CF-metadata] seeking CF name for total water column height >>> >>> Hello- >>> >>> I am a new subscriber. We are hoping to adopt CF names wherever >>> possible in the context of the Integrated Ocean Observing System >>> (IOOS) Sensor Observation Services (SOS). Not all phenomena we >>> measure have immediately apparent CF names, however. We are using >>> this URL as a reference: >>> http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/current/cf-standard-name-table.html >>> >>> The first example is total water column height as derived from a >>> bottom pressure recorder associated with a tsunami warning buoy. >>> This is not sea_surface_height_above_reference_ellipsoid or >>> _above_sea_level. It might be height_above_sea_floor but we're not >>> really sure what that refers to (height of what?). >>> >>> Is there a standard name present or planned that is equivalent to >>> total_water_column_height? >>> >>> Thanks for any information, >>> Jeff DLB >>> >>> -- >>> Jeff de La Beaujardi?re, PhD >>> Senior Systems Architect, Data Integration Framework >>> Integrated Ocean Observing System (IOOS) Program Office >>> National Oceanic and Atmospheric Administration >>> 1100 Wayne Ave #1225, Silver Spring MD 20910 USA >>> +1 301 427 2427 >>> Jeff.deLaBeaujardiere at noaa.gov >>> _______________________________________________ >>> CF-metadata mailing list >>> CF-metadata at cgd.ucar.edu >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>> >>> -- >>> This message (and any attachments) is for the recipient only. NERC >>> is subject to the Freedom of Information Act 2000 and the contents >>> of this email and any reply you make may be disclosed by NERC unless >>> it is exempt from release under the Act. Any material supplied to >>> NERC may be stored in an electronic records management system. >>> >>> _______________________________________________ >>> CF-metadata mailing list >>> CF-metadata at cgd.ucar.edu >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> -------------- >> I have my new work email address: jgraybeal at ucsd.edu >> -------------- >> >> John Graybeal >> phone: 858-534-2162 >> System Development Manager >> Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org >> Marine Metadata Interoperability Project: http://marinemetadata.org >> -- >> This message (and any attachments) is for the recipient only. NERC >> is subject to the Freedom of Information Act 2000 and the contents >> of this email and any reply you make may be disclosed by NERC unless >> it is exempt from release under the Act. Any material supplied to >> NERC may be stored in an electronic records management system. >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > -------------- > I have my new work email address: jgraybeal at ucsd.edu > -------------- > > John Graybeal > phone: 858-534-2162 > System Development Manager > Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org > Marine Metadata Interoperability Project: http://marinemetadata.org > > -- Jeff de La Beaujardi?re, PhD Senior Systems Architect, Data Integration Framework Integrated Ocean Observing System (IOOS) Program Office National Oceanic and Atmospheric Administration 1100 Wayne Ave #1225, Silver Spring MD 20910 USA +1 301 427 2427 Jeff.deLaBeaujardiere at noaa.gov From rkl at bodc.ac.uk Thu Jan 28 08:12:25 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Thu, 28 Jan 2010 15:12:25 +0000 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <4B6199AA.0@noaa.gov> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <5F29FB36-8366-4976-80FE-5F78B105E2DF@mindspring.com> <40829B0E077C1145A6DE44D39B3830A90886AB722D@nerckwmb1.ad.nerc.ac.uk> <6DAEEA19-0CB8-4A81-8D4C-E99495BBA2D2@mindspring.com> <40829B0E077C1145A6DE44D39B3830A90886F5A660@nerckwmb1.ad.nerc.ac.uk> <4B6199AA.0@noaa.gov> Message-ID: <40829B0E077C1145A6DE44D39B3830A9088705F779@nerckwmb1.ad.nerc.ac.uk> Hi Jeff, My motives for 'looking down' rather than 'looking up' were that we already had a 'sea_floor_depth_below_mean_sea_level' and established practice with CF name development has been to be as consistent as possible with name structure. Jonathan Gregory has led this development in the past - let's see what his take is on the best name syntax. The issue of encoding sea level measurements relative to reference datums other than MSL has been discussed on the list at length previously and I don't recall our ever reaching a satisfactory resolution. It might be worth your having a trawl around the archives or waiting for somebody with a better memory than me to summarise where the discussion had reached. Incidentally, I have seen the 'datum' for streams without a datum described as 'tide gauge zero', which often has a physical manifestation such as a metal peg driven into a wall. Cheers, Roy. -----Original Message----- From: Jeff deLaBeaujardiere [mailto:Jeff.deLaBeaujardiere at noaa.gov] Sent: 28 January 2010 14:06 To: Lowry, Roy K Cc: John Graybeal; cf-metadata at cgd.ucar.edu; Mike Garcia Subject: Re: [CF-metadata] seeking CF name for total water column height I should mention that there are other types of water level measurements for which we will want names. These are instruments such as tide gauges that measure water relative to a reference datum (such as mean lower low water, or highest astronomical tide), or stream gauges that measure relative to the station itself but not a formal datum. I spoke about this yesterday afternoon with some water-level experts at NOAA CO-OPS, and we felt that three new CF names like the following might suffice: sea_floor_depth_below_sea_surface[*] water_level_with_reference datum (or "above" instead of "with") water_level_without_reference datum [*] Looking at this one again, I wonder whether sea_surface_height_above_sea_floor would be more appropriate. NDBC had suggested total_water_column_height. -Jeff DLB Lowry, Roy K wrote: > Hi John, > > Ah, I thought you were objecting to having different names for different averaging intervals. Let's see if I can improve the definition. > > There are three varieties of water depth (sea_floor_depth_below_sea_surface) that I've encountered. > > 1 Instantaneous measurements collected at high frequency over a short time interval designed to quantify waves. These are normally reduced to a raft of wave statistics by processing on board the instrument and I've certainly never seen them as a stream and so didn't see any point in setting up a separate standard name. > > 2 Measurements averaged over a sampling interval (an hour or shorter) to filter out variance caused by normal waves but not tide (or unusually long period waves). This is Jeff's stream, and also pretty much what is measured by an echosounder mounted on all but the smallest ship. > > 3 Long-term averages or nominal calculations by models that filter out (or ignore in the case of models) the variances caused by waves and tide - which are covered by the existing Standard Name 'sea_floor_depth_below_mean_sea_level'. > > How about 'The vertical distance between the sea surface and the seabed as measured at a given point in space including the variance caused by tides and possibly waves'? Or can you do better? > > Cheers, Roy. > > -----Original Message----- > From: John Graybeal [mailto:jbgraybeal at mindspring.com] > Sent: 27 January 2010 23:01 > To: Lowry, Roy K > Cc: cf-metadata at cgd.ucar.edu; Mike Garcia > Subject: Re: [CF-metadata] seeking CF name for total water column height > > I have no concern about whether this stream needs labeling. My concern > is whether you are defining something in the definition which is in no > way described by the label, and which will prevent that label being > used for other variables in other streams. > > Put another way, what should the models that calculate the nominal > sea_floor_depth_below_sea_surface -- or an averaged value longer than > 1 hour -- call their values? > > John > > > On Jan 27, 2010, at 12:54, Lowry, Roy K wrote: > >> Hi John, >> >> Simple pragmatism. It's what a BPR data stream tends to contain and >> so it needs labelling. >> >> Cheers, Roy. >> >> ________________________________________ >> From: John Graybeal [jbgraybeal at mindspring.com] >> Sent: 27 January 2010 16:41 >> To: Lowry, Roy K >> Cc: Jeff deLaBeaujardiere; cf-metadata at cgd.ucar.edu; Mike Garcia >> Subject: Re: [CF-metadata] seeking CF name for total water column >> height >> >> Any particular reason that you are biased for this name representing >> only a short-term value? Seems to me there is equally the need for a >> (measured or modeled) value that would be defined exactly the same >> way, but without the time qualifiers. >> >> In general, when CF has a measured observable, the name makes no >> statement about whether the variable has been measured >> instantaneously, or for 1 hour, or for one month. It's time-neutral. >> This has several advantages. >> >> I suggest either the same principle be applied here, or that the >> possibility of the longer-time-frame name be accommodated by adding a >> qualifier to the name associated with this definition. >> >> John >> >> >> On Jan 27, 2010, at 00:58, Lowry, Roy K wrote: >> >>> Dear All, >>> >>> I think a new Standard Name 'sea_floor_depth_below_sea_surface' is >>> what's needed here. My definition for this would be 'The vertical >>> distance between the sea surface and the seabed at a given point in >>> space and at a given instant in time or averaged over a time >>> interval that is significantly less than a tidal cycle (1 hour or >>> less).' This may seem complicated, but is needed to cover BPRs which >>> do some averaging to smooth out waves. My take on >>> 'height_above_sea_floor' would be as the z co-ordinate for something >>> inside a water body. >>> >>> May be worth pointing out to Jeff that there is already >>> 'sea_water_pressure_at_sea_floor' for BPR data that haven't been >>> converted to depth. >>> >>> I've expressed this as a depth rather than as a height to be >>> consistent with 'sea_floor_depth_below_sea_level' and so we don't >>> end up with different terms for the same quantity depending upon >>> whether one is looking upwards or downwards. >>> >>> Cheers, Roy. >>> >>> -----Original Message----- >>> From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu >>> ] On Behalf Of Jeff deLaBeaujardiere >>> Sent: 26 January 2010 22:22 >>> To: cf-metadata at cgd.ucar.edu >>> Cc: Mike Garcia >>> Subject: [CF-metadata] seeking CF name for total water column height >>> >>> Hello- >>> >>> I am a new subscriber. We are hoping to adopt CF names wherever >>> possible in the context of the Integrated Ocean Observing System >>> (IOOS) Sensor Observation Services (SOS). Not all phenomena we >>> measure have immediately apparent CF names, however. We are using >>> this URL as a reference: >>> http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/current/cf-standard-name-table.html >>> >>> The first example is total water column height as derived from a >>> bottom pressure recorder associated with a tsunami warning buoy. >>> This is not sea_surface_height_above_reference_ellipsoid or >>> _above_sea_level. It might be height_above_sea_floor but we're not >>> really sure what that refers to (height of what?). >>> >>> Is there a standard name present or planned that is equivalent to >>> total_water_column_height? >>> >>> Thanks for any information, >>> Jeff DLB >>> >>> -- >>> Jeff de La Beaujardi?re, PhD >>> Senior Systems Architect, Data Integration Framework >>> Integrated Ocean Observing System (IOOS) Program Office >>> National Oceanic and Atmospheric Administration >>> 1100 Wayne Ave #1225, Silver Spring MD 20910 USA >>> +1 301 427 2427 >>> Jeff.deLaBeaujardiere at noaa.gov >>> _______________________________________________ >>> CF-metadata mailing list >>> CF-metadata at cgd.ucar.edu >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>> >>> -- >>> This message (and any attachments) is for the recipient only. NERC >>> is subject to the Freedom of Information Act 2000 and the contents >>> of this email and any reply you make may be disclosed by NERC unless >>> it is exempt from release under the Act. Any material supplied to >>> NERC may be stored in an electronic records management system. >>> >>> _______________________________________________ >>> CF-metadata mailing list >>> CF-metadata at cgd.ucar.edu >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> -------------- >> I have my new work email address: jgraybeal at ucsd.edu >> -------------- >> >> John Graybeal >> phone: 858-534-2162 >> System Development Manager >> Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org >> Marine Metadata Interoperability Project: http://marinemetadata.org >> -- >> This message (and any attachments) is for the recipient only. NERC >> is subject to the Freedom of Information Act 2000 and the contents >> of this email and any reply you make may be disclosed by NERC unless >> it is exempt from release under the Act. Any material supplied to >> NERC may be stored in an electronic records management system. >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > -------------- > I have my new work email address: jgraybeal at ucsd.edu > -------------- > > John Graybeal > phone: 858-534-2162 > System Development Manager > Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org > Marine Metadata Interoperability Project: http://marinemetadata.org > > -- Jeff de La Beaujardi?re, PhD Senior Systems Architect, Data Integration Framework Integrated Ocean Observing System (IOOS) Program Office National Oceanic and Atmospheric Administration 1100 Wayne Ave #1225, Silver Spring MD 20910 USA +1 301 427 2427 Jeff.deLaBeaujardiere at noaa.gov -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From olauret at cls.fr Thu Jan 28 10:28:31 2010 From: olauret at cls.fr (olivier lauret) Date: Thu, 28 Jan 2010 18:28:31 +0100 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <40829B0E077C1145A6DE44D39B3830A9088705F779@nerckwmb1.ad.nerc.ac.uk> References: <4B5F6AF2.9030301@noaa.gov><40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk><5F29FB36-8366-4976-80FE-5F78B105E2DF@mindspring.com><40829B0E077C1145A6DE44D39B3830A90886AB722D@nerckwmb1.ad.nerc.ac.uk><6DAEEA19-0CB8-4A81-8D4C-E99495BBA2D2@mindspring.com><40829B0E077C1145A6DE44D39B3830A90886F5A660@nerckwmb1.ad.nerc.ac.uk><4B6199AA.0@noaa.gov> <40829B0E077C1145A6DE44D39B3830A9088705F779@nerckwmb1.ad.nerc.ac.uk> Message-ID: <1240F43731C2EB4F8CC9BF70D233B5110172ED83@SRV-XCHANGE-2K3.pc.cls.fr> Hi, I've been involved in the other "sea_surface_above" definitions, it was at that time from a sea-level-from-space (radar altimetry) only point of view. Anyway, I've the feeling that you are suggesting Roy reminds more something close to bathymetry. Considering that bathymetry and sea level are very close topics, it's just a question of point of view.. Do you think it would be possible to use both 'sea_floor_depth_below_sea_surface' and 'sea_surface_height_above_sea_floor' with some alias? Only a compromise.. Cheers -----Message d'origine----- De?: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] De la part de Lowry, Roy K Envoy??: jeudi 28 janvier 2010 16:12 ??: Jeff deLaBeaujardiere Cc?: John Graybeal; cf-metadata at cgd.ucar.edu; Mike Garcia Objet?: Re: [CF-metadata] seeking CF name for total water column height Hi Jeff, My motives for 'looking down' rather than 'looking up' were that we already had a 'sea_floor_depth_below_mean_sea_level' and established practice with CF name development has been to be as consistent as possible with name structure. Jonathan Gregory has led this development in the past - let's see what his take is on the best name syntax. The issue of encoding sea level measurements relative to reference datums other than MSL has been discussed on the list at length previously and I don't recall our ever reaching a satisfactory resolution. It might be worth your having a trawl around the archives or waiting for somebody with a better memory than me to summarise where the discussion had reached. Incidentally, I have seen the 'datum' for streams without a datum described as 'tide gauge zero', which often has a physical manifestation such as a metal peg driven into a wall. Cheers, Roy. -----Original Message----- From: Jeff deLaBeaujardiere [mailto:Jeff.deLaBeaujardiere at noaa.gov] Sent: 28 January 2010 14:06 To: Lowry, Roy K Cc: John Graybeal; cf-metadata at cgd.ucar.edu; Mike Garcia Subject: Re: [CF-metadata] seeking CF name for total water column height I should mention that there are other types of water level measurements for which we will want names. These are instruments such as tide gauges that measure water relative to a reference datum (such as mean lower low water, or highest astronomical tide), or stream gauges that measure relative to the station itself but not a formal datum. I spoke about this yesterday afternoon with some water-level experts at NOAA CO-OPS, and we felt that three new CF names like the following might suffice: sea_floor_depth_below_sea_surface[*] water_level_with_reference datum (or "above" instead of "with") water_level_without_reference datum [*] Looking at this one again, I wonder whether sea_surface_height_above_sea_floor would be more appropriate. NDBC had suggested total_water_column_height. -Jeff DLB Lowry, Roy K wrote: > Hi John, > > Ah, I thought you were objecting to having different names for different averaging intervals. Let's see if I can improve the definition. > > There are three varieties of water depth (sea_floor_depth_below_sea_surface) that I've encountered. > > 1 Instantaneous measurements collected at high frequency over a short time interval designed to quantify waves. These are normally reduced to a raft of wave statistics by processing on board the instrument and I've certainly never seen them as a stream and so didn't see any point in setting up a separate standard name. > > 2 Measurements averaged over a sampling interval (an hour or shorter) to filter out variance caused by normal waves but not tide (or unusually long period waves). This is Jeff's stream, and also pretty much what is measured by an echosounder mounted on all but the smallest ship. > > 3 Long-term averages or nominal calculations by models that filter out (or ignore in the case of models) the variances caused by waves and tide - which are covered by the existing Standard Name 'sea_floor_depth_below_mean_sea_level'. > > How about 'The vertical distance between the sea surface and the seabed as measured at a given point in space including the variance caused by tides and possibly waves'? Or can you do better? > > Cheers, Roy. > > -----Original Message----- > From: John Graybeal [mailto:jbgraybeal at mindspring.com] > Sent: 27 January 2010 23:01 > To: Lowry, Roy K > Cc: cf-metadata at cgd.ucar.edu; Mike Garcia > Subject: Re: [CF-metadata] seeking CF name for total water column height > > I have no concern about whether this stream needs labeling. My concern > is whether you are defining something in the definition which is in no > way described by the label, and which will prevent that label being > used for other variables in other streams. > > Put another way, what should the models that calculate the nominal > sea_floor_depth_below_sea_surface -- or an averaged value longer than > 1 hour -- call their values? > > John > > > On Jan 27, 2010, at 12:54, Lowry, Roy K wrote: > >> Hi John, >> >> Simple pragmatism. It's what a BPR data stream tends to contain and >> so it needs labelling. >> >> Cheers, Roy. >> >> ________________________________________ >> From: John Graybeal [jbgraybeal at mindspring.com] >> Sent: 27 January 2010 16:41 >> To: Lowry, Roy K >> Cc: Jeff deLaBeaujardiere; cf-metadata at cgd.ucar.edu; Mike Garcia >> Subject: Re: [CF-metadata] seeking CF name for total water column >> height >> >> Any particular reason that you are biased for this name representing >> only a short-term value? Seems to me there is equally the need for a >> (measured or modeled) value that would be defined exactly the same >> way, but without the time qualifiers. >> >> In general, when CF has a measured observable, the name makes no >> statement about whether the variable has been measured >> instantaneously, or for 1 hour, or for one month. It's time-neutral. >> This has several advantages. >> >> I suggest either the same principle be applied here, or that the >> possibility of the longer-time-frame name be accommodated by adding a >> qualifier to the name associated with this definition. >> >> John >> >> >> On Jan 27, 2010, at 00:58, Lowry, Roy K wrote: >> >>> Dear All, >>> >>> I think a new Standard Name 'sea_floor_depth_below_sea_surface' is >>> what's needed here. My definition for this would be 'The vertical >>> distance between the sea surface and the seabed at a given point in >>> space and at a given instant in time or averaged over a time >>> interval that is significantly less than a tidal cycle (1 hour or >>> less).' This may seem complicated, but is needed to cover BPRs which >>> do some averaging to smooth out waves. My take on >>> 'height_above_sea_floor' would be as the z co-ordinate for something >>> inside a water body. >>> >>> May be worth pointing out to Jeff that there is already >>> 'sea_water_pressure_at_sea_floor' for BPR data that haven't been >>> converted to depth. >>> >>> I've expressed this as a depth rather than as a height to be >>> consistent with 'sea_floor_depth_below_sea_level' and so we don't >>> end up with different terms for the same quantity depending upon >>> whether one is looking upwards or downwards. >>> >>> Cheers, Roy. >>> >>> -----Original Message----- >>> From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu >>> ] On Behalf Of Jeff deLaBeaujardiere >>> Sent: 26 January 2010 22:22 >>> To: cf-metadata at cgd.ucar.edu >>> Cc: Mike Garcia >>> Subject: [CF-metadata] seeking CF name for total water column height >>> >>> Hello- >>> >>> I am a new subscriber. We are hoping to adopt CF names wherever >>> possible in the context of the Integrated Ocean Observing System >>> (IOOS) Sensor Observation Services (SOS). Not all phenomena we >>> measure have immediately apparent CF names, however. We are using >>> this URL as a reference: >>> http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/current/cf-standard-name-table.html >>> >>> The first example is total water column height as derived from a >>> bottom pressure recorder associated with a tsunami warning buoy. >>> This is not sea_surface_height_above_reference_ellipsoid or >>> _above_sea_level. It might be height_above_sea_floor but we're not >>> really sure what that refers to (height of what?). >>> >>> Is there a standard name present or planned that is equivalent to >>> total_water_column_height? >>> >>> Thanks for any information, >>> Jeff DLB >>> >>> -- >>> Jeff de La Beaujardi?re, PhD >>> Senior Systems Architect, Data Integration Framework >>> Integrated Ocean Observing System (IOOS) Program Office >>> National Oceanic and Atmospheric Administration >>> 1100 Wayne Ave #1225, Silver Spring MD 20910 USA >>> +1 301 427 2427 >>> Jeff.deLaBeaujardiere at noaa.gov >>> _______________________________________________ >>> CF-metadata mailing list >>> CF-metadata at cgd.ucar.edu >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>> >>> -- >>> This message (and any attachments) is for the recipient only. NERC >>> is subject to the Freedom of Information Act 2000 and the contents >>> of this email and any reply you make may be disclosed by NERC unless >>> it is exempt from release under the Act. Any material supplied to >>> NERC may be stored in an electronic records management system. >>> >>> _______________________________________________ >>> CF-metadata mailing list >>> CF-metadata at cgd.ucar.edu >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> -------------- >> I have my new work email address: jgraybeal at ucsd.edu >> -------------- >> >> John Graybeal >> phone: 858-534-2162 >> System Development Manager >> Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org >> Marine Metadata Interoperability Project: http://marinemetadata.org >> -- >> This message (and any attachments) is for the recipient only. NERC >> is subject to the Freedom of Information Act 2000 and the contents >> of this email and any reply you make may be disclosed by NERC unless >> it is exempt from release under the Act. Any material supplied to >> NERC may be stored in an electronic records management system. >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > -------------- > I have my new work email address: jgraybeal at ucsd.edu > -------------- > > John Graybeal > phone: 858-534-2162 > System Development Manager > Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org > Marine Metadata Interoperability Project: http://marinemetadata.org > > -- Jeff de La Beaujardi?re, PhD Senior Systems Architect, Data Integration Framework Integrated Ocean Observing System (IOOS) Program Office National Oceanic and Atmospheric Administration 1100 Wayne Ave #1225, Silver Spring MD 20910 USA +1 301 427 2427 Jeff.deLaBeaujardiere at noaa.gov -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata Cliquez sur l'url suivante https://www.mailcontrol.com/sr/cJeESQ9P7LDTndxI!oX7UtTXwRoU2H8XJLFY6kKd+vWv77NadiSdfn6HhRgAzFL9rkyeQYCEZJ+8ewgPpp7kgg== si ce message est ind?sirable (pourriel). From bryan.lawrence at stfc.ac.uk Fri Jan 29 02:05:52 2010 From: bryan.lawrence at stfc.ac.uk (Bryan Lawrence) Date: Fri, 29 Jan 2010 09:05:52 +0000 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <40829B0E077C1145A6DE44D39B3830A90886AB722D@nerckwmb1.ad.nerc.ac.uk> References: <4B5F6AF2.9030301@noaa.gov> <5F29FB36-8366-4976-80FE-5F78B105E2DF@mindspring.com> <40829B0E077C1145A6DE44D39B3830A90886AB722D@nerckwmb1.ad.nerc.ac.uk> Message-ID: <201001290905.52503.bryan.lawrence@stfc.ac.uk> > In general, when CF has a measured observable, the name makes no > statement about whether the variable has been measured > instantaneously, or for 1 hour, or for one month. It's time-neutral. ... because you can use other cf attributes to say things about time averaging (& intensivity/extensivity etc) implicit in the measurement/simulation ... Bryan -- Bryan Lawrence Director of Environmental Archival and Associated Research (NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC) STFC, Rutherford Appleton Laboratory Phone +44 1235 445012; Fax ... 5848; Web: home.badc.rl.ac.uk/lawrence From t.lavergne at met.no Fri Jan 29 04:11:23 2010 From: t.lavergne at met.no (Thomas Lavergne) Date: Fri, 29 Jan 2010 11:11:23 +0000 (UTC) Subject: [CF-metadata] Questions on cell boundaries In-Reply-To: <1081627932.143233.1264762492504.JavaMail.root@imap1b> Message-ID: <194788541.143429.1264763483929.JavaMail.root@imap1b> Hi everyone, I refer to Chapter 7 on "Data Representative of Cells", 7.1 "Cell Boundaries". The specification of those boundaries seems to biased towards polygonal boundaries (in the case of a 2D surface). This covers certainly most of the needs but what happens if the cell is defined as a disc of radius x km (with center at the coordinate value)? Of course, I can always give 10 to 10,000 vertices that will approximate my disc but it does not sound very neat nor efficient. We would have to somehow move away from listing the 'bounds' and start describing the shape of the cell (disc, ellipse, rectangle, etc...). Note that the concepts of "cell measures" and "cell methods" would still perfectly hold. One example of such a dataset would be one where at each grid location we report the mean/minimum/maximum temperature/pressure recorded by all stations found in a radius of, say, 30 km around the central point. Another example is satellite data in swath projection where each record is associated to a Field Of View, which is often approximated as a an ellipse. Did someone give it a thought already? Cheers, Thomas -- ========================================= Thomas Lavergne Norwegian Meteorological Institute P.O.BOX 43, Blindern, N-0313 OSLO, Norway Phone: (+47) 22963364 Fax: (+47) 22963380 Email: t.lavergne at met.no OSISAF Sea Ice Portal: http://saf.met.no ========================================= From stephen.pascoe at stfc.ac.uk Fri Jan 29 16:56:33 2010 From: stephen.pascoe at stfc.ac.uk (stephen.pascoe at stfc.ac.uk) Date: Fri, 29 Jan 2010 23:56:33 -0000 Subject: [CF-metadata] CF Trac is inaccessible Message-ID: I'm reporting a fault on the CF Trac. It is showing a configuration error: TracError: Unsupported version control system "svn". Check that the Python bindings for "svn" are correctly installed. Regards, Stephen. -- Scanned by iCritical. From stephen.pascoe at stfc.ac.uk Sun Jan 31 15:27:16 2010 From: stephen.pascoe at stfc.ac.uk (stephen.pascoe at stfc.ac.uk) Date: Sun, 31 Jan 2010 22:27:16 -0000 Subject: [CF-metadata] CF Trac is inaccessible References: <55AE4F6513A6DC46A3652D716B7DD7C5BA4A3320E2@NSPEXMBX-A.the-lab.llnl.gov> Message-ID: Thanks Anthony, it appears fine now. S. -----Original Message----- From: Hoang, Anthony T. [mailto:Hoang1 at llnl.gov] Sent: Sun 1/31/2010 10:21 PM To: Pascoe, Stephen (STFC,RAL,SSTD) Cc: cf-metadata at cgd.ucar.edu Subject: RE: [CF-metadata] CF Trac is inaccessible Hello Stephen, Would you try it again? I upgraded our Web server and in the process inadvertently messed up the Trac server. Sorry for any inconvenience this may have caused. Tony -- Scanned by iCritical. From j.m.gregory at reading.ac.uk Tue Feb 2 11:22:55 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 2 Feb 2010 18:22:55 +0000 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <4B604DA3.2030504@noaa.gov> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> Message-ID: <20100202182255.GA19905@met.reading.ac.uk> Dear Jeff and Roy I agree, it is arbitrary whether it is called sea_floor_depth_below_sea_surface or sea_surface_height_above_sea_floor and I agree with Roy that consistency with existing names would suggest the former. It's interesting that this kind of ambiguity hasn't arisen before. What you want to name is the distance between two named surfaces. In other names, we call the vertical distance between two surfaces a "thickness" e.g. ocean_mixed_layer_thickness. That doesn't have an associated "direction" (upward or downward) and so avoids this problem. By that analogy the quantity you want to name might be called thickness_of_ocean but I suspect most people would find that less obvious. What we are aiming at principally is clarity. The procedure for adding names is that Alison Pamment, the manager of standard names, will consider them and add them. She is dealing with CMIP5 names at present, I believe, so it might be a while before she gets to this. If no-one else objects soon or makes an alternative proposal, I'd suggest you use this name on the assumption that it will be added to the stdname table in due course. Best wishes Jonathan From jbgraybeal at mindspring.com Tue Feb 2 11:30:44 2010 From: jbgraybeal at mindspring.com (John Graybeal) Date: Tue, 2 Feb 2010 10:30:44 -0800 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <20100202182255.GA19905@met.reading.ac.uk> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk> Message-ID: <9A767FE6-DD75-4ADB-B098-F8B702938A57@mindspring.com> Perhaps the infamous aliases would be an appropriate technique? I seem to recall that aliases are considered OK in some cases in CF, or am I remembering that incorrectly? I like the idea of 'distance_between_sea_floor_and_sea_surface' myself, rather than 'thickness_of_ocean' (though the latter is elegant too!). But in any case, it would be delightful if the two (three?) alternatives were also present, for searchers. John On Feb 2, 2010, at 10:22, Jonathan Gregory wrote: > Dear Jeff and Roy > > I agree, it is arbitrary whether it is called > sea_floor_depth_below_sea_surface > or > sea_surface_height_above_sea_floor > and I agree with Roy that consistency with existing names would > suggest > the former. > > It's interesting that this kind of ambiguity hasn't arisen before. > What you > want to name is the distance between two named surfaces. In other > names, we > call the vertical distance between two surfaces a "thickness" e.g. > ocean_mixed_layer_thickness. That doesn't have an associated > "direction" > (upward or downward) and so avoids this problem. By that analogy the > quantity > you want to name might be called thickness_of_ocean but I suspect > most people > would find that less obvious. What we are aiming at principally is > clarity. > > The procedure for adding names is that Alison Pamment, the manager > of standard > names, will consider them and add them. She is dealing with CMIP5 > names at > present, I believe, so it might be a while before she gets to this. > If no-one > else objects soon or makes an alternative proposal, I'd suggest you > use this > name on the assumption that it will be added to the stdname table in > due > course. > > Best wishes > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From j.m.gregory at reading.ac.uk Tue Feb 2 11:43:18 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 2 Feb 2010 18:43:18 +0000 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <9A767FE6-DD75-4ADB-B098-F8B702938A57@mindspring.com> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk> <9A767FE6-DD75-4ADB-B098-F8B702938A57@mindspring.com> Message-ID: <20100202184318.GE19905@met.reading.ac.uk> Dear John Yes, good suggestion, we could adopt a new pattern vertical_distance_between_X and_Y for cases where "thickness" sounds peculiar. Aliases are really intended for cases where we make mistakes or change our minds, rather than to provide synonyms deliberately. We've preferred to force ourselves to agree where possible on a minimal vocabulary. Best wishes Jonathan From rkl at bodc.ac.uk Tue Feb 2 14:23:49 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Tue, 2 Feb 2010 21:23:49 +0000 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <20100202184318.GE19905@met.reading.ac.uk> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk> <9A767FE6-DD75-4ADB-B098-F8B702938A57@mindspring.com>, <20100202184318.GE19905@met.reading.ac.uk> Message-ID: <40829B0E077C1145A6DE44D39B3830A90886AB7254@nerckwmb1.ad.nerc.ac.uk> Dear Jonathan, The alias structure has developed into a deprecation mechanism and some of the more recent corrections have changed the meanings of the terms, so that the term and its alias are no longer synonyms. Using the alias mechanism to establish synonyms between undeprecated terms invites confusion - it's like building RDF triples with no predicate. Should the decision be taken to develop the Standard Names into a semantic network (which has been advocated at GO-ESSP meetings) then a more robust mechanism for specifying the relationship between terms is needed. I can support this, but the infrastructure on the CF site would need a minor upgrade. Cheers, Roy. ________________________________________ From: cf-metadata-bounces at cgd.ucar.edu [cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory [j.m.gregory at reading.ac.uk] Sent: 02 February 2010 18:43 To: John Graybeal Cc: CF Metadata List Subject: Re: [CF-metadata] seeking CF name for total water column height Dear John Yes, good suggestion, we could adopt a new pattern vertical_distance_between_X and_Y for cases where "thickness" sounds peculiar. Aliases are really intended for cases where we make mistakes or change our minds, rather than to provide synonyms deliberately. We've preferred to force ourselves to agree where possible on a minimal vocabulary. Best wishes Jonathan _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From j.m.gregory at reading.ac.uk Wed Feb 3 02:33:35 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Wed, 3 Feb 2010 09:33:35 +0000 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <20100202182255.GA19905@met.reading.ac.uk> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk> Message-ID: <20100203093335.GA21845@met.reading.ac.uk> Dear Jeff I think the best choice is still > sea_floor_depth_below_sea_surface for this quantity. John's vertical_distance idea could be a good one to adopt for other layer thicknesses, but this name would be consistent with existing names, and so it seems suitable. Also the surface is a natural reference level, more than other surfaces. If we decide later that was a wrong decision, we can use an alias, as discussed. Best wishes Jonathan From j.d.blower at reading.ac.uk Thu Feb 4 04:14:25 2010 From: j.d.blower at reading.ac.uk (Jonathan Blower) Date: Thu, 4 Feb 2010 11:14:25 -0000 Subject: [CF-metadata] Some questions about 360-day calendars Message-ID: <7CD7F00F17085C4EBB045A35177C85FDB9C8B6@VIME-VS1.rdg-home.ad.rdg.ac.uk> Hi all, I'm trying to understand how to handle some climate data with a 360-day calendar. As I understand it (http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.ht ml#calendar), this calendar uses 12-month years with exactly 30 days each. I have a few questions: 1) In this system, how long is a day in milliseconds? Is it the normal 24*60*60*1000? Or is it somehow scaled so that a year of 360 days has the same number of milliseconds as an "average" Gregorian year? 2) Is there any way of translating (even roughly) between 360-day and Gregorian calendars? E.g. perhaps one could, for a given date-time, calculate the fraction of a year that has elapsed and apply this in the conversion? Or is the comparison only meaningful in a statistical sense (e.g. annual/seasonal averages)? 3) Would the most usual way to encode a CF time axis in a 360-day calendar be to use "days since..."? I guess if a day has a standard length in (milli)seconds then one could also safely use "seconds since..."? 4) Finally on practical note: I seem to remember that someone has implemented the 360-day calendar using the Java library joda-time? Is this code available for re-use? Thanks in advance, Jon -- Dr Jon Blower Technical Director, Reading e-Science Centre Environmental Systems Science Centre University of Reading Harry Pitt Building, 3 Earley Gate Reading RG6 6AL. UK Tel: +44 (0)118 378 5213 Fax: +44 (0)118 378 6413 j.d.blower at reading.ac.uk http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm From bryan.lawrence at stfc.ac.uk Thu Feb 4 06:09:24 2010 From: bryan.lawrence at stfc.ac.uk (Bryan Lawrence) Date: Thu, 4 Feb 2010 13:09:24 +0000 Subject: [CF-metadata] Some questions about 360-day calendars In-Reply-To: <7CD7F00F17085C4EBB045A35177C85FDB9C8B6@VIME-VS1.rdg-home.ad.rdg.ac.uk> References: <7CD7F00F17085C4EBB045A35177C85FDB9C8B6@VIME-VS1.rdg-home.ad.rdg.ac.uk> Message-ID: <201002041309.24732.bryan.lawrence@stfc.ac.uk> Hi Jon > 1) In this system, how long is a day in milliseconds? Is it the normal > 24*60*60*1000? Yes. > Or is it somehow scaled so that a year of 360 days has > the same number of milliseconds as an "average" Gregorian year? No. > 2) Is there any way of translating (even roughly) between 360-day and > Gregorian calendars? Yes and no. Mostly no. Some folk have been known to run a 360-day model and update the boundary conditions annually as they might were it a 365 day model. In that sense, the months correspond ok to the real months ... but this sort of model should never be used in any sort of "comparison with real days" mode - and indeed, no climate model (whether 365 day or not) is ever used that way. They're simply not constructed as initial condition models ... and even where they attempt to do that (seasonal forecasting), even in a 365 day model, there is no meaningful comparison between a prediction at tzero plus a few weeks and the actual day ... it's statistics all the way ... so that's a long way of saying there is no reason for such a conversion beyond month and year, and then only for statistical comparison. Cheers Bryan -- Bryan Lawrence Director of Environmental Archival and Associated Research (NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC) STFC, Rutherford Appleton Laboratory Phone +44 1235 445012; Fax ... 5848; Web: home.badc.rl.ac.uk/lawrence From dominic.lowe at stfc.ac.uk Thu Feb 4 08:37:06 2010 From: dominic.lowe at stfc.ac.uk (Dominic Lowe) Date: Thu, 04 Feb 2010 15:37:06 +0000 Subject: [CF-metadata] Some questions about 360-day calendars In-Reply-To: <7CD7F00F17085C4EBB045A35177C85FDB9C8B6@VIME-VS1.rdg-home.ad.rdg.ac.uk> References: <7CD7F00F17085C4EBB045A35177C85FDB9C8B6@VIME-VS1.rdg-home.ad.rdg.ac.uk> Message-ID: <4B6AE9A2.7060802@stfc.ac.uk> Hi Jon > > 4) Finally on practical note: I seem to remember that someone has > implemented the 360-day calendar using the Java library joda-time? Is > this code available for re-use? > I don't know about joda-time, but there is a python implementation in the CDMS cdtime module: http://esg.llnl.gov/cdat/cdms_html/cdms-3.htm Cheers, Dom > Thanks in advance, > Jon > > -- From ngalbraith at whoi.edu Thu Feb 4 10:29:26 2010 From: ngalbraith at whoi.edu (Nan Galbraith) Date: Thu, 04 Feb 2010 12:29:26 -0500 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <20100202182255.GA19905@met.reading.ac.uk> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk> Message-ID: <4B6B03F6.4090404@whoi.edu> Sea_floor_depth_below_sea_surface seems very appropriate when the water depth is measured from the surface. Some communities need to distinguish this measurement from one made from the sea floor. Shipboard water depth measurements in the open ocean generally ignore tides and other variations in sea surface height, while bottom pressure recorders or other instruments used in transport studies are monitoring these differences. The oceansites project is looking for a way to identify this distinction - maybe having 2 "water depth" terms in CF will be the solution, although it may not be clear enough (especially since most people seem to think these terms are synonyms). If this has been mentioned, please excuse; I've been on a ship with terrible network throughput, and I'm slowly trying to catch up with email discussions. Cheers - Nan > I agree, it is arbitrary whether it is called > sea_floor_depth_below_sea_surface > or > sea_surface_height_above_sea_floor > and I agree with Roy that consistency with existing names would suggest > the former. > > It's interesting that this kind of ambiguity hasn't arisen before. What you > want to name is the distance between two named surfaces. In other names, we > call the vertical distance between two surfaces a "thickness" e.g. > ocean_mixed_layer_thickness. That doesn't have an associated "direction" > (upward or downward) and so avoids this problem. By that analogy the quantity > you want to name might be called thickness_of_ocean but I suspect most people > would find that less obvious. What we are aiming at principally is clarity. > > The procedure for adding names is that Alison Pamment, the manager of standard > names, will consider them and add them. She is dealing with CMIP5 names at > present, I believe, so it might be a while before she gets to this. If no-one > else objects soon or makes an alternative proposal, I'd suggest you use this > name on the assumption that it will be added to the stdname table in due > course. > > Best wishes > > Jonathan > -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* From rkl at bodc.ac.uk Fri Feb 5 01:03:23 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Fri, 5 Feb 2010 08:03:23 +0000 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <4B6B03F6.4090404@whoi.edu> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk>, <4B6B03F6.4090404@whoi.edu> Message-ID: <40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk> Hello Nan, I was arguing at the start of this thread that an instantaneous single-beam echosounder measurement is the so close to being the same thing as a BPR measurement in tidal mode with waves filtered out (ever looked at echosounder data from an anchored ship?) that they should be called the same thing on the basis that the Standard Name represents the phenomenon and should not describe how it was measured. Cheers, Roy. ________________________________________ From: cf-metadata-bounces at cgd.ucar.edu [cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Nan Galbraith [ngalbraith at whoi.edu] Sent: 04 February 2010 17:29 To: Jonathan Gregory Cc: cf-metadata at cgd.ucar.edu; Mike Garcia Subject: Re: [CF-metadata] seeking CF name for total water column height Sea_floor_depth_below_sea_surface seems very appropriate when the water depth is measured from the surface. Some communities need to distinguish this measurement from one made from the sea floor. Shipboard water depth measurements in the open ocean generally ignore tides and other variations in sea surface height, while bottom pressure recorders or other instruments used in transport studies are monitoring these differences. The oceansites project is looking for a way to identify this distinction - maybe having 2 "water depth" terms in CF will be the solution, although it may not be clear enough (especially since most people seem to think these terms are synonyms). If this has been mentioned, please excuse; I've been on a ship with terrible network throughput, and I'm slowly trying to catch up with email discussions. Cheers - Nan > I agree, it is arbitrary whether it is called > sea_floor_depth_below_sea_surface > or > sea_surface_height_above_sea_floor > and I agree with Roy that consistency with existing names would suggest > the former. > > It's interesting that this kind of ambiguity hasn't arisen before. What you > want to name is the distance between two named surfaces. In other names, we > call the vertical distance between two surfaces a "thickness" e.g. > ocean_mixed_layer_thickness. That doesn't have an associated "direction" > (upward or downward) and so avoids this problem. By that analogy the quantity > you want to name might be called thickness_of_ocean but I suspect most people > would find that less obvious. What we are aiming at principally is clarity. > > The procedure for adding names is that Alison Pamment, the manager of standard > names, will consider them and add them. She is dealing with CMIP5 names at > present, I believe, so it might be a while before she gets to this. If no-one > else objects soon or makes an alternative proposal, I'd suggest you use this > name on the assumption that it will be added to the stdname table in due > course. > > Best wishes > > Jonathan > -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From ngalbraith at whoi.edu Mon Feb 8 08:09:43 2010 From: ngalbraith at whoi.edu (Nan Galbraith) Date: Mon, 08 Feb 2010 10:09:43 -0500 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk>, <4B6B03F6.4090404@whoi.edu> <40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk> Message-ID: <4B702937.8060902@whoi.edu> Hi Roy - > I was arguing at the start of this thread ... This first came up in August, 2008: Subject: Same parameter, different meaning (pressure) Can (or should) the CF standard differentiate between these two very different measurements of sea water pressure: The consensus then was that we should use a single name and infer the "meaning" of the data from metadata about how the sensor was mounted. > ... that an instantaneous single-beam echosounder measurement is the so close to being the same thing as a BPR measurement in tidal mode with waves filtered out (ever looked at echosounder data from an anchored ship?) that they should be called the same thing on the basis that the Standard Name represents the phenomenon and should not describe how it was measured. > Exactly; they're comparable when the BPR is processed in a specific way - and not comparable otherwise. So, does data from the different modes of a pressure recorder (or data that's been post-processed as you describe) constitute different physical phenomena, worthy of different standard names, or not? It looks like we're sticking with the original decision, and using a single name, but users will need to come to some agreement on how to document the sensor mounting and/or post-processing, to provide enough information to understand the "meaning" of the data. Cheers - Nan > ________________________________________ > From: Nan Galbraith [ngalbraith at whoi.edu] > Sent: 04 February 2010 17:29 > Subject: Re: [CF-metadata] seeking CF name for total water column height > > Sea_floor_depth_below_sea_surface seems very appropriate when > the water depth is measured from the surface. > > Some communities need to distinguish this measurement from one > made from the sea floor. Shipboard water depth measurements in the > open ocean generally ignore tides and other variations in sea surface > height, while bottom pressure recorders or other instruments used in > transport studies are monitoring these differences. > > The oceansites project is looking for a way to identify this distinction - > maybe having 2 "water depth" terms in CF will be the solution, although > it may not be clear enough (especially since most people seem to think > these terms are synonyms). > > If this has been mentioned, please excuse; I've been on a ship with > terrible network throughput, and I'm slowly trying to catch up with > email discussions. > > Cheers - Nan > > -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* From alison.pamment at stfc.ac.uk Fri Feb 12 04:15:18 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Fri, 12 Feb 2010 11:15:18 -0000 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: <4B702937.8060902@whoi.edu> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk>, <4B6B03F6.4090404@whoi.edu><40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk> <4B702937.8060902@whoi.edu> Message-ID: Dear Jeff, Thank you for your standard name proposal for water column height and thanks to all who have contributed comments to this discussion. The consensus view seems to be that > sea_floor_depth_below_sea_surface is an acceptable name for this quantity and that it is consistent with the existing standard name sea_floor_depth_below_sea_level. The canonical units will be metres (m). Roy has suggested the following definition: > 'The vertical distance between the sea surface and the seabed as measured at a given point > in space including the variance caused by tides and possibly waves.' If no further comments on this name or its definition are received over the next seven days then they will be accepted in their present form for inclusion in the standard name table. You have also suggested two further standard names: water_level_with|above_reference_datum water_level_without_reference_datum For the latter name, Roy has suggested the term 'tide gauge zero' to express the lack of reference datum. Am I correct in thinking that all these quantities are referring to measurements in the open sea or coastal areas? If so, I think we should refer to sea_surface_height rather than water_level for consistency with other names. So we could have: sea_surface_height_above_reference_datum sea_surface_height_above_tide_gauge_zero. I am wondering how many different reference datums there are likely to be? You mentioned low water and highest astronomical tide but are there likely to be dozens of these quantities? If there are only a few we could consider introducing separate standard names for them as we have done with quantities such as sea_surface_height_above_reference_ellipsoid and sea_surface_height_above_geoid for example. If there are a large number of possible datums then it wouldn't be practical to introduce standard names for them all and we would need another way to record which datum is being used. Regarding the definitions, do both quantities average out the effects of waves? Nan has raised the question of how to distinguish between the same geophysical quantity measured with different sensors/sensor configurations or post-processed differently. This question has arisen in a number of contexts recently. For example, as well as sea water pressure and depth measurements, we discussed some CMIP5 proposals in which climate models were simulating cloud amounts as retrieved from two different satellite instruments. In the case of CMIP5 I believe the issue was resolved by using the same standard name for both quantities and placing them in differently named files, but a simple way of distinguishing between instruments/instrument types/retrieval algorithms in metadata would be to use the 'source' attribute which can be either global or attached to a single variable (this is already part of the CF conventions, section 2.6.2). Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. From rkl at bodc.ac.uk Fri Feb 12 04:23:49 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Fri, 12 Feb 2010 11:23:49 +0000 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk>, <4B6B03F6.4090404@whoi.edu><40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk> <4B702937.8060902@whoi.edu> Message-ID: <40829B0E077C1145A6DE44D39B3830A90887492122@nerckwmb1.ad.nerc.ac.uk> Hello Alison, There are a lot of potential reference datums. I have a vocabulary containing 31 examples plus two nulls (http://vocab.ndg.nerc.ac.uk/list/L111/current or http://seadatanet.maris2.nl/v_bodc_vocab/search.asp?name=(L111)%20Vertical+Co-ordinate+Reference+System+Origins&l=L111 in plaintext - just press the 'Search' button), but this is far from complete particularly outside Europe. Cheers, Roy. -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of alison.pamment at stfc.ac.uk Sent: 12 February 2010 11:15 To: cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] seeking CF name for total water column height Dear Jeff, Thank you for your standard name proposal for water column height and thanks to all who have contributed comments to this discussion. The consensus view seems to be that > sea_floor_depth_below_sea_surface is an acceptable name for this quantity and that it is consistent with the existing standard name sea_floor_depth_below_sea_level. The canonical units will be metres (m). Roy has suggested the following definition: > 'The vertical distance between the sea surface and the seabed as measured at a given point > in space including the variance caused by tides and possibly waves.' If no further comments on this name or its definition are received over the next seven days then they will be accepted in their present form for inclusion in the standard name table. You have also suggested two further standard names: water_level_with|above_reference_datum water_level_without_reference_datum For the latter name, Roy has suggested the term 'tide gauge zero' to express the lack of reference datum. Am I correct in thinking that all these quantities are referring to measurements in the open sea or coastal areas? If so, I think we should refer to sea_surface_height rather than water_level for consistency with other names. So we could have: sea_surface_height_above_reference_datum sea_surface_height_above_tide_gauge_zero. I am wondering how many different reference datums there are likely to be? You mentioned low water and highest astronomical tide but are there likely to be dozens of these quantities? If there are only a few we could consider introducing separate standard names for them as we have done with quantities such as sea_surface_height_above_reference_ellipsoid and sea_surface_height_above_geoid for example. If there are a large number of possible datums then it wouldn't be practical to introduce standard names for them all and we would need another way to record which datum is being used. Regarding the definitions, do both quantities average out the effects of waves? Nan has raised the question of how to distinguish between the same geophysical quantity measured with different sensors/sensor configurations or post-processed differently. This question has arisen in a number of contexts recently. For example, as well as sea water pressure and depth measurements, we discussed some CMIP5 proposals in which climate models were simulating cloud amounts as retrieved from two different satellite instruments. In the case of CMIP5 I believe the issue was resolved by using the same standard name for both quantities and placing them in differently named files, but a simple way of distinguishing between instruments/instrument types/retrieval algorithms in metadata would be to use the 'source' attribute which can be either global or attached to a single variable (this is already part of the CF conventions, section 2.6.2). Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From olauret at cls.fr Fri Feb 12 09:42:53 2010 From: olauret at cls.fr (olivier lauret) Date: Fri, 12 Feb 2010 17:42:53 +0100 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk>, <4B6B03F6.4090404@whoi.edu><40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk><4B702937.8060902@whoi.edu> Message-ID: <1240F43731C2EB4F8CC9BF70D233B511017F98C0@SRV-XCHANGE-2K3.pc.cls.fr> Hi Alison, *About the 'water level' vs 'sea surface height' In the case of Jeff needs would only concern ocean data, would you mind if I ask CF to introduce both? I was about to ask CF for such quantities on rivers and lakes.. *About reference datum, my opinion is that considering CF standard name is supposed to uniquely identify one geophysical field, we should ask: "are there as many standard names as there are datums?" Is the sea surface height above French Naval Chart Datum geophysically different from the sea surface height above French Naval Chart Datum for Lebanon? If the answer is yes, I guess introducing a new datum attribute in CF would be relevant. By the way if we consider the sea surface height above geoid, geoid is not exactly a datum, or became indirectly a datum: the whole quantity refers first to the geophysical information retrieved, which is the absolute ocean topography, and which is not obtained by measuring some heights and subtracting geoid heights from. It is really full of meaning in terms of ocean dynamics - and less on the way it was really measured.. *I confirm that what you explained about distinction between the same geophysical field obtained by different sensors was also applied by OSTST/Jason community. In the NetCDF product you can have 2 variables with the same standard name, but one is obtained via the onboard instrument, and the second via ECMWF forecasts. It is another illustration. Cheers, Olivier. -----Message d'origine----- De : cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] De la part de alison.pamment at stfc.ac.uk Envoy? : vendredi 12 f?vrier 2010 12:15 ? : cf-metadata at cgd.ucar.edu Objet : Re: [CF-metadata] seeking CF name for total water column height Dear Jeff, Thank you for your standard name proposal for water column height and thanks to all who have contributed comments to this discussion. The consensus view seems to be that > sea_floor_depth_below_sea_surface is an acceptable name for this quantity and that it is consistent with the existing standard name sea_floor_depth_below_sea_level. The canonical units will be metres (m). Roy has suggested the following definition: > 'The vertical distance between the sea surface and the seabed as measured at a given point > in space including the variance caused by tides and possibly waves.' If no further comments on this name or its definition are received over the next seven days then they will be accepted in their present form for inclusion in the standard name table. You have also suggested two further standard names: water_level_with|above_reference_datum water_level_without_reference_datum For the latter name, Roy has suggested the term 'tide gauge zero' to express the lack of reference datum. Am I correct in thinking that all these quantities are referring to measurements in the open sea or coastal areas? If so, I think we should refer to sea_surface_height rather than water_level for consistency with other names. So we could have: sea_surface_height_above_reference_datum sea_surface_height_above_tide_gauge_zero. I am wondering how many different reference datums there are likely to be? You mentioned low water and highest astronomical tide but are there likely to be dozens of these quantities? If there are only a few we could consider introducing separate standard names for them as we have done with quantities such as sea_surface_height_above_reference_ellipsoid and sea_surface_height_above_geoid for example. If there are a large number of possible datums then it wouldn't be practical to introduce standard names for them all and we would need another way to record which datum is being used. Regarding the definitions, do both quantities average out the effects of waves? Nan has raised the question of how to distinguish between the same geophysical quantity measured with different sensors/sensor configurations or post-processed differently. This question has arisen in a number of contexts recently. For example, as well as sea water pressure and depth measurements, we discussed some CMIP5 proposals in which climate models were simulating cloud amounts as retrieved from two different satellite instruments. In the case of CMIP5 I believe the issue was resolved by using the same standard name for both quantities and placing them in differently named files, but a simple way of distinguishing between instruments/instrument types/retrieval algorithms in metadata would be to use the 'source' attribute which can be either global or attached to a single variable (this is already part of the CF conventions, section 2.6.2). Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata Cliquez sur l'url suivante https://www.mailcontrol.com/sr/qfIJjnfim1XTndxI!oX7UibJmmb6AuK6ZrMZav1w5d4ZfWlb5l2PBu6fCO3jlD4LbdPTFJ7Xke9TQ40Is2HDWw== si ce message est ind?sirable (pourriel). -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jeff.deLaBeaujardiere at noaa.gov Fri Feb 12 10:56:38 2010 From: Jeff.deLaBeaujardiere at noaa.gov (Jeff deLaBeaujardiere) Date: Fri, 12 Feb 2010 12:56:38 -0500 Subject: [CF-metadata] water level with/without datum In-Reply-To: References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk> <4B6B03F6.4090404@whoi.edu> <40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk> <4B702937.8060902@whoi.edu> Message-ID: <4B759656.2020306@noaa.gov> Thank you for the discussion and current status regarding sea_floor_depth_below_sea_surface as a new standard name. I have changed the subject line of this email to focus on the other names we discussed. I have also CCed our local water level expert (Andrea Hardy from NOAA CO-OPS); my replies are based on limited knowledge. alison.pamment at stfc.ac.uk wrote: > You have also suggested two further standard names: > water_level_with|above_reference_datum > water_level_without_reference_datum > > For the latter name, Roy has suggested the term 'tide gauge zero' to > express the lack of reference datum. I suppose you mean the latter name could be something like water_level_relative_to_tide_gauge_zero ? I believe that at NOAA we use the term "station datum" to refer to measurements relative only to the station (which might be a tide gauge or not), so perhaps one of these would be better: water_level_relative_to_station_datum water_level_above_station_datum I like the use of the word "above" because it indicates the sign of the value, but that's just a personal preference. > Am I correct in thinking that all these quantities are referring to > measurements in the open sea or coastal areas? If so, I think we should > refer to sea_surface_height rather than water_level for consistency with > other names. My understanding is that water level stations may be associated with rivers or the US Great Lakes, so "sea surface" would not be ideal. > I am wondering how many different reference datums there are likely to > be? You mentioned low water and highest astronomical tide but are there > likely to be dozens of these quantities? If there are only a few we > could consider introducing separate standard names for them Possible datums include at least International Great Lakes Datum (IGLD), mean high water (MHW), mean lower low water (MLLW), mean sea level (MSL), and NAVD88. I believe our preference would be *not* to include the datum name in the standard name, so that the user can request the datum of their choice. Andrea: I see that on your server Station Datum is among the choices. Are you sure it wouldn't be better to have a single name like water_level_relative_to_datum, with station datum merely being one of the options? > Regarding the definitions, do both quantities average out the effects of waves? I don't know. Andrea? Regards to all from snowy Washington, Jeff DLB -- Jeff de La Beaujardi?re, PhD Senior Systems Architect, Data Integration Framework Integrated Ocean Observing System (IOOS) Program Office National Oceanic and Atmospheric Administration 1100 Wayne Ave #1225, Silver Spring MD 20910 USA +1 301 427 2427 Jeff.deLaBeaujardiere at noaa.gov From beate.geyer at gkss.de Fri Feb 12 05:50:26 2010 From: beate.geyer at gkss.de (beate.geyer at gkss.de) Date: Fri, 12 Feb 2010 13:50:26 +0100 Subject: [CF-metadata] proposals for two new standard_names Message-ID: Dear Jonathan, Ingeborg Noehren and I'd like to propose 2 new standard_names: Sea_surface_wave_skewness Sea surface wave skewness of the directional energy distribution per frequency D() is obtained from second order and third order circular moments of D(). Unit: [1] Sea_surface_wave_kurtosis Sea surface wave kurtosis of the directional energy distribution per frequency D() is obtained from second order and fourth order circular moments of D(). Unit: [1] Since they are not very common, Ingeborg wrote an explanation: Best regards, Beate ==================================================== Dr. Beate Geyer GKSS Research Centre Institute for Coastal Research Max-Planck-Str. D-21502 Geesthacht, Germany E-Mail: Beate.Geyer at gkss.de Phone: +49 4152-871871 www: http://icts.gkss.de ==================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wave_directional_characteristics_V02.doc Type: application/octet-stream Size: 61440 bytes Desc: not available URL: From j.m.gregory at reading.ac.uk Fri Feb 12 11:49:11 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 12 Feb 2010 18:49:11 +0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: <4B759656.2020306@noaa.gov> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk> <4B6B03F6.4090404@whoi.edu> <40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk> <4B702937.8060902@whoi.edu> <4B759656.2020306@noaa.gov> Message-ID: <20100212184911.GA29286@met.reading.ac.uk> Dear Jeff, Alison et al. Like Alison, I prefer sea_surface_height to water_level, because it's really the same geophysical quantity at the coast and far from the coast, isn't it. It seems awkward to me to say that the satellite altimeter measures SSH, while a tide gauge measures water level. The altimeter comes right up to the coast (in principle), so where is the distinction? Also, water_level is rather like sea_level, which is the name of a special surface i.e. mean sea level, whereas SSH is the name of time-varying quantity. I tend to think that geophysically different datums imply different geophysical quantities and standard names. The reference surface might also be time- dependent, in a different way (in general, more slowly) from the SSH; it's not a constant offset. There is some vagueness about this; some of the reference surfaces might be different estimates of the "same" thing e.g. different geoids and different reference ellipsoids. In that case we could use the same stdname, but we ought to use other attributes to be more precise, when necessary. But I don't think the lowest tide level, the mean high water, the (mean) sea level etc. should be regarded as the "same" reference surface. They're all different. Having a dozen different SSH standard names would be OK, I'd say. As for sea, lake and river - this is a vexed question we have never resolved! If only there were a simple word which meant any of the three! At the moment, we only have "sea" names. A possibility is to define sea to mean sea, lake or river, in CF standard names; obviously that could be confusing. We could replace "sea" (almost) everywhere with e.g. "slr", which would not be self- explanatory, but it would force the user to look it up, and so it would not be confusing. (We do use a few other abbreviations e.g. toa and lwe.) e.g. sea_water_temperature -> slr_water_temperature. I think that would be a reasonable solution, but there are probably better ones. Best wishes Jonathan From Jeff.deLaBeaujardiere at noaa.gov Fri Feb 12 14:13:20 2010 From: Jeff.deLaBeaujardiere at noaa.gov (Jeff deLaBeaujardiere) Date: Fri, 12 Feb 2010 16:13:20 -0500 Subject: [CF-metadata] water level with/without datum In-Reply-To: <20100212184911.GA29286@met.reading.ac.uk> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk> <4B6B03F6.4090404@whoi.edu> <40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk> <4B702937.8060902@whoi.edu> <4B759656.2020306@noaa.gov> <20100212184911.GA29286@met.reading.ac.uk> Message-ID: <4B75C470.6060402@noaa.gov> Jonathan Gregory wrote: > As for sea, lake and river - this is a vexed question we have never resolved! > If only there were a simple word which meant any of the three! That's why 'water_' seems preferable, in my view. Cheers, Jeff DLB From j.m.gregory at reading.ac.uk Fri Feb 12 14:53:41 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 12 Feb 2010 21:53:41 +0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: <4B75C470.6060402@noaa.gov> References: <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk> <4B6B03F6.4090404@whoi.edu> <40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk> <4B702937.8060902@whoi.edu> <4B759656.2020306@noaa.gov> <20100212184911.GA29286@met.reading.ac.uk> <4B75C470.6060402@noaa.gov> Message-ID: <20100212215341.GA29697@met.reading.ac.uk> Dear Jeff > >As for sea, lake and river - this is a vexed question we have never > >resolved! > >If only there were a simple word which meant any of the three! > > That's why 'water_' seems preferable, in my view. Unfortunately "water" occurs not just in the sea, lakes and rivers, but also in the atmosphere and the ground. Best wishes Jonathan From jbgraybeal at mindspring.com Fri Feb 12 20:36:05 2010 From: jbgraybeal at mindspring.com (John Graybeal) Date: Fri, 12 Feb 2010 19:36:05 -0800 Subject: [CF-metadata] water level with/without datum In-Reply-To: <20100212215341.GA29697@met.reading.ac.uk> References: <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk> <4B6B03F6.4090404@whoi.edu> <40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk> <4B702937.8060902@whoi.edu> <4B759656.2020306@noaa.gov> <20100212184911.GA29286@met.reading.ac.uk> <4B75C470.6060402@noaa.gov> <20100212215341.GA29697@met.reading.ac.uk> Message-ID: <9D3EED0C-12B1-43A6-8F8A-2D89018076A4@mindspring.com> The term 'water_' is preferable to me too. When this liquid occurs underground, it still is appropriate to measure this quantity (and temperature, and other things). And when it occurs in the atmosphere, I don't think the term has any meaning -- measuring the height of atmospheric water is a conundrum at best; if the term's meaning is problematic, then define its meaning in that special case, and everything is consistent and meaningful with the most intuitive term available. john On Feb 12, 2010, at 13:53, Jonathan Gregory wrote: > Dear Jeff > >>> As for sea, lake and river - this is a vexed question we have never >>> resolved! >>> If only there were a simple word which meant any of the three! >> >> That's why 'water_' seems preferable, in my view. > > Unfortunately "water" occurs not just in the sea, lakes and rivers, > but also > in the atmosphere and the ground. > > Best wishes > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -------------- I have my new work email address: jgraybeal at ucsd.edu -------------- John Graybeal phone: 858-534-2162 System Development Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org From j.m.gregory at reading.ac.uk Sat Feb 13 02:00:05 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Sat, 13 Feb 2010 09:00:05 +0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: <9D3EED0C-12B1-43A6-8F8A-2D89018076A4@mindspring.com> References: <20100202182255.GA19905@met.reading.ac.uk> <4B6B03F6.4090404@whoi.edu> <40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk> <4B702937.8060902@whoi.edu> <4B759656.2020306@noaa.gov> <20100212184911.GA29286@met.reading.ac.uk> <4B75C470.6060402@noaa.gov> <20100212215341.GA29697@met.reading.ac.uk> <9D3EED0C-12B1-43A6-8F8A-2D89018076A4@mindspring.com> Message-ID: <20100213090005.GA26566@met.reading.ac.uk> Dear John Sorry not to be clear. My main point is that sea_surface_height is an existing term which is customarily used to refer to the level of the water surface in the open ocean. I am arguing that, at the coast, the level of the sea water surface is really the same quantity as sea_surface_height away from the coast, and so it should have the same name. Then that raises the question of what to call the level of the water surface when it is a lake or a river but not the sea. We could have standard names using the phrases lake_surface_height and river_surface_height. That would be fine, except that the distinction may in some cases become inconvenient and arbitrary, as you have to decide exactly when it is one or another. It would be convenient to use the same word for all of them. I don't think it's such a good idea to solve this by dropping "sea" and calling it just "water". Although you are right that the exact term water_level might not be needed in the atmosphere and the ground (though I suppose something like it might be used for ground water), I think it is preferable to use a term which includes the context. We try to make the standard names as informative and self-explanatory as we can, so we don't use just the word "water" without indicating somehow where the water is in the Earth system. For instance, we do not have a standard name of "water content" because the context is not clear. We have names such as atmosphere_water_content and soil_frozen_water_content. Best wishes Jonathan From caron at unidata.ucar.edu Sat Feb 13 07:39:09 2010 From: caron at unidata.ucar.edu (john caron) Date: Sat, 13 Feb 2010 07:39:09 -0700 Subject: [CF-metadata] Some questions about 360-day calendars In-Reply-To: <7CD7F00F17085C4EBB045A35177C85FDB9C8B6@VIME-VS1.rdg-home.ad.rdg.ac.uk> References: <7CD7F00F17085C4EBB045A35177C85FDB9C8B6@VIME-VS1.rdg-home.ad.rdg.ac.uk> Message-ID: <4B76B98D.6050704@unidata.ucar.edu> Jonathan Blower wrote: > 4) Finally on practical note: I seem to remember that someone has > implemented the 360-day calendar using the Java library joda-time? Is > this code available for re-use? > roland schweitzer has extended joda for 360 day calendar. I am planning to use joda time or its JSR successor in the future, replacing udunits for date/time processing. From rkl at bodc.ac.uk Mon Feb 15 00:57:14 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Mon, 15 Feb 2010 07:57:14 +0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: <4B759656.2020306@noaa.gov> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk> <4B6B03F6.4090404@whoi.edu> <40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk> <4B702937.8060902@whoi.edu> <4B759656.2020306@noaa.gov> Message-ID: <40829B0E077C1145A6DE44D39B3830A9088749264A@nerckwmb1.ad.nerc.ac.uk> Hi Jeff, (1) I like 'station_datum' and definitely prefer 'above_station_datum' to 'water_level_relative_to_station_datum'. (2) I was arguing against including datum references in the Standard Name (though that might not have bee clear!) by pointing out how many we have. If we go with a generic 'above_reference_datum', what is the preferred mechanism for documenting which on it is in CF? (3) There was a lot of debate in the Compass project domain expert workshops about a term to encompass oceans, seas, rivers and lakes. The conclusion was 'water_body'. Cheers, Roy. -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jeff deLaBeaujardiere Sent: 12 February 2010 17:57 To: cf-metadata at cgd.ucar.edu Cc: Andrea Hardy Subject: [CF-metadata] water level with/without datum Thank you for the discussion and current status regarding sea_floor_depth_below_sea_surface as a new standard name. I have changed the subject line of this email to focus on the other names we discussed. I have also CCed our local water level expert (Andrea Hardy from NOAA CO-OPS); my replies are based on limited knowledge. alison.pamment at stfc.ac.uk wrote: > You have also suggested two further standard names: > water_level_with|above_reference_datum > water_level_without_reference_datum > > For the latter name, Roy has suggested the term 'tide gauge zero' to > express the lack of reference datum. I suppose you mean the latter name could be something like water_level_relative_to_tide_gauge_zero ? I believe that at NOAA we use the term "station datum" to refer to measurements relative only to the station (which might be a tide gauge or not), so perhaps one of these would be better: water_level_relative_to_station_datum water_level_above_station_datum I like the use of the word "above" because it indicates the sign of the value, but that's just a personal preference. > Am I correct in thinking that all these quantities are referring to > measurements in the open sea or coastal areas? If so, I think we should > refer to sea_surface_height rather than water_level for consistency with > other names. My understanding is that water level stations may be associated with rivers or the US Great Lakes, so "sea surface" would not be ideal. > I am wondering how many different reference datums there are likely to > be? You mentioned low water and highest astronomical tide but are there > likely to be dozens of these quantities? If there are only a few we > could consider introducing separate standard names for them Possible datums include at least International Great Lakes Datum (IGLD), mean high water (MHW), mean lower low water (MLLW), mean sea level (MSL), and NAVD88. I believe our preference would be *not* to include the datum name in the standard name, so that the user can request the datum of their choice. Andrea: I see that on your server Station Datum is among the choices. Are you sure it wouldn't be better to have a single name like water_level_relative_to_datum, with station datum merely being one of the options? > Regarding the definitions, do both quantities average out the effects of waves? I don't know. Andrea? Regards to all from snowy Washington, Jeff DLB -- Jeff de La Beaujardi?re, PhD Senior Systems Architect, Data Integration Framework Integrated Ocean Observing System (IOOS) Program Office National Oceanic and Atmospheric Administration 1100 Wayne Ave #1225, Silver Spring MD 20910 USA +1 301 427 2427 Jeff.deLaBeaujardiere at noaa.gov _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From j.m.gregory at reading.ac.uk Mon Feb 15 01:26:48 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Mon, 15 Feb 2010 08:26:48 +0000 Subject: [CF-metadata] humdity Message-ID: <20100215082648.GA4473@met.reading.ac.uk> The standard_name product_of_northward_wind_and_specific_humdity in the current version of the table is missing an "i" in "humidity". Jonathan From j.m.gregory at reading.ac.uk Tue Feb 16 15:45:11 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 16 Feb 2010 22:45:11 +0000 Subject: [CF-metadata] cloud_liquid in standard names? Message-ID: <20100216224511.GA16327@met.reading.ac.uk> Dear all I notice that three standard names (probably recently) added have the phrase cloud_liquid. I suggest that this should be cloud_liquid_water as it is in all other names; cloud_liquid_water and cloud_ice are corresponding phrases. tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_heterogeneous_nucleation_from_cloud_liquid tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_melting_to_cloud_liquid tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_riming_from_cloud_liquid Any comments? Cheers Jonathan From t.lavergne at met.no Wed Feb 17 06:36:21 2010 From: t.lavergne at met.no (Thomas Lavergne) Date: Wed, 17 Feb 2010 13:36:21 +0000 (UTC) Subject: [CF-metadata] Questions on cell boundaries In-Reply-To: <194788541.143429.1264763483929.JavaMail.root@imap1b> Message-ID: <1856511022.358983.1266413781710.JavaMail.root@imap1b> Dear all, I do not think someone reacted on my concern/question about non-polygonal cell boundaries. Maybe I am the only one with this issue or maybe this topic went un-noticed because of heavy load on the CF list at that time. I thus re-post my original message in hope that someone will comment on it (or point me to an archived thread that I did not yet see). Original post: > Hi everyone, > > I refer to Chapter 7 on "Data Representative of Cells", 7.1 "Cell > Boundaries". > > The specification of those boundaries seems to biased towards > polygonal boundaries (in the case of a 2D surface). This covers > certainly most of the needs but what happens if the cell is defined as > a disc of radius x km (with center at the coordinate value)? > > Of course, I can always give 10 to 10,000 vertices that will > approximate my disc but it does not sound very neat nor efficient. We > would have to somehow move away from listing the 'bounds' and start > describing the shape of the cell (disc, ellipse, rectangle, etc...). > Note that the concepts of "cell measures" and "cell methods" would > still perfectly hold. > > One example of such a dataset would be one where at each grid location > we report the mean/minimum/maximum temperature or pressure recorded by > any station found in a radius of, say, 30 km around the central > point. > > Another example is satellite data in swath projection where each > record is associated to a Field Of View, which is often approximated > as a an ellipse. > > Did someone give it a thought already? From bryan.lawrence at stfc.ac.uk Thu Feb 18 04:58:45 2010 From: bryan.lawrence at stfc.ac.uk (Bryan Lawrence) Date: Thu, 18 Feb 2010 11:58:45 +0000 Subject: [CF-metadata] Questions on cell boundaries In-Reply-To: <1856511022.358983.1266413781710.JavaMail.root@imap1b> References: <1856511022.358983.1266413781710.JavaMail.root@imap1b> Message-ID: <201002181158.45995.bryan.lawrence@stfc.ac.uk> hi Thomas Not so much ignored, as not so sure how to respond to it. I'm *very* interested in getting a suitable solution. All the answers I can come up with imagine an extension to CF ... (it'd require a pretty minor extension to cell bounds and/or cell measures) so I'm interested to know if anyone thinks we can do it in another way that we haven't spotted. Cheers Bryan On Wednesday 17 February 2010 13:36:21 Thomas Lavergne wrote: > Dear all, > > I do not think someone reacted on my concern/question about non-polygonal cell boundaries. Maybe I am the only one with this issue or maybe this topic went un-noticed because of heavy load on the CF list at that time. > > I thus re-post my original message in hope that someone will comment on it (or point me to an archived thread that I did not yet see). > > Original post: > > > Hi everyone, > > > > I refer to Chapter 7 on "Data Representative of Cells", 7.1 "Cell > > Boundaries". > > > > The specification of those boundaries seems to biased towards > > polygonal boundaries (in the case of a 2D surface). This covers > > certainly most of the needs but what happens if the cell is defined as > > a disc of radius x km (with center at the coordinate value)? > > > > Of course, I can always give 10 to 10,000 vertices that will > > approximate my disc but it does not sound very neat nor efficient. We > > would have to somehow move away from listing the 'bounds' and start > > describing the shape of the cell (disc, ellipse, rectangle, etc...). > > Note that the concepts of "cell measures" and "cell methods" would > > still perfectly hold. > > > > One example of such a dataset would be one where at each grid location > > we report the mean/minimum/maximum temperature or pressure recorded by > > any station found in a radius of, say, 30 km around the central > > point. > > > > Another example is satellite data in swath projection where each > > record is associated to a Field Of View, which is often approximated > > as a an ellipse. > > > > Did someone give it a thought already? > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -- Bryan Lawrence Director of Environmental Archival and Associated Research (NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC) STFC, Rutherford Appleton Laboratory Phone +44 1235 445012; Fax ... 5848; Web: home.badc.rl.ac.uk/lawrence From ngalbraith at whoi.edu Thu Feb 18 07:36:05 2010 From: ngalbraith at whoi.edu (Nan Galbraith) Date: Thu, 18 Feb 2010 09:36:05 -0500 Subject: [CF-metadata] Questions on cell boundaries In-Reply-To: <201002181158.45995.bryan.lawrence@stfc.ac.uk> References: <1856511022.358983.1266413781710.JavaMail.root@imap1b> <201002181158.45995.bryan.lawrence@stfc.ac.uk> Message-ID: <4B7D5055.60500@whoi.edu> Four coordinates and an area is enough to define an ellipse; if these are more complex shapes, that's another problem. As long as these are ellipses, the existing convention should work; you'd give the n/s e/w extremes of the disc in lat(cell), lon(cell) and use cell_measures = "area: cell_area" after calculating the area from the lengths of the major & minor axes. Maybe my geometry is even rustier than I thought, otherwise this should work as it exists in the standard. > The vertices of the cells can be stored in the variable identified by > the bounds > attribute, but the cell perimeter is not uniquely defined by its > vertices (because > the vertices could, for example, be connected by straight lines, or, > on a sphere, > by lines following a great circle, or, in general, in some other way). - Nan > On Wednesday 17 February 2010 13:36:21 Thomas Lavergne wrote: > >> Dear all, >> >> I do not think someone reacted on my concern/question about non-polygonal cell boundaries. Maybe I am the only one with this issue or maybe this topic went un-noticed because of heavy load on the CF list at that time. >> >> I thus re-post my original message in hope that someone will comment on it (or point me to an archived thread that I did not yet see). >> >> Original post: >> >> >>> Hi everyone, >>> >>> I refer to Chapter 7 on "Data Representative of Cells", 7.1 "Cell >>> Boundaries". >>> >>> The specification of those boundaries seems to biased towards >>> polygonal boundaries (in the case of a 2D surface). This covers >>> certainly most of the needs but what happens if the cell is defined as >>> a disc of radius x km (with center at the coordinate value)? >>> >>> Of course, I can always give 10 to 10,000 vertices that will >>> approximate my disc but it does not sound very neat nor efficient. We >>> would have to somehow move away from listing the 'bounds' and start >>> describing the shape of the cell (disc, ellipse, rectangle, etc...). >>> Note that the concepts of "cell measures" and "cell methods" would >>> still perfectly hold. >>> >>> One example of such a dataset would be one where at each grid location >>> we report the mean/minimum/maximum temperature or pressure recorded by >>> any station found in a radius of, say, 30 km around the central >>> point. >>> >>> Another example is satellite data in swath projection where each >>> record is associated to a Field Of View, which is often approximated >>> as a an ellipse. >>> >>> Did someone give it a thought already? >>> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> > > > > -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* From alison.pamment at stfc.ac.uk Fri Feb 19 05:09:39 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Fri, 19 Feb 2010 12:09:39 -0000 Subject: [CF-metadata] humdity In-Reply-To: <20100215082648.GA4473@met.reading.ac.uk> References: <20100215082648.GA4473@met.reading.ac.uk> Message-ID: Dear Jonathan, Thank you for pointing out the typo. The name with the incorrect spelling appears as far back as version 1 of the standard name table, which means that it was probably like that even before we migrated to the present CF website. In view of the length of time this name has been around (at least 3 years), I will make the correction by creating an alias in the next table update so as not to invalidate any data that may have been written with the misspelled version. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. > -----Original Message----- > From: Jonathan Gregory [mailto:jonathan at met.reading.ac.uk] On Behalf Of > Jonathan Gregory > Sent: 15 February 2010 08:27 > To: cf-metadata at cgd.ucar.edu > Cc: Pamment, Alison (STFC,RAL,SSTD) > Subject: humdity > > The standard_name > product_of_northward_wind_and_specific_humdity > in the current version of the table is missing an "i" in "humidity". > > Jonathan -- Scanned by iCritical. From alison.pamment at stfc.ac.uk Fri Feb 19 05:49:00 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Fri, 19 Feb 2010 12:49:00 -0000 Subject: [CF-metadata] cloud_liquid in standard names? In-Reply-To: <20100216224511.GA16327@met.reading.ac.uk> References: <20100216224511.GA16327@met.reading.ac.uk> Message-ID: Dear Jonathan, These names were among the CMIP5 quantities that were added at the last table update. I agree that changing the phrase to cloud_liquid_water for these names would be more consistent with all other cloud liquid names (including several others that were newly introduced for CMIP5). I will add aliases for these three quantities: tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_heteroge neous_nucleation_from_cloud_liquid will become tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_heteroge neous_nucleation_from_cloud_liquid_water tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_melting_ to_cloud_liquid will become tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_melting_ to_cloud_liquid_water tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_riming_f rom_cloud_liquid will become tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_riming_f rom_cloud_liquid_water Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory > Sent: 16 February 2010 22:45 > To: cf-metadata at cgd.ucar.edu > Subject: [CF-metadata] cloud_liquid in standard names? > > Dear all > > I notice that three standard names (probably recently) added have the > phrase > cloud_liquid. I suggest that this should be cloud_liquid_water as it is > in all > other names; cloud_liquid_water and cloud_ice are corresponding > phrases. > > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_heterog > eneous_nucleation_from_cloud_liquid > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_melting > _to_cloud_liquid > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_riming_ > from_cloud_liquid > > Any comments? > > Cheers > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Scanned by iCritical. From alison.pamment at stfc.ac.uk Fri Feb 19 06:57:05 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Fri, 19 Feb 2010 13:57:05 -0000 Subject: [CF-metadata] seeking CF name for total water column height In-Reply-To: References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk>, <4B6B03F6.4090404@whoi.edu><40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk><4B702937.8060902@whoi.edu> Message-ID: Dear Jeff, No further comments have been received regarding the water column name so it is now accepted for inclusion in the standard name table. > > Thank you for your standard name proposal for water column height and > thanks to all who have contributed comments to this discussion. The > consensus view seems to be that > > sea_floor_depth_below_sea_surface > is an acceptable name for this quantity and that it is consistent with > the existing standard name sea_floor_depth_below_sea_level. The > canonical units will be metres (m). Roy has suggested the following > definition: > > 'The vertical distance between the sea surface and the seabed as > measured at a given point > > in space including the variance caused by tides and possibly waves.' > > If no further comments on this name or its definition are received over > the next seven days then they will be accepted in their present form > for > inclusion in the standard name table. > Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. From bryan.lawrence at stfc.ac.uk Fri Feb 19 07:09:41 2010 From: bryan.lawrence at stfc.ac.uk (Bryan Lawrence) Date: Fri, 19 Feb 2010 14:09:41 +0000 Subject: [CF-metadata] Questions on cell boundaries In-Reply-To: <4B7D5055.60500@whoi.edu> References: <1856511022.358983.1266413781710.JavaMail.root@imap1b> <201002181158.45995.bryan.lawrence@stfc.ac.uk> <4B7D5055.60500@whoi.edu> Message-ID: <201002191409.42063.bryan.lawrence@stfc.ac.uk> Hi Nan ... but you couldn't plot this properly because you don't know that it's an ellipse ... which is why I would suggest a very slight modification to add that particular piece of metadata ... (or am I missing something) Cheers Bryan On Thursday 18 February 2010 14:36:05 Nan Galbraith wrote: > Four coordinates and an area is enough to define an ellipse; if > these are more complex shapes, that's another problem. > > As long as these are ellipses, the existing convention should work; you'd > give the n/s e/w extremes of the disc in lat(cell), lon(cell) and use > cell_measures = "area: cell_area" after calculating the area from the > lengths > of the major & minor axes. > > Maybe my geometry is even rustier than I thought, otherwise this should > work as it exists in the standard. > > > > The vertices of the cells can be stored in the variable identified by > > the bounds > > attribute, but the cell perimeter is not uniquely defined by its > > vertices (because > > the vertices could, for example, be connected by straight lines, or, > > on a sphere, > > by lines following a great circle, or, in general, in some other way). > > - Nan > > > > On Wednesday 17 February 2010 13:36:21 Thomas Lavergne wrote: > > > >> Dear all, > >> > >> I do not think someone reacted on my concern/question about non-polygonal cell boundaries. Maybe I am the only one with this issue or maybe this topic went un-noticed because of heavy load on the CF list at that time. > >> > >> I thus re-post my original message in hope that someone will comment on it (or point me to an archived thread that I did not yet see). > >> > >> Original post: > >> > >> > >>> Hi everyone, > >>> > >>> I refer to Chapter 7 on "Data Representative of Cells", 7.1 "Cell > >>> Boundaries". > >>> > >>> The specification of those boundaries seems to biased towards > >>> polygonal boundaries (in the case of a 2D surface). This covers > >>> certainly most of the needs but what happens if the cell is defined as > >>> a disc of radius x km (with center at the coordinate value)? > >>> > >>> Of course, I can always give 10 to 10,000 vertices that will > >>> approximate my disc but it does not sound very neat nor efficient. We > >>> would have to somehow move away from listing the 'bounds' and start > >>> describing the shape of the cell (disc, ellipse, rectangle, etc...). > >>> Note that the concepts of "cell measures" and "cell methods" would > >>> still perfectly hold. > >>> > >>> One example of such a dataset would be one where at each grid location > >>> we report the mean/minimum/maximum temperature or pressure recorded by > >>> any station found in a radius of, say, 30 km around the central > >>> point. > >>> > >>> Another example is satellite data in swath projection where each > >>> record is associated to a Field Of View, which is often approximated > >>> as a an ellipse. > >>> > >>> Did someone give it a thought already? > >>> > >> _______________________________________________ > >> CF-metadata mailing list > >> CF-metadata at cgd.ucar.edu > >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > >> > >> > > > > > > > > > > -- Bryan Lawrence Director of Environmental Archival and Associated Research (NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC) STFC, Rutherford Appleton Laboratory Phone +44 1235 445012; Fax ... 5848; Web: home.badc.rl.ac.uk/lawrence From t.lavergne at met.no Fri Feb 19 07:15:47 2010 From: t.lavergne at met.no (Thomas Lavergne) Date: Fri, 19 Feb 2010 14:15:47 +0000 (UTC) Subject: [CF-metadata] Questions on cell boundaries In-Reply-To: <1653404370.376680.1266588808731.JavaMail.root@imap1b> Message-ID: <1306703531.376737.1266588947389.JavaMail.root@imap1b> Hei Nan and Bryan, Indeed, as far as I see it, you could not specify or reproduce this shape since you do not know it is an ellipse. It might furthermore be slanted with respect to the axis, which requires an extra piece of information. Bryan, did I miss something or you haven't yet proposed your "slight modification"? I am all ears :-) Thomas ----- "Bryan Lawrence" wrote: > Hi Nan > > ... but you couldn't plot this properly because you don't know that > it's an ellipse ... which is why I would suggest a very slight > modification to add that particular piece of metadata ... (or am I > missing something) > > Cheers > Bryan > > On Thursday 18 February 2010 14:36:05 Nan Galbraith wrote: > > Four coordinates and an area is enough to define an ellipse; if > > these are more complex shapes, that's another problem. > > > > As long as these are ellipses, the existing convention should work; > you'd > > give the n/s e/w extremes of the disc in lat(cell), lon(cell) and > use > > cell_measures = "area: cell_area" after calculating the area from > the > > lengths > > of the major & minor axes. > > > > Maybe my geometry is even rustier than I thought, otherwise this > should > > work as it exists in the standard. > > > > > > > The vertices of the cells can be stored in the variable identified > by > > > the bounds > > > attribute, but the cell perimeter is not uniquely defined by its > > > vertices (because > > > the vertices could, for example, be connected by straight lines, > or, > > > on a sphere, > > > by lines following a great circle, or, in general, in some other > way). > > > > - Nan > > > > > > > On Wednesday 17 February 2010 13:36:21 Thomas Lavergne wrote: > > > > > >> Dear all, > > >> > > >> I do not think someone reacted on my concern/question about > non-polygonal cell boundaries. Maybe I am the only one with this issue > or maybe this topic went un-noticed because of heavy load on the CF > list at that time. > > >> > > >> I thus re-post my original message in hope that someone will > comment on it (or point me to an archived thread that I did not yet > see). > > >> > > >> Original post: > > >> > > >> > > >>> Hi everyone, > > >>> > > >>> I refer to Chapter 7 on "Data Representative of Cells", 7.1 > "Cell > > >>> Boundaries". > > >>> > > >>> The specification of those boundaries seems to biased towards > > >>> polygonal boundaries (in the case of a 2D surface). This covers > > >>> certainly most of the needs but what happens if the cell is > defined as > > >>> a disc of radius x km (with center at the coordinate value)? > > >>> > > >>> Of course, I can always give 10 to 10,000 vertices that will > > >>> approximate my disc but it does not sound very neat nor > efficient. We > > >>> would have to somehow move away from listing the 'bounds' and > start > > >>> describing the shape of the cell (disc, ellipse, rectangle, > etc...). > > >>> Note that the concepts of "cell measures" and "cell methods" > would > > >>> still perfectly hold. > > >>> > > >>> One example of such a dataset would be one where at each grid > location > > >>> we report the mean/minimum/maximum temperature or pressure > recorded by > > >>> any station found in a radius of, say, 30 km around the central > > >>> point. > > >>> > > >>> Another example is satellite data in swath projection where > each > > >>> record is associated to a Field Of View, which is often > approximated > > >>> as a an ellipse. > > >>> > > >>> Did someone give it a thought already? > > >>> > > >> _______________________________________________ > > >> CF-metadata mailing list > > >> CF-metadata at cgd.ucar.edu > > >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > >> > > >> > > > > > > > > > > > > > > > > > > > > -- > Bryan Lawrence > Director of Environmental Archival and Associated Research > (NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC) > STFC, Rutherford Appleton Laboratory > Phone +44 1235 445012; Fax ... 5848; > Web: home.badc.rl.ac.uk/lawrence -- ========================================= Thomas Lavergne Norwegian Meteorological Institute P.O.BOX 43, Blindern, N-0313 OSLO, Norway Phone: (+47) 22963364 Fax: (+47) 22963380 Email: t.lavergne at met.no OSISAF Sea Ice Portal: http://saf.met.no ========================================= From bryan.lawrence at stfc.ac.uk Fri Feb 19 07:45:01 2010 From: bryan.lawrence at stfc.ac.uk (Bryan Lawrence) Date: Fri, 19 Feb 2010 14:45:01 +0000 Subject: [CF-metadata] Questions on cell boundaries In-Reply-To: <1306703531.376737.1266588947389.JavaMail.root@imap1b> References: <1306703531.376737.1266588947389.JavaMail.root@imap1b> Message-ID: <201002191445.01907.bryan.lawrence@stfc.ac.uk> hi Thomas I think Nan's right that four points is enough to unambiguously define an ellipse, but how do we know it's an ellipse? We get the vertices from cell bounds We get the area from cell measures The only thing missing is the knowledge that the bounds need to be interpreted as ellipse coordinates rather than a polygon when plotting or something more sophisticated. There are at least two possible routes: a) while long_name is not required for a boundary variable, we could use it to say it's an elllipse, or b) We extend cell_measures or cell_methods. My preference would be the latter, so we could add ellipse or FOV or something like that to appendix E (I haven't thought this through in detail yet, I was hoping someone else would suggest something). Cheers Bryan On Friday 19 February 2010 14:15:47 Thomas Lavergne wrote: > Hei Nan and Bryan, > > Indeed, as far as I see it, you could not specify or reproduce this shape since you do not know it is an ellipse. It might furthermore be slanted with respect to the axis, which requires an extra piece of information. > > Bryan, did I miss something or you haven't yet proposed your "slight modification"? I am all ears :-) > > Thomas > > ----- "Bryan Lawrence" wrote: > > > Hi Nan > > > > ... but you couldn't plot this properly because you don't know that > > it's an ellipse ... which is why I would suggest a very slight > > modification to add that particular piece of metadata ... (or am I > > missing something) > > > > Cheers > > Bryan > > > > On Thursday 18 February 2010 14:36:05 Nan Galbraith wrote: > > > Four coordinates and an area is enough to define an ellipse; if > > > these are more complex shapes, that's another problem. > > > > > > As long as these are ellipses, the existing convention should work; > > you'd > > > give the n/s e/w extremes of the disc in lat(cell), lon(cell) and > > use > > > cell_measures = "area: cell_area" after calculating the area from > > the > > > lengths > > > of the major & minor axes. > > > > > > Maybe my geometry is even rustier than I thought, otherwise this > > should > > > work as it exists in the standard. > > > > > > > > > > The vertices of the cells can be stored in the variable identified > > by > > > > the bounds > > > > attribute, but the cell perimeter is not uniquely defined by its > > > > vertices (because > > > > the vertices could, for example, be connected by straight lines, > > or, > > > > on a sphere, > > > > by lines following a great circle, or, in general, in some other > > way). > > > > > > - Nan > > > > > > > > > > On Wednesday 17 February 2010 13:36:21 Thomas Lavergne wrote: > > > > > > > >> Dear all, > > > >> > > > >> I do not think someone reacted on my concern/question about > > non-polygonal cell boundaries. Maybe I am the only one with this issue > > or maybe this topic went un-noticed because of heavy load on the CF > > list at that time. > > > >> > > > >> I thus re-post my original message in hope that someone will > > comment on it (or point me to an archived thread that I did not yet > > see). > > > >> > > > >> Original post: > > > >> > > > >> > > > >>> Hi everyone, > > > >>> > > > >>> I refer to Chapter 7 on "Data Representative of Cells", 7.1 > > "Cell > > > >>> Boundaries". > > > >>> > > > >>> The specification of those boundaries seems to biased towards > > > >>> polygonal boundaries (in the case of a 2D surface). This covers > > > >>> certainly most of the needs but what happens if the cell is > > defined as > > > >>> a disc of radius x km (with center at the coordinate value)? > > > >>> > > > >>> Of course, I can always give 10 to 10,000 vertices that will > > > >>> approximate my disc but it does not sound very neat nor > > efficient. We > > > >>> would have to somehow move away from listing the 'bounds' and > > start > > > >>> describing the shape of the cell (disc, ellipse, rectangle, > > etc...). > > > >>> Note that the concepts of "cell measures" and "cell methods" > > would > > > >>> still perfectly hold. > > > >>> > > > >>> One example of such a dataset would be one where at each grid > > location > > > >>> we report the mean/minimum/maximum temperature or pressure > > recorded by > > > >>> any station found in a radius of, say, 30 km around the central > > > >>> point. > > > >>> > > > >>> Another example is satellite data in swath projection where > > each > > > >>> record is associated to a Field Of View, which is often > > approximated > > > >>> as a an ellipse. > > > >>> > > > >>> Did someone give it a thought already? > > > >>> > > > >> _______________________________________________ > > > >> CF-metadata mailing list > > > >> CF-metadata at cgd.ucar.edu > > > >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > >> > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Bryan Lawrence > > Director of Environmental Archival and Associated Research > > (NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC) > > STFC, Rutherford Appleton Laboratory > > Phone +44 1235 445012; Fax ... 5848; > > Web: home.badc.rl.ac.uk/lawrence > -- Bryan Lawrence Director of Environmental Archival and Associated Research (NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC) STFC, Rutherford Appleton Laboratory Phone +44 1235 445012; Fax ... 5848; Web: home.badc.rl.ac.uk/lawrence From taylor13 at llnl.gov Fri Feb 19 09:25:02 2010 From: taylor13 at llnl.gov (Karl Taylor) Date: Fri, 19 Feb 2010 08:25:02 -0800 Subject: [CF-metadata] Questions on cell boundaries In-Reply-To: <201002191445.01907.bryan.lawrence@stfc.ac.uk> References: <1306703531.376737.1266588947389.JavaMail.root@imap1b> <201002191445.01907.bryan.lawrence@stfc.ac.uk> Message-ID: <4B7EBB5E.9090209@llnl.gov> Dear all, Grid cell bounds were originally meant to provide precise information about the spatial extent of each grid cell or the interval of time over which a measurement was made. An ellipse would be inappropriate in either of these two cases (because 2-d space can't be completely completely represented by a set of non-overlapping ellipses). We note that CF does not in fact unambiguously provide any information about the shape of the grid cells; it just says that there are "vertices" that get connected (presumably by quasi-straight lines, perhaps running along great-circles or latitude circles). An ellipse might be considered a special case in which the "vertices" are connected by curves following the shape of an ellipse (with the definition of "vertice" stretched in this case to mean the 4 locations representing locally maximum distances from the center of the ellipse). Perhaps that's too much of a stretch, but I think it points to the fact that we might think a bit longer about what cell "shapes" might be need to specified. Should we specify, for example, that for a particular latitude-longitude grid the grid cell latitude bounds might follow latitude circles, while the longitude bounds follow great circles along lines of longitude? In the measurement examples provided as motivation for extending the definition of cell bounds to include ellipses, the cell shapes were in fact only *approximately* represented by an ellipse, so should the description include this information to distinguish it from a true ellipse (i.e., should we use the words "approximate ellipse" rather than "ellipse")? Best regards, Karl On 19-Feb-10 6:45 AM, Bryan Lawrence wrote: > hi Thomas > > I think Nan's right that four points is enough to unambiguously define an ellipse, but how do we know it's an ellipse? > > We get the vertices from cell bounds > We get the area from cell measures > > The only thing missing is the knowledge that the bounds need to be interpreted as ellipse coordinates rather than a polygon when plotting or something more sophisticated. > > There are at least two possible routes: > a) while long_name is not required for a boundary variable, we could use it to say it's an elllipse, or > b) We extend cell_measures or cell_methods. My preference would be the latter, so we could add ellipse or FOV or something like that to appendix E (I haven't thought this through in detail yet, I was hoping someone else would suggest something). > > Cheers > Bryan > > On Friday 19 February 2010 14:15:47 Thomas Lavergne wrote: > >> Hei Nan and Bryan, >> >> Indeed, as far as I see it, you could not specify or reproduce this shape since you do not know it is an ellipse. It might furthermore be slanted with respect to the axis, which requires an extra piece of information. >> >> Bryan, did I miss something or you haven't yet proposed your "slight modification"? I am all ears :-) >> >> Thomas >> >> ----- "Bryan Lawrence" wrote: >> >> >>> Hi Nan >>> >>> ... but you couldn't plot this properly because you don't know that >>> it's an ellipse ... which is why I would suggest a very slight >>> modification to add that particular piece of metadata ... (or am I >>> missing something) >>> >>> Cheers >>> Bryan >>> >>> On Thursday 18 February 2010 14:36:05 Nan Galbraith wrote: >>> >>>> Four coordinates and an area is enough to define an ellipse; if >>>> these are more complex shapes, that's another problem. >>>> >>>> As long as these are ellipses, the existing convention should work; >>>> >>> you'd >>> >>>> give the n/s e/w extremes of the disc in lat(cell), lon(cell) and >>>> >>> use >>> >>>> cell_measures = "area: cell_area" after calculating the area from >>>> >>> the >>> >>>> lengths >>>> of the major& minor axes. >>>> >>>> Maybe my geometry is even rustier than I thought, otherwise this >>>> >>> should >>> >>>> work as it exists in the standard. >>>> >>>> >>>> >>>>> The vertices of the cells can be stored in the variable identified >>>>> >>> by >>> >>>>> the bounds >>>>> attribute, but the cell perimeter is not uniquely defined by its >>>>> vertices (because >>>>> the vertices could, for example, be connected by straight lines, >>>>> >>> or, >>> >>>>> on a sphere, >>>>> by lines following a great circle, or, in general, in some other >>>>> >>> way). >>> >>>> - Nan >>>> >>>> >>>> >>>>> On Wednesday 17 February 2010 13:36:21 Thomas Lavergne wrote: >>>>> >>>>> >>>>>> Dear all, >>>>>> >>>>>> I do not think someone reacted on my concern/question about >>>>>> >>> non-polygonal cell boundaries. Maybe I am the only one with this issue >>> or maybe this topic went un-noticed because of heavy load on the CF >>> list at that time. >>> >>>>>> I thus re-post my original message in hope that someone will >>>>>> >>> comment on it (or point me to an archived thread that I did not yet >>> see). >>> >>>>>> Original post: >>>>>> >>>>>> >>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> I refer to Chapter 7 on "Data Representative of Cells", 7.1 >>>>>>> >>> "Cell >>> >>>>>>> Boundaries". >>>>>>> >>>>>>> The specification of those boundaries seems to biased towards >>>>>>> polygonal boundaries (in the case of a 2D surface). This covers >>>>>>> certainly most of the needs but what happens if the cell is >>>>>>> >>> defined as >>> >>>>>>> a disc of radius x km (with center at the coordinate value)? >>>>>>> >>>>>>> Of course, I can always give 10 to 10,000 vertices that will >>>>>>> approximate my disc but it does not sound very neat nor >>>>>>> >>> efficient. We >>> >>>>>>> would have to somehow move away from listing the 'bounds' and >>>>>>> >>> start >>> >>>>>>> describing the shape of the cell (disc, ellipse, rectangle, >>>>>>> >>> etc...). >>> >>>>>>> Note that the concepts of "cell measures" and "cell methods" >>>>>>> >>> would >>> >>>>>>> still perfectly hold. >>>>>>> >>>>>>> One example of such a dataset would be one where at each grid >>>>>>> >>> location >>> >>>>>>> we report the mean/minimum/maximum temperature or pressure >>>>>>> >>> recorded by >>> >>>>>>> any station found in a radius of, say, 30 km around the central >>>>>>> point. >>>>>>> >>>>>>> Another example is satellite data in swath projection where >>>>>>> >>> each >>> >>>>>>> record is associated to a Field Of View, which is often >>>>>>> >>> approximated >>> >>>>>>> as a an ellipse. >>>>>>> >>>>>>> Did someone give it a thought already? >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> CF-metadata mailing list >>>>>> CF-metadata at cgd.ucar.edu >>>>>> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> -- >>> Bryan Lawrence >>> Director of Environmental Archival and Associated Research >>> (NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC) >>> STFC, Rutherford Appleton Laboratory >>> Phone +44 1235 445012; Fax ... 5848; >>> Web: home.badc.rl.ac.uk/lawrence >>> >> > > > From t.lavergne at met.no Fri Feb 19 11:47:20 2010 From: t.lavergne at met.no (Thomas Lavergne) Date: Fri, 19 Feb 2010 18:47:20 +0000 (UTC) Subject: [CF-metadata] Questions on cell boundaries In-Reply-To: <316679807.378413.1266604059333.JavaMail.root@imap1b> Message-ID: <1954820574.378462.1266605240928.JavaMail.root@imap1b> Dear Karl, I agree with the points you made and do not think we will get along with simple changes and yet cover all the possibilities. I also like your remark that the lines connecting the vertices are not necessarily straight lines in CF. However, you write: > In the measurement examples provided as motivation for extending the > definition of cell bounds to include ellipses, the cell shapes were in > fact only *approximately* represented by an ellipse, so should the > description include this information to distinguish it from a true > ellipse (i.e., should we use the words "approximate ellipse" rather > than "ellipse")? My original post contained two examples: > One example of such a dataset would be one where at each grid location > we report the mean/minimum/maximum temperature or pressure recorded by > any station found in a radius of, say, 30 km around the central > point. > > Another example is satellite data in swath projection where each > record is associated to a Field Of View, which is often approximated > as a an ellipse. The first one has no "approximation" in it. It only reflects a different (but not very rare) way of collecting information around a point. A circle instead of a cell in cartesian coordinates. As far as this example is concerned, we could maybe manage with some attribute stating that the connecting lines are "circular" (with constant 2nd curvature) and provide two points only. The cell is defined by the interior of this domain. Alternatively, we could give only one point, but specify that the cell is centered at the point given by the coordinates values. This would also work for ellipses (3 points are enough, right?) and we could extend this to 3D. Definitions would then rely on some maths (is that topology?) and we would probably have to limit ourselves to the most obvious shapes, still covering arbitrarily shaped polygons, circles and ellipses. As far as the second example is concerned, you are right, it is only an approximation. However, I mean that if the data provider wants to approximate the FOV by an ellipse (his choice), the CF convention should maybe provide a vocabulary for that. The question is then if CF wants to strongly specify the shape of the cell or does it merely encourage users to approximate any shape with a sufficient number of vertices, report the exact area and use freely formatted comments for describing those cells. It would serve most of the purpose of describing the data collection method to a human reader but would not allow for efficient interpretation by specialized software. Cheers, Thomas From V.Balaji at noaa.gov Fri Feb 19 12:45:18 2010 From: V.Balaji at noaa.gov (V. Balaji) Date: Fri, 19 Feb 2010 14:45:18 -0500 (EST) Subject: [CF-metadata] Questions on cell boundaries In-Reply-To: <1954820574.378462.1266605240928.JavaMail.root@imap1b> References: <1954820574.378462.1266605240928.JavaMail.root@imap1b> Message-ID: The gridspec doc (which hasn't yet been vetted by CF) does indeed contain a specification of arc_type, how you draw a line between vertices, specified by a controlled vocabulary: great_circle, small_circle, etc. It's needed for regridding. If the need is only a correct specification of areas and volumes for doing integrals, it would be enough for the creator of the data to write out the area they want you to use and specify it as a cell_measure. For swath data (where neighbouring pixels may have overlapping spheres of influence) would it make sense to even connect lines between the vertices? Thomas Lavergne writes: > Dear Karl, > > > I agree with the points you made and do not think we will get along with simple changes and yet cover all the possibilities. > > I also like your remark that the lines connecting the vertices are not necessarily straight lines in CF. > > However, you write: >> In the measurement examples provided as motivation for extending the >> definition of cell bounds to include ellipses, the cell shapes were in >> fact only *approximately* represented by an ellipse, so should the >> description include this information to distinguish it from a true >> ellipse (i.e., should we use the words "approximate ellipse" rather >> than "ellipse")? > > My original post contained two examples: >> One example of such a dataset would be one where at each grid location >> we report the mean/minimum/maximum temperature or pressure recorded by >> any station found in a radius of, say, 30 km around the central >> point. >> >> Another example is satellite data in swath projection where each >> record is associated to a Field Of View, which is often approximated >> as a an ellipse. > > The first one has no "approximation" in it. It only reflects a different (but not very rare) way of collecting information around a point. A circle instead of a cell in cartesian coordinates. > > As far as this example is concerned, we could maybe manage with some attribute stating that the connecting lines are "circular" (with constant 2nd curvature) and provide two points only. The cell is defined by the interior of this domain. Alternatively, we could give only one point, but specify that the cell is centered at the point given by the coordinates values. This would also work for ellipses (3 points are enough, right?) and we could extend this to 3D. > > Definitions would then rely on some maths (is that topology?) and we would probably have to limit ourselves to the most obvious shapes, still covering arbitrarily shaped polygons, circles and ellipses. > > As far as the second example is concerned, you are right, it is only an approximation. However, I mean that if the data provider wants to approximate the FOV by an ellipse (his choice), the CF convention should maybe provide a vocabulary for that. > > The question is then if CF wants to strongly specify the shape of the cell or does it merely encourage users to approximate any shape with a sufficient number of vertices, report the exact area and use freely formatted comments for describing those cells. It would serve most of the purpose of describing the data collection method to a human reader but would not allow for efficient interpretation by specialized software. > > Cheers, > Thomas > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -- 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 From j.m.gregory at reading.ac.uk Mon Feb 22 12:01:40 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Mon, 22 Feb 2010 19:01:40 +0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: <4B759656.2020306@noaa.gov> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk> <4B6B03F6.4090404@whoi.edu> <40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk> <4B702937.8060902@whoi.edu> <4B759656.2020306@noaa.gov> Message-ID: <20100222190140.GA18823@met.reading.ac.uk> Dear Jeff et al About >water_level_with|above_reference_datum >water_level_without_reference_datum I'd like to make some suggestions: * Since we don't have a convenient word for river, lake or sea, perhaps we should have separate names for each of them i.e. sea_surface_height, lake_surface_height and river_surface_height. All these terms are in use, often in connection with altimetry. Obviously the same duplication (or triplication) could occur with other sea-related names, but we have not had a great demand for terms related to lakes and rivers up to now. Even if we did, it would not be an unmanageable expansion of the standard name table. There are currently 284 standard names containing the word "sea". * If the datum is an arbitrary local benchmark, then I think a name of sea/lake/river_surface_height_above_reference_datum would be fine. If the datum itself needs to be located, we could have standard names for that such as sea/lake/river_surface_reference_datum_altitude. * If the datum is a quantity which could be regarded as a continuous function of location, I think it should be identified in the standard name, as in the existing sea_surface_height_above_geoid. Other standard names would thus be needed for sea_surface_height_above_mean_high_water etc. We also have an existing name of sea_surface_height_above_reference_ellipsoid. Here, the ellipsoid is not identified, but it can be with other CF metadata. I think that's OK because the geophysical intention of the reference ellipsoid is always the same, so this is in a sense a matter of measurement rather than the quantity itself. By contrast, mean high water is a different geophysical concept from the geoid. Best wishes Jonathan From j.m.gregory at reading.ac.uk Tue Feb 23 01:10:42 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 23 Feb 2010 08:10:42 +0000 Subject: [CF-metadata] two anomalous standard names Message-ID: <20100223081042.GA21674@met.reading.ac.uk> Dear Alison I suggest that these two standard names should be amended: moles_per_unit_mass_of_cfc11_in_sea_water -> moles_of_cfc11_per_unit_mass_in_sea_water The latter order is followed by all the other names i.e. moles_of_X_per_unit_mass_in_sea_water change_over_time_in_atmospheric_water_content_due_to_advection -> change_over_time_in_atmosphere_water_content_due_to_advection since this is the only standard name containing the word "atmospheric", and in other standard names we have phrases atmosphere[_...]_water_content I noticed these exceptions because I've been working on a method of inferring the "lexicon" from which the standard names are constructed. I hope to post some information about this soon. Cheers Jonathan From rkl at bodc.ac.uk Tue Feb 23 01:16:41 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Tue, 23 Feb 2010 08:16:41 +0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: <20100222190140.GA18823@met.reading.ac.uk> References: <4B5F6AF2.9030301@noaa.gov> <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk> <4B6B03F6.4090404@whoi.edu> <40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk> <4B702937.8060902@whoi.edu> <4B759656.2020306@noaa.gov> <20100222190140.GA18823@met.reading.ac.uk> Message-ID: <40829B0E077C1145A6DE44D39B3830A9088766A4A0@nerckwmb1.ad.nerc.ac.uk> Hello Jonathan, I have concerns about having separate names for river, lake and sea. If you have them for height, then the logic would extend to temperature. I have temperature data from a boat that started in the North Sea, went up the Humber and then up to the navigable limit of the Yorkshire Ouse. I would much prefer a single Standard Name across the whole dataset. My suggestion of 'water body' as the generic term didn't get any reaction. Was that acceptance or did nobody notice it? Cheers, Roy. -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory Sent: 22 February 2010 19:02 To: Jeff deLaBeaujardiere Cc: Andrea Hardy; cf-metadata at cgd.ucar.edu Subject: [CF-metadata] water level with/without datum Dear Jeff et al About >water_level_with|above_reference_datum >water_level_without_reference_datum I'd like to make some suggestions: * Since we don't have a convenient word for river, lake or sea, perhaps we should have separate names for each of them i.e. sea_surface_height, lake_surface_height and river_surface_height. All these terms are in use, often in connection with altimetry. Obviously the same duplication (or triplication) could occur with other sea-related names, but we have not had a great demand for terms related to lakes and rivers up to now. Even if we did, it would not be an unmanageable expansion of the standard name table. There are currently 284 standard names containing the word "sea". * If the datum is an arbitrary local benchmark, then I think a name of sea/lake/river_surface_height_above_reference_datum would be fine. If the datum itself needs to be located, we could have standard names for that such as sea/lake/river_surface_reference_datum_altitude. * If the datum is a quantity which could be regarded as a continuous function of location, I think it should be identified in the standard name, as in the existing sea_surface_height_above_geoid. Other standard names would thus be needed for sea_surface_height_above_mean_high_water etc. We also have an existing name of sea_surface_height_above_reference_ellipsoid. Here, the ellipsoid is not identified, but it can be with other CF metadata. I think that's OK because the geophysical intention of the reference ellipsoid is always the same, so this is in a sense a matter of measurement rather than the quantity itself. By contrast, mean high water is a different geophysical concept from the geoid. Best wishes Jonathan _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From j.m.gregory at reading.ac.uk Tue Feb 23 01:47:13 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 23 Feb 2010 08:47:13 +0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: <40829B0E077C1145A6DE44D39B3830A9088766A4A0@nerckwmb1.ad.nerc.ac.uk> References: <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk> <4B6B03F6.4090404@whoi.edu> <40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk> <4B702937.8060902@whoi.edu> <4B759656.2020306@noaa.gov> <20100222190140.GA18823@met.reading.ac.uk> <40829B0E077C1145A6DE44D39B3830A9088766A4A0@nerckwmb1.ad.nerc.ac.uk> Message-ID: <20100223084713.GA22783@met.reading.ac.uk> Dear Roy > I have concerns about having separate names for river, lake and sea. If you have them for height, then the logic would extend to temperature. I have temperature data from a boat that started in the North Sea, went up the Humber and then up to the navigable limit of the Yorkshire Ouse. I would much prefer a single Standard Name across the whole dataset. I share that concern, but I didn't have a use-case where it would be a problem to have separate names, so thanks for that. > My suggestion of 'water body' as the generic term didn't get any reaction. Was that acceptance or did nobody notice it? I noticed it, yes, thanks! It is a correct generic term, of course, but I feel it would cause a loss of clarity to replace "sea" with "water body" in existing standard names e.g. water_body_surface_height, water_body_water_temperature, water_body_water_speed and water_body_ice_thickness are all unfamiliar terms, whereas sea_surface_height, sea_water_temperature, sea_water_speed and sea_ice_thickness are all recognisable. In the particular case of Jeff's, "water body surface height" is not a term that Google finds, whereas "sea surface height", "lake surface height" and "river surface height" do all exist. More cumbersome than "water body", but clearer I think, would be to use the phrase "sea/lake/river" (I think "/" is a permitted character) e.g. sea/lake/river_surface_height, sea/lake/river_water_temperature. We could provide such names of this type as are requested, for generic uses like yours, but keep the "sea" names as well. In a case such as yours, would it be acceptable to use "sea" all the time, even when it's a river? Best wishes Jonathan From rkl at bodc.ac.uk Tue Feb 23 02:05:42 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Tue, 23 Feb 2010 09:05:42 +0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: <20100223084713.GA22783@met.reading.ac.uk> References: <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk> <4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk> <4B6B03F6.4090404@whoi.edu> <40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk> <4B702937.8060902@whoi.edu> <4B759656.2020306@noaa.gov> <20100222190140.GA18823@met.reading.ac.uk> <40829B0E077C1145A6DE44D39B3830A9088766A4A0@nerckwmb1.ad.nerc.ac.uk> <20100223084713.GA22783@met.reading.ac.uk> Message-ID: <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk> Hello again, I wouldn't recommend using '/' in a string, such as a Standard Name, that could potentially be incorporated into a URL. I think using 'sea' as defined shorthand for 'river/lake/sea' has been suggested before. I certainly have no problem with it as long as that information is included in the definition. Cheers, Roy. -----Original Message----- From: Jonathan Gregory [mailto:jonathan at met.reading.ac.uk] On Behalf Of Jonathan Gregory Sent: 23 February 2010 08:47 To: Lowry, Roy K Cc: Jeff deLaBeaujardiere; Andrea Hardy; cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] water level with/without datum Dear Roy > I have concerns about having separate names for river, lake and sea. If you have them for height, then the logic would extend to temperature. I have temperature data from a boat that started in the North Sea, went up the Humber and then up to the navigable limit of the Yorkshire Ouse. I would much prefer a single Standard Name across the whole dataset. I share that concern, but I didn't have a use-case where it would be a problem to have separate names, so thanks for that. > My suggestion of 'water body' as the generic term didn't get any reaction. Was that acceptance or did nobody notice it? I noticed it, yes, thanks! It is a correct generic term, of course, but I feel it would cause a loss of clarity to replace "sea" with "water body" in existing standard names e.g. water_body_surface_height, water_body_water_temperature, water_body_water_speed and water_body_ice_thickness are all unfamiliar terms, whereas sea_surface_height, sea_water_temperature, sea_water_speed and sea_ice_thickness are all recognisable. In the particular case of Jeff's, "water body surface height" is not a term that Google finds, whereas "sea surface height", "lake surface height" and "river surface height" do all exist. More cumbersome than "water body", but clearer I think, would be to use the phrase "sea/lake/river" (I think "/" is a permitted character) e.g. sea/lake/river_surface_height, sea/lake/river_water_temperature. We could provide such names of this type as are requested, for generic uses like yours, but keep the "sea" names as well. In a case such as yours, would it be acceptable to use "sea" all the time, even when it's a river? Best wishes Jonathan -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From philip.bentley at metoffice.gov.uk Tue Feb 23 02:25:08 2010 From: philip.bentley at metoffice.gov.uk (Bentley, Philip) Date: Tue, 23 Feb 2010 09:25:08 -0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk> References: <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk><4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk><4B6B03F6.4090404@whoi.edu><40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk><4B702937.8060902@whoi.edu><4B759656.2020306@noaa.gov> <20100222190140.GA18823@met.reading.ac.uk><40829B0E077C1145A6DE44D39B3830A9088766A4A0@nerckwmb1.ad.nerc.ac.uk><20100223084713.GA22783@met.reading.ac.uk> <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk> Message-ID: Hi Roy, Would simply inventing an artificial new term to represent sea+lakes+rivers be an option here? Presumably, back in the day, there was no word for a land-locked body of fresh water so someone thought, I know, I'll call it a 'lake'. Or whatever the latin/greek equivalent was back then! So we might choose, say, the word 'sorl', this being an acronym for seas, oceans, rivers and lakes. Sure that's not very pretty but no doubt someone can think of a better word. Answers on an e-postcard... Regards, Phil > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu > [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Lowry, Roy K > Sent: 23 February 2010 09:06 > To: Jonathan Gregory > Cc: Andrea Hardy; cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] water level with/without datum > > Hello again, > > I wouldn't recommend using '/' in a string, such as a > Standard Name, that could potentially be incorporated into a URL. > > I think using 'sea' as defined shorthand for 'river/lake/sea' > has been suggested before. I certainly have no problem with > it as long as that information is included in the definition. > > Cheers, Roy. > > -----Original Message----- > From: Jonathan Gregory [mailto:jonathan at met.reading.ac.uk] On > Behalf Of Jonathan Gregory > Sent: 23 February 2010 08:47 > To: Lowry, Roy K > Cc: Jeff deLaBeaujardiere; Andrea Hardy; cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] water level with/without datum > > Dear Roy > > > I have concerns about having separate names for river, lake > and sea. If you have them for height, then the logic would > extend to temperature. I have temperature data from a boat > that started in the North Sea, went up the Humber and then up > to the navigable limit of the Yorkshire Ouse. I would much > prefer a single Standard Name across the whole dataset. > > I share that concern, but I didn't have a use-case where it > would be a problem to have separate names, so thanks for that. > > > My suggestion of 'water body' as the generic term didn't > get any reaction. Was that acceptance or did nobody notice it? > > I noticed it, yes, thanks! It is a correct generic term, of > course, but I feel it would cause a loss of clarity to > replace "sea" with "water body" in existing standard names > e.g. water_body_surface_height, water_body_water_temperature, > water_body_water_speed and water_body_ice_thickness are all > unfamiliar terms, whereas sea_surface_height, > sea_water_temperature, sea_water_speed and sea_ice_thickness > are all recognisable. In the particular case of Jeff's, > "water body surface height" is not a term that Google finds, > whereas "sea surface height", "lake surface height" and > "river surface height" > do all exist. > > More cumbersome than "water body", but clearer I think, would > be to use the phrase "sea/lake/river" (I think "/" is a > permitted character) e.g. > sea/lake/river_surface_height, > sea/lake/river_water_temperature. We could provide such names > of this type as are requested, for generic uses like yours, > but keep the "sea" names as well. > > In a case such as yours, would it be acceptable to use "sea" > all the time, even when it's a river? > > Best wishes > > Jonathan > > -- > This message (and any attachments) is for the recipient only. > NERC is subject to the Freedom of Information Act 2000 and > the contents of this email and any reply you make may be > disclosed by NERC unless it is exempt from release under the > Act. Any material supplied to NERC may be stored in an > electronic records management system. > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > From rkl at bodc.ac.uk Tue Feb 23 04:19:04 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Tue, 23 Feb 2010 11:19:04 +0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: References: <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk><4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk><4B6B03F6.4090404@whoi.edu><40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk><4B702937.8060902@whoi.edu><4B759656.2020306@noaa.gov> <20100222190140.GA18823@met.reading.ac.uk><40829B0E077C1145A6DE44D39B3830A9088766A4A0@nerckwmb1.ad.nerc.ac.uk><20100223084713.GA22783@met.reading.ac.uk> <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk> Message-ID: <40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk> Hi Phil, Jonathan's argument against 'water body' was that it was not as well-known as 'sea'. I think that the argument applies even more strongly to 'sorl'. Cheers, Roy. -----Original Message----- From: Bentley, Philip [mailto:philip.bentley at metoffice.gov.uk] Sent: 23 February 2010 09:25 To: Lowry, Roy K Cc: cf-metadata at cgd.ucar.edu Subject: RE: [CF-metadata] water level with/without datum Hi Roy, Would simply inventing an artificial new term to represent sea+lakes+rivers be an option here? Presumably, back in the day, there was no word for a land-locked body of fresh water so someone thought, I know, I'll call it a 'lake'. Or whatever the latin/greek equivalent was back then! So we might choose, say, the word 'sorl', this being an acronym for seas, oceans, rivers and lakes. Sure that's not very pretty but no doubt someone can think of a better word. Answers on an e-postcard... Regards, Phil > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu > [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Lowry, Roy K > Sent: 23 February 2010 09:06 > To: Jonathan Gregory > Cc: Andrea Hardy; cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] water level with/without datum > > Hello again, > > I wouldn't recommend using '/' in a string, such as a > Standard Name, that could potentially be incorporated into a URL. > > I think using 'sea' as defined shorthand for 'river/lake/sea' > has been suggested before. I certainly have no problem with > it as long as that information is included in the definition. > > Cheers, Roy. > > -----Original Message----- > From: Jonathan Gregory [mailto:jonathan at met.reading.ac.uk] On > Behalf Of Jonathan Gregory > Sent: 23 February 2010 08:47 > To: Lowry, Roy K > Cc: Jeff deLaBeaujardiere; Andrea Hardy; cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] water level with/without datum > > Dear Roy > > > I have concerns about having separate names for river, lake > and sea. If you have them for height, then the logic would > extend to temperature. I have temperature data from a boat > that started in the North Sea, went up the Humber and then up > to the navigable limit of the Yorkshire Ouse. I would much > prefer a single Standard Name across the whole dataset. > > I share that concern, but I didn't have a use-case where it > would be a problem to have separate names, so thanks for that. > > > My suggestion of 'water body' as the generic term didn't > get any reaction. Was that acceptance or did nobody notice it? > > I noticed it, yes, thanks! It is a correct generic term, of > course, but I feel it would cause a loss of clarity to > replace "sea" with "water body" in existing standard names > e.g. water_body_surface_height, water_body_water_temperature, > water_body_water_speed and water_body_ice_thickness are all > unfamiliar terms, whereas sea_surface_height, > sea_water_temperature, sea_water_speed and sea_ice_thickness > are all recognisable. In the particular case of Jeff's, > "water body surface height" is not a term that Google finds, > whereas "sea surface height", "lake surface height" and > "river surface height" > do all exist. > > More cumbersome than "water body", but clearer I think, would > be to use the phrase "sea/lake/river" (I think "/" is a > permitted character) e.g. > sea/lake/river_surface_height, > sea/lake/river_water_temperature. We could provide such names > of this type as are requested, for generic uses like yours, > but keep the "sea" names as well. > > In a case such as yours, would it be acceptable to use "sea" > all the time, even when it's a river? > > Best wishes > > Jonathan > > -- > This message (and any attachments) is for the recipient only. > NERC is subject to the Freedom of Information Act 2000 and > the contents of this email and any reply you make may be > disclosed by NERC unless it is exempt from release under the > Act. Any material supplied to NERC may be stored in an > electronic records management system. > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From SEmsley at argans.co.uk Tue Feb 23 04:22:41 2010 From: SEmsley at argans.co.uk (Stephen Emsley) Date: Tue, 23 Feb 2010 11:22:41 +0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: <40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk> References: <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk><4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk><4B6B03F6.4090404@whoi.edu><40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk><4B702937.8060902@whoi.edu><4B759656.2020306@noaa.gov> <20100222190140.GA18823@met.reading.ac.uk><40829B0E077C1145A6DE44D39B3830A9088766A4A0@nerckwmb1.ad.nerc.ac.uk><20100223084713.GA22783@met.reading.ac.uk> <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk> <40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk> Message-ID: <5B828D1373752F43A43240B3EBF08FF30122384C4B@SVR-SBS2008.sbsnetwork.local> If I may make a suggestion that maintains the classical etymology and intuitive understanding ... the characteristic that applies to all of these water bodies is that they are water. Hence, I suggest that 'aqua' is both short, descriptive and pertinent. Kind Regards Steve -- Dr Stephen Emsley??????? ??????????????????????????????????????????????T: +44 (0)1752 764 289 ? ARGANS Limited????????????????????????????????????????????????????? ?M: +44 (0)7912 515 418 -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Lowry, Roy K Sent: 23 February 2010 11:19 To: Bentley, Philip Cc: cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] water level with/without datum Hi Phil, Jonathan's argument against 'water body' was that it was not as well-known as 'sea'. I think that the argument applies even more strongly to 'sorl'. Cheers, Roy. -----Original Message----- From: Bentley, Philip [mailto:philip.bentley at metoffice.gov.uk] Sent: 23 February 2010 09:25 To: Lowry, Roy K Cc: cf-metadata at cgd.ucar.edu Subject: RE: [CF-metadata] water level with/without datum Hi Roy, Would simply inventing an artificial new term to represent sea+lakes+rivers be an option here? Presumably, back in the day, there was no word for a land-locked body of fresh water so someone thought, I know, I'll call it a 'lake'. Or whatever the latin/greek equivalent was back then! So we might choose, say, the word 'sorl', this being an acronym for seas, oceans, rivers and lakes. Sure that's not very pretty but no doubt someone can think of a better word. Answers on an e-postcard... Regards, Phil > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu > [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Lowry, Roy K > Sent: 23 February 2010 09:06 > To: Jonathan Gregory > Cc: Andrea Hardy; cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] water level with/without datum > > Hello again, > > I wouldn't recommend using '/' in a string, such as a > Standard Name, that could potentially be incorporated into a URL. > > I think using 'sea' as defined shorthand for 'river/lake/sea' > has been suggested before. I certainly have no problem with > it as long as that information is included in the definition. > > Cheers, Roy. > > -----Original Message----- > From: Jonathan Gregory [mailto:jonathan at met.reading.ac.uk] On > Behalf Of Jonathan Gregory > Sent: 23 February 2010 08:47 > To: Lowry, Roy K > Cc: Jeff deLaBeaujardiere; Andrea Hardy; cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] water level with/without datum > > Dear Roy > > > I have concerns about having separate names for river, lake > and sea. If you have them for height, then the logic would > extend to temperature. I have temperature data from a boat > that started in the North Sea, went up the Humber and then up > to the navigable limit of the Yorkshire Ouse. I would much > prefer a single Standard Name across the whole dataset. > > I share that concern, but I didn't have a use-case where it > would be a problem to have separate names, so thanks for that. > > > My suggestion of 'water body' as the generic term didn't > get any reaction. Was that acceptance or did nobody notice it? > > I noticed it, yes, thanks! It is a correct generic term, of > course, but I feel it would cause a loss of clarity to > replace "sea" with "water body" in existing standard names > e.g. water_body_surface_height, water_body_water_temperature, > water_body_water_speed and water_body_ice_thickness are all > unfamiliar terms, whereas sea_surface_height, > sea_water_temperature, sea_water_speed and sea_ice_thickness > are all recognisable. In the particular case of Jeff's, > "water body surface height" is not a term that Google finds, > whereas "sea surface height", "lake surface height" and > "river surface height" > do all exist. > > More cumbersome than "water body", but clearer I think, would > be to use the phrase "sea/lake/river" (I think "/" is a > permitted character) e.g. > sea/lake/river_surface_height, > sea/lake/river_water_temperature. We could provide such names > of this type as are requested, for generic uses like yours, > but keep the "sea" names as well. > > In a case such as yours, would it be acceptable to use "sea" > all the time, even when it's a river? > > Best wishes > > Jonathan > > -- > This message (and any attachments) is for the recipient only. > NERC is subject to the Freedom of Information Act 2000 and > the contents of this email and any reply you make may be > disclosed by NERC unless it is exempt from release under the > Act. Any material supplied to NERC may be stored in an > electronic records management system. > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From philip.bentley at metoffice.gov.uk Tue Feb 23 04:32:16 2010 From: philip.bentley at metoffice.gov.uk (Bentley, Philip) Date: Tue, 23 Feb 2010 11:32:16 -0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: <40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk> References: <40829B0E077C1145A6DE44D39B3830A90886F59D45@nerckwmb1.ad.nerc.ac.uk><4B604DA3.2030504@noaa.gov> <20100202182255.GA19905@met.reading.ac.uk><4B6B03F6.4090404@whoi.edu><40829B0E077C1145A6DE44D39B3830A90886AB7269@nerckwmb1.ad.nerc.ac.uk><4B702937.8060902@whoi.edu><4B759656.2020306@noaa.gov> <20100222190140.GA18823@met.reading.ac.uk><40829B0E077C1145A6DE44D39B3830A9088766A4A0@nerckwmb1.ad.nerc.ac.uk><20100223084713.GA22783@met.reading.ac.uk> <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk> <40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk> Message-ID: Hi Roy, For sure, I wasn't proposing use of the word 'sorl', that was merely an examplar. My argument was that since there appears to be no existing term for what you want to describe - at least none without overloaded meaning(s) - then just invent a completely new word. So, yes, by its very nature it wouldn't be well-known on day 1! Cheers, Phil > -----Original Message----- > From: Lowry, Roy K [mailto:rkl at bodc.ac.uk] > Sent: 23 February 2010 11:19 > To: Bentley, Philip > Cc: cf-metadata at cgd.ucar.edu > Subject: RE: [CF-metadata] water level with/without datum > > Hi Phil, > > Jonathan's argument against 'water body' was that it was not > as well-known as 'sea'. I think that the argument applies > even more strongly to 'sorl'. > > Cheers, Roy. > > -----Original Message----- > From: Bentley, Philip [mailto:philip.bentley at metoffice.gov.uk] > Sent: 23 February 2010 09:25 > To: Lowry, Roy K > Cc: cf-metadata at cgd.ucar.edu > Subject: RE: [CF-metadata] water level with/without datum > > Hi Roy, > > Would simply inventing an artificial new term to represent > sea+lakes+rivers be an option here? Presumably, back in the day, there > was no word for a land-locked body of fresh water so someone > thought, I know, I'll call it a 'lake'. Or whatever the > latin/greek equivalent was back then! > > So we might choose, say, the word 'sorl', this being an > acronym for seas, oceans, rivers and lakes. Sure that's not > very pretty but no doubt someone can think of a better word. > Answers on an e-postcard... From j.m.gregory at reading.ac.uk Tue Feb 23 04:33:37 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 23 Feb 2010 11:33:37 +0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: <5B828D1373752F43A43240B3EBF08FF30122384C4B@SVR-SBS2008.sbsnetwork.local> References: <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk> <40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk> <5B828D1373752F43A43240B3EBF08FF30122384C4B@SVR-SBS2008.sbsnetwork.local> Message-ID: <20100223113337.GA23537@met.reading.ac.uk> Dear Stephen The issue here is that water doesn't only exist in these "bodies" of water viz seas, lakes and river. It also exists in the atmosphere and the ground. For this reason we don't have a standard name of just "water temperature", for instance. We could define "aqua" to mean "sea, lake or river", but this is not really any more self-explanatory than using an abbreviation, I'd say. Roy pointed out that / would be a dangerous character to use, so I'd next suggest sea+lake+river. I prefer + to - because - looks like _, and it's terribly confusing to have a mixture of - and _. I really would prefer defining "sea" to mean "sea, lake or river" but not everyone who's given an opinion would support that, and I agree that it's not really self-describing - it would be new jargon. Best wishes Jonathan From Jeff.deLaBeaujardiere at noaa.gov Tue Feb 23 07:11:24 2010 From: Jeff.deLaBeaujardiere at noaa.gov (Jeff deLaBeaujardiere) Date: Tue, 23 Feb 2010 09:11:24 -0500 Subject: [CF-metadata] water level with/without datum In-Reply-To: <20100223113337.GA23537@met.reading.ac.uk> References: <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk> <40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk> <5B828D1373752F43A43240B3EBF08FF30122384C4B@SVR-SBS2008.sbsnetwork.local> <20100223113337.GA23537@met.reading.ac.uk> Message-ID: <4B83E20C.1020405@noaa.gov> Dear CF group: Thank you for your time in discussing this matter. I would counsel you *not* to make wholesale changes to existing names just because IOOS needs names for water levels that may or may not be measured in the ocean! Replacing 'sea_' with something else seems like it would break much existing code. Adding some names should be mostly harmless. For the specific case of water-level measurement devices, I think the term water_level_* is better, applied generically regardless of oceanic, lacustrine or riverine environment, for the following reasons. * There is no other generic name, and inventing one like SLR or sea+lake+river seems contrived. * Every use of sea_level I can find in the CF name list refers to sea level as a semi-constant reference point rather than as an instantaneous measurement. Indeed, a comment used repeatedly in the CF table is that "sea_level means mean sea level, which is close to the geoid in sea areas." Therefore, separate names for sea_level_*, lake_level_ and river_level_* do not seem appropriate. * Yes, there is water in the atmosphere and underground. CF already seems to qualify those uses with terms like 'atmosphere', 'cloud' and 'in air.' Therefore, it does not seem necessary to qualify 'water' as being on the surface--simply retain the existing non-surface qualifiers. If you later need a name to refer to the level of water in an underground aquifer or something, then create one. Regarding the Use Case of measuring temperature in the sea and then continuing the trajectory upriver: there currently do not exist water_temperature names other than sea_water_temperature, so the Use Case is not satisfied at present. Perhaps in future CF could define additional generic names like water_temperature that may have specializations such as sea_water_temperature and fresh_water_temperature, but this can be done later and independently of the existing actual use case of water level measurements. Cheers, Jeff DLB -- Jeff de La Beaujardi?re, PhD Senior Systems Architect, Data Integration Framework Integrated Ocean Observing System (IOOS) Program Office National Oceanic and Atmospheric Administration 1100 Wayne Ave #1225, Silver Spring MD 20910 USA +1 301 427 2427 Jeff.deLaBeaujardiere at noaa.gov From j.m.gregory at reading.ac.uk Tue Feb 23 07:33:00 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 23 Feb 2010 14:33:00 +0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: <4B83E20C.1020405@noaa.gov> References: <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk> <40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk> <5B828D1373752F43A43240B3EBF08FF30122384C4B@SVR-SBS2008.sbsnetwork.local> <20100223113337.GA23537@met.reading.ac.uk> <4B83E20C.1020405@noaa.gov> Message-ID: <20100223143300.GB23914@met.reading.ac.uk> Dear Jeff Thanks for your email. I appreciate your arguments, which are very reasonable, but I don't agree with them so far. > Replacing 'sea_' with something else seems like it would > break much existing code. Adding some names should be mostly harmless. Yes, adding names is better. We can resolve this by keeping "sea" to mean "sea", and adding some other ones to refer to "sea, lake or river", as requested. We agree on that point. > For the specific case of water-level measurement devices, I think the term > water_level_* is better, applied generically regardless of oceanic, > lacustrine or riverine environment, for the following reasons. > > * There is no other generic name, and inventing one like SLR or > sea+lake+river seems contrived. Contrived, yes, but sea+lake+river is certainly explicit and self-explanatory, isn't it? Standard names are contrived to explain what they mean, rather than being the terms used most commonly (although some of them are common terms). The term "name" is a bit misleading. They are not names, in most cases. They are answers to the question, "What does that mean?", when a term is used. > * Every use of sea_level I can find in the CF name list refers to sea level > as a semi-constant reference point rather than as an instantaneous > measurement. Indeed, a comment used repeatedly in the CF table is that > "sea_level means mean sea level, which is close to the geoid in sea areas." > Therefore, separate names for sea_level_*, lake_level_ and river_level_* do > not seem appropriate. Yes, sea_level refers to a fixed level, like geoid, but the quantity you are referring to as water_level is more like sea_surface_height, which is a time-varying level, and is referred to a fixed level. I am proposing of sea+lake+river_surface_height_above_X for your water level, if it's not the sea. > * Yes, there is water in the atmosphere and underground. CF already seems > to qualify those uses with terms like 'atmosphere', 'cloud' and 'in air.' > Therefore, it does not seem necessary to qualify 'water' as being on the > surface--simply retain the existing non-surface qualifiers. If you later > need a name to refer to the level of water in an underground aquifer or > something, then create one. That gives a special status to water on the surface. CF names attempt to deal even-handedly with all geophysical quantities. Such an argument would mean that, in the first place, we would have used the plain name "temperature" to mean air temperature (since we started with atmospheric models, mostly), and later added sea_water_temperature. That would have been inconsistent and I believe that such inconsistencies would make standard names less satisfactory in practice. In general, we have tried to include some context in standard names. > Regarding the Use Case of measuring temperature in the sea and then > continuing the trajectory upriver: there currently do not exist > water_temperature names other than sea_water_temperature, so the Use Case > is not satisfied at present. Perhaps in future CF could define additional > generic names like water_temperature that may have specializations such as > sea_water_temperature and fresh_water_temperature, but this can be done > later and independently of the existing actual use case of water level > measurements. I think Roy's example is a relevant use case. Although he has not made a proposal, his data set requires either a new name of river_water_temperature, or a name which can be used for both sea and river. The existing name of sea_water_temperature is not sufficient for the case he described. Best wishes Jonathan From Roland.Schweitzer at noaa.gov Tue Feb 23 08:10:59 2010 From: Roland.Schweitzer at noaa.gov (Roland Schweitzer) Date: Tue, 23 Feb 2010 09:10:59 -0600 Subject: [CF-metadata] Some questions about 360-day calendars In-Reply-To: <4B76B98D.6050704@unidata.ucar.edu> References: <7CD7F00F17085C4EBB045A35177C85FDB9C8B6@VIME-VS1.rdg-home.ad.rdg.ac.uk> <4B76B98D.6050704@unidata.ucar.edu> Message-ID: <4B83F003.4040706@noaa.gov> john caron wrote: > Jonathan Blower wrote: >> 4) Finally on practical note: I seem to remember that someone has >> implemented the 360-day calendar using the Java library joda-time? Is >> this code available for re-use? >> > roland schweitzer has extended joda for 360 day calendar. I am > planning to use joda time or its JSR successor in the future, > replacing udunits for date/time processing. To give credit where due, Emanuele Lombardi actually did the 360 calendar. I did the all-leap and no-leap. :-) I have all three and will gladly share them with anybody that wants them. I did send them to the joda folks, but I did not follow up to see if they went into their source tree. ROland From jbgraybeal at mindspring.com Wed Feb 24 00:17:24 2010 From: jbgraybeal at mindspring.com (John Graybeal) Date: Tue, 23 Feb 2010 23:17:24 -0800 Subject: [CF-metadata] water level with/without datum In-Reply-To: <20100223143300.GB23914@met.reading.ac.uk> References: <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk> <40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk> <5B828D1373752F43A43240B3EBF08FF30122384C4B@SVR-SBS2008.sbsnetwork.local> <20100223113337.GA23537@met.reading.ac.uk> <4B83E20C.1020405@noaa.gov> <20100223143300.GB23914@met.reading.ac.uk> Message-ID: On Feb 23, 2010, at 06:33, Jonathan Gregory wrote: > Contrived, yes, but sea+lake+river is certainly explicit and self- > explanatory, > isn't it? Standard names are contrived to explain what they mean, > rather than > being the terms used most commonly (although some of them are common > terms). > The term "name" is a bit misleading. They are not names, in most > cases. They > are answers to the question, "What does that mean?", when a term is > used. water_surface_height_above_x seems to meet all the criteria. It answers "what does that mean?" It is explicit and self-explanatory (and even reasonably short). Thanks to the 'surface' term, it can not be confused with 'atmospheric surface water height' (what would that mean?). The fact that it also applies to underground water is a non-issue, scientifically speaking, and in my mind is advantageous, because it is equally meaningful in that context. (Two data sets with this term can be compared, regardless of whether the water is underground or not -- the x normalized the reference, as does the location.) I can even construct a valid use case (for an AUV or hydro model) that is the analog of Roy's, in the case of underground streams feeding into oceans or rivers. I could handle sea+lake+river but it doesn't thrill me, because of (a) special characters which can have unintended consequences for times now and yet to come, (b) 'sea' is not self-explanatory until you know it really means ocean (in some local dialects) and excludes inland seas (or maybe not?), and (c) awkwardness. Not a preference but if all others get ruled out, there we'd be. John From cameronsmith1 at llnl.gov Wed Feb 24 11:29:31 2010 From: cameronsmith1 at llnl.gov (Philip J. Cameronsmith1) Date: Wed, 24 Feb 2010 10:29:31 -0800 (PST) Subject: [CF-metadata] water level with/without datum In-Reply-To: References: <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk> <40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk> <5B828D1373752F43A43240B3EBF08FF30122384C4B@SVR-SBS2008.sbsnetwork.local> <20100223113337.GA23537@met.reading.ac.uk> <4B83E20C.1020405@noaa.gov> <20100223143300.GB23914@met.reading.ac.uk> Message-ID: On Tue, 23 Feb 2010, John Graybeal wrote: > > On Feb 23, 2010, at 06:33, Jonathan Gregory wrote: > >> Contrived, yes, but sea+lake+river is certainly explicit and >> self-explanatory, >> isn't it? Standard names are contrived to explain what they mean, rather >> than >> being the terms used most commonly (although some of them are common >> terms). >> The term "name" is a bit misleading. They are not names, in most cases. >> They >> are answers to the question, "What does that mean?", when a term is used. > > > water_surface_height_above_x seems to meet all the criteria. It answers "what > does that mean?" It is explicit and self-explanatory (and even reasonably > short). > > Thanks to the 'surface' term, it can not be confused with 'atmospheric > surface water height' (what would that mean?). > > The fact that it also applies to underground water is a non-issue, > scientifically speaking, and in my mind is advantageous, because it is > equally meaningful in that context. (Two data sets with this term can be > compared, regardless of whether the water is underground or not -- the x > normalized the reference, as does the location.) I can even construct a > valid use case (for an AUV or hydro model) that is the analog of Roy's, in > the case of underground streams feeding into oceans or rivers. > > I could handle sea+lake+river but it doesn't thrill me, because of (a) > special characters which can have unintended consequences for times now and > yet to come, (b) 'sea' is not self-explanatory until you know it really means > ocean (in some local dialects) and excludes inland seas (or maybe not?), and > (c) awkwardness. Not a preference but if all others get ruled out, there we'd > be. > > John Hi John, Your suggestion does seem to have a lot of merits, and addresses many of the concerns I've seen raised. You mention using water_surface for underground streams. Could it also be used for ground water table? I presume it could, but I'm no expert. I couldn't find a water table quantity in the standard name table, and I'm sure it would be useful. If so, then this would be an added benefit. Yours truly, Philip ------------------------------------------------------------------------ Dr Philip Cameron-Smith Atmospheric, Earth, and Energy Division pjc at llnl.gov Lawrence Livermore National Laboratory +1 925 4236634 7000 East Avenue, Livermore, CA94550, USA ------------------------------------------------------------------------ From j.m.gregory at reading.ac.uk Thu Feb 25 03:16:18 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Thu, 25 Feb 2010 10:16:18 +0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: References: <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk> <40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk> <5B828D1373752F43A43240B3EBF08FF30122384C4B@SVR-SBS2008.sbsnetwork.local> <20100223113337.GA23537@met.reading.ac.uk> <4B83E20C.1020405@noaa.gov> <20100223143300.GB23914@met.reading.ac.uk> Message-ID: <20100225101618.GA3112@met.reading.ac.uk> Dear John et al. > water_surface_height_above_x seems to meet all the criteria. I agree, this would be fine for Jeff's need. Thanks for suggesting it. It is like sea_surface_height_above_X, which already exists, and "surface" disambiguates it. It does not solve the general problem, illustrated by Roy's use case. We will not be able to use "surface" for properties measured *within* the water, such as temperature, velocity, etc., as that would be confusing. But, as is our usual habit, we can postpone trying to solve that problem until someone definitely requests a standard name which raises it. In that case, we'd probably have to return to the sea/lake/river debate. > I could handle sea+lake+river but it doesn't thrill me, because of (a) > special characters which can have unintended consequences for times > now and yet to come, (b) 'sea' is not self-explanatory until you know > it really means ocean (in some local dialects) and excludes inland > seas (or maybe not?), and (c) awkwardness. Not a preference but if all > others get ruled out, there we'd be. Yes, I actually agree. As for (a), maybe sea_lake_river would be better. "Sea" means ocean or sea in CF names - any body of water which is connected to the world ocean. Best wishes Jonathan From ngalbraith at whoi.edu Thu Feb 25 09:46:55 2010 From: ngalbraith at whoi.edu (Nan Galbraith) Date: Thu, 25 Feb 2010 11:46:55 -0500 Subject: [CF-metadata] water level with/without datum In-Reply-To: <20100225101618.GA3112@met.reading.ac.uk> References: <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk> <40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk> <5B828D1373752F43A43240B3EBF08FF30122384C4B@SVR-SBS2008.sbsnetwork.local> <20100223113337.GA23537@met.reading.ac.uk> <4B83E20C.1020405@noaa.gov> <20100223143300.GB23914@met.reading.ac.uk> <20100225101618.GA3112@met.reading.ac.uk> Message-ID: <4B86A97F.7010805@whoi.edu> Agreed, water_surface_height_above_x is perfect. And simple, as Jeff pointed out earlier this week. > I think Roy's example is a relevant use case. Although he has not made a > proposal, his data set requires either a new name of river_water_temperature, > or a name which can be used for both sea and river. The existing name of > sea_water_temperature is not sufficient for the case he described. > Roy's example shows the need for a *single name* that can be used for both sea and river temperature, not different names, if I understand his description correctly. I'd like to extend the use of this prospective term to sub-surface water bodies, which, like rivers, don't always have clear boundaries. We have ROVs that travel from lakes and reservoirs through subsurface passages; I don't see any reason to (or reasonable way to) split up the measurements made by these instruments based on which side of an invisible line they're on at any given point. So, I think 'water' is far better than 'sea_lake_river_water'. There are several names that use the modifiers 'atmosphere', 'in_air' and 'surface' to indicate water that's not part of a water body. Does this imply that the unmodified term 'water' means water that's in a water body? The only names I can find that use plain 'water' seem to be sound_intensity and sound_pressure terms - I assume these refer to water in a water body? Is that enough of a precedent to suggest that water_temperature, _velocity, _salinity, etc etc could be standard names for properties of the water in bodies of water? Cheers - Nan >> water_surface_height_above_x seems to meet all the criteria. >> > > -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* From ksshannon at gmail.com Thu Feb 25 10:14:20 2010 From: ksshannon at gmail.com (Kyle Shannon) Date: Thu, 25 Feb 2010 10:14:20 -0700 Subject: [CF-metadata] Adding tags to CF-1.x In-Reply-To: References: Message-ID: Is this the proper forum to request that a tag be added to the CF-1.x conventions? In the interest of usability, I would like to see a tag that contains an Open Geospatial Consortium WKT representation of the Spatial Reference System under grid_mapping_name example grid_mapping_name:spatial_ref lambert_conformal_conic:spatial_ref = "PROJCS["unnamed",GEOGCS["unknown",DATUM["unknown",SPHEROID["Sphere",6371200,0]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",33],PARAMETER["standard_parallel_2",45],PARAMETER["latitude_of_origin",40],PARAMETER["central_meridian",0],PARAMETER["false_easting",0],PARAMETER["false_northing",0]]" This is a well defined standard, and can be read by many applications on the fly. It is slightly redundant, but it may improve usability. a link to ogc simple features standards, spatial ref is in the pdf here: http://www.opengeospatial.org/standards/sfa Thanks. -Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkl at bodc.ac.uk Fri Feb 26 02:13:06 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Fri, 26 Feb 2010 09:13:06 +0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: <4B86A97F.7010805@whoi.edu> References: <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk> <40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk> <5B828D1373752F43A43240B3EBF08FF30122384C4B@SVR-SBS2008.sbsnetwork.local> <20100223113337.GA23537@met.reading.ac.uk> <4B83E20C.1020405@noaa.gov> <20100223143300.GB23914@met.reading.ac.uk> <20100225101618.GA3112@met.reading.ac.uk> <4B86A97F.7010805@whoi.edu> Message-ID: <40829B0E077C1145A6DE44D39B3830A90887775C6E@nerckwmb1.ad.nerc.ac.uk> Hi Nan, Using unqualified 'water' to signify water within a water body works for me. Cheers, Roy. -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Nan Galbraith Sent: 25 February 2010 16:47 To: Jonathan Gregory Cc: John Graybeal; cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] water level with/without datum Agreed, water_surface_height_above_x is perfect. And simple, as Jeff pointed out earlier this week. > I think Roy's example is a relevant use case. Although he has not made a > proposal, his data set requires either a new name of river_water_temperature, > or a name which can be used for both sea and river. The existing name of > sea_water_temperature is not sufficient for the case he described. > Roy's example shows the need for a *single name* that can be used for both sea and river temperature, not different names, if I understand his description correctly. I'd like to extend the use of this prospective term to sub-surface water bodies, which, like rivers, don't always have clear boundaries. We have ROVs that travel from lakes and reservoirs through subsurface passages; I don't see any reason to (or reasonable way to) split up the measurements made by these instruments based on which side of an invisible line they're on at any given point. So, I think 'water' is far better than 'sea_lake_river_water'. There are several names that use the modifiers 'atmosphere', 'in_air' and 'surface' to indicate water that's not part of a water body. Does this imply that the unmodified term 'water' means water that's in a water body? The only names I can find that use plain 'water' seem to be sound_intensity and sound_pressure terms - I assume these refer to water in a water body? Is that enough of a precedent to suggest that water_temperature, _velocity, _salinity, etc etc could be standard names for properties of the water in bodies of water? Cheers - Nan >> water_surface_height_above_x seems to meet all the criteria. >> > > -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From j.m.gregory at reading.ac.uk Fri Feb 26 02:41:55 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 26 Feb 2010 09:41:55 +0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: <4B86A97F.7010805@whoi.edu> References: <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk> <40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk> <5B828D1373752F43A43240B3EBF08FF30122384C4B@SVR-SBS2008.sbsnetwork.local> <20100223113337.GA23537@met.reading.ac.uk> <4B83E20C.1020405@noaa.gov> <20100223143300.GB23914@met.reading.ac.uk> <20100225101618.GA3112@met.reading.ac.uk> <4B86A97F.7010805@whoi.edu> Message-ID: <20100226094155.GA5904@met.reading.ac.uk> Dear Nan > >I think Roy's example is a relevant use case. Although he has not made a > >proposal, his data set requires either a new name of > >river_water_temperature, > >or a name which can be used for both sea and river. The existing name of > >sea_water_temperature is not sufficient for the case he described. > > Roy's example shows the need for a *single name* that can be used for > both sea and river temperature, not different names, if I understand his > description correctly. That's right. He needs a single name which covers sea and river. > I don't see any reason to (or reasonable way to) split up the measurements > made by these instruments based on which side of an invisible line they're > on at any given point. Yes. In some applications it is artificial to distinguish between sea, lake, reservoir, river etc. > There are several names that use the modifiers 'atmosphere', 'in_air' and > 'surface' to indicate water that's not part of a water body. Does this imply > that the unmodified term 'water' means water that's in a water body? > > The only names I can find that use plain 'water' seem to be sound_intensity > and sound_pressure terms - I assume these refer to water in a water body? > Is that enough of a precedent to suggest that water_temperature, _velocity, > _salinity, etc etc could be standard names for properties of the water in > bodies of water? I don't remember the intention of those standard names. I am surprised that they don't say "sea" or "river" if that's what they meant. I am sorry to be obstinate on this, but I don't think that it would be right to assume that "water" without any qualifier meant water that is part of a water body. As I said in a previous email, we always try to indicate the context explicitly in standard names, to make them self-describing. This use of "water" would be a kind of definition by omission, rather than explicitly. I think that our discussion so far indicates that we should keep the existing "sea" names, and add corresponding new names for water bodies in general (as and when they are requested). We can likewise add new "sea" names. Therefore I think we have to decide what to call the new names. Roy suggested water body. As I've said before, I would prefer sea/lake/river_water (or with some other punctuation) to water_body_water, because sea/lake/river_water is more self-explanatory, and the repetition of "water" in water_body_water is clumsy and possibly confusing. I can imagine someone not being sure how to parse "water body water temperature" when they first come across it. As Roy said, "/" could be a problem, although it's legal for netCDF. It does make the intention clearer, since "/" means "or". It could be spelled out, at the cost of greater length, as sea_or_lake_or_river_water. best wishes Jonathan From Jeff.deLaBeaujardiere at noaa.gov Fri Feb 26 07:50:01 2010 From: Jeff.deLaBeaujardiere at noaa.gov (Jeff deLaBeaujardiere) Date: Fri, 26 Feb 2010 09:50:01 -0500 Subject: [CF-metadata] water level with/without datum In-Reply-To: <4B86A97F.7010805@whoi.edu> References: <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk> <40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk> <5B828D1373752F43A43240B3EBF08FF30122384C4B@SVR-SBS2008.sbsnetwork.local> <20100223113337.GA23537@met.reading.ac.uk> <4B83E20C.1020405@noaa.gov> <20100223143300.GB23914@met.reading.ac.uk> <20100225101618.GA3112@met.reading.ac.uk> <4B86A97F.7010805@whoi.edu> Message-ID: <4B87DF99.2040707@noaa.gov> Hello- After more internal discussion we feel that the single name 'water_surface_height_above_reference_datum' would meet our needs admirably (i.e., no separate name for the "station datum" case). Thank you, Jeff DLB Nan Galbraith wrote: > Agreed, water_surface_height_above_x is perfect. And simple, > as Jeff pointed out earlier this week. >> I think Roy's example is a relevant use case. Although he has not made a >> proposal, his data set requires either a new name of >> river_water_temperature, >> or a name which can be used for both sea and river. The existing name of >> sea_water_temperature is not sufficient for the case he described. >> > > Roy's example shows the need for a *single name* that can be used for > both sea and river temperature, not different names, if I understand his > description correctly. > I'd like to extend the use of this prospective term to sub-surface water > bodies, which, like rivers, don't always have clear boundaries. We have > ROVs that travel from lakes and reservoirs through subsurface passages; > I don't see any reason to (or reasonable way to) split up the measurements > made by these instruments based on which side of an invisible line they're > on at any given point. > > So, I think 'water' is far better than 'sea_lake_river_water'. > There are several names that use the modifiers 'atmosphere', 'in_air' and > 'surface' to indicate water that's not part of a water body. Does this > imply > that the unmodified term 'water' means water that's in a water body? > > The only names I can find that use plain 'water' seem to be sound_intensity > and sound_pressure terms - I assume these refer to water in a water body? > Is that enough of a precedent to suggest that water_temperature, _velocity, > _salinity, etc etc could be standard names for properties of the water in > bodies of water? > > Cheers - > Nan > > > >>> water_surface_height_above_x seems to meet all the criteria. >>> >> >> > > From j.m.gregory at reading.ac.uk Fri Feb 26 08:13:21 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 26 Feb 2010 15:13:21 +0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: <4B87DF99.2040707@noaa.gov> References: <40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk> <5B828D1373752F43A43240B3EBF08FF30122384C4B@SVR-SBS2008.sbsnetwork.local> <20100223113337.GA23537@met.reading.ac.uk> <4B83E20C.1020405@noaa.gov> <20100223143300.GB23914@met.reading.ac.uk> <20100225101618.GA3112@met.reading.ac.uk> <4B86A97F.7010805@whoi.edu> <4B87DF99.2040707@noaa.gov> Message-ID: <20100226151321.GA8802@met.reading.ac.uk> Dear Jeff > After more internal discussion we feel that the single name > 'water_surface_height_above_reference_datum' would meet our needs admirably > (i.e., no separate name for the "station datum" case). Very good. Is this an arbitrary local reference datum? I think that would be the right name, if so. If it's the geoid or some tide level, I think that should be indicated in the name. That's because quantities with these different datums do not differ by a constant, and could not be regarded as the same geophysical quantity, so should have different standard names. Best wishes Jonathan From mcginnis at ucar.edu Fri Feb 26 20:50:59 2010 From: mcginnis at ucar.edu (Seth McGinnis) Date: Fri, 26 Feb 2010 20:50:59 -0700 Subject: [CF-metadata] water level with/without datum In-Reply-To: <20100226094155.GA5904@met.reading.ac.uk> References: <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk> <40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk> <5B828D1373752F43A43240B3EBF08FF30122384C4B@SVR-SBS2008.sbsnetwork.local> <20100223113337.GA23537@met.reading.ac.uk> <4B83E20C.1020405@noaa.gov> <20100223143300.GB23914@met.reading.ac.uk> <20100225101618.GA3112@met.reading.ac.uk> <4B86A97F.7010805@whoi.edu> <20100226094155.GA5904@met.reading.ac.uk> Message-ID: >Therefore I think we have to decide what to call the new names. Roy suggested >water body. As I've said before, I would prefer sea/lake/river_water (or with >some other punctuation) to water_body_water, because sea/lake/river_water is >more self-explanatory, and the repetition of "water" in water_body_water is >clumsy and possibly confusing. I can imagine someone not being sure how to >parse "water body water temperature" when they first come across it. Instead of a prefix modifer, how about adding _body as a postfix modifier? So you could have sea_water_temperature for oceans and water_body_temperature for oceans, rivers, lakes, and other significant accumulations of liquid water. Cheers, ---- Seth McGinnis NARCCAP Data Manager ISSE / ISP / IMAGe / CISL / NCAR ---- (P.S.: Observation/tangent: It seems like this conundrum may be arising in part because the day-to-day meaning of the term "water" -- liquid H2O -- is at odds with the definition given in the standard name guidelines of "water in all phases if not otherwise qualified". Were there a blank slate, I would suggest using the unqualified term to mean "liquid water", in better alignment with its commonsense meaning, and coming up with a new term for the more restricted contexts where one needs to refer to all three phases. How frequently in current usage does the "all phases" sense differ fom the usual sense? Would it be worth considering a switch? That would be an alternate way around the issue of generic water bodies.) From r.s.hatcher at reading.ac.uk Mon Mar 1 08:43:24 2010 From: r.s.hatcher at reading.ac.uk (Rosalyn Hatcher) Date: Mon, 01 Mar 2010 15:43:24 +0000 Subject: [CF-metadata] CF Checker Upgraded Message-ID: <4B8BE09C.4030106@reading.ac.uk> Dear All, I have recently upgraded the CF Checker to work with CDAT-5.2, UDUNITS-2 and NetCDF-4.0 The latest release can be found on the PUMA server at: http://puma.nerc.ac.uk/cgi-bin/cf-checker.pl Please give it try and let me know of any issues or equally to tell me it works just fine. ;-) Once it's had a reasonable work-out I'll release it officially and ask Alison to update the version available from the BADC server. Regards, Rosalyn. From olauret at cls.fr Mon Mar 1 09:07:58 2010 From: olauret at cls.fr (olivier lauret) Date: Mon, 1 Mar 2010 17:07:58 +0100 Subject: [CF-metadata] water level with/without datum In-Reply-To: References: <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk><40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk><5B828D1373752F43A43240B3EBF08FF30122384C4B@SVR-SBS2008.sbsnetwork.local><20100223113337.GA23537@met.reading.ac.uk><4B83E20C.1020405@noaa.gov><20100223143300.GB23914@met.reading.ac.uk><20100225101618.GA3112@met.reading.ac.uk><4B86A97F.7010805@whoi.edu><20100226094155.GA5904@met.reading.ac.uk> Message-ID: <1240F43731C2EB4F8CC9BF70D233B511018C0103@SRV-XCHANGE-2K3.pc.cls.fr> Hi all, I think the use case sent by Roy is excellent and a little bit misleading at the same time: of course in his situation there is no need each time for a new standard name, if it is the same geophysical quantity that is estimated. Or as a corollary, if I were Roy, I would put a different CF standard name only if it is a different temperature stored in the dataset. Surface type (eg ocean, or river) is not always a criteria defining a specific geophysical quantity, it is only some kind of information for data location. Besides this information is also sometimes provided as flag values (like 0=river, 1=ocean etc.) in netCDF files. Back to the the suite of "sea_surface_height_above_", I would personally militate for keeping them as they are, and adding new ones for lake+rivers.. Like "lake_surface_height_..", as the first proposal from Jonathan. (And perhaps something in the near future for ice sheets topography too, but it is not the priority now.) Not because they are considering different surface types, but because they do not represent the same geophysical quantity, they are not processed using the same methods and assumptions (processes scales etc.). In my opinion that makes the difference, and that's why we need them. And it is possible we do not need them in other situations, like we do not need to apply GRHSST definitions using heights instead of temperature, do we? Kind regards Olivier. -----Message d'origine----- De : cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] De la part de Seth McGinnis Envoy? : samedi 27 f?vrier 2010 04:51 ? : cf-metadata at cgd.ucar.edu Objet : Re: [CF-metadata] water level with/without datum >Therefore I think we have to decide what to call the new names. Roy suggested >water body. As I've said before, I would prefer sea/lake/river_water (or with >some other punctuation) to water_body_water, because sea/lake/river_water is >more self-explanatory, and the repetition of "water" in water_body_water is >clumsy and possibly confusing. I can imagine someone not being sure how to >parse "water body water temperature" when they first come across it. Instead of a prefix modifer, how about adding _body as a postfix modifier? So you could have sea_water_temperature for oceans and water_body_temperature for oceans, rivers, lakes, and other significant accumulations of liquid water. Cheers, ---- Seth McGinnis NARCCAP Data Manager ISSE / ISP / IMAGe / CISL / NCAR ---- (P.S.: Observation/tangent: It seems like this conundrum may be arising in part because the day-to-day meaning of the term "water" -- liquid H2O -- is at odds with the definition given in the standard name guidelines of "water in all phases if not otherwise qualified". Were there a blank slate, I would suggest using the unqualified term to mean "liquid water", in better alignment with its commonsense meaning, and coming up with a new term for the more restricted contexts where one needs to refer to all three phases. How frequently in current usage does the "all phases" sense differ fom the usual sense? Would it be worth considering a switch? That would be an alternate way around the issue of generic water bodies.) _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata Cliquez sur l'url suivante https://www.mailcontrol.com/sr/Y8JdOU4DsM7TndxI!oX7UvGHrMX8oTLhxXmnApiAmj9zdQJy4gJWXe3FyfcXLuoUBltZoDt4qRPbd8XIx2vetQ== si ce message est ind?sirable (pourriel). -------------- next part -------------- An HTML attachment was scrubbed... URL: From alison.pamment at stfc.ac.uk Tue Mar 2 04:02:58 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Tue, 2 Mar 2010 11:02:58 -0000 Subject: [CF-metadata] two anomalous standard names In-Reply-To: <20100223081042.GA21674@met.reading.ac.uk> References: <20100223081042.GA21674@met.reading.ac.uk> Message-ID: Dear Jonathan, Thank you for pointing out these anomalies. I agree that we should standardise the syntax where possible. I'll create two new aliases in the next update of the table. I'll look forward to reading your work on standard name construction. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory > Sent: 23 February 2010 08:11 > To: cf-metadata at cgd.ucar.edu > Subject: [CF-metadata] two anomalous standard names > > Dear Alison > > I suggest that these two standard names should be amended: > moles_per_unit_mass_of_cfc11_in_sea_water -> > moles_of_cfc11_per_unit_mass_in_sea_water > The latter order is followed by all the other names i.e. > moles_of_X_per_unit_mass_in_sea_water > > change_over_time_in_atmospheric_water_content_due_to_advection -> > change_over_time_in_atmosphere_water_content_due_to_advection > since this is the only standard name containing the word "atmospheric", > and > in other standard names we have phrases > atmosphere[_...]_water_content > > I noticed these exceptions because I've been working on a method of > inferring > the "lexicon" from which the standard names are constructed. I hope to > post > some information about this soon. > > Cheers > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Scanned by iCritical. From ancl at pml.ac.uk Wed Mar 3 08:10:43 2010 From: ancl at pml.ac.uk (Andrew Clegg) Date: Wed, 03 Mar 2010 15:10:43 +0000 Subject: [CF-metadata] udunits 1 or 2 for CF? Message-ID: <4B8E7BF3.6030600@pml.ac.uk> Hi all, I'm running into some problems regarding units in CF-compliant files. Up until now I've been using udunits 1 to check units, but I recently tried the CF checker which uses udunits2. There are some unit strings which are valid in one but not the other. In particular, I am dealing with milligrams per cubic meter. In udunits1, I used 'ukg m^-3', which udunits2 rejects as invalid. udunits2 accepts 'mg m^-3' (which is much better!), but udunits1 interprets this as to do with gravity. Because of this, I can't include a unit string which is generally compatible with udunits... I would guess that udunits2 is the preferred option, given that udunits1 is deprecated. Should the CF conventions be updated to specify udunits 2? Cheers, Andrew Clegg Plymouth Marine Laboratory -------------------------------------------------------------------------------- Plymouth Marine Laboratory Registered Office: Prospect Place The Hoe Plymouth PL1 3DH Website: www.pml.ac.uk Registered Charity No. 1091222 PML is a company limited by guarantee registered in England & Wales company number 4178503 PML is a member of the Plymouth Marine Sciences Partnership Website: www.pmsp.org.uk -------------------------------------------------------------------------------- This e-mail, its content and any file attachments are confidential. If you have received this e-mail in error please do not copy, disclose it to any third party or use the contents or attachments in any way. Please notify the sender by replying to this e-mail or e-mail forinfo at pml.ac.uk and then delete the email without making any copies or using it in any other way. The content of this message may contain personal views which are not the views of Plymouth Marine Laboratory unless specifically stated. You are reminded that e-mail communications are not secure and may contain viruses. Plymouth Marine Laboratory accepts no liability for any loss or damage which may be caused by viruses. -------------------------------------------------------------------------------- From taylor13 at llnl.gov Wed Mar 3 10:51:44 2010 From: taylor13 at llnl.gov (Karl Taylor) Date: Wed, 03 Mar 2010 09:51:44 -0800 Subject: [CF-metadata] udunits 1 or 2 for CF? In-Reply-To: <4B8E7BF3.6030600@pml.ac.uk> References: <4B8E7BF3.6030600@pml.ac.uk> Message-ID: <4B8EA1B0.5060706@llnl.gov> Hi all, This is too bad that udunits is not backward compatible. I vote for CF to recommend using the latest available udunits library. Best regards, Karl On 03-Mar-10 7:10 AM, Andrew Clegg wrote: > Hi all, > > I'm running into some problems regarding units in CF-compliant files. > Up until now I've been using udunits 1 to check units, but I recently > tried the CF checker which uses udunits2. There are some unit strings > which are valid in one but not the other. In particular, I am dealing > with milligrams per cubic meter. In udunits1, I used 'ukg m^-3', which > udunits2 rejects as invalid. udunits2 accepts 'mg m^-3' (which is much > better!), but udunits1 interprets this as to do with gravity. Because > of this, I can't include a unit string which is generally compatible > with udunits... > > I would guess that udunits2 is the preferred option, given that > udunits1 is deprecated. Should the CF conventions be updated to > specify udunits 2? > > Cheers, > Andrew Clegg > Plymouth Marine Laboratory > > -------------------------------------------------------------------------------- > > Plymouth Marine Laboratory > > Registered Office: > Prospect Place The Hoe > Plymouth PL1 3DH > > Website: www.*pml.ac.uk > Registered Charity No. 1091222 > PML is a company limited by guarantee > registered in England & Wales > company number 4178503 > > PML is a member of the Plymouth Marine Sciences Partnership > Website: www.*pmsp.org.uk > -------------------------------------------------------------------------------- > > This e-mail, its content and any file attachments are confidential. > > If you have received this e-mail in error please do not copy, disclose > it to any third party or use the contents or attachments in any way. > Please notify the sender by replying to this e-mail or e-mail > forinfo at pml.ac.uk and then delete the email without making any copies > or using it in any other way. > > The content of this message may contain personal views which are not > the views of Plymouth Marine Laboratory unless specifically stated. > > You are reminded that e-mail communications are not secure and may > contain viruses. Plymouth Marine Laboratory accepts no liability for > any loss or damage which may be caused by viruses. > -------------------------------------------------------------------------------- > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > From Upendra.Dadi at noaa.gov Wed Mar 3 12:21:56 2010 From: Upendra.Dadi at noaa.gov (Upendra Dadi) Date: Wed, 03 Mar 2010 14:21:56 -0500 Subject: [CF-metadata] equivalent of TOWGS84 in CF Message-ID: <4B8EB6D4.1080507@noaa.gov> Hi, I am new to CF convention. I am looking at how to incorporate coordinate system information in the netcdf file. Referring to the CF documentation, I found that there are parameters like grid_mapping_name, semi_major_axis, longitude_of_prime_meridian, etc to describe the coordinate system.But I haven't found any attributes for specifying Bursa Wolf transformation parameters (equivalent of TOWGS84 in WKT). Or am I missing something? These parameters may be required when I am using data which is not based on WGS 84 datum in order to be able to apply proper transformation. Thanks. Upendra From ksshannon at gmail.com Wed Mar 3 12:55:40 2010 From: ksshannon at gmail.com (Kyle Shannon) Date: Wed, 3 Mar 2010 12:55:40 -0700 Subject: [CF-metadata] equivalent of TOWGS84 in CF In-Reply-To: <4B8EB6D4.1080507@noaa.gov> References: <4B8EB6D4.1080507@noaa.gov> Message-ID: I don't believe there are any such tags for TOWGS84. I would like to see a more conformance or integration with OGC WKT as well. This could take the form of spatial reference well known text or proj4 definitions. For the spheroid in cf, you have to specify earth_radius and inverse_flattening or semi_major_axis and semi_minor_axis. I think longitude_of_prime_meridian is in there too. The other grid_mapping tags are for projected coordinate systems. -Kyle On Wed, Mar 3, 2010 at 12:21 PM, Upendra Dadi wrote: > Hi, > I am new to CF convention. I am looking at how to incorporate coordinate > system information in the netcdf file. Referring to the CF documentation, I > found that there are parameters like grid_mapping_name, semi_major_axis, > longitude_of_prime_meridian, etc to describe the coordinate system.But I > haven't found any attributes for specifying Bursa Wolf transformation > parameters (equivalent of TOWGS84 in WKT). Or am I missing something? These > parameters may be required when I am using data which is not based on WGS 84 > datum in order to be able to apply proper transformation. Thanks. > > Upendra > > > > > > > _______________________________________________ > 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: From steve at unidata.ucar.edu Wed Mar 3 13:29:03 2010 From: steve at unidata.ucar.edu (Steve Emmerson) Date: Wed, 03 Mar 2010 13:29:03 -0700 Subject: [CF-metadata] "Andrew Clegg": udunits 1 or 2 for CF? In-Reply-To: <27898.1267633660@buddy.unidata.ucar.edu> References: <27898.1267633660@buddy.unidata.ucar.edu> Message-ID: <4B8EC68F.9050203@unidata.ucar.edu> Andrew, > I'm running into some problems regarding units in CF-compliant files. > Up until now I've been using udunits 1 to check units, but I recently > tried the CF checker which uses udunits2. There are some unit strings > which are valid in one but not the other. In particular, I am dealing > with milligrams per cubic meter. In udunits1, I used 'ukg m-3', which > udunits2 rejects as invalid. udunits2 accepts 'mg m-3' (which is much > better!), but udunits1 interprets this as to do with gravity. Because > of this, I can't include a unit string which is generally compatible > with udunits... > I would guess that udunits2 is the preferred option, given that > udunits1 is deprecated. Should the CF conventions be updated to > specify udunits 2? The UDUNITS-1 library had a bug in it. The bug was that "g" was interpreted as meaning "gravity" (i.e., "standard_free_fall") rather than "gram". This was corrected in version 1.12.10 of the UDUNITS-1 package, which was released on 2009-09-17. The UDUNITS-2 package did not have this bug from the outset. If you create a CF file that uses "g" for "gram", then it will be correctly interpreted by the UDUNITS-2 library and also by the UDUNITS-1 library from version 1.12.10 on. Applications that use the UDUNITS-1 library prior to version 1.12.10 can be easily modified to interpret "g" as "gram" by removing the following entry from the UDUNITS-1 database ($prefix/etc/udunits.dat): g S gravity # approx. should ... I hope this helps. Regards, Steve Emmerson UDUNITS developer From Upendra.Dadi at noaa.gov Wed Mar 3 13:41:38 2010 From: Upendra.Dadi at noaa.gov (Upendra Dadi) Date: Wed, 03 Mar 2010 15:41:38 -0500 Subject: [CF-metadata] equivalent of TOWGS84 in CF In-Reply-To: References: <4B8EB6D4.1080507@noaa.gov> Message-ID: <4B8EC982.9030900@noaa.gov> As I understand, scientists often use reference systems more complex than can be represented using the WKT. So it might not be good to fully depend on WKT, but having an optional attribute which can be used whenever possible might be a good idea. Upendra Kyle Shannon wrote: > I don't believe there are any such tags for TOWGS84. I would like to > see a more conformance or integration with OGC WKT as well. This > could take the form of spatial reference well known text or proj4 > definitions. For the spheroid in cf, you have to specify earth_radius > and inverse_flattening or semi_major_axis and semi_minor_axis. I > think longitude_of_prime_meridian is in there too. The other > grid_mapping tags are for projected coordinate systems. > > > > -Kyle > > > On Wed, Mar 3, 2010 at 12:21 PM, Upendra Dadi > wrote: > > Hi, > I am new to CF convention. I am looking at how to incorporate > coordinate system information in the netcdf file. Referring to the > CF documentation, I found that there are parameters like > grid_mapping_name, semi_major_axis, longitude_of_prime_meridian, > etc to describe the coordinate system.But I haven't found any > attributes for specifying Bursa Wolf transformation parameters > (equivalent of TOWGS84 in WKT). Or am I missing something? These > parameters may be required when I am using data which is not based > on WGS 84 datum in order to be able to apply proper > transformation. Thanks. > > Upendra > > > > > > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > ------------------------------------------------------------------------ > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > From andrea.antonello at gmail.com Wed Mar 3 13:49:36 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Wed, 3 Mar 2010 21:49:36 +0100 Subject: [CF-metadata] equivalent of TOWGS84 in CF In-Reply-To: <4B8EC982.9030900@noaa.gov> References: <4B8EB6D4.1080507@noaa.gov> <4B8EC982.9030900@noaa.gov> Message-ID: <116eb44a1003031249m281c0bfeoc0170a20001881a6@mail.gmail.com> I would really welcome such an enhancement, leaning towards OGC. This would make things far easier for people coming from GIS modelling environments. Best regards, Andrea On Wed, Mar 3, 2010 at 9:41 PM, Upendra Dadi wrote: > ?As I understand, scientists often use reference systems more complex than > can be represented using the WKT. So it might not be good to fully depend on > WKT, but having an optional attribute which can be used whenever possible > might be a good idea. > > Upendra > > Kyle Shannon wrote: >> >> I don't believe there are any such tags for TOWGS84. ?I would like to see >> a more conformance or integration with OGC WKT as well. ?This could take the >> form of spatial reference well known text or proj4 definitions. ?For the >> spheroid in cf, you have to specify earth_radius and inverse_flattening or >> semi_major_axis and semi_minor_axis. ?I think longitude_of_prime_meridian is >> in there too. ?The other grid_mapping tags are for projected coordinate >> systems. >> >> >> >> -Kyle >> >> >> On Wed, Mar 3, 2010 at 12:21 PM, Upendra Dadi > > wrote: >> >> ? ?Hi, >> ? ? I am new to CF convention. I am looking at how to incorporate >> ? ?coordinate system information in the netcdf file. Referring to the >> ? ?CF documentation, I found that there are parameters like >> ? ?grid_mapping_name, semi_major_axis, longitude_of_prime_meridian, >> ? ?etc to describe the coordinate system.But I haven't found any >> ? ?attributes for specifying Bursa Wolf transformation parameters >> ? ?(equivalent of TOWGS84 in WKT). Or am I missing something? These >> ? ?parameters may be required when I am using data which is not based >> ? ?on WGS 84 datum in order to be able to apply proper >> ? ?transformation. Thanks. >> >> ? ?Upendra >> >> >> >> >> >> >> ? ?_______________________________________________ >> ? ?CF-metadata mailing list >> ? ?CF-metadata at cgd.ucar.edu >> ? ?http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > From j.m.gregory at reading.ac.uk Thu Mar 4 01:15:40 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Thu, 4 Mar 2010 08:15:40 +0000 Subject: [CF-metadata] udunits 1 or 2 for CF? In-Reply-To: <4B8EA1B0.5060706@llnl.gov> References: <4B8E7BF3.6030600@pml.ac.uk> <4B8EA1B0.5060706@llnl.gov> Message-ID: <20100304081540.GC28201@met.reading.ac.uk> Dear all I think CF should specify udunits-2 as well. We could could clarify that in the convention as correcting a defect, I think. Best wishes Jonathan From philip.bentley at metoffice.gov.uk Thu Mar 4 02:49:26 2010 From: philip.bentley at metoffice.gov.uk (Bentley, Philip) Date: Thu, 4 Mar 2010 09:49:26 -0000 Subject: [CF-metadata] equivalent of TOWGS84 in CF In-Reply-To: <4B8EC982.9030900@noaa.gov> References: <4B8EB6D4.1080507@noaa.gov> <4B8EC982.9030900@noaa.gov> Message-ID: Upendra, Kyle, et al, I proposed the use of an optional wkt attribute, for similar reasons to those that you suggest, when I put together my submission for additional CRS attributes to the CF standard. You can read some of the discussions under CF trac tickets #9 and #18. This particular attribute received a lukewarm reception at the time. However, if you feel there is a stronger case now then by all means submit another proposal to the CF trac site. Of course, there's nothing to stop you adding a wkt attribute to your netcdf files today. ESRI does just this. So long as the files are CF-compliant in other respects then any additional attributes are supplementary (I'm presuming CF-compliance is your goal). Regards, Phil > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu > [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Upendra Dadi > Sent: 03 March 2010 20:42 > To: Kyle Shannon > Cc: CF-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] equivalent of TOWGS84 in CF > > As I understand, scientists often use reference systems > more complex than can be represented using the WKT. So it > might not be good to fully depend on WKT, but having an > optional attribute which can be used whenever possible might > be a good idea. > > Upendra > > Kyle Shannon wrote: > > I don't believe there are any such tags for TOWGS84. I > would like to > > see a more conformance or integration with OGC WKT as well. This > > could take the form of spatial reference well known text or proj4 > > definitions. For the spheroid in cf, you have to specify > earth_radius > > and inverse_flattening or semi_major_axis and semi_minor_axis. I > > think longitude_of_prime_meridian is in there too. The other > > grid_mapping tags are for projected coordinate systems. > > > > > > > > -Kyle > > > > > > On Wed, Mar 3, 2010 at 12:21 PM, Upendra Dadi > > > wrote: > > > > Hi, > > I am new to CF convention. I am looking at how to incorporate > > coordinate system information in the netcdf file. > Referring to the > > CF documentation, I found that there are parameters like > > grid_mapping_name, semi_major_axis, longitude_of_prime_meridian, > > etc to describe the coordinate system.But I haven't found any > > attributes for specifying Bursa Wolf transformation parameters > > (equivalent of TOWGS84 in WKT). Or am I missing something? These > > parameters may be required when I am using data which > is not based > > on WGS 84 datum in order to be able to apply proper > > transformation. Thanks. > > > > Upendra > > > > > > > > > > > > > > _______________________________________________ > > CF-metadata mailing list > > CF-metadata at cgd.ucar.edu > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > CF-metadata mailing list > > CF-metadata at cgd.ucar.edu > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > From ancl at pml.ac.uk Thu Mar 4 03:08:13 2010 From: ancl at pml.ac.uk (Andrew Clegg) Date: Thu, 04 Mar 2010 10:08:13 +0000 Subject: [CF-metadata] "Andrew Clegg": udunits 1 or 2 for CF? In-Reply-To: <4B8EC68F.9050203@unidata.ucar.edu> References: <27898.1267633660@buddy.unidata.ucar.edu> <4B8EC68F.9050203@unidata.ucar.edu> Message-ID: <4B8F868D.7040707@pml.ac.uk> Steve, > The UDUNITS-1 library had a bug in it. The bug was that "g" was > interpreted as meaning "gravity" (i.e., "standard_free_fall") rather > than "gram". This was corrected in version 1.12.10 of the UDUNITS-1 > package, which was released on 2009-09-17. > > The UDUNITS-2 package did not have this bug from the outset. > Thanks for this, however this is not the only incompatibility I have found. Another one is specifying microns. Udunits1 understands 'um', while Udunits2 recognises '?m'. I note that the CF conventions list in Table 3.1 that the abbreviation for micro is 'u', not '?'. It may well be that these are the only 2 incompatibilities - in which case, it might be wise to note these specifically in the conventions, ie to specify that "The value of the |units| attribute is a string that can be recognized by UNIDATA"s Udunits package (version 1.12.10 or higher) ", and perhaps that '1e-6' should be used in place of u/? to ensure compatibility with both versions. Cheers, Andrew -------------------------------------------------------------------------------- Plymouth Marine Laboratory Registered Office: Prospect Place The Hoe Plymouth PL1 3DH Website: www.pml.ac.uk Registered Charity No. 1091222 PML is a company limited by guarantee registered in England & Wales company number 4178503 PML is a member of the Plymouth Marine Sciences Partnership Website: www.pmsp.org.uk -------------------------------------------------------------------------------- This e-mail, its content and any file attachments are confidential. If you have received this e-mail in error please do not copy, disclose it to any third party or use the contents or attachments in any way. Please notify the sender by replying to this e-mail or e-mail forinfo at pml.ac.uk and then delete the email without making any copies or using it in any other way. The content of this message may contain personal views which are not the views of Plymouth Marine Laboratory unless specifically stated. You are reminded that e-mail communications are not secure and may contain viruses. Plymouth Marine Laboratory accepts no liability for any loss or damage which may be caused by viruses. -------------------------------------------------------------------------------- From bruno.piguet at meteo.fr Thu Mar 4 07:58:48 2010 From: bruno.piguet at meteo.fr (Bruno PIGUET) Date: Thu, 04 Mar 2010 15:58:48 +0100 Subject: [CF-metadata] udunits 1 or 2 for CF? In-Reply-To: <4B8E7BF3.6030600@pml.ac.uk> References: <4B8E7BF3.6030600@pml.ac.uk> Message-ID: <1267714728.11050.28.camel@lxtramm2> Le mercredi 03 mars 2010 ? 15:10 +0000, Andrew Clegg a ?crit : > [...] In udunits1, I used 'ukg m^-3', which > udunits2 rejects as invalid. udunits2 accepts 'mg m^-3' (which is much > better!), but udunits1 interprets this as to do with gravity. Because of > this, I can't include a unit string which is generally compatible with > udunits... As a personal choice, to deal with this problem, I use the full word "gram" with udunits-1. And "mgram" is accepted as milligram, which I find better than ukg, which i would never have thought of by myself. I guess (can't test it by now) that "mgram" should also be accepted by udunits-2. Is it an option for you ? Bruno. -- Bruno PIGUET M?l : bruno.piguet at meteo.fr | GAME : URA CNRS & METEO-FRANCE Tel : +33 (0)5 61 07 96 59 | CNRM/GMEI/TRAMM Fax : +33 (0)5 61 07 96 27 | 42 Av. G. Coriolis Sec : +33 (0)5 61 07 96 63 | 31057 TOULOUSE cedex 1 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ancl at pml.ac.uk Thu Mar 4 08:06:01 2010 From: ancl at pml.ac.uk (Andrew Clegg) Date: Thu, 04 Mar 2010 15:06:01 +0000 Subject: [CF-metadata] udunits 1 or 2 for CF? In-Reply-To: <1267714728.11050.28.camel@lxtramm2> References: <4B8E7BF3.6030600@pml.ac.uk> <1267714728.11050.28.camel@lxtramm2> Message-ID: <4B8FCC59.7070705@pml.ac.uk> Bruno PIGUET wrote: > Le mercredi 03 mars 2010 ? 15:10 +0000, Andrew Clegg a ?crit : > >> [...] In udunits1, I used 'ukg m^-3', which >> udunits2 rejects as invalid. udunits2 accepts 'mg m^-3' (which is much >> better!), but udunits1 interprets this as to do with gravity. Because of >> this, I can't include a unit string which is generally compatible with >> udunits... >> > > As a personal choice, to deal with this problem, I use the full word > "gram" with udunits-1. And "mgram" is accepted as milligram, which I > find better than ukg, which i would never have thought of by myself. > > I guess (can't test it by now) that "mgram" should also be accepted by > udunits-2. Is it an option for you ? > > Bruno. > I never thought of using the full word 'gram' - I've just checked and 'gram' and 'mgram' work on udunits-2 as well. Thanks. However, I'm still concerned that there are differences between the 2 versions, and that this should be at least noted in the conventions. Other people in the future will probably have the same problem, and it would be nice to have a definitive answer. My (strong) personal preference is to say that all unit strings should be correct when interpreted with udunits-2, rather than relying on a set of 'hacks' to ensure compatibility between the 2. Cheers, Andrew -------------------------------------------------------------------------------- Plymouth Marine Laboratory Registered Office: Prospect Place The Hoe Plymouth PL1 3DH Website: www.pml.ac.uk Registered Charity No. 1091222 PML is a company limited by guarantee registered in England & Wales company number 4178503 PML is a member of the Plymouth Marine Sciences Partnership Website: www.pmsp.org.uk -------------------------------------------------------------------------------- This e-mail, its content and any file attachments are confidential. If you have received this e-mail in error please do not copy, disclose it to any third party or use the contents or attachments in any way. Please notify the sender by replying to this e-mail or e-mail forinfo at pml.ac.uk and then delete the email without making any copies or using it in any other way. The content of this message may contain personal views which are not the views of Plymouth Marine Laboratory unless specifically stated. You are reminded that e-mail communications are not secure and may contain viruses. Plymouth Marine Laboratory accepts no liability for any loss or damage which may be caused by viruses. -------------------------------------------------------------------------------- From ngalbraith at whoi.edu Thu Mar 4 08:11:58 2010 From: ngalbraith at whoi.edu (Nan Galbraith) Date: Thu, 04 Mar 2010 10:11:58 -0500 Subject: [CF-metadata] "Andrew Clegg": udunits 1 or 2 for CF? In-Reply-To: <4B8EC68F.9050203@unidata.ucar.edu> References: <27898.1267633660@buddy.unidata.ucar.edu> <4B8EC68F.9050203@unidata.ucar.edu> Message-ID: <4B8FCDBE.2050500@whoi.edu> Hi Steve - Are all the terms in the new vocabulary backwards compatible, other than non-ASCII characters and log units? I just spent some time looking on the unidata web site to see if I could find any information on changes to basic units names - additions or otherwise. I'd thought there might be some new basic units, e.g. PSU for salinity. There doesn't seem to be any way to compare the two versions, as they're in very different formats. (The new xml list is great, by the way.) Lots of people and systems, including the CF spec, use the vocabulary for basic units from udunits, so when and if these terms change, it would be helpful to have a description of those changes. The v2 manual doesn't mention any additions, other than new support for non-ASCII and log units. In 10/2006, Alison wrote: > It emerged that there are already some units that have been identified as being useful for CF that are not currently part of udunits. > Jonathan wrote: > >> > sverdrup = 1e6 m3 s-1 (we can't use the usual abbrev Sv though as it >> > already has another definition) >> > PSU and psu = 1e-3 (practical salinity unit, effectively mass >> > fraction) >> > There is also decibel (dB). Thanks - Nan Galbraith >> I'm running into some problems regarding units in CF-compliant files. >> Up until now I've been using udunits 1 to check units, but I recently >> tried the CF checker which uses udunits2. There are some unit strings >> which are valid in one but not the other. In particular, I am dealing >> with milligrams per cubic meter. In udunits1, I used 'ukg m-3', which >> udunits2 rejects as invalid. udunits2 accepts 'mg m-3' (which is much >> better!), but udunits1 interprets this as to do with gravity. Because >> of this, I can't include a unit string which is generally compatible > >> > ... > The UDUNITS-1 library had a bug in it. The bug was that "g" was > interpreted as meaning "gravity" (i.e., "standard_free_fall") rather > than "gram". This was corrected in version 1.12.10 of the UDUNITS-1 > package, which was released on 2009-09-17. > > ... > > Applications that use the UDUNITS-1 library prior to version 1.12.10 can > be easily modified to interpret "g" as "gram" by removing the following > entry from the UDUNITS-1 database ($prefix/etc/udunits.dat): > > g S gravity # approx. should ... > > I hope this helps. > > Regards, > Steve Emmerson > UDUNITS developer > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* From steve at unidata.ucar.edu Thu Mar 4 08:53:41 2010 From: steve at unidata.ucar.edu (Steven Emmerson) Date: Thu, 04 Mar 2010 08:53:41 -0700 Subject: [CF-metadata] "Andrew Clegg": udunits 1 or 2 for CF? In-Reply-To: <4B8F868D.7040707@pml.ac.uk> References: <27898.1267633660@buddy.unidata.ucar.edu> <4B8EC68F.9050203@unidata.ucar.edu> <4B8F868D.7040707@pml.ac.uk> Message-ID: <4B8FD785.4000003@unidata.ucar.edu> Andrew, The "u" prefix can be added to the UDUNITS-2 database by inserting the line u in the set of other "symbol" definitions for the value "1e-6" in the database file "$(prefix)/share/udunits/udunits2-prefixes.xml". At this time, however, I can't say whether or not doing so will have unintended consequences. If you wish to try it, please do so and get back to me. I think a larger issue regarding the adoption of the UDUNITS-2 package is the fact that it doesn't yet have a Fortran interface. I have not investigated this matter much but, apparently, Fortran-95 has a relatively easy mechanism for creating such an interface -- which, hopefully, would mean that few resources would be needed to create one. The question then becomes one of priority: given that the CF convention adopts the UDUNITS-2 package, how necessary or important is a Fortran interface? On the other hand, given that creating a Fortran interface will consume resources (most especially time) how necessary is adoption of the UDUNITS-2 package? I encourage and await your input on the matter. Would you please CC me directly as I don't (yet?) subscribe to the CF mailing-list. Regards, Steve Emmerson UDUNITS Developer On 3/4/2010 3:08 AM, Andrew Clegg wrote: > Steve, >> The UDUNITS-1 library had a bug in it. The bug was that "g" was >> interpreted as meaning "gravity" (i.e., "standard_free_fall") rather >> than "gram". This was corrected in version 1.12.10 of the UDUNITS-1 >> package, which was released on 2009-09-17. >> >> The UDUNITS-2 package did not have this bug from the outset. > Thanks for this, however this is not the only incompatibility I have > found. Another one is specifying microns. Udunits1 understands 'um', > while Udunits2 recognises '?m'. I note that the CF conventions list in > Table 3.1 that the abbreviation for micro is 'u', not '?'. > > It may well be that these are the only 2 incompatibilities - in which > case, it might be wise to note these specifically in the conventions, ie > to specify that "The value of the |units| attribute is a string that can > be recognized by UNIDATA"s Udunits package (version 1.12.10 or higher) > ", > and perhaps that '1e-6' should be used in place of u/? to ensure > compatibility with both versions. > > Cheers, > Andrew > > -------------------------------------------------------------------------------- > > Plymouth Marine Laboratory > > Registered Office: > Prospect Place The Hoe > Plymouth PL1 3DH > > Website: www.pml.ac.uk > Registered Charity No. 1091222 > PML is a company limited by guarantee > registered in England & Wales > company number 4178503 > > PML is a member of the Plymouth Marine Sciences Partnership > Website: www.pmsp.org.uk > -------------------------------------------------------------------------------- > > This e-mail, its content and any file attachments are confidential. > > If you have received this e-mail in error please do not copy, disclose > it to any third party or use the contents or attachments in any way. > Please notify the sender by replying to this e-mail or e-mail > forinfo at pml.ac.uk and then delete the email without making any copies or > using it in any other way. > > The content of this message may contain personal views which are not the > views of Plymouth Marine Laboratory unless specifically stated. > > You are reminded that e-mail communications are not secure and may > contain viruses. Plymouth Marine Laboratory accepts no liability for any > loss or damage which may be caused by viruses. > -------------------------------------------------------------------------------- > From j.m.gregory at reading.ac.uk Thu Mar 4 09:00:41 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Thu, 4 Mar 2010 16:00:41 +0000 Subject: [CF-metadata] "Andrew Clegg": udunits 1 or 2 for CF? In-Reply-To: <4B8FD785.4000003@unidata.ucar.edu> References: <27898.1267633660@buddy.unidata.ucar.edu> <4B8EC68F.9050203@unidata.ucar.edu> <4B8F868D.7040707@pml.ac.uk> <4B8FD785.4000003@unidata.ucar.edu> Message-ID: <20100304160041.GB29878@met.reading.ac.uk> Dear Steve et al. We can distinguish udunits-2 as a standard for units strings, and udunits-2 as software. If we say that CF uses udunits-2 as its reference, programs in Fortran can still use udunits-1 to process the units strings, in nearly all cases, though obviously a ununits-2 Fortran interface would be preferable. To address Andrew's point about "u" for 1e-6 and Nan's about PSU, we could make CF-specific xml files available for use with udunits-2. We decided to do this with udunits.dat, in order to add sverdrup as well as PSU, but didn't get round to it. Cheers Jonathan From ancl at pml.ac.uk Thu Mar 4 09:16:23 2010 From: ancl at pml.ac.uk (Andrew Clegg) Date: Thu, 04 Mar 2010 16:16:23 +0000 Subject: [CF-metadata] "Andrew Clegg": udunits 1 or 2 for CF? In-Reply-To: <4B8FD785.4000003@unidata.ucar.edu> References: <27898.1267633660@buddy.unidata.ucar.edu> <4B8EC68F.9050203@unidata.ucar.edu> <4B8F868D.7040707@pml.ac.uk> <4B8FD785.4000003@unidata.ucar.edu> Message-ID: <4B8FDCD7.9090807@pml.ac.uk> Steve, I just tried adding u as a prefix, and it certainly worked (although I also can't say if it would have any unintended consequences, I only use a small set of unit strings). I don't use Fortran personally, so a lack of a Fortran interface wouldn't be a problem for me. Of course, we would not want to deliberately cause problems for Fortran users. Jonathan's response reflects my opinion on this: We can distinguish udunits-2 as a standard for units strings, and udunits-2 as software. If we say that CF uses udunits-2 as its reference, programs in Fortran can still use udunits-1 to process the units strings, in nearly all cases, though obviously a ununits-2 Fortran interface would be preferable. Cheers, Andrew Clegg Steven Emmerson wrote: > Andrew, > > The "u" prefix can be added to the UDUNITS-2 database by inserting the > line > > u > > in the set of other "symbol" definitions for the value "1e-6" in the > database file "$(prefix)/share/udunits/udunits2-prefixes.xml". > > At this time, however, I can't say whether or not doing so will have > unintended consequences. If you wish to try it, please do so and get > back to me. > > I think a larger issue regarding the adoption of the UDUNITS-2 package > is the fact that it doesn't yet have a Fortran interface. I have not > investigated this matter much but, apparently, Fortran-95 has a > relatively easy mechanism for creating such an interface -- which, > hopefully, would mean that few resources would be needed to create > one. The question then becomes one of priority: given that the CF > convention adopts the UDUNITS-2 package, how necessary or important is > a Fortran interface? On the other hand, given that creating a Fortran > interface will consume resources (most especially time) how necessary > is adoption of the UDUNITS-2 package? > > I encourage and await your input on the matter. Would you please CC > me directly as I don't (yet?) subscribe to the CF mailing-list. > > Regards, > Steve Emmerson > UDUNITS Developer > > On 3/4/2010 3:08 AM, Andrew Clegg wrote: >> Steve, >>> The UDUNITS-1 library had a bug in it. The bug was that "g" was >>> interpreted as meaning "gravity" (i.e., "standard_free_fall") rather >>> than "gram". This was corrected in version 1.12.10 of the UDUNITS-1 >>> package, which was released on 2009-09-17. >>> >>> The UDUNITS-2 package did not have this bug from the outset. >> Thanks for this, however this is not the only incompatibility I have >> found. Another one is specifying microns. Udunits1 understands 'um', >> while Udunits2 recognises '?m'. I note that the CF conventions list in >> Table 3.1 that the abbreviation for micro is 'u', not '?'. >> >> It may well be that these are the only 2 incompatibilities - in which >> case, it might be wise to note these specifically in the conventions, ie >> to specify that "The value of the |units| attribute is a string that can >> be recognized by UNIDATA"s Udunits package (version 1.12.10 or higher) >> ", >> >> and perhaps that '1e-6' should be used in place of u/? to ensure >> compatibility with both versions. >> >> Cheers, >> Andrew >> >> -------------------------------------------------------------------------------- >> >> >> Plymouth Marine Laboratory >> >> Registered Office: >> Prospect Place The Hoe >> Plymouth PL1 3DH >> >> Website: www.pml.ac.uk >> Registered Charity No. 1091222 >> PML is a company limited by guarantee >> registered in England & Wales >> company number 4178503 >> >> PML is a member of the Plymouth Marine Sciences Partnership >> Website: www.pmsp.org.uk >> -------------------------------------------------------------------------------- >> >> >> This e-mail, its content and any file attachments are confidential. >> >> If you have received this e-mail in error please do not copy, disclose >> it to any third party or use the contents or attachments in any way. >> Please notify the sender by replying to this e-mail or e-mail >> forinfo at pml.ac.uk and then delete the email without making any copies or >> using it in any other way. >> >> The content of this message may contain personal views which are not the >> views of Plymouth Marine Laboratory unless specifically stated. >> >> You are reminded that e-mail communications are not secure and may >> contain viruses. Plymouth Marine Laboratory accepts no liability for any >> loss or damage which may be caused by viruses. >> -------------------------------------------------------------------------------- >> >> > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -------------------------------------------------------------------------------- Plymouth Marine Laboratory Registered Office: Prospect Place The Hoe Plymouth PL1 3DH Website: www.pml.ac.uk Registered Charity No. 1091222 PML is a company limited by guarantee registered in England & Wales company number 4178503 PML is a member of the Plymouth Marine Sciences Partnership Website: www.pmsp.org.uk -------------------------------------------------------------------------------- This e-mail, its content and any file attachments are confidential. If you have received this e-mail in error please do not copy, disclose it to any third party or use the contents or attachments in any way. Please notify the sender by replying to this e-mail or e-mail forinfo at pml.ac.uk and then delete the email without making any copies or using it in any other way. The content of this message may contain personal views which are not the views of Plymouth Marine Laboratory unless specifically stated. You are reminded that e-mail communications are not secure and may contain viruses. Plymouth Marine Laboratory accepts no liability for any loss or damage which may be caused by viruses. -------------------------------------------------------------------------------- From caron at unidata.ucar.edu Thu Mar 4 09:35:50 2010 From: caron at unidata.ucar.edu (John Caron) Date: Thu, 04 Mar 2010 09:35:50 -0700 Subject: [CF-metadata] "Andrew Clegg": udunits 1 or 2 for CF? In-Reply-To: <20100304160041.GB29878@met.reading.ac.uk> References: <27898.1267633660@buddy.unidata.ucar.edu> <4B8EC68F.9050203@unidata.ucar.edu> <4B8F868D.7040707@pml.ac.uk> <4B8FD785.4000003@unidata.ucar.edu> <20100304160041.GB29878@met.reading.ac.uk> Message-ID: <4B8FE166.8090600@unidata.ucar.edu> Jonathan Gregory wrote: > Dear Steve et al. > > We can distinguish udunits-2 as a standard for units strings, and udunits-2 > as software. If we say that CF uses udunits-2 as its reference, programs in > Fortran can still use udunits-1 to process the units strings, in nearly all > cases, though obviously a ununits-2 Fortran interface would be preferable. > > To address Andrew's point about "u" for 1e-6 and Nan's about PSU, we could > make CF-specific xml files available for use with udunits-2. We decided to > do this with udunits.dat, in order to add sverdrup as well as PSU, but didn't > get round to it. > I _think_ to be completely accurate, in order to specify "udunits-2 standard for units strings" you need to also specify which udunits.dat database to use. Ideally this would be the default one, but as the discussion shows, its not necessarily the same. From steve at unidata.ucar.edu Thu Mar 4 11:06:09 2010 From: steve at unidata.ucar.edu (Steve Emmerson) Date: Thu, 04 Mar 2010 11:06:09 -0700 Subject: [CF-metadata] "Andrew Clegg": udunits 1 or 2 for CF? In-Reply-To: <4B8FCDBE.2050500@whoi.edu> References: <27898.1267633660@buddy.unidata.ucar.edu> <4B8EC68F.9050203@unidata.ucar.edu> <4B8FCDBE.2050500@whoi.edu> Message-ID: <4B8FF691.2070806@unidata.ucar.edu> Nan, Because the potential set of input unit strings to both packages is infinite, I concentrated on trying to keep the interpretation algorithm in the UDUNITS-2 package compatible with that of the UDUNITS-1 package so that the UDUNITS-2 package would interpret any string the same way the UDUNITS-1 package does. I can't guarantee that I was successful, however, especially when it comes to "fringe" unit specification. For example, the UDUNITS-1 package will interpret a bare prefix "unit" like "k" as 1000; whereas, the UDUNITS-2 package rejects such "units". Fortunately, people tend to not shoot themselves in the foot that way. Regards, Steve Emmerson On 03/04/2010 08:11 AM, Nan Galbraith wrote: > Hi Steve - > > Are all the terms in the new vocabulary backwards compatible, other > than non-ASCII characters and log units? > I just spent some time looking on the unidata web site to see if I could > find any information on changes to basic units names - additions or > otherwise. I'd thought there might be some new basic units, e.g. PSU > for salinity. There doesn't seem to be any way to compare the two > versions, as they're in very different formats. (The new xml list is > great, by the way.) > > Lots of people and systems, including the CF spec, use the vocabulary > for basic units from udunits, so when and if these terms change, it would > be helpful to have a description of those changes. The v2 manual doesn't > mention any additions, other than new support for non-ASCII and log > units. > > > In 10/2006, Alison wrote: > >> It emerged that there are already some units that have been identified >> as being useful for CF that are not currently part of udunits. >> Jonathan wrote: >> >>> > sverdrup = 1e6 m3 s-1 (we can't use the usual abbrev Sv though as it >>> > already has another definition) >>> > PSU and psu = 1e-3 (practical salinity unit, effectively mass >>> > fraction) >>> >> There is also decibel (dB). > > > Thanks - > > Nan Galbraith > > >>> I'm running into some problems regarding units in CF-compliant files. >>> Up until now I've been using udunits 1 to check units, but I recently >>> tried the CF checker which uses udunits2. There are some unit strings >>> which are valid in one but not the other. In particular, I am dealing >>> with milligrams per cubic meter. In udunits1, I used 'ukg m-3', which >>> udunits2 rejects as invalid. udunits2 accepts 'mg m-3' (which is much >>> better!), but udunits1 interprets this as to do with gravity. Because >>> of this, I can't include a unit string which is generally compatible > >>> >> ... >> The UDUNITS-1 library had a bug in it. The bug was that "g" was >> interpreted as meaning "gravity" (i.e., "standard_free_fall") rather >> than "gram". This was corrected in version 1.12.10 of the UDUNITS-1 >> package, which was released on 2009-09-17. >> >> ... >> >> Applications that use the UDUNITS-1 library prior to version 1.12.10 can >> be easily modified to interpret "g" as "gram" by removing the following >> entry from the UDUNITS-1 database ($prefix/etc/udunits.dat): >> >> g S gravity # approx. should ... >> >> I hope this helps. >> >> Regards, >> Steve Emmerson >> UDUNITS developer >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> > > From steve at unidata.ucar.edu Thu Mar 4 11:19:49 2010 From: steve at unidata.ucar.edu (Steve Emmerson) Date: Thu, 04 Mar 2010 11:19:49 -0700 Subject: [CF-metadata] udunits 1 or 2 for CF? In-Reply-To: <19272.1267715541@buddy.unidata.ucar.edu> References: <19272.1267715541@buddy.unidata.ucar.edu> Message-ID: <4B8FF9C5.5040404@unidata.ucar.edu> CF-conventioners, I recommend using full unit names and prefixes in unit specifications for just this reason: unit symbols and prefix symbols can be ambiguous, whereas unit names and prefix names are not. The UDUNITS-2 package will format a binary unit into a string representation using either symbols or names -- as requested by the client. Regards, Steve Emmerson Andrew Clegg wrote: I never thought of using the full word 'gram' - I've just checked and 'gram' and 'mgram' work on udunits-2 as well. Thanks. However, I'm still concerned that there are differences between the 2 versions, and that this should be at least noted in the conventions. Other people in the future will probably have the same problem, and it would be nice to have a definitive answer. My (strong) personal preference is to say that all unit strings should be correct when interpreted with udunits-2, rather than relying on a set of 'hacks' to ensure compatibility between the 2. From steve at unidata.ucar.edu Thu Mar 4 11:26:59 2010 From: steve at unidata.ucar.edu (Steve Emmerson) Date: Thu, 04 Mar 2010 11:26:59 -0700 Subject: [CF-metadata] UDUNITS 1 or 2 for CF? Message-ID: <4B8FFB73.9060104@unidata.ucar.edu> Just a couple of items: 1. Russ Rew reminded me that it's Fortran 2003 that supports the relatively easy creation of a Fortran interface to a C library. Using this feature for UDUNITS-2 would, therefore, have consequences for the Fortran crowd: they would have to use a Fortran 2003 conforming compiler. 2. I've subscribed to the cf-metadata mailing-list (at least for the duration of the UDUNITS storm :-). Regards, Steve Emmerson From olauret at cls.fr Fri Mar 5 06:03:26 2010 From: olauret at cls.fr (olivier lauret) Date: Fri, 5 Mar 2010 14:03:26 +0100 Subject: [CF-metadata] water level with/without datum In-Reply-To: References: <40829B0E077C1145A6DE44D39B3830A9088766A55B@nerckwmb1.ad.nerc.ac.uk><40829B0E077C1145A6DE44D39B3830A90887713994@nerckwmb1.ad.nerc.ac.uk><5B828D1373752F43A43240B3EBF08FF30122384C4B@SVR-SBS2008.sbsnetwork.local><20100223113337.GA23537@met.reading.ac.uk><4B83E20C.1020405@noaa.gov><20100223143300.GB23914@met.reading.ac.uk><20100225101618.GA3112@met.reading.ac.uk><4B86A97F.7010805@whoi.edu><20100226094155.GA5904@met.reading.ac.uk> Message-ID: <1240F43731C2EB4F8CC9BF70D233B511018C0685@SRV-XCHANGE-2K3.pc.cls.fr> Hi all, When I reread my previous mail, I found it was very confused and also looked not nice with previous contributions like Roy's: it was not my intentions, sorry for that. Writing things too fast causes muddled and blurred discourse! If we consider the last proposal from Seth, does that mean that we could have two different possibilities for the same standard name? If yes, I am afraid we could raise a situation where one would have collocated satellite data to compare with in-situ data and: - In the satellite dataset, CF attribute would be sea_surface_height_above_.. - In the in-situ dataset, CF attribute would be water_body_surface_height_above.. ? (Or perhaps I haven't well understood) Olivier -----Message d'origine----- De : cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] De la part de Seth McGinnis Envoy? : samedi 27 f?vrier 2010 04:51 ? : cf-metadata at cgd.ucar.edu Objet : Re: [CF-metadata] water level with/without datum >Therefore I think we have to decide what to call the new names. Roy suggested >water body. As I've said before, I would prefer sea/lake/river_water (or with >some other punctuation) to water_body_water, because sea/lake/river_water is >more self-explanatory, and the repetition of "water" in water_body_water is >clumsy and possibly confusing. I can imagine someone not being sure how to >parse "water body water temperature" when they first come across it. Instead of a prefix modifer, how about adding _body as a postfix modifier? So you could have sea_water_temperature for oceans and water_body_temperature for oceans, rivers, lakes, and other significant accumulations of liquid water. Cheers, ---- Seth McGinnis NARCCAP Data Manager ISSE / ISP / IMAGe / CISL / NCAR ---- (P.S.: Observation/tangent: It seems like this conundrum may be arising in part because the day-to-day meaning of the term "water" -- liquid H2O -- is at odds with the definition given in the standard name guidelines of "water in all phases if not otherwise qualified". Were there a blank slate, I would suggest using the unqualified term to mean "liquid water", in better alignment with its commonsense meaning, and coming up with a new term for the more restricted contexts where one needs to refer to all three phases. How frequently in current usage does the "all phases" sense differ fom the usual sense? Would it be worth considering a switch? That would be an alternate way around the issue of generic water bodies.) _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata Cliquez sur l'url suivante https://www.mailcontrol.com/sr/Y8JdOU4DsM7TndxI!oX7UvGHrMX8oTLhxXmnApiAmj9zdQJy4gJWXe3FyfcXLuoUBltZoDt4qRPbd8XIx2vetQ== si ce message est ind?sirable (pourriel). -------------- next part -------------- An HTML attachment was scrubbed... URL: From alison.pamment at stfc.ac.uk Fri Mar 5 06:11:04 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Fri, 5 Mar 2010 13:11:04 -0000 Subject: [CF-metadata] Standard name table update Message-ID: Dear All, I am planning to update the standard name table on Tuesday 9th March to add a number of new names and aliases and to make other changes that have been agreed in recent weeks. The Standard Names Guidelines document will also be updated. Please see below for a full list of the planned changes. If anyone spots any errors in the list please contact me as soon as possible. Best wishes, Alison 1. New aliases for existing names a. Cloud and precipitation variables for CMIP5. Proposed by Mark Webb. tendency_of_air_temperature_due_to_large_scale_precipitation will become tendency_of_air_temperature_due_to_stratiform_precipitation; K s-1 tendency_of_specific_humidity_due_to_large_scale_precipitation will become tendency_of_specific_humidity_due_to_stratiform_precipitation; s-1 b. Clarification of direction for convective mass flux. Proposed by Karl Taylor. atmosphere_convective_mass_flux will become atmosphere_net_upward_convective_mass_flux; kg m-2 s-1 c. Spelling and syntax corrections for three names. Reported by Jonathan Gregory. product_of_northward_wind_and_specific_humdity will become product_of_northward_wind_and_specific_humidity; m s-1 (adding an extra "i" in humidity). moles_per_unit_mass_of_cfc11_in_sea_water will become moles_of_cfc11_per_unit_mass_in_sea_water; mol kg-1 change_over_time_in_atmospheric_water_content_due_to_advection will become change_over_time_in_atmosphere_water_content_due_to_advection; kg m-2 d. Cloud liquid water names. Proposed by Jonathan Gregory. The phrase "cloud_liquid" will be changed to "cloud_liquid_water" in three names. tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_heteroge neous_nucleation_from_cloud_liquid will become tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_heteroge neous_nucleation_from_cloud_liquid_water tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_melting_ to_cloud_liquid will become tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_melting_ to_cloud_liquid_water tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_riming_f rom_cloud_liquid will become tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_riming_f rom_cloud_liquid_water e. Atmosphere optical thickness names. Arising from a 2008 mailing list thread 'Modification of some existing CF standard names for chemical constituents'. atmosphere_optical_thickness_due_to_aerosol will become atmosphere_optical_thickness_due_to_ambient_aerosol + defn update optical_thickness_of_atmosphere_layer_due_to_aerosol will become optical_thickness_of_atmosphere_layer_due_to_ambient_aerosol + defn update 2. New names a. Cloud and radiation variables for CMIP5. Proposed by Mark Webb. tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to _convective_detrainment; s-1 tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_convecti ve_detrainment; s-1 tendency_of_air_temperature_due_to_model_physics; K s-1 tendency_of_air_temperature_due_to_convection; K s-1 atmosphere_updraft_convective_mass_flux; kg m-2 s-1 atmosphere_downdraft_convective_mass_flux; kg m-2 s-1 atmosphere_net_upward_shallow_convective_mass_flux; kg m-2 s-1 atmosphere_net_upward_deep_convective_mass_flux; kg m-2 s-1 tendency_of_air_temperature_due_to_stratiform_cloud_and_precipitation_an d_boundary_layer_mixing; K s-1 tendency_of_specific_humidity_due_to_stratiform_cloud_and_precipitation_ and_boundary_layer_mixing; K s-1 upwelling_longwave_flux_in_air_assuming_clear_sky; W m-2 upwelling_shortwave_flux_in_air_assuming_clear_sky; W m-2 downwelling_longwave_flux_in_air_assuming_clear_sky; W m-2 downwelling_shortwave_flux_in_air_assuming_clear_sky; W m-2 b. Satellite ice-drift names. Proposed by Thomas Lavergne. eastward_sea_ice_displacement; m northward_sea_ice_displacement; m sea_ice_x_displacement; m sea_ice_y_displacement; m sea_ice_displacement; m direction_of_sea_ice_displacement; degrees c. Climate indexes, resulting from acceptance of trac ticket 33 proposed by Heinke Hock. number_of_days_with_air_temperature_below_threshold number_of_days_with_air_temperature_above_threshold number_of_days_with_lwe_thickness_of_precipitation_amount_above_threshol d number_of_days_with_wind_speed_above_threshold spell_length_of_days_with_air_temperature_below_threshold spell_length_of_days_with_air_temperature_above_threshold spell_length_of_days_with_lwe_thickness_of_precipitation_amount_above_th reshold spell_length_of_days_with_lwe_thickness_of_precipitation_amount_below_th reshold d. Peak wave period name. Proposed by Jennifer Brown. sea_surface_wave_period_at_variance_spectral_density_maximum; s e. Sea water transparency and reflectance names. Proposed by Olivier Lauret. secchi_depth_of_sea_water; m ratio_of_upwelling_radiance_emerging_from_sea_water_to_downwelling_radia tive_flux_in_air; sr^-1 angle_of_incidence; degree angle_of_emergence; degree f. Sea water velocity names. Proposed by Stephane Tarot. radial_sea_water_velocity_away_from_instrument; m s-1 direction_of_radial_vector_away_from_instrument; degree eastward_sea_water_velocity_assuming_no_tide; m s-1 northward_sea_water_velocity_assuming_no_tide; m s-1 g. Water column name. Proposed by Jeff deLaBeaujardiere. sea_floor_depth_below_sea_surface; m h. Aerosol optical thickness names. Proposed by Heinke Hoeck. atmosphere_absorption_optical_thickness_due_to_ambient_aerosol; 1 atmosphere_absorption_optical_thickness_due_to_dust_ambient_aerosol; 1 atmosphere_absorption_optical_thickness_due_to_particulate_organic_matte r_ambient_aerosol; 1 atmosphere_absorption_optical_thickness_due_to_sulfate_ambient_aerosol; 1 atmosphere_absorption_optical_thickness_due_to_seasalt_ambient_aerosol; 1 atmosphere_absorption_optical_thickness_due_to_black_carbon_ambient_aero sol; 1 3. Modification to definition of land_ice names following discussion in mailing list thread "Standard names for Glaciology and ice-sheet modeling:land_ice, sea_ice, floating_ice, ice shelves..." (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2009/002733.html and following). This change affects the following 17 names: land_ice_area_fraction land_ice_basal_melt_rate land_ice_basal_x_velocity land_ice_basal_y_velocity land_ice_calving_rate land_ice_lwe_basal_melt_rate land_ice_lwe_calving_rate land_ice_lwe_surface_specific_mass_balance land_ice_sigma_coordinate land_ice_surface_specific_mass_balance land_ice_temperature land_ice_thickness land_ice_vertical_mean_x_velocity land_ice_vertical_mean_y_velocity land_ice_x_velocity land_ice_y_velocity tendency_of_land_ice_thickness. In the definitions, the sentence reading ' "Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock' will be extended to read ' "Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock and also includes ice-shelves.' 4. Other changes to the standard name table. a. Remove duplicate entry for sea_surface_height_above_reference_ellipsoid. Reported by Heinke Hoeck and Phil Bentley. 5. Modifications to the Standard Name Guidelines document resulting from the acceptance of trac ticket 33. The following wording will be added to the 'Transformations' section of the document. A variable whose standard name has the form number_of_days_with_X_below|above_threshold must have a coordinate variable or scalar coordinate variable with the a standard name of X to supply the threshold(s). It must have a climatological time variable, and a cell_methods entry for within days which describes the processing of quantity X before the threshold is applied. A number_of_days is an extensive quantity in time, and the cell_methods entry for over days should be sum. A variable whose standard name has the form spell_length_of_days_with_X_below|above_threshold must have a coordinate variable or scalar coordinate variable with the a standard name of X to supply the threshold(s). It must have a climatological time variable, and a cell_method entry for within days which describes the processing of quantity X before the threshold is applied. A spell_length_of_days is an intensive quantity in time, and the cell_methods entry for over days can be any of the methods listed in Appendix E appropriate for intensive quantities e.g. maximum, minimum or mean. ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. From j.m.gregory at reading.ac.uk Fri Mar 5 06:28:56 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 5 Mar 2010 13:28:56 +0000 Subject: [CF-metadata] water level with/without datum In-Reply-To: <1240F43731C2EB4F8CC9BF70D233B511018C0685@SRV-XCHANGE-2K3.pc.cls.fr> References: <1240F43731C2EB4F8CC9BF70D233B511018C0685@SRV-XCHANGE-2K3.pc.cls.fr> Message-ID: <20100305132856.GA4832@met.reading.ac.uk> Dear Olivier > - In the satellite dataset, CF attribute would be > sea_surface_height_above_.. > > - In the in-situ dataset, CF attribute would be > water_body_surface_height_above.. I believe that we have agreed to call the latter water_surface_height_above... (John's suggestion). Are you happy with that? I think this general name could be used for sea, lake or river, but we also keep the sea_surface_height for sea specifically. I think sea_surface_height is the name which should be used for both satellite altimetry and tide-gauge measurements (on the sea). It's the same geophysical quantity, whichever way it's measured, so it should have the same name. water_surface_height could equally be used for either measurement method, and is appropriate if the data are not just for the sea. This sidesteps the general issue of sea/lake/river terms. The use of "surface" in water_surface makes it clear enough where the water is. If someone is definitely asking for a standard name which refers to a property of water in in sea, lake or river in general, we can return to that discussion. Roy gave a use case, but I'm not sure if that's a definite need. At present, my own preference would be for the lengthy but clear phrase sea_or_lake_or_river. Best wishes Jonathan From olauret at cls.fr Fri Mar 5 06:51:51 2010 From: olauret at cls.fr (olivier lauret) Date: Fri, 5 Mar 2010 14:51:51 +0100 Subject: [CF-metadata] water level with/without datum In-Reply-To: <20100305132856.GA4832@met.reading.ac.uk> References: <1240F43731C2EB4F8CC9BF70D233B511018C0685@SRV-XCHANGE-2K3.pc.cls.fr> <20100305132856.GA4832@met.reading.ac.uk> Message-ID: <1240F43731C2EB4F8CC9BF70D233B511018C06A7@SRV-XCHANGE-2K3.pc.cls.fr> Hi Jonathan, All right! Thank you very much for the clarification, it sounds good to me. I'm OK with that Olivier -----Message d'origine----- De?: Jonathan Gregory [mailto:jonathan at met.reading.ac.uk] De la part de Jonathan Gregory Envoy??: vendredi 5 mars 2010 14:29 ??: olivier lauret Cc?: Seth McGinnis; cf-metadata at cgd.ucar.edu Objet?: Re: [CF-metadata] water level with/without datum Dear Olivier > - In the satellite dataset, CF attribute would be > sea_surface_height_above_.. > > - In the in-situ dataset, CF attribute would be > water_body_surface_height_above.. I believe that we have agreed to call the latter water_surface_height_above... (John's suggestion). Are you happy with that? I think this general name could be used for sea, lake or river, but we also keep the sea_surface_height for sea specifically. I think sea_surface_height is the name which should be used for both satellite altimetry and tide-gauge measurements (on the sea). It's the same geophysical quantity, whichever way it's measured, so it should have the same name. water_surface_height could equally be used for either measurement method, and is appropriate if the data are not just for the sea. This sidesteps the general issue of sea/lake/river terms. The use of "surface" in water_surface makes it clear enough where the water is. If someone is definitely asking for a standard name which refers to a property of water in in sea, lake or river in general, we can return to that discussion. Roy gave a use case, but I'm not sure if that's a definite need. At present, my own preference would be for the lengthy but clear phrase sea_or_lake_or_river. Best wishes Jonathan Cliquez sur l'url suivante https://www.mailcontrol.com/sr/ROXy6RRVjiDTndxI!oX7UtECuJx2pP2xUXH5bYXq6nCtlOBZquI!qzF+!sGAiQv0NoXV7xPWi+wY6wpstbrpNg== si ce message est ind?sirable (pourriel). From Jeff.deLaBeaujardiere at noaa.gov Fri Mar 5 11:03:15 2010 From: Jeff.deLaBeaujardiere at noaa.gov (Jeff deLaBeaujardiere) Date: Fri, 05 Mar 2010 13:03:15 -0500 Subject: [CF-metadata] sea_surface_wave_mean_period In-Reply-To: <4B5F6AF2.9030301@noaa.gov> References: <4B5F6AF2.9030301@noaa.gov> Message-ID: <4B914763.7070607@noaa.gov> Hello- Thanks again for helpful discussion regarding sea_floor_depth_below_sea_surface and water_surface_height_above_reference datum. My next question is about wave data. We report a quantity that we call "Average Wave Period." A likely-seeming CF name would be sea_surface_wave_mean_period, but I only find that name qualified by a calculation method: sea_surface_wave_mean_period_from_variance_spectral_density_first_frequency_moment sea_surface_wave_mean_period_from_variance_spectral_density_inverse_frequency_moment sea_surface_wave_mean_period_from_variance_spectral_density_second_frequency_moment We would like to report mean periods without explicitly stating the method in the variable name. (We do have a metadata record that states a method such as "Longuet-Higgins 1964"; I do not know whether that title implies any particular method from the CF list). May we use sea_surface_wave_mean_period without qualification? More generally, below please find my proposed mapping of our current names to existing CF names: Significant Wave Height = sea_surface_wave_significant_height (m) Dominant Wave Period = sea_surface_wave_peak_period (s) Average Wave Period = sea_surface_wave_mean_period (s) [*] Swell Height = sea_surface_swell_wave_significant_height (m) Swell Period = sea_surface_swell_wave_period (s) Wind Wave Height = sea_surface_wind_wave_significant_height (m) Wind Wave Period = sea_surface_wind_wave_period (s) Water Temperature = sea_water_temperature (C) Mean Wave Direction at Peak Period = sea_surface_wave_to_direction (degree) [**] Swell Wave Direction = sea_surface_swell_wave_to_direction (degree) Wind Wave Direction = sea_surface_wind_wave_to_direction (degree) [*] This is the proposed shortened name. [**] I think this is the appropriate CF name but will consult with out wave experts. -Jeff DLB From j.m.gregory at reading.ac.uk Fri Mar 5 11:27:07 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 5 Mar 2010 18:27:07 +0000 Subject: [CF-metadata] sea_surface_wave_mean_period In-Reply-To: <4B914763.7070607@noaa.gov> References: <4B5F6AF2.9030301@noaa.gov> <4B914763.7070607@noaa.gov> Message-ID: <20100305182707.GA6442@met.reading.ac.uk> Dear Jeff > We would like to report mean periods without explicitly stating the method > in the variable name. (We do have a metadata record that states a method > such as "Longuet-Higgins 1964"; I do not know whether that title implies > any particular method from the CF list). > > May we use sea_surface_wave_mean_period without qualification? I would say Yes. Standard names are provided with different degrees of generality for different purposes. If you think that all the data to which you would give that standard name are the same geophysical quantity, and it is valid to compare them, even if the methods are different for deriving them, then it is correct to give them the same standard name. > More generally, below please find my proposed mapping of our current names > to existing CF names: > > Significant Wave Height = sea_surface_wave_significant_height (m) > Dominant Wave Period = sea_surface_wave_peak_period (s) > Average Wave Period = sea_surface_wave_mean_period (s) [*] > Swell Height = sea_surface_swell_wave_significant_height (m) > Swell Period = sea_surface_swell_wave_period (s) > Wind Wave Height = sea_surface_wind_wave_significant_height (m) > Wind Wave Period = sea_surface_wind_wave_period (s) > Water Temperature = sea_water_temperature (C) > Mean Wave Direction at Peak Period = sea_surface_wave_to_direction (degree) > [**] > Swell Wave Direction = sea_surface_swell_wave_to_direction (degree) > Wind Wave Direction = sea_surface_wind_wave_to_direction (degree) These mappings look right to me, but I am not an expert on these quantities myself. Best wishes Jonathan From hyoklee at hdfgroup.org Fri Mar 5 13:30:07 2010 From: hyoklee at hdfgroup.org (H. Joe Lee) Date: Fri, 5 Mar 2010 14:30:07 -0600 Subject: [CF-metadata] CF-convention for three-dimensional lat/long coordinate variables? Message-ID: Hi, I have a satellite data that stores lat / lon information in 3-D array and I'm wondering how such data can meet the CF convention. Following the http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/ch05s02.html page example convention, here's the description of my data: ------------------------- dimensions: d0 = 447 ; d1 = 3 ; d2 = 360; lev = 18 ; variables: float V(lev,d0,d1,d2) ; T:long_name = "Precipitable Water" ; T:units = "cm" ; T:coordinates = "lon lat" ; float lev(lev) ; lev:long_name = "pressure level" ; lev:units = "hPa" ; float lon(d0,d1,d2) ; lon:long_name = "longitude" ; lon:units = "degrees_east" ; float lat(d0,d1,d2) ; lat:long_name = "latitude" ; lat:units = "degrees_north" ; ----------------------------------------------- My question is, should lat / lon coordinate variables be always 2-D array in CF-convention for two dimensional coordinate system? Thanks, -- +1(217)265-7710 http://hdfeos.org From caron at unidata.ucar.edu Fri Mar 5 14:54:22 2010 From: caron at unidata.ucar.edu (John Caron) Date: Fri, 05 Mar 2010 14:54:22 -0700 Subject: [CF-metadata] CF-convention for three-dimensional lat/long coordinate variables? In-Reply-To: References: Message-ID: <4B917D8E.6050202@unidata.ucar.edu> what does the 3rd dimension represent ? On 3/5/2010 1:30 PM, H. Joe Lee wrote: > Hi, > > I have a satellite data that stores lat / lon information in 3-D > array and I'm wondering how such data can meet the CF convention. > > Following the > http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/ch05s02.html > page example convention, here's the description of my data: > > ------------------------- > dimensions: > > d0 = 447 ; > d1 = 3 ; > d2 = 360; > lev = 18 ; > > variables: > float V(lev,d0,d1,d2) ; > T:long_name = "Precipitable Water" ; > T:units = "cm" ; > T:coordinates = "lon lat" ; > float lev(lev) ; > lev:long_name = "pressure level" ; > lev:units = "hPa" ; > float lon(d0,d1,d2) ; > lon:long_name = "longitude" ; > lon:units = "degrees_east" ; > float lat(d0,d1,d2) ; > lat:long_name = "latitude" ; > lat:units = "degrees_north" ; > ----------------------------------------------- > > My question is, should lat / lon coordinate variables be always 2-D > array in CF-convention for two dimensional coordinate system? > > Thanks, > > -- > +1(217)265-7710 > http://hdfeos.org > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > From taylor13 at llnl.gov Fri Mar 5 15:14:26 2010 From: taylor13 at llnl.gov (Karl Taylor) Date: Fri, 05 Mar 2010 14:14:26 -0800 Subject: [CF-metadata] CF-convention for three-dimensional lat/long coordinate variables? In-Reply-To: References: Message-ID: <4B918242.6090605@llnl.gov> Hi, This file looks CF-compliant to me. I don't think it has to be 2-d. Like John Caron, I am mildly curious what the 3-dimensions represent. regards, Karl On 05-Mar-10 12:30 PM, H. Joe Lee wrote: > Hi, > > I have a satellite data that stores lat / lon information in 3-D > array and I'm wondering how such data can meet the CF convention. > > Following the > http://*cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/ch05s02.html > page example convention, here's the description of my data: > > ------------------------- > dimensions: > > d0 = 447 ; > d1 = 3 ; > d2 = 360; > lev = 18 ; > > variables: > float V(lev,d0,d1,d2) ; > T:long_name = "Precipitable Water" ; > T:units = "cm" ; > T:coordinates = "lon lat" ; > float lev(lev) ; > lev:long_name = "pressure level" ; > lev:units = "hPa" ; > float lon(d0,d1,d2) ; > lon:long_name = "longitude" ; > lon:units = "degrees_east" ; > float lat(d0,d1,d2) ; > lat:long_name = "latitude" ; > lat:units = "degrees_north" ; > ----------------------------------------------- > > My question is, should lat / lon coordinate variables be always 2-D > array in CF-convention for two dimensional coordinate system? > > Thanks, > > -- > +1(217)265-7710 > http://*hdfeos.org > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > From rkl at bodc.ac.uk Sat Mar 6 07:25:57 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Sat, 6 Mar 2010 14:25:57 +0000 Subject: [CF-metadata] sea_surface_wave_mean_period In-Reply-To: <20100305182707.GA6442@met.reading.ac.uk> References: <4B5F6AF2.9030301@noaa.gov> <4B914763.7070607@noaa.gov>,<20100305182707.GA6442@met.reading.ac.uk> Message-ID: <40829B0E077C1145A6DE44D39B3830A90886AB72B6@nerckwmb1.ad.nerc.ac.uk> Dear Jonathan, The existing wave period terms could be considered different geophysical quantities (they're periods pertaining to specific parts of the wave energy spectrum) and I would advise against using them in Jeff's case. I therefore support his suggestion at add sea_surface_wave_mean_period to the list of Standard Names. The only mapping that causes me to wonder a little is Mean Wave Direction at Peak Period = sea_surface_wave_to_direction, which implies that the CF term refers to the energetically dominant waves. I think this is OK, but opinions of any specialists out there would be welcomed. Cheers, Roy. ________________________________________ From: cf-metadata-bounces at cgd.ucar.edu [cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory [j.m.gregory at reading.ac.uk] Sent: 05 March 2010 18:27 To: Jeff deLaBeaujardiere Cc: cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] sea_surface_wave_mean_period Dear Jeff > We would like to report mean periods without explicitly stating the method > in the variable name. (We do have a metadata record that states a method > such as "Longuet-Higgins 1964"; I do not know whether that title implies > any particular method from the CF list). > > May we use sea_surface_wave_mean_period without qualification? I would say Yes. Standard names are provided with different degrees of generality for different purposes. If you think that all the data to which you would give that standard name are the same geophysical quantity, and it is valid to compare them, even if the methods are different for deriving them, then it is correct to give them the same standard name. > More generally, below please find my proposed mapping of our current names > to existing CF names: > > Significant Wave Height = sea_surface_wave_significant_height (m) > Dominant Wave Period = sea_surface_wave_peak_period (s) > Average Wave Period = sea_surface_wave_mean_period (s) [*] > Swell Height = sea_surface_swell_wave_significant_height (m) > Swell Period = sea_surface_swell_wave_period (s) > Wind Wave Height = sea_surface_wind_wave_significant_height (m) > Wind Wave Period = sea_surface_wind_wave_period (s) > Water Temperature = sea_water_temperature (C) > Mean Wave Direction at Peak Period = sea_surface_wave_to_direction (degree) > [**] > Swell Wave Direction = sea_surface_swell_wave_to_direction (degree) > Wind Wave Direction = sea_surface_wind_wave_to_direction (degree) These mappings look right to me, but I am not an expert on these quantities myself. Best wishes Jonathan _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From frederic.melin at jrc.ec.europa.eu Mon Mar 8 03:38:46 2010 From: frederic.melin at jrc.ec.europa.eu (Frederic MELIN) Date: Mon, 8 Mar 2010 11:38:46 +0100 Subject: [CF-metadata] Standard name table update : In-Reply-To: References: Message-ID: Dear Alison, I've participated in the definition of: ratio_of_upwelling_radiance_emerging_from_sea_water_to_downwelling_radiative _flux_in_air to indicate the so-called remote-sensing reflectance, that more specifically is the ratio of: surface_upwelling_spectral_radiance_in_air_emerging_from_sea_water and surface_downwelling_spectral_radiative_flux_in_air I've realized that the term 'surface' has been dropped off in this operation. As far as I am aware, the only context where this quantity is used is to describe its surface value (associated with a remote sensing context). I think it would be appropriate to add "surface_" in front for completeness: surface_ratio_of_upwelling_radiance_emerging_from_sea_water_to_downwelling_r adiative_flux_in_air I 'm sorry for the lateness of this input. Best regards, F. M?lin -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of alison.pamment at stfc.ac.uk Sent: Friday, 05 March, 2010 14:11 To: cf-metadata at cgd.ucar.edu Subject: [CF-metadata] Standard name table update Dear All, I am planning to update the standard name table on Tuesday 9th March to add a number of new names and aliases and to make other changes that have been agreed in recent weeks. The Standard Names Guidelines document will also be updated. Please see below for a full list of the planned changes. If anyone spots any errors in the list please contact me as soon as possible. Best wishes, Alison 1. New aliases for existing names a. Cloud and precipitation variables for CMIP5. Proposed by Mark Webb. tendency_of_air_temperature_due_to_large_scale_precipitation will become tendency_of_air_temperature_due_to_stratiform_precipitation; K s-1 tendency_of_specific_humidity_due_to_large_scale_precipitation will become tendency_of_specific_humidity_due_to_stratiform_precipitation; s-1 b. Clarification of direction for convective mass flux. Proposed by Karl Taylor. atmosphere_convective_mass_flux will become atmosphere_net_upward_convective_mass_flux; kg m-2 s-1 c. Spelling and syntax corrections for three names. Reported by Jonathan Gregory. product_of_northward_wind_and_specific_humdity will become product_of_northward_wind_and_specific_humidity; m s-1 (adding an extra "i" in humidity). moles_per_unit_mass_of_cfc11_in_sea_water will become moles_of_cfc11_per_unit_mass_in_sea_water; mol kg-1 change_over_time_in_atmospheric_water_content_due_to_advection will become change_over_time_in_atmosphere_water_content_due_to_advection; kg m-2 d. Cloud liquid water names. Proposed by Jonathan Gregory. The phrase "cloud_liquid" will be changed to "cloud_liquid_water" in three names. tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_heteroge neous_nucleation_from_cloud_liquid will become tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_heteroge neous_nucleation_from_cloud_liquid_water tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_melting_ to_cloud_liquid will become tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_melting_ to_cloud_liquid_water tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_riming_f rom_cloud_liquid will become tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_riming_f rom_cloud_liquid_water e. Atmosphere optical thickness names. Arising from a 2008 mailing list thread 'Modification of some existing CF standard names for chemical constituents'. atmosphere_optical_thickness_due_to_aerosol will become atmosphere_optical_thickness_due_to_ambient_aerosol + defn update optical_thickness_of_atmosphere_layer_due_to_aerosol will become optical_thickness_of_atmosphere_layer_due_to_ambient_aerosol + defn update 2. New names a. Cloud and radiation variables for CMIP5. Proposed by Mark Webb. tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to _convective_detrainment; s-1 tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_convecti ve_detrainment; s-1 tendency_of_air_temperature_due_to_model_physics; K s-1 tendency_of_air_temperature_due_to_convection; K s-1 atmosphere_updraft_convective_mass_flux; kg m-2 s-1 atmosphere_downdraft_convective_mass_flux; kg m-2 s-1 atmosphere_net_upward_shallow_convective_mass_flux; kg m-2 s-1 atmosphere_net_upward_deep_convective_mass_flux; kg m-2 s-1 tendency_of_air_temperature_due_to_stratiform_cloud_and_precipitation_an d_boundary_layer_mixing; K s-1 tendency_of_specific_humidity_due_to_stratiform_cloud_and_precipitation_ and_boundary_layer_mixing; K s-1 upwelling_longwave_flux_in_air_assuming_clear_sky; W m-2 upwelling_shortwave_flux_in_air_assuming_clear_sky; W m-2 downwelling_longwave_flux_in_air_assuming_clear_sky; W m-2 downwelling_shortwave_flux_in_air_assuming_clear_sky; W m-2 b. Satellite ice-drift names. Proposed by Thomas Lavergne. eastward_sea_ice_displacement; m northward_sea_ice_displacement; m sea_ice_x_displacement; m sea_ice_y_displacement; m sea_ice_displacement; m direction_of_sea_ice_displacement; degrees c. Climate indexes, resulting from acceptance of trac ticket 33 proposed by Heinke Hock. number_of_days_with_air_temperature_below_threshold number_of_days_with_air_temperature_above_threshold number_of_days_with_lwe_thickness_of_precipitation_amount_above_threshol d number_of_days_with_wind_speed_above_threshold spell_length_of_days_with_air_temperature_below_threshold spell_length_of_days_with_air_temperature_above_threshold spell_length_of_days_with_lwe_thickness_of_precipitation_amount_above_th reshold spell_length_of_days_with_lwe_thickness_of_precipitation_amount_below_th reshold d. Peak wave period name. Proposed by Jennifer Brown. sea_surface_wave_period_at_variance_spectral_density_maximum; s e. Sea water transparency and reflectance names. Proposed by Olivier Lauret. secchi_depth_of_sea_water; m ratio_of_upwelling_radiance_emerging_from_sea_water_to_downwelling_radia tive_flux_in_air; sr^-1 angle_of_incidence; degree angle_of_emergence; degree f. Sea water velocity names. Proposed by Stephane Tarot. radial_sea_water_velocity_away_from_instrument; m s-1 direction_of_radial_vector_away_from_instrument; degree eastward_sea_water_velocity_assuming_no_tide; m s-1 northward_sea_water_velocity_assuming_no_tide; m s-1 g. Water column name. Proposed by Jeff deLaBeaujardiere. sea_floor_depth_below_sea_surface; m h. Aerosol optical thickness names. Proposed by Heinke Hoeck. atmosphere_absorption_optical_thickness_due_to_ambient_aerosol; 1 atmosphere_absorption_optical_thickness_due_to_dust_ambient_aerosol; 1 atmosphere_absorption_optical_thickness_due_to_particulate_organic_matte r_ambient_aerosol; 1 atmosphere_absorption_optical_thickness_due_to_sulfate_ambient_aerosol; 1 atmosphere_absorption_optical_thickness_due_to_seasalt_ambient_aerosol; 1 atmosphere_absorption_optical_thickness_due_to_black_carbon_ambient_aero sol; 1 3. Modification to definition of land_ice names following discussion in mailing list thread "Standard names for Glaciology and ice-sheet modeling:land_ice, sea_ice, floating_ice, ice shelves..." (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2009/002733.html and following). This change affects the following 17 names: land_ice_area_fraction land_ice_basal_melt_rate land_ice_basal_x_velocity land_ice_basal_y_velocity land_ice_calving_rate land_ice_lwe_basal_melt_rate land_ice_lwe_calving_rate land_ice_lwe_surface_specific_mass_balance land_ice_sigma_coordinate land_ice_surface_specific_mass_balance land_ice_temperature land_ice_thickness land_ice_vertical_mean_x_velocity land_ice_vertical_mean_y_velocity land_ice_x_velocity land_ice_y_velocity tendency_of_land_ice_thickness. In the definitions, the sentence reading ' "Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock' will be extended to read ' "Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock and also includes ice-shelves.' 4. Other changes to the standard name table. a. Remove duplicate entry for sea_surface_height_above_reference_ellipsoid. Reported by Heinke Hoeck and Phil Bentley. 5. Modifications to the Standard Name Guidelines document resulting from the acceptance of trac ticket 33. The following wording will be added to the 'Transformations' section of the document. A variable whose standard name has the form number_of_days_with_X_below|above_threshold must have a coordinate variable or scalar coordinate variable with the a standard name of X to supply the threshold(s). It must have a climatological time variable, and a cell_methods entry for within days which describes the processing of quantity X before the threshold is applied. A number_of_days is an extensive quantity in time, and the cell_methods entry for over days should be sum. A variable whose standard name has the form spell_length_of_days_with_X_below|above_threshold must have a coordinate variable or scalar coordinate variable with the a standard name of X to supply the threshold(s). It must have a climatological time variable, and a cell_method entry for within days which describes the processing of quantity X before the threshold is applied. A spell_length_of_days is an intensive quantity in time, and the cell_methods entry for over days can be any of the methods listed in Appendix E appropriate for intensive quantities e.g. maximum, minimum or mean. ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From alison.pamment at stfc.ac.uk Mon Mar 8 05:40:48 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Mon, 8 Mar 2010 12:40:48 -0000 Subject: [CF-metadata] Standard name table update : In-Reply-To: References: Message-ID: Dear Frederic, Thank you for checking the list and pointing out this clarification. I will amend the name to include 'surface' as you suggest. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. > -----Original Message----- > From: Frederic MELIN [mailto:frederic.melin at jrc.ec.europa.eu] > Sent: 08 March 2010 10:39 > To: Pamment, Alison (STFC,RAL,SSTD) > Cc: cf-metadata at cgd.ucar.edu; 'olivier lauret' > Subject: RE: [CF-metadata] Standard name table update : > > Dear Alison, > > I've participated in the definition of: > > ratio_of_upwelling_radiance_emerging_from_sea_water_to_downwelling_radi > ative > _flux_in_air > > to indicate the so-called remote-sensing reflectance, that more > specifically > is the ratio of: > surface_upwelling_spectral_radiance_in_air_emerging_from_sea_water > and > surface_downwelling_spectral_radiative_flux_in_air > > I've realized that the term 'surface' has been dropped off in this > operation. As far as I am aware, the only context where this quantity > is > used is to describe its surface value (associated with a remote sensing > context). > I think it would be appropriate to add "surface_" in front for > completeness: > > > surface_ratio_of_upwelling_radiance_emerging_from_sea_water_to_downwell > ing_r > adiative_flux_in_air > > I 'm sorry for the lateness of this input. > Best regards, > F. M?lin > > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu > [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of > alison.pamment at stfc.ac.uk > Sent: Friday, 05 March, 2010 14:11 > To: cf-metadata at cgd.ucar.edu > Subject: [CF-metadata] Standard name table update > > Dear All, > > I am planning to update the standard name table on Tuesday 9th March to > add a number of new names and aliases and to > make other changes that have been agreed in recent weeks. The Standard > Names Guidelines document will also be updated. > Please see below for a full list of the planned changes. If anyone > spots > any errors in the list please contact > me as soon as possible. > > Best wishes, > Alison > > 1. New aliases for existing names > > a. Cloud and precipitation variables for CMIP5. Proposed by Mark Webb. > > tendency_of_air_temperature_due_to_large_scale_precipitation will > become > tendency_of_air_temperature_due_to_stratiform_precipitation; K s-1 > > tendency_of_specific_humidity_due_to_large_scale_precipitation will > become tendency_of_specific_humidity_due_to_stratiform_precipitation; > s-1 > > b. Clarification of direction for convective mass flux. Proposed by > Karl Taylor. > > atmosphere_convective_mass_flux will become > atmosphere_net_upward_convective_mass_flux; kg m-2 s-1 > > c. Spelling and syntax corrections for three names. Reported by > Jonathan > Gregory. > > product_of_northward_wind_and_specific_humdity will become > product_of_northward_wind_and_specific_humidity; m s-1 (adding an extra > "i" in humidity). > > moles_per_unit_mass_of_cfc11_in_sea_water will become > moles_of_cfc11_per_unit_mass_in_sea_water; mol kg-1 > > change_over_time_in_atmospheric_water_content_due_to_advection will > become change_over_time_in_atmosphere_water_content_due_to_advection; > kg > m-2 > > d. Cloud liquid water names. Proposed by Jonathan Gregory. > The phrase "cloud_liquid" will be changed to "cloud_liquid_water" in > three names. > > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_heterog > e > neous_nucleation_from_cloud_liquid will become > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_heterog > e > neous_nucleation_from_cloud_liquid_water > > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_melting > _ > to_cloud_liquid will become > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_melting > _ > to_cloud_liquid_water > > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_riming_ > f > rom_cloud_liquid will become > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_riming_ > f > rom_cloud_liquid_water > > e. Atmosphere optical thickness names. Arising from a 2008 mailing > list > thread 'Modification of some existing CF standard names for chemical > constituents'. > > atmosphere_optical_thickness_due_to_aerosol will become > atmosphere_optical_thickness_due_to_ambient_aerosol > + defn update > > optical_thickness_of_atmosphere_layer_due_to_aerosol will become > optical_thickness_of_atmosphere_layer_due_to_ambient_aerosol + defn > update > > 2. New names > > a. Cloud and radiation variables for CMIP5. Proposed by Mark Webb. > > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_t > o > _convective_detrainment; s-1 > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_convect > i > ve_detrainment; s-1 > tendency_of_air_temperature_due_to_model_physics; K s-1 > tendency_of_air_temperature_due_to_convection; K s-1 > atmosphere_updraft_convective_mass_flux; kg m-2 s-1 > atmosphere_downdraft_convective_mass_flux; kg m-2 s-1 > atmosphere_net_upward_shallow_convective_mass_flux; kg m-2 s-1 > atmosphere_net_upward_deep_convective_mass_flux; kg m-2 s-1 > tendency_of_air_temperature_due_to_stratiform_cloud_and_precipitation_a > n > d_boundary_layer_mixing; K s-1 > tendency_of_specific_humidity_due_to_stratiform_cloud_and_precipitation > _ > and_boundary_layer_mixing; K s-1 > upwelling_longwave_flux_in_air_assuming_clear_sky; W m-2 > upwelling_shortwave_flux_in_air_assuming_clear_sky; W m-2 > downwelling_longwave_flux_in_air_assuming_clear_sky; W m-2 > downwelling_shortwave_flux_in_air_assuming_clear_sky; W m-2 > > b. Satellite ice-drift names. Proposed by Thomas Lavergne. > > eastward_sea_ice_displacement; m > northward_sea_ice_displacement; m > sea_ice_x_displacement; m > sea_ice_y_displacement; m > sea_ice_displacement; m > direction_of_sea_ice_displacement; degrees > > c. Climate indexes, resulting from acceptance of trac ticket 33 > proposed > by Heinke Hock. > > number_of_days_with_air_temperature_below_threshold > number_of_days_with_air_temperature_above_threshold > number_of_days_with_lwe_thickness_of_precipitation_amount_above_thresho > l > d > number_of_days_with_wind_speed_above_threshold > > spell_length_of_days_with_air_temperature_below_threshold > spell_length_of_days_with_air_temperature_above_threshold > spell_length_of_days_with_lwe_thickness_of_precipitation_amount_above_t > h > reshold > spell_length_of_days_with_lwe_thickness_of_precipitation_amount_below_t > h > reshold > > d. Peak wave period name. Proposed by Jennifer Brown. > > sea_surface_wave_period_at_variance_spectral_density_maximum; s > > e. Sea water transparency and reflectance names. Proposed by Olivier > Lauret. > > secchi_depth_of_sea_water; m > ratio_of_upwelling_radiance_emerging_from_sea_water_to_downwelling_radi > a > tive_flux_in_air; sr^-1 > angle_of_incidence; degree > angle_of_emergence; degree > > f. Sea water velocity names. Proposed by Stephane Tarot. > > radial_sea_water_velocity_away_from_instrument; m s-1 > direction_of_radial_vector_away_from_instrument; degree > eastward_sea_water_velocity_assuming_no_tide; m s-1 > northward_sea_water_velocity_assuming_no_tide; m s-1 > > g. Water column name. Proposed by Jeff deLaBeaujardiere. > > sea_floor_depth_below_sea_surface; m > > h. Aerosol optical thickness names. Proposed by Heinke Hoeck. > > atmosphere_absorption_optical_thickness_due_to_ambient_aerosol; 1 > atmosphere_absorption_optical_thickness_due_to_dust_ambient_aerosol; 1 > atmosphere_absorption_optical_thickness_due_to_particulate_organic_matt > e > r_ambient_aerosol; 1 > atmosphere_absorption_optical_thickness_due_to_sulfate_ambient_aerosol; > 1 > atmosphere_absorption_optical_thickness_due_to_seasalt_ambient_aerosol; > 1 > atmosphere_absorption_optical_thickness_due_to_black_carbon_ambient_aer > o > sol; 1 > > 3. Modification to definition of land_ice names following discussion in > mailing list thread "Standard names for Glaciology and ice-sheet > modeling:land_ice, sea_ice, floating_ice, ice shelves..." > (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2009/002733.html and > following). > > This change affects the following 17 names: > > land_ice_area_fraction > land_ice_basal_melt_rate > land_ice_basal_x_velocity > land_ice_basal_y_velocity > land_ice_calving_rate > land_ice_lwe_basal_melt_rate > land_ice_lwe_calving_rate > land_ice_lwe_surface_specific_mass_balance > land_ice_sigma_coordinate > land_ice_surface_specific_mass_balance > land_ice_temperature > land_ice_thickness > land_ice_vertical_mean_x_velocity > land_ice_vertical_mean_y_velocity > land_ice_x_velocity > land_ice_y_velocity > tendency_of_land_ice_thickness. > > In the definitions, the sentence reading ' "Land ice" means glaciers, > ice-caps and ice-sheets resting on bedrock' will be extended to read ' > "Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock > and also includes ice-shelves.' > > 4. Other changes to the standard name table. > > a. Remove duplicate entry for > sea_surface_height_above_reference_ellipsoid. Reported by Heinke Hoeck > and Phil Bentley. > > 5. Modifications to the Standard Name Guidelines document resulting > from > the acceptance of trac ticket 33. > > The following wording will be added to the 'Transformations' section of > the document. > > A variable whose standard name has the form > number_of_days_with_X_below|above_threshold must have a coordinate > variable or scalar coordinate variable with the a standard name of X to > supply the threshold(s). It must have a climatological time variable, > and a cell_methods entry for within days which describes the processing > of quantity X before the threshold is applied. A number_of_days is an > extensive quantity in time, and the cell_methods entry for over days > should be sum. > > A variable whose standard name has the form > spell_length_of_days_with_X_below|above_threshold must have a > coordinate > variable or scalar coordinate variable with the a standard name of X to > supply the threshold(s). It must have a climatological time variable, > and a cell_method entry for within days which describes the processing > of quantity X before the threshold is applied. A spell_length_of_days > is > an intensive quantity in time, and the cell_methods entry for over days > can be any of the methods listed in Appendix E appropriate for > intensive > quantities e.g. maximum, minimum or mean. > > ------ > Alison Pamment Tel: +44 1235 778065 > NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > Rutherford Appleton Laboratory Email: > alison.pamment at stfc.ac.uk > Chilton, Didcot, OX11 0QX, U.K. > > > -- > Scanned by iCritical. > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Scanned by iCritical. From hyoklee at hdfgroup.org Mon Mar 8 07:37:18 2010 From: hyoklee at hdfgroup.org (H. Joe Lee) Date: Mon, 8 Mar 2010 08:37:18 -0600 Subject: [CF-metadata] CF-convention for three-dimensional lat/long coordinate variables? In-Reply-To: <4B918242.6090605@llnl.gov> References: <4B918242.6090605@llnl.gov> Message-ID: Thanks, Karl! Maybe, I think it's good to mention this possibility in the CF document: coordinate variables can be arbitrary n-Dimension arrays where n > 1. Regarding the 3rd dimension, the 3-D lat/lon coordinate variables have dimension names like below. 447 (Number of HourBoxes) x 3 (1.0 deg. Colat Zones: 178 - 180) x 360 (1.0 deg. longitude regions) -- +1(217)265-7710 http://hdfeos.org On Fri, Mar 5, 2010 at 4:14 PM, Karl Taylor wrote: > Hi, > > This file looks CF-compliant to me. I don't think it has to be 2-d. Like > John Caron, I am mildly curious what the 3-dimensions represent. > > regards, > Karl > > On 05-Mar-10 12:30 PM, H. Joe Lee wrote: >> >> Hi, >> >> I have a satellite data that stores lat / lon information in 3-D >> array and I'm wondering how such data can meet the CF convention. >> >> Following the >> http://*cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/ch05s02.html >> page example convention, here's the description of my data: >> >> ------------------------- >> dimensions: >> >> d0 = 447 ; >> d1 = 3 ; >> d2 = 360; >> lev = 18 ; >> >> variables: >> float V(lev,d0,d1,d2) ; >> T:long_name = "Precipitable Water" ; >> T:units = "cm" ; >> T:coordinates = "lon lat" ; >> float lev(lev) ; >> lev:long_name = "pressure level" ; >> lev:units = "hPa" ; >> float lon(d0,d1,d2) ; >> lon:long_name = "longitude" ; >> lon:units = "degrees_east" ; >> float lat(d0,d1,d2) ; >> lat:long_name = "latitude" ; >> lat:units = "degrees_north" ; >> ----------------------------------------------- >> >> My question is, should lat / lon coordinate variables be always 2-D >> array in CF-convention for two dimensional coordinate system? >> >> Thanks, >> >> -- >> +1(217)265-7710 >> http://*hdfeos.org >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> >> > > From ancl at pml.ac.uk Tue Mar 9 03:53:38 2010 From: ancl at pml.ac.uk (Andrew Clegg) Date: Tue, 09 Mar 2010 10:53:38 +0000 Subject: [CF-metadata] udunits 1 or 2 for CF? In-Reply-To: <4B8FF9C5.5040404@unidata.ucar.edu> References: <19272.1267715541@buddy.unidata.ucar.edu> <4B8FF9C5.5040404@unidata.ucar.edu> Message-ID: <4B9628B2.1050500@pml.ac.uk> This seems like a good solution to me. Maybe a recommendation (rather than a requirement) should be added that full units names & prefixes are used, with a note mentioning that in some cases there may be incompatibilities when using symbols. Cheers, Andrew Clegg Steve Emmerson wrote: > CF-conventioners, > > I recommend using full unit names and prefixes in unit specifications > for just this reason: unit symbols and prefix symbols can be ambiguous, > whereas unit names and prefix names are not. > > The UDUNITS-2 package will format a binary unit into a string > representation using either symbols or names -- as requested by the client. > > Regards, > Steve Emmerson > > Andrew Clegg wrote: > I never thought of using the full word 'gram' - I've just checked and > 'gram' and 'mgram' work on udunits-2 as well. Thanks. > > However, I'm still concerned that there are differences between the 2 > versions, and that this should be at least noted in the conventions. > Other people in the future will probably have the same problem, and it > would be nice to have a definitive answer. My (strong) personal > preference is to say that all unit strings should be correct when > interpreted with udunits-2, rather than relying on a set of 'hacks' to > ensure compatibility between the 2. > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -------------------------------------------------------------------------------- Plymouth Marine Laboratory Registered Office: Prospect Place The Hoe Plymouth PL1 3DH Website: www.pml.ac.uk Registered Charity No. 1091222 PML is a company limited by guarantee registered in England & Wales company number 4178503 PML is a member of the Plymouth Marine Sciences Partnership Website: www.pmsp.org.uk -------------------------------------------------------------------------------- This e-mail, its content and any file attachments are confidential. If you have received this e-mail in error please do not copy, disclose it to any third party or use the contents or attachments in any way. Please notify the sender by replying to this e-mail or e-mail forinfo at pml.ac.uk and then delete the email without making any copies or using it in any other way. The content of this message may contain personal views which are not the views of Plymouth Marine Laboratory unless specifically stated. You are reminded that e-mail communications are not secure and may contain viruses. Plymouth Marine Laboratory accepts no liability for any loss or damage which may be caused by viruses. -------------------------------------------------------------------------------- From olauret at cls.fr Tue Mar 9 04:16:07 2010 From: olauret at cls.fr (olivier lauret) Date: Tue, 9 Mar 2010 12:16:07 +0100 Subject: [CF-metadata] CF Conventions versioning Message-ID: <1240F43731C2EB4F8CC9BF70D233B511019ABFAD@SRV-XCHANGE-2K3.pc.cls.fr> Hi all, In the frame of MyOcean EU Project, I have one request about CF Conventions versions: if one recommend the use of CF 1.4, I guess that means it won't be compliant with previous version (1.3, 1.1..), is it? (My understanding is that there is no retro-compatibility, but I am not sure) Thanks for your help! Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.m.gregory at reading.ac.uk Tue Mar 9 11:02:53 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 9 Mar 2010 18:02:53 +0000 Subject: [CF-metadata] CF Conventions versioning In-Reply-To: <1240F43731C2EB4F8CC9BF70D233B511019ABFAD@SRV-XCHANGE-2K3.pc.cls.fr> References: <1240F43731C2EB4F8CC9BF70D233B511019ABFAD@SRV-XCHANGE-2K3.pc.cls.fr> Message-ID: <20100309180253.GB19399@met.reading.ac.uk> Dear Olivier > In the frame of MyOcean EU Project, I have one request about CF > Conventions versions: if one recommend the use of CF 1.4, I guess that > means it won't be compliant with previous version (1.3, 1.1..), is it? > (My understanding is that there is no retro-compatibility, but I am > not sure) Actually, so far CF versions are backward compatible. New features have always been introduced as optional, not mandatory, and existing features have not so far been deleted. Best wishes Jonathan From olauret at cls.fr Tue Mar 9 11:05:45 2010 From: olauret at cls.fr (olivier lauret) Date: Tue, 9 Mar 2010 19:05:45 +0100 Subject: [CF-metadata] CF Conventions versioning In-Reply-To: <20100309180253.GB19399@met.reading.ac.uk> References: <1240F43731C2EB4F8CC9BF70D233B511019ABFAD@SRV-XCHANGE-2K3.pc.cls.fr> <20100309180253.GB19399@met.reading.ac.uk> Message-ID: <1240F43731C2EB4F8CC9BF70D233B511019AC056@SRV-XCHANGE-2K3.pc.cls.fr> Good news, Thank you very much Jonathan. -----Message d'origine----- De?: Jonathan Gregory [mailto:jonathan at met.reading.ac.uk] De la part de Jonathan Gregory Envoy??: mardi 9 mars 2010 19:03 ??: olivier lauret Cc?: cf-metadata at cgd.ucar.edu; Thomas LOUBRIEU Objet?: Re: [CF-metadata] CF Conventions versioning Dear Olivier > In the frame of MyOcean EU Project, I have one request about CF > Conventions versions: if one recommend the use of CF 1.4, I guess that > means it won't be compliant with previous version (1.3, 1.1..), is it? > (My understanding is that there is no retro-compatibility, but I am > not sure) Actually, so far CF versions are backward compatible. New features have always been introduced as optional, not mandatory, and existing features have not so far been deleted. Best wishes Jonathan Cliquez sur l'url suivante https://www.mailcontrol.com/sr/Ec68i5kpS9nTndxI!oX7Us3fUQZbLcSFvqtmSXVlph36cDCjM1mYrdjuXYLmb14ox5HHDbW7tgB8TccP!XTbKg== si ce message est ind?sirable (pourriel). From caron at unidata.ucar.edu Wed Mar 10 08:27:38 2010 From: caron at unidata.ucar.edu (john caron) Date: Wed, 10 Mar 2010 10:27:38 -0500 Subject: [CF-metadata] CF-convention for three-dimensional lat/long coordinate variables? In-Reply-To: References: <4B918242.6090605@llnl.gov> Message-ID: <4B97BA6A.4050307@unidata.ucar.edu> It appears that d0 is a time dimension? If so, CF would require a time coordinate for it. In any case, its necessary to distinguish between "CF compliant" and "able to be georeferenced by generic programs using CF metadata". The latter is more stringent, and at the moment i dont think your dataset has enough info. H. Joe Lee wrote: > Thanks, Karl! Maybe, I think it's good to mention this possibility > in the CF document: coordinate variables can be arbitrary n-Dimension > arrays where n > 1. > > Regarding the 3rd dimension, the 3-D lat/lon coordinate variables > have dimension names like below. > > 447 (Number of HourBoxes) x 3 (1.0 deg. Colat Zones: 178 - 180) x > 360 (1.0 deg. longitude regions) > > > -- > +1(217)265-7710 > http://hdfeos.org > > > > On Fri, Mar 5, 2010 at 4:14 PM, Karl Taylor wrote: > >> Hi, >> >> This file looks CF-compliant to me. I don't think it has to be 2-d. Like >> John Caron, I am mildly curious what the 3-dimensions represent. >> >> regards, >> Karl >> >> On 05-Mar-10 12:30 PM, H. Joe Lee wrote: >> >>> Hi, >>> >>> I have a satellite data that stores lat / lon information in 3-D >>> array and I'm wondering how such data can meet the CF convention. >>> >>> Following the >>> http://*cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/ch05s02.html >>> page example convention, here's the description of my data: >>> >>> ------------------------- >>> dimensions: >>> >>> d0 = 447 ; >>> d1 = 3 ; >>> d2 = 360; >>> lev = 18 ; >>> >>> variables: >>> float V(lev,d0,d1,d2) ; >>> T:long_name = "Precipitable Water" ; >>> T:units = "cm" ; >>> T:coordinates = "lon lat" ; >>> float lev(lev) ; >>> lev:long_name = "pressure level" ; >>> lev:units = "hPa" ; >>> float lon(d0,d1,d2) ; >>> lon:long_name = "longitude" ; >>> lon:units = "degrees_east" ; >>> float lat(d0,d1,d2) ; >>> lat:long_name = "latitude" ; >>> lat:units = "degrees_north" ; >>> ----------------------------------------------- >>> >>> My question is, should lat / lon coordinate variables be always 2-D >>> array in CF-convention for two dimensional coordinate system? >>> >>> Thanks, >>> >>> -- >>> +1(217)265-7710 >>> http://*hdfeos.org >>> _______________________________________________ >>> CF-metadata mailing list >>> CF-metadata at cgd.ucar.edu >>> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>> >>> >>> >>> >> > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > From hyoklee at hdfgroup.org Wed Mar 10 09:26:40 2010 From: hyoklee at hdfgroup.org (H. Joe Lee) Date: Wed, 10 Mar 2010 10:26:40 -0600 Subject: [CF-metadata] CF-convention for three-dimensional lat/long coordinate variables? In-Reply-To: <4B97BA6A.4050307@unidata.ucar.edu> References: <4B918242.6090605@llnl.gov> <4B97BA6A.4050307@unidata.ucar.edu> Message-ID: Hi, John! On Wed, Mar 10, 2010 at 9:27 AM, john caron wrote: > It appears that d0 is a time dimension? If so, CF would require a time > coordinate for it. I don't know its precise physical meaning but the real interesting part is that lat/lon positions are recorded in 3-D array since most EOS swath has 2-D array lat/lon coordinate variables. The data has a separate time variable in 3-D array as well. In CF-1.4 two dimensional coordinate system, I believe that the name and the number of dimensions are not significant as long as they are unique enough to associate between coordinate variables and variables. > In any case, its necessary to distinguish between "CF > compliant" and "able to be georeferenced by generic programs using CF > metadata". The latter is more stringent, and at the moment i dont think your > dataset has enough info. I agree that the latter is more stringent. I often feel frustrated by the gap between "CF-compliant"-ness of data and "geo-referencing capability of the real softwares using CF metadata". However, I think my data has enough information to be plotted on the World map if softwares are smart enough to pick up lat/lon coordinate variables represented in 3-D, 4-D, ... n-D. > > > H. Joe Lee wrote: >> >> Thanks, Karl! Maybe, I think it's good to mention this possibility >> in the CF document: coordinate variables can be arbitrary n-Dimension >> arrays where n > 1. >> >> Regarding the 3rd dimension, the 3-D lat/lon coordinate variables >> have dimension names like below. >> >> 447 (Number of HourBoxes) x 3 (1.0 deg. Colat Zones: 178 - 180) x >> 360 (1.0 deg. longitude regions) >> >> >> -- >> +1(217)265-7710 >> http://hdfeos.org >> >> >> >> On Fri, Mar 5, 2010 at 4:14 PM, Karl Taylor wrote: >> >>> >>> Hi, >>> >>> This file looks CF-compliant to me. I don't think it has to be 2-d. >>> Like >>> John Caron, I am mildly curious what the 3-dimensions represent. >>> >>> regards, >>> Karl >>> >>> On 05-Mar-10 12:30 PM, H. Joe Lee wrote: >>> >>>> >>>> Hi, >>>> >>>> I have a satellite data that stores lat / lon information in 3-D >>>> array and I'm wondering how such data can meet the CF convention. >>>> >>>> Following the >>>> http://*cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/ch05s02.html >>>> page example convention, here's the description of my data: >>>> >>>> ------------------------- >>>> dimensions: >>>> >>>> d0 = 447 ; >>>> d1 = 3 ; >>>> d2 = 360; >>>> lev = 18 ; >>>> >>>> variables: >>>> float V(lev,d0,d1,d2) ; >>>> T:long_name = "Precipitable Water" ; >>>> T:units = "cm" ; >>>> T:coordinates = "lon lat" ; >>>> float lev(lev) ; >>>> lev:long_name = "pressure level" ; >>>> lev:units = "hPa" ; >>>> float lon(d0,d1,d2) ; >>>> lon:long_name = "longitude" ; >>>> lon:units = "degrees_east" ; >>>> float lat(d0,d1,d2) ; >>>> lat:long_name = "latitude" ; >>>> lat:units = "degrees_north" ; >>>> ----------------------------------------------- >>>> >>>> My question is, should lat / lon coordinate variables be always 2-D >>>> array in CF-convention for two dimensional coordinate system? >>>> >>>> Thanks, >>>> >>>> -- >>>> +1(217)265-7710 >>>> http://*hdfeos.org >>>> _______________________________________________ >>>> CF-metadata mailing list >>>> CF-metadata at cgd.ucar.edu >>>> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>>> >>>> >>>> >>>> >>> >>> >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> > > From alison.pamment at stfc.ac.uk Thu Mar 11 05:47:11 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Thu, 11 Mar 2010 12:47:11 -0000 Subject: [CF-metadata] Standard name table update In-Reply-To: References: Message-ID: Dear All, The standard name table has been updated as detailed in my previous posting. The current version is now version 13, dated 11 March 2010. While every effort has been made to ensure that the names, units and definitions are correct, please let me know if you do spot any mistakes or omissions. Best wishes, Alison > > Dear All, > > I am planning to update the standard name table on Tuesday 9th March to > add a number of new names and aliases and to > make other changes that have been agreed in recent weeks. The Standard > Names Guidelines document will also be updated. > Please see below for a full list of the planned changes. If anyone > spots > any errors in the list please contact > me as soon as possible. > > Best wishes, > Alison > > 1. New aliases for existing names > > a. Cloud and precipitation variables for CMIP5. Proposed by Mark Webb. > > tendency_of_air_temperature_due_to_large_scale_precipitation will > become > tendency_of_air_temperature_due_to_stratiform_precipitation; K s-1 > > tendency_of_specific_humidity_due_to_large_scale_precipitation will > become tendency_of_specific_humidity_due_to_stratiform_precipitation; > s-1 > > b. Clarification of direction for convective mass flux. Proposed by > Karl Taylor. > > atmosphere_convective_mass_flux will become > atmosphere_net_upward_convective_mass_flux; kg m-2 s-1 > > c. Spelling and syntax corrections for three names. Reported by > Jonathan > Gregory. > > product_of_northward_wind_and_specific_humdity will become > product_of_northward_wind_and_specific_humidity; m s-1 (adding an extra > "i" in humidity). > > moles_per_unit_mass_of_cfc11_in_sea_water will become > moles_of_cfc11_per_unit_mass_in_sea_water; mol kg-1 > > change_over_time_in_atmospheric_water_content_due_to_advection will > become change_over_time_in_atmosphere_water_content_due_to_advection; > kg > m-2 > > d. Cloud liquid water names. Proposed by Jonathan Gregory. > The phrase "cloud_liquid" will be changed to "cloud_liquid_water" in > three names. > > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_heteroge neous_nucleation_from_cloud_liquid will become > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_heteroge neous_nucleation_from_cloud_liquid_water > > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_melting_ to_cloud_liquid will become > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_melting_ to_cloud_liquid_water > > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_riming_f rom_cloud_liquid will become > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_riming_f rom_cloud_liquid_water > > e. Atmosphere optical thickness names. Arising from a 2008 mailing list > thread 'Modification of some existing CF standard names for chemical constituents'. > > atmosphere_optical_thickness_due_to_aerosol will become > atmosphere_optical_thickness_due_to_ambient_aerosol > + defn update > > optical_thickness_of_atmosphere_layer_due_to_aerosol will become > optical_thickness_of_atmosphere_layer_due_to_ambient_aerosol + defn update > > 2. New names > > a. Cloud and radiation variables for CMIP5. Proposed by Mark Webb. > > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to _convective_detrainment; s-1 > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_convecti ve_detrainment; s-1 > tendency_of_air_temperature_due_to_model_physics; K s-1 > tendency_of_air_temperature_due_to_convection; K s-1 > atmosphere_updraft_convective_mass_flux; kg m-2 s-1 > atmosphere_downdraft_convective_mass_flux; kg m-2 s-1 > atmosphere_net_upward_shallow_convective_mass_flux; kg m-2 s-1 > atmosphere_net_upward_deep_convective_mass_flux; kg m-2 s-1 > tendency_of_air_temperature_due_to_stratiform_cloud_and_precipitation_an d_boundary_layer_mixing; K s-1 > tendency_of_specific_humidity_due_to_stratiform_cloud_and_precipitation_ and_boundary_layer_mixing; K s-1 > upwelling_longwave_flux_in_air_assuming_clear_sky; W m-2 > upwelling_shortwave_flux_in_air_assuming_clear_sky; W m-2 > downwelling_longwave_flux_in_air_assuming_clear_sky; W m-2 > downwelling_shortwave_flux_in_air_assuming_clear_sky; W m-2 > > b. Satellite ice-drift names. Proposed by Thomas Lavergne. > > eastward_sea_ice_displacement; m > northward_sea_ice_displacement; m > sea_ice_x_displacement; m > sea_ice_y_displacement; m > sea_ice_displacement; m > direction_of_sea_ice_displacement; degrees > > c. Climate indexes, resulting from acceptance of trac ticket 33 > proposed > by Heinke Hock. > > number_of_days_with_air_temperature_below_threshold > number_of_days_with_air_temperature_above_threshold > number_of_days_with_lwe_thickness_of_precipitation_amount_above_threshol d > number_of_days_with_wind_speed_above_threshold > > spell_length_of_days_with_air_temperature_below_threshold > spell_length_of_days_with_air_temperature_above_threshold > spell_length_of_days_with_lwe_thickness_of_precipitation_amount_above_th reshold > spell_length_of_days_with_lwe_thickness_of_precipitation_amount_below_th reshold > > d. Peak wave period name. Proposed by Jennifer Brown. > > sea_surface_wave_period_at_variance_spectral_density_maximum; s > > e. Sea water transparency and reflectance names. Proposed by Olivier > Lauret. > > secchi_depth_of_sea_water; m > surface_ratio_of_upwelling_radiance_emerging_from_sea_water_to_downwelli ng_radiative_flux_in_air; sr^-1 > angle_of_incidence; degree > angle_of_emergence; degree > > f. Sea water velocity names. Proposed by Stephane Tarot. > > radial_sea_water_velocity_away_from_instrument; m s-1 > direction_of_radial_vector_away_from_instrument; degree > eastward_sea_water_velocity_assuming_no_tide; m s-1 > northward_sea_water_velocity_assuming_no_tide; m s-1 > > g. Water column name. Proposed by Jeff deLaBeaujardiere. > > sea_floor_depth_below_sea_surface; m > > h. Aerosol optical thickness names. Proposed by Heinke Hoeck. > > atmosphere_absorption_optical_thickness_due_to_ambient_aerosol; 1 > atmosphere_absorption_optical_thickness_due_to_dust_ambient_aerosol; 1 > atmosphere_absorption_optical_thickness_due_to_particulate_organic_matte r_ambient_aerosol; 1 > atmosphere_absorption_optical_thickness_due_to_sulfate_ambient_aerosol; 1 > atmosphere_absorption_optical_thickness_due_to_seasalt_ambient_aerosol; 1 > atmosphere_absorption_optical_thickness_due_to_black_carbon_ambient_aero sol; 1 > > 3. Modification to definition of land_ice names following discussion in > mailing list thread "Standard names for Glaciology and ice-sheet > modeling:land_ice, sea_ice, floating_ice, ice shelves..." > (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2009/002733.html and > following). > > This change affects the following 17 names: > > land_ice_area_fraction > land_ice_basal_melt_rate > land_ice_basal_x_velocity > land_ice_basal_y_velocity > land_ice_calving_rate > land_ice_lwe_basal_melt_rate > land_ice_lwe_calving_rate > land_ice_lwe_surface_specific_mass_balance > land_ice_sigma_coordinate > land_ice_surface_specific_mass_balance > land_ice_temperature > land_ice_thickness > land_ice_vertical_mean_x_velocity > land_ice_vertical_mean_y_velocity > land_ice_x_velocity > land_ice_y_velocity > tendency_of_land_ice_thickness. > > In the definitions, the sentence reading ' "Land ice" means glaciers, > ice-caps and ice-sheets resting on bedrock' will be extended to read ' > "Land ice" means glaciers, ice-caps and ice-sheets resting on bedrock > and also includes ice-shelves.' > > 4. Other changes to the standard name table. > > a. Remove duplicate entry for > sea_surface_height_above_reference_ellipsoid. Reported by Heinke Hoeck > and Phil Bentley. > > 5. Modifications to the Standard Name Guidelines document resulting > from > the acceptance of trac ticket 33. > > The following wording will be added to the 'Transformations' section of > the document. > > A variable whose standard name has the form > number_of_days_with_X_below|above_threshold must have a coordinate > variable or scalar coordinate variable with the a standard name of X to > supply the threshold(s). It must have a climatological time variable, > and a cell_methods entry for within days which describes the processing > of quantity X before the threshold is applied. A number_of_days is an > extensive quantity in time, and the cell_methods entry for over days > should be sum. > > A variable whose standard name has the form > spell_length_of_days_with_X_below|above_threshold must have a > coordinate > variable or scalar coordinate variable with the a standard name of X to > supply the threshold(s). It must have a climatological time variable, > and a cell_method entry for within days which describes the processing > of quantity X before the threshold is applied. A spell_length_of_days > is > an intensive quantity in time, and the cell_methods entry for over days > can be any of the methods listed in Appendix E appropriate for > intensive > quantities e.g. maximum, minimum or mean. > ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email:alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. From caron at unidata.ucar.edu Fri Mar 12 12:21:25 2010 From: caron at unidata.ucar.edu (John Caron) Date: Fri, 12 Mar 2010 12:21:25 -0700 Subject: [CF-metadata] ensemble dimension Message-ID: <4B9A9435.4060100@unidata.ucar.edu> Im not sure if we ever converged on how to write ensemble files. Particularly, how does software recognize the ensemble dimension? I have an example file: netcdf C:/data/CMIP3_Rank_Qensemble_4D.nc { dimensions: model = 2; latitude = 97; longitude = 93; time = 13; variables: float latitude(latitude=97); :units = "degrees_north"; :axis = "Y"; float longitude(longitude=93); :units = "degrees_east"; :axis = "X"; int model(model=2); :ID = "number"; int time(time=13); :units = "days since 1950-01-01 00:00:00"; :axis = "T"; float data(time=13, model=2, latitude=97, longitude=93); :units = "mm/d"; } Perhaps we should add :axis = "Ensemble" to the model coordinate variable? From j.m.gregory at reading.ac.uk Tue Mar 16 11:22:09 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 16 Mar 2010 17:22:09 +0000 Subject: [CF-metadata] ensemble dimension In-Reply-To: <4B9A9435.4060100@unidata.ucar.edu> References: <4B9A9435.4060100@unidata.ucar.edu> Message-ID: <20100316172209.GC13911@met.reading.ac.uk> Dear John > Im not sure if we ever converged on how to write ensemble files. No, we didn't. If I remember correctly, we couldn't agree on the relationship between attributes and coordinates, and that was a sticking-point. I thought that we ought to allow multivalued auxiliary coord variables for ensemble axes, corresponding to attributes that might be used to describe a single model. I would give these standard_names to identify them. Paco started the discussion, and in the end he made his own decisions for what to do for the ENSEMBLES project (because CF had not concluded), so he might comment on it. > Particularly, how does software recognize the ensemble dimension? We didn't agree. But at the end of the discussion, Steve also suggested that it could be identified by an axis attribute, just as you have. I like that idea too. But it could also be given a standard name, like other coordinate variables e.g. ensemble_member_identifier. I suppose the values of this coord var might be either numeric or strings, though it your example it is integer. I haven't looked at the trac ticket to see if we discussed these points before. > Perhaps we should add :axis = "Ensemble" to the model coordinate variable? I'd suggest lower case, like most CF keywords. The other axis attributes are all single letters (X Y Z T) but I don't think it would be a problem to use a word. Best wishes Jonathan From jma at cola.iges.org Tue Mar 16 12:36:03 2010 From: jma at cola.iges.org (Jennifer Adams) Date: Tue, 16 Mar 2010 14:36:03 -0400 Subject: [CF-metadata] ensemble dimension In-Reply-To: <20100316172209.GC13911@met.reading.ac.uk> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> Message-ID: <5F9F329A-C3D4-4C9C-8794-4BCEA381D01C@cola.iges.org> In the absence of a standard, I have also made some choices about how to handle ensemble metadata with GrADS and the GDS. Below is a shortened example of the ncdump output from a GFS ensemble data set behind GDS. I put the metadata that GrADS needs in customized attributes (e.g. grads_name, grads_dim, etc.) I steered clear of using data or coordinate variables of type 'char', because I feel attributes are the better place for this kind of metadata, and GrADS and the GDS have no interface for handing data variables that are not numeric. I have always assumed it would be necessary to add more metadata to make this data set CF compliant, but in the meanwhile, the ensemble axis is a plain old linear dimension. --Jennifer -- Jennifer M. Adams IGES/COLA 4041 Powder Mill Road, Suite 302 Calverton, MD 20705 jma at cola.iges.org # ncdump -c http://monsoondata.org:9090/dods/gfsens/gfsens.2010031612 netcdf gfsens { dimensions: ens = 22 ; lat = 181 ; lev = 7 ; lon = 360 ; time = 31 ; variables: double ens(ens) ; ens:grads_name = "avg ,c00 ,p01 ,p02 ,p03 ,p04,p05,p06,p07,p08,p09,p10,p11,p12,p13,p14,p15,p16,p17,p18,p19,p20" ; ens:grads_length = "31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31" ; ens:grads_tinit = "1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1" ; ens:avg = "unweighted mean of all members" ; ens:c00 = "unperturbed control forecast" ; ens:p01 = "positively perturbed forecast" ; ens:p02 = "positively perturbed forecast" ; ens:p19= "positively perturbed forecast" ; ens:p20 = "positively perturbed forecast" ; ens:grads_dim = "e" ; ens:grads_size = "22" ; ens:grads_mapping = "null" ; ens:units = "count" ; ens:long_name = "ensemble member" ; double time(time) ; time:grads_dim = "t" ; time:grads_mapping = "linear" ; time:grads_size = "31" ; time:grads_min = "12z16mar2010" ; time:grads_step = "6hr" ; time:units = "days since 1-1-1 00:00:0.0" ; time:long_name = "time" ; time:minimum = "12z16mar2010" ; time:maximum = "00z24mar2010" ; time:resolution = 0.25f ; float t(ens, time, lev, lat, lon) ; t:_FillValue = -9.99e+33f ; t:missing_value = -9.99e+33f ; t:long_name = "temperature [k] " ; data: ens = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22 ; time = 733848.5, 733848.75, 733849, 733849.25, 733849.5, 733849.75, 733850, 733850.25, 733850.5, 733850.75, 733851, 733851.25, 733851.5, 733851.75, 733852, 733852.25, 733852.5, 733852.75, 733853, 733853.25, 733853.5, 733853.75, 733854, 733854.25, 733854.5, 733854.75, 733855, 733855.25, 733855.5, 733855.75, 733856 ; } On Mar 16, 2010, at 1:22 PM, Jonathan Gregory wrote: > Dear John > >> Im not sure if we ever converged on how to write ensemble files. > No, we didn't. If I remember correctly, we couldn't agree on the > relationship > between attributes and coordinates, and that was a sticking-point. I > thought > that we ought to allow multivalued auxiliary coord variables for > ensemble > axes, corresponding to attributes that might be used to describe a > single > model. I would give these standard_names to identify them. Paco > started the > discussion, and in the end he made his own decisions for what to do > for the > ENSEMBLES project (because CF had not concluded), so he might > comment on it. > >> Particularly, how does software recognize the ensemble dimension? > We didn't agree. But at the end of the discussion, Steve also > suggested that > it could be identified by an axis attribute, just as you have. I > like that > idea too. But it could also be given a standard name, like other > coordinate > variables e.g. ensemble_member_identifier. I suppose the values of > this > coord var might be either numeric or strings, though it your example > it is > integer. I haven't looked at the trac ticket to see if we discussed > these > points before. > >> Perhaps we should add :axis = "Ensemble" to the model coordinate >> variable? > I'd suggest lower case, like most CF keywords. The other axis > attributes are > all single letters (X Y Z T) but I don't think it would be a problem > to use > a word. > > 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: From tomas.kral at ecmwf.int Tue Mar 16 13:21:50 2010 From: tomas.kral at ecmwf.int (Tomas Kral) Date: Tue, 16 Mar 2010 19:21:50 +0000 Subject: [CF-metadata] new standard names for momentum fluxes Message-ID: <4B9FDA4E.9040109@ecmwf.int> Dear all, I'd like to propose two variable names to be included in the CF standard name table for u and v components of momentum fluxes due to vertical diffusion (rho*u'w' and rho*v'w'). These two variables are part of diagnostic output of IFS model at ECMWF and they are required for the CEOP Phase II project. I checked the CF list and found the following two possible naming alternatives: 1) downward_eastward_momentum_flux_in_air_due_to_diffusion [Pa] downward_northward_momentum_flux_in_air_due_to_diffusion [Pa] 2) atmosphere_eastward_stress_due_to_diffusion [Pa] atmosphere_northward_stress_due_to_diffusion [Pa] Please let me know your comments. Kind regards, Tomas From V.Balaji at noaa.gov Tue Mar 16 13:31:27 2010 From: V.Balaji at noaa.gov (V. Balaji) Date: Tue, 16 Mar 2010 15:31:27 -0400 (EDT) Subject: [CF-metadata] ensemble dimension In-Reply-To: <20100316172209.GC13911@met.reading.ac.uk> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> Message-ID: Jonathan Gregory writes: > Dear John > >> Im not sure if we ever converged on how to write ensemble files. > No, we didn't. If I remember correctly, we couldn't agree on the relationship > between attributes and coordinates, and that was a sticking-point. I thought > that we ought to allow multivalued auxiliary coord variables for ensemble > axes, corresponding to attributes that might be used to describe a single > model. I would give these standard_names to identify them. Paco started the > discussion, and in the end he made his own decisions for what to do for the > ENSEMBLES project (because CF had not concluded), so he might comment on it. http://ensembles.ecmwf.int/thredds/ensembles/stream2/seasonal/atmospheric/catalog.html has examples of how Paco has it set up. (esp see the "mother of all aggregations" :-). It requires the ensemble to share the same space and time discretization. > >> Particularly, how does software recognize the ensemble dimension? > We didn't agree. But at the end of the discussion, Steve also suggested that > it could be identified by an axis attribute, just as you have. I like that > idea too. But it could also be given a standard name, like other coordinate > variables e.g. ensemble_member_identifier. I suppose the values of this > coord var might be either numeric or strings, though it your example it is > integer. I haven't looked at the trac ticket to see if we discussed these > points before. > >> Perhaps we should add :axis = "Ensemble" to the model coordinate variable? > I'd suggest lower case, like most CF keywords. The other axis attributes are > all single letters (X Y Z T) but I don't think it would be a problem to use > a word. > > Best wishes > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -- 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 From schuster at ucar.edu Tue Mar 16 13:46:42 2010 From: schuster at ucar.edu (Doug Schuster) Date: Tue, 16 Mar 2010 13:46:42 -0600 Subject: [CF-metadata] ensemble dimension In-Reply-To: References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> Message-ID: NCAR uses a modified version of Paco's file structure for TIGGE output. All ensemble members found in the file require the same "single" model initialization time, the same forecast timesteps, and identical grids types. A sample file can be found at: http://dss.ucar.edu/download/tigge/ncep_20100223000000_tp_lev_255_id_528.1.5deg.nc Here's a snippet from the file header metadata -Doug: dimensions: longitude = 240 ; latitude = 121 ; string4 = 4 ; string2 = 2 ; time = 4 ; realization = 21 ; variables: float longitude(longitude) ; longitude:data_type = "float" ; longitude:units = "degrees_east" ; longitude:axis = "X" ; longitude:standard_name = "longitude" ; longitude:valid_min = 0.f ; longitude:valid_max = 358.5f ; float latitude(latitude) ; latitude:data_type = "float" ; latitude:units = "degrees_north" ; latitude:axis = "Y" ; latitude:standard_name = "latitude" ; latitude:valid_min = -90.f ; latitude:valid_max = 90.f ; int time(time) ; time:data_type = "int" ; time:units = "hours since 1950-01-01 00:00:00" ; time:standard_name = "time" ; time:long_name = "Forecast Valid Time" ; int realization(realization) ; realization:data_type = "int" ; realization:units = "1" ; realization:standard_name = "realization" ; realization:long_name = "Number of the simulation in the ensemble" ; char forecast_type(realization, string2) ; forecast_type:data_type = "char" ; forecast_type:long_name = "Forecast type" ; char institution(realization, string4) ; institution:data_type = "char" ; institution:standard_name = "institution" ; institution:long_name = "Institution responsible for the forecast system" ; char source(realization, string4) ; source:data_type = "char" ; source:standard_name = "source" ; source:long_name = "Method of production of the data" ; char experiment_id(realization, string4) ; experiment_id:data_type = "char" ; experiment_id:standard_name = "experiment_id" ; experiment_id:long_name = "Experiment identifier" ; int perturbation_method(realization) ; perturbation_method:data_type = "int" ; perturbation_method:long_name = "Perturbation method, GRIB-2 Code table 4.6" ; float tp(time, realization, latitude, longitude) ; tp:data_type = "float" ; tp:units = "kg m-2 s-1" ; tp:standard_name = "precipitation_amount" ; tp:level_name = "Ground or water surface " ; tp:level_units = "unknown" ; tp:level_value = 0.f ; tp:coordinates = "institution forecast_type source experiment_id perturbation_method" ; tp:_FillValue = 9.96921e+36f ; // global attributes: :Model_Initialization_Date_and_Time_UTC = "2010-2-23 0 UTC" ; :Conventions = "CF-1.0" ; :Institution = "NCAR" ; :Generator = "grib2_to_netcdf" ; :Created = "Wed Mar 03 04:37:58 2010" ; :Title = "TIGGE" ; :References = "For TIGGE, check http://tigge.ucar.edu" ; On Mar 16, 2010, at 1:31 PM, V. Balaji wrote: > Jonathan Gregory writes: > >> Dear John >> >>> Im not sure if we ever converged on how to write ensemble files. >> No, we didn't. If I remember correctly, we couldn't agree on the >> relationship >> between attributes and coordinates, and that was a sticking-point. >> I thought >> that we ought to allow multivalued auxiliary coord variables for >> ensemble >> axes, corresponding to attributes that might be used to describe a >> single >> model. I would give these standard_names to identify them. Paco >> started the >> discussion, and in the end he made his own decisions for what to do >> for the >> ENSEMBLES project (because CF had not concluded), so he might >> comment on it. > > http://ensembles.ecmwf.int/thredds/ensembles/stream2/seasonal/atmospheric/catalog.html > > has examples of how Paco has it set up. > (esp see the "mother of all aggregations" :-). > > It requires the ensemble to share the same space and time > discretization. > >> >>> Particularly, how does software recognize the ensemble dimension? >> We didn't agree. But at the end of the discussion, Steve also >> suggested that >> it could be identified by an axis attribute, just as you have. I >> like that >> idea too. But it could also be given a standard name, like other >> coordinate >> variables e.g. ensemble_member_identifier. I suppose the values of >> this >> coord var might be either numeric or strings, though it your >> example it is >> integer. I haven't looked at the trac ticket to see if we discussed >> these >> points before. >> >>> Perhaps we should add :axis = "Ensemble" to the model coordinate >>> variable? >> I'd suggest lower case, like most CF keywords. The other axis >> attributes are >> all single letters (X Y Z T) but I don't think it would be a >> problem to use >> a word. >> >> Best wishes >> >> Jonathan >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> > > -- > > 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 > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From caron at unidata.ucar.edu Tue Mar 16 15:30:26 2010 From: caron at unidata.ucar.edu (John Caron) Date: Tue, 16 Mar 2010 15:30:26 -0600 Subject: [CF-metadata] ensemble dimension In-Reply-To: <5F9F329A-C3D4-4C9C-8794-4BCEA381D01C@cola.iges.org> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> <5F9F329A-C3D4-4C9C-8794-4BCEA381D01C@cola.iges.org> Message-ID: <4B9FF872.3060106@unidata.ucar.edu> Hi Jennifer, in this instance, how do you know its an ensemble dimension, as opposed to say, a wavelength ? is it ens:long_name = "ensemble member" ?? On 3/16/2010 12:36 PM, Jennifer Adams wrote: > In the absence of a standard, I have also made some choices about how > to handle ensemble metadata with GrADS and the GDS. Below is a > shortened example of the ncdump output from a GFS ensemble data set > behind GDS. I put the metadata that GrADS needs in customized > attributes (e.g. grads_name, grads_dim, etc.) I steered clear of using > data or coordinate variables of type 'char', because I feel attributes > are the better place for this kind of metadata, and GrADS and the GDS > have no interface for handing data variables that are not numeric. I > have always assumed it would be necessary to add more metadata to make > this data set CF compliant, but in the meanwhile, the ensemble axis is > a plain old linear dimension. --Jennifer > -- > Jennifer M. Adams > IGES/COLA > 4041 Powder Mill Road, Suite 302 > Calverton, MD 20705 > jma at cola.iges.org > > > > # ncdump -c http://monsoondata.org:9090/dods/gfsens/gfsens.2010031612 > netcdf gfsens { > dimensions: > ens = 22 ; > lat = 181 ; > lev = 7 ; > lon = 360 ; > time = 31 ; > variables: > double ens(ens) ; > ens:grads_name = > "avg,c00,p01,p02,p03,p04,p05,p06,p07,p08,p09,p10,p11,p12,p13,p14,p15,p16,p17,p18,p19,p20" > ; > ens:grads_length = > "31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31" ; > ens:grads_tinit = > "1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1" ; > ens:avg = "unweighted mean of all members" ; > ens:c00 = "unperturbed control forecast" ; > ens:p01 = "positively perturbed forecast" ; > ens:p02 = "positively perturbed forecast" ; > > ens:p19= "positively perturbed forecast" ; > ens:p20 = "positively perturbed forecast" ; > ens:grads_dim = "e" ; > ens:grads_size = "22" ; > ens:grads_mapping = "null" ; > ens:units = "count" ; > ens:long_name = "ensemble member" ; > double time(time) ; > time:grads_dim = "t" ; > time:grads_mapping = "linear" ; > time:grads_size = "31" ; > time:grads_min = "12z16mar2010" ; > time:grads_step = "6hr" ; > time:units = "days since 1-1-1 00:00:0.0" ; > time:long_name = "time" ; > time:minimum = "12z16mar2010" ; > time:maximum = "00z24mar2010" ; > time:resolution = 0.25f ; > > float t(ens, time, lev, lat, lon) ; > t:_FillValue = -9.99e+33f ; > t:missing_value = -9.99e+33f ; > t:long_name = "temperature [k] " ; > > > data: > > ens = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, > 19, 20, > 21, 22 ; > > time = 733848.5, 733848.75, 733849, 733849.25, 733849.5, 733849.75, > 733850, > 733850.25, 733850.5, 733850.75, 733851, 733851.25, 733851.5, > 733851.75, > 733852, 733852.25, 733852.5, 733852.75, 733853, 733853.25, 733853.5, > 733853.75, 733854, 733854.25, 733854.5, 733854.75, 733855, 733855.25, > 733855.5, 733855.75, 733856 ; > > } > > > > On Mar 16, 2010, at 1:22 PM, Jonathan Gregory wrote: > >> Dear John >> >>> Im not sure if we ever converged on how to write ensemble files. >> No, we didn't. If I remember correctly, we couldn't agree on the >> relationship >> between attributes and coordinates, and that was a sticking-point. I >> thought >> that we ought to allow multivalued auxiliary coord variables for ensemble >> axes, corresponding to attributes that might be used to describe a single >> model. I would give these standard_names to identify them. Paco >> started the >> discussion, and in the end he made his own decisions for what to do >> for the >> ENSEMBLES project (because CF had not concluded), so he might comment >> on it. >> >>> Particularly, how does software recognize the ensemble dimension? >> We didn't agree. But at the end of the discussion, Steve also >> suggested that >> it could be identified by an axis attribute, just as you have. I like >> that >> idea too. But it could also be given a standard name, like other >> coordinate >> variables e.g. ensemble_member_identifier. I suppose the values of this >> coord var might be either numeric or strings, though it your example >> it is >> integer. I haven't looked at the trac ticket to see if we discussed these >> points before. >> >>> Perhaps we should add :axis = "Ensemble" to the model coordinate >>> variable? >> I'd suggest lower case, like most CF keywords. The other axis >> attributes are >> all single letters (X Y Z T) but I don't think it would be a problem >> to use >> a word. >> >> Best wishes >> >> Jonathan >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > > _______________________________________________ > 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: From caron at unidata.ucar.edu Tue Mar 16 15:38:59 2010 From: caron at unidata.ucar.edu (John Caron) Date: Tue, 16 Mar 2010 15:38:59 -0600 Subject: [CF-metadata] ensemble dimension In-Reply-To: References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> Message-ID: <4B9FFA73.7060102@unidata.ucar.edu> On 3/16/2010 1:31 PM, V. Balaji wrote: > Jonathan Gregory writes: > >> Dear John >> >>> Im not sure if we ever converged on how to write ensemble files. >> No, we didn't. If I remember correctly, we couldn't agree on the >> relationship >> between attributes and coordinates, and that was a sticking-point. I >> thought >> that we ought to allow multivalued auxiliary coord variables for >> ensemble >> axes, corresponding to attributes that might be used to describe a >> single >> model. I would give these standard_names to identify them. Paco >> started the >> discussion, and in the end he made his own decisions for what to do >> for the >> ENSEMBLES project (because CF had not concluded), so he might comment >> on it. > > http://ensembles.ecmwf.int/thredds/ensembles/stream2/seasonal/atmospheric/catalog.html > > > has examples of how Paco has it set up. > (esp see the "mother of all aggregations" :-). > > It requires the ensemble to share the same space and time > discretization. in this case, it appears that perhaps :standard_name = "realization"; would be used to figure out the ensemble coordinate (??) a number of aux coordinates are used to describe the members, as pointed to by the coordinates attribute on the data variables: float g(time=1610, ensemble=54, level=5, latitude=73, longitude=144); :coordinates = "reftime leadtime experiment_id source realization institution time_bnd"; int realization(ensemble=54); :standard_name = "realization"; :long_name = "Number of the simulation in the ensemble"; char experiment_id(ensemble=54, string4=4); :standard_name = "experiment_id"; :long_name = "Experiment identifier"; char source(ensemble=54, string60=60); :standard_name = "source"; :long_name = "Method of production of the data"; char institution(ensemble=54, string15=15); :standard_name = "institution"; :long_name = "Institution responsible for the forecast system"; From caron at unidata.ucar.edu Tue Mar 16 15:43:00 2010 From: caron at unidata.ucar.edu (John Caron) Date: Tue, 16 Mar 2010 15:43:00 -0600 Subject: [CF-metadata] ensemble dimension In-Reply-To: References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> Message-ID: <4B9FFB64.2060301@unidata.ucar.edu> Hi Doug: Looks to be the same as Paco's. Do you know what was modified? On 3/16/2010 1:46 PM, Doug Schuster wrote: > NCAR uses a modified version of Paco's file structure for TIGGE output. > All ensemble members found in the file require the same "single" model > initialization time, the same forecast timesteps, and > identical grids types. > > A sample file can be found at: > > http://dss.ucar.edu/download/tigge/ncep_20100223000000_tp_lev_255_id_528.1.5deg.nc > > > Here's a snippet from the file header metadata -Doug: > > dimensions: > longitude = 240 ; > latitude = 121 ; > string4 = 4 ; > string2 = 2 ; > time = 4 ; > realization = 21 ; > variables: > float longitude(longitude) ; > longitude:data_type = "float" ; > longitude:units = "degrees_east" ; > longitude:axis = "X" ; > longitude:standard_name = "longitude" ; > longitude:valid_min = 0.f ; > longitude:valid_max = 358.5f ; > float latitude(latitude) ; > latitude:data_type = "float" ; > latitude:units = "degrees_north" ; > latitude:axis = "Y" ; > latitude:standard_name = "latitude" ; > latitude:valid_min = -90.f ; > latitude:valid_max = 90.f ; > int time(time) ; > time:data_type = "int" ; > time:units = "hours since 1950-01-01 00:00:00" ; > time:standard_name = "time" ; > time:long_name = "Forecast Valid Time" ; > int realization(realization) ; > realization:data_type = "int" ; > realization:units = "1" ; > realization:standard_name = "realization" ; > realization:long_name = "Number of the simulation in the > ensemble" ; > char forecast_type(realization, string2) ; > forecast_type:data_type = "char" ; > forecast_type:long_name = "Forecast type" ; > char institution(realization, string4) ; > institution:data_type = "char" ; > institution:standard_name = "institution" ; > institution:long_name = "Institution responsible for the > forecast system" ; > char source(realization, string4) ; > source:data_type = "char" ; > source:standard_name = "source" ; > source:long_name = "Method of production of the data" ; > char experiment_id(realization, string4) ; > experiment_id:data_type = "char" ; > experiment_id:standard_name = "experiment_id" ; > experiment_id:long_name = "Experiment identifier" ; > int perturbation_method(realization) ; > perturbation_method:data_type = "int" ; > perturbation_method:long_name = "Perturbation method, GRIB-2 > Code table 4.6" ; > float tp(time, realization, latitude, longitude) ; > tp:data_type = "float" ; > tp:units = "kg m-2 s-1" ; > tp:standard_name = "precipitation_amount" ; > tp:level_name = "Ground or water surface " ; > tp:level_units = "unknown" ; > tp:level_value = 0.f ; > tp:coordinates = "institution forecast_type source > experiment_id perturbation_method" ; > tp:_FillValue = 9.96921e+36f ; > > // global attributes: > :Model_Initialization_Date_and_Time_UTC = "2010-2-23 0 UTC" ; > :Conventions = "CF-1.0" ; > :Institution = "NCAR" ; > :Generator = "grib2_to_netcdf" ; > :Created = "Wed Mar 03 04:37:58 2010" ; > :Title = "TIGGE" ; > :References = "For TIGGE, check http://tigge.ucar.edu" ; > > On Mar 16, 2010, at 1:31 PM, V. Balaji wrote: > >> Jonathan Gregory writes: >> >>> Dear John >>> >>>> Im not sure if we ever converged on how to write ensemble files. >>> No, we didn't. If I remember correctly, we couldn't agree on the >>> relationship >>> between attributes and coordinates, and that was a sticking-point. I >>> thought >>> that we ought to allow multivalued auxiliary coord variables for >>> ensemble >>> axes, corresponding to attributes that might be used to describe a >>> single >>> model. I would give these standard_names to identify them. Paco >>> started the >>> discussion, and in the end he made his own decisions for what to do >>> for the >>> ENSEMBLES project (because CF had not concluded), so he might >>> comment on it. >> >> http://ensembles.ecmwf.int/thredds/ensembles/stream2/seasonal/atmospheric/catalog.html >> >> >> has examples of how Paco has it set up. >> (esp see the "mother of all aggregations" :-). >> >> It requires the ensemble to share the same space and time >> discretization. >> >>> >>>> Particularly, how does software recognize the ensemble dimension? >>> We didn't agree. But at the end of the discussion, Steve also >>> suggested that >>> it could be identified by an axis attribute, just as you have. I >>> like that >>> idea too. But it could also be given a standard name, like other >>> coordinate >>> variables e.g. ensemble_member_identifier. I suppose the values of this >>> coord var might be either numeric or strings, though it your example >>> it is >>> integer. I haven't looked at the trac ticket to see if we discussed >>> these >>> points before. >>> >>>> Perhaps we should add :axis = "Ensemble" to the model coordinate >>>> variable? >>> I'd suggest lower case, like most CF keywords. The other axis >>> attributes are >>> all single letters (X Y Z T) but I don't think it would be a problem >>> to use >>> a word. >>> >>> Best wishes >>> >>> Jonathan >>> _______________________________________________ >>> CF-metadata mailing list >>> CF-metadata at cgd.ucar.edu >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>> >> >> -- >> >> 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 >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From caron at unidata.ucar.edu Tue Mar 16 15:44:20 2010 From: caron at unidata.ucar.edu (John Caron) Date: Tue, 16 Mar 2010 15:44:20 -0600 Subject: [CF-metadata] ensemble dimension In-Reply-To: <20100316172209.GC13911@met.reading.ac.uk> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> Message-ID: <4B9FFBB4.1060003@unidata.ucar.edu> On 3/16/2010 11:22 AM, Jonathan Gregory wrote: > Dear John > > >> Im not sure if we ever converged on how to write ensemble files. >> > No, we didn't. If I remember correctly, we couldn't agree on the relationship > between attributes and coordinates, and that was a sticking-point. I thought > that we ought to allow multivalued auxiliary coord variables for ensemble > axes, corresponding to attributes that might be used to describe a single > model. I would give these standard_names to identify them. Paco started the > discussion, and in the end he made his own decisions for what to do for the > ENSEMBLES project (because CF had not concluded), so he might comment on it. > > >> Particularly, how does software recognize the ensemble dimension? >> > We didn't agree. But at the end of the discussion, Steve also suggested that > it could be identified by an axis attribute, just as you have. I like that > idea too. But it could also be given a standard name, like other coordinate > variables e.g. ensemble_member_identifier. I suppose the values of this > coord var might be either numeric or strings, though it your example it is > integer. I haven't looked at the trac ticket to see if we discussed these > points before. > > >> Perhaps we should add :axis = "Ensemble" to the model coordinate variable? >> > I'd suggest lower case, like most CF keywords. The other axis attributes are > all single letters (X Y Z T) but I don't think it would be a problem to use > a word. > > Best wishes > > Jonathan > Im good with either/both axis = "ensemble" and/or standard_name = "ensemble_member_identifier". for backwards compatibility, we could consider recognizing standard_name = "realization". From schuster at ucar.edu Tue Mar 16 17:16:26 2010 From: schuster at ucar.edu (Doug Schuster) Date: Tue, 16 Mar 2010 17:16:26 -0600 Subject: [CF-metadata] ensemble dimension In-Reply-To: <4B9FFB64.2060301@unidata.ucar.edu> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> <4B9FFB64.2060301@unidata.ucar.edu> Message-ID: <78CC1C02-04F5-414E-A453-9C06168E83D4@ucar.edu> John, I think the standard names and basic template are all the same. The only difference is that the structure we're using for TIGGE has 4 variable dimensions vs 5, where the 5th allows for multiple forecast initialization times. On Mar 16, 2010, at 3:43 PM, John Caron wrote: > Hi Doug: > > Looks to be the same as Paco's. Do you know what was modified? > > On 3/16/2010 1:46 PM, Doug Schuster wrote: >> NCAR uses a modified version of Paco's file structure for TIGGE >> output. >> All ensemble members found in the file require the same "single" >> model initialization time, the same forecast timesteps, and >> identical grids types. >> >> A sample file can be found at: >> >> http://dss.ucar.edu/download/tigge/ncep_20100223000000_tp_lev_255_id_528.1.5deg.nc >> >> Here's a snippet from the file header metadata -Doug: >> >> dimensions: >> longitude = 240 ; >> latitude = 121 ; >> string4 = 4 ; >> string2 = 2 ; >> time = 4 ; >> realization = 21 ; >> variables: >> float longitude(longitude) ; >> longitude:data_type = "float" ; >> longitude:units = "degrees_east" ; >> longitude:axis = "X" ; >> longitude:standard_name = "longitude" ; >> longitude:valid_min = 0.f ; >> longitude:valid_max = 358.5f ; >> float latitude(latitude) ; >> latitude:data_type = "float" ; >> latitude:units = "degrees_north" ; >> latitude:axis = "Y" ; >> latitude:standard_name = "latitude" ; >> latitude:valid_min = -90.f ; >> latitude:valid_max = 90.f ; >> int time(time) ; >> time:data_type = "int" ; >> time:units = "hours since 1950-01-01 00:00:00" ; >> time:standard_name = "time" ; >> time:long_name = "Forecast Valid Time" ; >> int realization(realization) ; >> realization:data_type = "int" ; >> realization:units = "1" ; >> realization:standard_name = "realization" ; >> realization:long_name = "Number of the simulation in the >> ensemble" ; >> char forecast_type(realization, string2) ; >> forecast_type:data_type = "char" ; >> forecast_type:long_name = "Forecast type" ; >> char institution(realization, string4) ; >> institution:data_type = "char" ; >> institution:standard_name = "institution" ; >> institution:long_name = "Institution responsible for the >> forecast system" ; >> char source(realization, string4) ; >> source:data_type = "char" ; >> source:standard_name = "source" ; >> source:long_name = "Method of production of the data" ; >> char experiment_id(realization, string4) ; >> experiment_id:data_type = "char" ; >> experiment_id:standard_name = "experiment_id" ; >> experiment_id:long_name = "Experiment identifier" ; >> int perturbation_method(realization) ; >> perturbation_method:data_type = "int" ; >> perturbation_method:long_name = "Perturbation method, GRIB-2 >> Code table 4.6" ; >> float tp(time, realization, latitude, longitude) ; >> tp:data_type = "float" ; >> tp:units = "kg m-2 s-1" ; >> tp:standard_name = "precipitation_amount" ; >> tp:level_name = "Ground or water surface " ; >> tp:level_units = "unknown" ; >> tp:level_value = 0.f ; >> tp:coordinates = "institution forecast_type source >> experiment_id perturbation_method" ; >> tp:_FillValue = 9.96921e+36f ; >> >> // global attributes: >> :Model_Initialization_Date_and_Time_UTC = "2010-2-23 0 UTC" ; >> :Conventions = "CF-1.0" ; >> :Institution = "NCAR" ; >> :Generator = "grib2_to_netcdf" ; >> :Created = "Wed Mar 03 04:37:58 2010" ; >> :Title = "TIGGE" ; >> :References = "For TIGGE, check http://tigge.ucar.edu" ; >> >> On Mar 16, 2010, at 1:31 PM, V. Balaji wrote: >> >>> Jonathan Gregory writes: >>> >>>> Dear John >>>> >>>>> Im not sure if we ever converged on how to write ensemble files. >>>> No, we didn't. If I remember correctly, we couldn't agree on the >>>> relationship >>>> between attributes and coordinates, and that was a sticking- >>>> point. I thought >>>> that we ought to allow multivalued auxiliary coord variables for >>>> ensemble >>>> axes, corresponding to attributes that might be used to describe >>>> a single >>>> model. I would give these standard_names to identify them. Paco >>>> started the >>>> discussion, and in the end he made his own decisions for what to >>>> do for the >>>> ENSEMBLES project (because CF had not concluded), so he might >>>> comment on it. >>> >>> http://ensembles.ecmwf.int/thredds/ensembles/stream2/seasonal/atmospheric/catalog.html >>> >>> has examples of how Paco has it set up. >>> (esp see the "mother of all aggregations" :-). >>> >>> It requires the ensemble to share the same space and time >>> discretization. >>> >>>> >>>>> Particularly, how does software recognize the ensemble dimension? >>>> We didn't agree. But at the end of the discussion, Steve also >>>> suggested that >>>> it could be identified by an axis attribute, just as you have. I >>>> like that >>>> idea too. But it could also be given a standard name, like other >>>> coordinate >>>> variables e.g. ensemble_member_identifier. I suppose the values >>>> of this >>>> coord var might be either numeric or strings, though it your >>>> example it is >>>> integer. I haven't looked at the trac ticket to see if we >>>> discussed these >>>> points before. >>>> >>>>> Perhaps we should add :axis = "Ensemble" to the model coordinate >>>>> variable? >>>> I'd suggest lower case, like most CF keywords. The other axis >>>> attributes are >>>> all single letters (X Y Z T) but I don't think it would be a >>>> problem to use >>>> a word. >>>> >>>> Best wishes >>>> >>>> Jonathan >>>> _______________________________________________ >>>> CF-metadata mailing list >>>> CF-metadata at cgd.ucar.edu >>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>>> >>> >>> -- >>> >>> 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 >>> _______________________________________________ >>> CF-metadata mailing list >>> CF-metadata at cgd.ucar.edu >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From schuster at ucar.edu Tue Mar 16 17:19:22 2010 From: schuster at ucar.edu (Doug Schuster) Date: Tue, 16 Mar 2010 17:19:22 -0600 Subject: [CF-metadata] ensemble dimension In-Reply-To: <78CC1C02-04F5-414E-A453-9C06168E83D4@ucar.edu> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> <4B9FFB64.2060301@unidata.ucar.edu> <78CC1C02-04F5-414E-A453-9C06168E83D4@ucar.edu> Message-ID: <67274D28-F662-408C-BB4D-BA4BC518F4D0@ucar.edu> Where the 5th dimension allows for multiple levels I meant to say. The files NCAR produces for TIGGE are all on one fixed level, with one fixed forecast initialization time. Doug On Mar 16, 2010, at 5:16 PM, Doug Schuster wrote: > John, > > I think the standard names and basic template are all the same. The > only difference is that > the structure we're using for TIGGE has 4 variable dimensions vs 5, > where the 5th allows for multiple forecast initialization times. > > On Mar 16, 2010, at 3:43 PM, John Caron wrote: > >> Hi Doug: >> >> Looks to be the same as Paco's. Do you know what was modified? >> >> On 3/16/2010 1:46 PM, Doug Schuster wrote: >>> NCAR uses a modified version of Paco's file structure for TIGGE >>> output. >>> All ensemble members found in the file require the same "single" >>> model initialization time, the same forecast timesteps, and >>> identical grids types. >>> >>> A sample file can be found at: >>> >>> http://dss.ucar.edu/download/tigge/ncep_20100223000000_tp_lev_255_id_528.1.5deg.nc >>> >>> Here's a snippet from the file header metadata -Doug: >>> >>> dimensions: >>> longitude = 240 ; >>> latitude = 121 ; >>> string4 = 4 ; >>> string2 = 2 ; >>> time = 4 ; >>> realization = 21 ; >>> variables: >>> float longitude(longitude) ; >>> longitude:data_type = "float" ; >>> longitude:units = "degrees_east" ; >>> longitude:axis = "X" ; >>> longitude:standard_name = "longitude" ; >>> longitude:valid_min = 0.f ; >>> longitude:valid_max = 358.5f ; >>> float latitude(latitude) ; >>> latitude:data_type = "float" ; >>> latitude:units = "degrees_north" ; >>> latitude:axis = "Y" ; >>> latitude:standard_name = "latitude" ; >>> latitude:valid_min = -90.f ; >>> latitude:valid_max = 90.f ; >>> int time(time) ; >>> time:data_type = "int" ; >>> time:units = "hours since 1950-01-01 00:00:00" ; >>> time:standard_name = "time" ; >>> time:long_name = "Forecast Valid Time" ; >>> int realization(realization) ; >>> realization:data_type = "int" ; >>> realization:units = "1" ; >>> realization:standard_name = "realization" ; >>> realization:long_name = "Number of the simulation in the >>> ensemble" ; >>> char forecast_type(realization, string2) ; >>> forecast_type:data_type = "char" ; >>> forecast_type:long_name = "Forecast type" ; >>> char institution(realization, string4) ; >>> institution:data_type = "char" ; >>> institution:standard_name = "institution" ; >>> institution:long_name = "Institution responsible for the >>> forecast system" ; >>> char source(realization, string4) ; >>> source:data_type = "char" ; >>> source:standard_name = "source" ; >>> source:long_name = "Method of production of the data" ; >>> char experiment_id(realization, string4) ; >>> experiment_id:data_type = "char" ; >>> experiment_id:standard_name = "experiment_id" ; >>> experiment_id:long_name = "Experiment identifier" ; >>> int perturbation_method(realization) ; >>> perturbation_method:data_type = "int" ; >>> perturbation_method:long_name = "Perturbation method, GRIB-2 >>> Code table 4.6" ; >>> float tp(time, realization, latitude, longitude) ; >>> tp:data_type = "float" ; >>> tp:units = "kg m-2 s-1" ; >>> tp:standard_name = "precipitation_amount" ; >>> tp:level_name = "Ground or water surface " ; >>> tp:level_units = "unknown" ; >>> tp:level_value = 0.f ; >>> tp:coordinates = "institution forecast_type source >>> experiment_id perturbation_method" ; >>> tp:_FillValue = 9.96921e+36f ; >>> >>> // global attributes: >>> :Model_Initialization_Date_and_Time_UTC = "2010-2-23 0 UTC" ; >>> :Conventions = "CF-1.0" ; >>> :Institution = "NCAR" ; >>> :Generator = "grib2_to_netcdf" ; >>> :Created = "Wed Mar 03 04:37:58 2010" ; >>> :Title = "TIGGE" ; >>> :References = "For TIGGE, check http://tigge.ucar.edu" ; >>> >>> On Mar 16, 2010, at 1:31 PM, V. Balaji wrote: >>> >>>> Jonathan Gregory writes: >>>> >>>>> Dear John >>>>> >>>>>> Im not sure if we ever converged on how to write ensemble files. >>>>> No, we didn't. If I remember correctly, we couldn't agree on the >>>>> relationship >>>>> between attributes and coordinates, and that was a sticking- >>>>> point. I thought >>>>> that we ought to allow multivalued auxiliary coord variables for >>>>> ensemble >>>>> axes, corresponding to attributes that might be used to describe >>>>> a single >>>>> model. I would give these standard_names to identify them. Paco >>>>> started the >>>>> discussion, and in the end he made his own decisions for what to >>>>> do for the >>>>> ENSEMBLES project (because CF had not concluded), so he might >>>>> comment on it. >>>> >>>> http://ensembles.ecmwf.int/thredds/ensembles/stream2/seasonal/atmospheric/catalog.html >>>> >>>> has examples of how Paco has it set up. >>>> (esp see the "mother of all aggregations" :-). >>>> >>>> It requires the ensemble to share the same space and time >>>> discretization. >>>> >>>>> >>>>>> Particularly, how does software recognize the ensemble dimension? >>>>> We didn't agree. But at the end of the discussion, Steve also >>>>> suggested that >>>>> it could be identified by an axis attribute, just as you have. I >>>>> like that >>>>> idea too. But it could also be given a standard name, like other >>>>> coordinate >>>>> variables e.g. ensemble_member_identifier. I suppose the values >>>>> of this >>>>> coord var might be either numeric or strings, though it your >>>>> example it is >>>>> integer. I haven't looked at the trac ticket to see if we >>>>> discussed these >>>>> points before. >>>>> >>>>>> Perhaps we should add :axis = "Ensemble" to the model >>>>>> coordinate variable? >>>>> I'd suggest lower case, like most CF keywords. The other axis >>>>> attributes are >>>>> all single letters (X Y Z T) but I don't think it would be a >>>>> problem to use >>>>> a word. >>>>> >>>>> Best wishes >>>>> >>>>> Jonathan >>>>> _______________________________________________ >>>>> CF-metadata mailing list >>>>> CF-metadata at cgd.ucar.edu >>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>>>> >>>> >>>> -- >>>> >>>> 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 >>>> _______________________________________________ >>>> CF-metadata mailing list >>>> CF-metadata at cgd.ucar.edu >>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From jma at cola.iges.org Tue Mar 16 18:27:11 2010 From: jma at cola.iges.org (Jennifer Adams) Date: Tue, 16 Mar 2010 20:27:11 -0400 Subject: [CF-metadata] ensemble dimension In-Reply-To: <4B9FF872.3060106@unidata.ucar.edu> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> <5F9F329A-C3D4-4C9C-8794-4BCEA381D01C@cola.iges.org> <4B9FF872.3060106@unidata.ucar.edu> Message-ID: <8DF940CB-551E-4460-A763-C75E37A3201A@cola.iges.org> On Mar 16, 2010, at 5:30 PM, John Caron wrote: > Hi Jennifer, in this instance, how do you know its an ensemble > dimension, as opposed to say, a wavelength ? is it > > ens:long_name = "ensemble member" > Grads knows it's an ensemble by the attribute: ens:grads_dim = "e" ; I could just as easily look for the axis="E" attribute, since I also look at the axis attribute to find X, Y, Z, or T. If the E dimension were used for wavelength, then it would have a different long name but the same grads_dim='e' attribute. --Jennifer > ?? > > On 3/16/2010 12:36 PM, Jennifer Adams wrote: >> >> In the absence of a standard, I have also made some choices about >> how to handle ensemble metadata with GrADS and the GDS. Below is a >> shortened example of the ncdump output from a GFS ensemble data set >> behind GDS. I put the metadata that GrADS needs in customized >> attributes (e.g. grads_name, grads_dim, etc.) I steered clear of >> using data or coordinate variables of type 'char', because I feel >> attributes are the better place for this kind of metadata, and >> GrADS and the GDS have no interface for handing data variables that >> are not numeric. I have always assumed it would be necessary to add >> more metadata to make this data set CF compliant, but in the >> meanwhile, the ensemble axis is a plain old linear dimension. -- >> Jennifer >> -- >> Jennifer M. Adams >> IGES/COLA >> 4041 Powder Mill Road, Suite 302 >> Calverton, MD 20705 >> jma at cola.iges.org >> >> >> >> # ncdump -c http://monsoondata.org:9090/dods/gfsens/gfsens.2010031612 >> netcdf gfsens { >> dimensions: >> ens = 22 ; >> lat = 181 ; >> lev = 7 ; >> lon = 360 ; >> time = 31 ; >> variables: >> double ens(ens) ; >> ens:grads_name = >> "avg >> ,c00 >> ,p01 >> ,p02 >> ,p03 >> ,p04 >> ,p05,p06,p07,p08,p09,p10,p11,p12,p13,p14,p15,p16,p17,p18,p19,p20" ; >> ens:grads_length = >> "31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31,31" ; >> ens:grads_tinit = >> "1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1" ; >> ens:avg = "unweighted mean of all members" ; >> ens:c00 = "unperturbed control forecast" ; >> ens:p01 = "positively perturbed forecast" ; >> ens:p02 = "positively perturbed forecast" ; >> >> ens:p19= "positively perturbed forecast" ; >> ens:p20 = "positively perturbed forecast" ; >> ens:grads_dim = "e" ; >> ens:grads_size = "22" ; >> ens:grads_mapping = "null" ; >> ens:units = "count" ; >> ens:long_name = "ensemble member" ; >> double time(time) ; >> time:grads_dim = "t" ; >> time:grads_mapping = "linear" ; >> time:grads_size = "31" ; >> time:grads_min = "12z16mar2010" ; >> time:grads_step = "6hr" ; >> time:units = "days since 1-1-1 00:00:0.0" ; >> time:long_name = "time" ; >> time:minimum = "12z16mar2010" ; >> time:maximum = "00z24mar2010" ; >> time:resolution = 0.25f ; >> >> float t(ens, time, lev, lat, lon) ; >> t:_FillValue = -9.99e+33f ; >> t:missing_value = -9.99e+33f ; >> t:long_name = "temperature [k] " ; >> >> >> data: >> >> ens = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, >> 18, 19, 20, >> 21, 22 ; >> >> time = 733848.5, 733848.75, 733849, 733849.25, 733849.5, >> 733849.75, 733850, >> 733850.25, 733850.5, 733850.75, 733851, 733851.25, 733851.5, >> 733851.75, >> 733852, 733852.25, 733852.5, 733852.75, 733853, 733853.25, >> 733853.5, >> 733853.75, 733854, 733854.25, 733854.5, 733854.75, 733855, >> 733855.25, >> 733855.5, 733855.75, 733856 ; >> >> } >> >> >> >> On Mar 16, 2010, at 1:22 PM, Jonathan Gregory wrote: >> >>> Dear John >>> >>>> Im not sure if we ever converged on how to write ensemble files. >>> No, we didn't. If I remember correctly, we couldn't agree on the >>> relationship >>> between attributes and coordinates, and that was a sticking-point. >>> I thought >>> that we ought to allow multivalued auxiliary coord variables for >>> ensemble >>> axes, corresponding to attributes that might be used to describe a >>> single >>> model. I would give these standard_names to identify them. Paco >>> started the >>> discussion, and in the end he made his own decisions for what to >>> do for the >>> ENSEMBLES project (because CF had not concluded), so he might >>> comment on it. >>> >>>> Particularly, how does software recognize the ensemble dimension? >>> We didn't agree. But at the end of the discussion, Steve also >>> suggested that >>> it could be identified by an axis attribute, just as you have. I >>> like that >>> idea too. But it could also be given a standard name, like other >>> coordinate >>> variables e.g. ensemble_member_identifier. I suppose the values of >>> this >>> coord var might be either numeric or strings, though it your >>> example it is >>> integer. I haven't looked at the trac ticket to see if we >>> discussed these >>> points before. >>> >>>> Perhaps we should add :axis = "Ensemble" to the model coordinate >>>> variable? >>> I'd suggest lower case, like most CF keywords. The other axis >>> attributes are >>> all single letters (X Y Z T) but I don't think it would be a >>> problem to use >>> a word. >>> >>> Best wishes >>> >>> Jonathan >>> _______________________________________________ >>> CF-metadata mailing list >>> CF-metadata at cgd.ucar.edu >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> >> >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> > -- Jennifer M. Adams IGES/COLA 4041 Powder Mill Road, Suite 302 Calverton, MD 20705 jma at cola.iges.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie.kettleborough at metoffice.gov.uk Wed Mar 17 04:14:17 2010 From: jamie.kettleborough at metoffice.gov.uk (Kettleborough, Jamie) Date: Wed, 17 Mar 2010 10:14:17 -0000 Subject: [CF-metadata] ensemble dimension In-Reply-To: <4B9FFBB4.1060003@unidata.ucar.edu> References: <4B9A9435.4060100@unidata.ucar.edu><20100316172209.GC13911@met.reading.ac.uk> <4B9FFBB4.1060003@unidata.ucar.edu> Message-ID: Hello John, > Im good with either/both axis = "ensemble" and/or > standard_name = "ensemble_member_identifier". > > for backwards compatibility, we could consider recognizing > standard_name = "realization". do we need anything new - or is standard_name = "realization" enough? I prefer "realization" to "ensemble" as I think its a bit more neutral - for instance you can produce a set of realizations of past and future climates using detection and attribution techniques, its not clear (to me) that "ensemble" is the most natural term for these. I think the term ensemble is a bit loaded to imply a production technique, whereas realization is more descriptive of the intent. (But I'm happy to be wrong on this.) >From what I remember a lot of the issues that caused the previous discussion on ensembles to stall were around the aggregation of different files into a single ensemble file, and what you do in this case to maintain traceability back to the original model experiments. So a scenario something like: 1. There is a repository of CMIP5 integrations (a collection of mega-ensembles): a number of models, with a number of initial conditions and a number of forcing scenarios. The output from each model integration is stored in its own set of NetCDF files with global attributes likse source, forcing, experiment, model, institute, realization used to identify this data in the CMIP5 mega-ensemble. Each model can be on a different grid. 2. A data user takes all (or a selection of) the files for a mega-ensemble and puts them on the *same* space-time sampling for analysis. e.g. decadal mean global means or continent means 3. The result of the analysis may be a reduced size to the original data and so comfortably fit into one file. If the user wants to share this data with others and maitain links to the original model integrations - how do they do this? I don't know if/when we want to return to this analysis and aggregation case (is it a CF problem?). To me at least, it feels logically related to some of the discussion around station data - though I didn't follow this discussion that closely - https://cf-pcmdi.llnl.gov/trac/ticket/37#comment:34. As I understood it the problem there was 'aggregating' over instruments to for a depth coordinate, whereas here we are aggregating over model integrations to give an ensemble coordinate. Jamie > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > From f.doblas-reyes at ecmwf.int Wed Mar 17 05:07:42 2010 From: f.doblas-reyes at ecmwf.int (Francisco Doblas-Reyes) Date: Wed, 17 Mar 2010 11:07:42 -0000 (UTC) Subject: [CF-metadata] ensemble dimension In-Reply-To: References: <4B9A9435.4060100@unidata.ucar.edu><20100316172209.GC13911@met.reading.ac.uk> <4B9FFBB4.1060003@unidata.ucar.edu> Message-ID: <45776.84.88.65.192.1268824062.squirrel@webmail.ecmwf.int> Hi all, I'd like to say that I finally created the ENSEMBLES dataset dealing with the ensemble dimension in my own way. Doug happened to be at the time at ECMWF, learned about our ENSEMBLES solution and adapted it to TIGEE, which was very helpful as he singled out some problems we had. It was clear from the previous round of discussions that it would be very difficult to aggregate ensemble members produced with different grids using NetCDF3. Hence, for the ENSEMBLES multi-forecast system (which comprises multi-model, perturbed parameters and stochastic physics initial-condition ensembles) dataset I first had to interpolate the data into a common grid. I then tried to define the ensemble-member attributes using auxiliary coordinates that borrowed some of the global attributes used in the CMIP3 dataset. Although all the ensemble members in the ENSEMBLES dataset share the same time dimension, this is not strictly necessary and the time coordinates (giving the start date and the lead time) can be also defined per ensemble member. This might imply introducing some missing fields in the NetCDF files though. Maybe NetCDF4 can deal with all this in a much more efficient way. On Wed, March 17, 2010 10:14, Kettleborough, Jamie wrote: > Hello John, > > >> Im good with either/both axis = "ensemble" and/or >> standard_name = "ensemble_member_identifier". >> >> for backwards compatibility, we could consider recognizing standard_name >> = "realization". >> do we need anything new - or is standard_name = "realization" enough? > > I prefer "realization" to "ensemble" as I think its a bit more neutral - > for instance you can produce a set of realizations of past and future > climates using detection and attribution techniques, its not clear (to me) > that "ensemble" is the most natural term for these. I think the term > ensemble is a bit loaded to imply a production technique, whereas > realization is more descriptive of the intent. (But I'm happy to be wrong > on this.) I seem to remember that I finally used "realization" following a long exchange with John, Jamie and others for the reasons given above. >> From what I remember a lot of the issues that caused the previous >> > discussion on ensembles to stall were around the aggregation of different > files into a single ensemble file, and what you do in this case to > maintain traceability back to the original model experiments. So a > scenario something like: > > 1. There is a repository of CMIP5 integrations (a collection of > mega-ensembles): a number of models, with a number of initial conditions > and a number of forcing scenarios. The output from each model integration > is stored in its own set of NetCDF files with global attributes likse > source, forcing, experiment, model, institute, realization used to > identify this data in the CMIP5 mega-ensemble. Each model can be on a > different grid. > > 2. A data user takes all (or a selection of) the files for a > mega-ensemble and puts them on the *same* space-time sampling for analysis. > e.g. decadal mean global means or continent means > > 3. The result of the analysis may be a reduced size to the original data > and so comfortably fit into one file. If the user wants to share this data > with others and maitain links to the original model integrations - how do > they do this? > > I don't know if/when we want to return to this analysis and aggregation > case (is it a CF problem?). To me at least, it feels logically related to > some of the discussion around station data - though I didn't follow this > discussion that closely - > https://cf-pcmdi.llnl.gov/trac/ticket/37#comment:34. As I understood it > the problem there was 'aggregating' over instruments to for a depth > coordinate, whereas here we are aggregating over model integrations to > give an ensemble coordinate. I'd just like to point out that the problem Jamie mentions above will be faced by a large part of the community. At least, I see that happening quickly with the decadal prediction part of CMIP5. If this is not a CF problem, I wonder whether GO-ESSP, Metafor, ESG-CET or Curator are doing something about it. If someone has an idea of who might be dealing with the issue, I'd be really interested in hearing about it. Cheers, Paco -- ____________________________________________ Francisco J. Doblas-Reyes Catalan Institute for Climate Sciences (IC3) Doctor Trueta 203 - 08005 Barcelona, Spain +34 93 5679977 Ext 316 ____________________________________________ From j.m.gregory at reading.ac.uk Wed Mar 17 06:18:35 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Wed, 17 Mar 2010 12:18:35 +0000 Subject: [CF-metadata] new standard names for momentum fluxes In-Reply-To: <4B9FDA4E.9040109@ecmwf.int> References: <4B9FDA4E.9040109@ecmwf.int> Message-ID: <20100317121835.GA19286@met.reading.ac.uk> Dear Tomas > u and v components of momentum fluxes due to vertical > diffusion (rho*u'w' and rho*v'w'). > > I checked the CF list and found the following two possible naming > alternatives: > > 1) downward_eastward_momentum_flux_in_air_due_to_diffusion [Pa] > downward_northward_momentum_flux_in_air_due_to_diffusion [Pa] > > 2) atmosphere_eastward_stress_due_to_diffusion [Pa] > atmosphere_northward_stress_due_to_diffusion [Pa] If it's a flux that you want, I think (1) is the right choice. (2) is more intended for the difference in flux, corresponding to an acceleration. Best wishes Jonathan From j.m.gregory at reading.ac.uk Wed Mar 17 06:24:47 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Wed, 17 Mar 2010 12:24:47 +0000 Subject: [CF-metadata] ensemble dimension In-Reply-To: <4B9FFBB4.1060003@unidata.ucar.edu> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> <4B9FFBB4.1060003@unidata.ucar.edu> Message-ID: <20100317122447.GB19286@met.reading.ac.uk> Dear all "realization" is fine as a standard name. I had forgotten we had introduced it. I withdraw my suggestion of ensemble_member_identifier. Thus, the standard name (of realization) can be used to identify an ensemble axis. I think that providing an axis attribute as well could be helpful: with spatiotemporal axes we have both methods of identification, and it is possible there might be ensemble axes in which realization was a not a good choice of standard name. Best wishes Jonathan From hyoklee at hdfgroup.org Thu Mar 18 08:56:31 2010 From: hyoklee at hdfgroup.org (H. Joe Lee) Date: Thu, 18 Mar 2010 09:56:31 -0500 Subject: [CF-metadata] Can coordinate variable have a comment attribute? Message-ID: Hi, Is there any particular reason that "comment" attribute applies only to G(global) and D(data variable)? http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/apa.html Can a coordinate variable have a comment attribute? -- +1(217)265-7710 http://hdfeos.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From caron at unidata.ucar.edu Thu Mar 18 17:15:19 2010 From: caron at unidata.ucar.edu (John Caron) Date: Thu, 18 Mar 2010 17:15:19 -0600 Subject: [CF-metadata] ensemble dimension In-Reply-To: <20100317122447.GB19286@met.reading.ac.uk> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> <4B9FFBB4.1060003@unidata.ucar.edu> <20100317122447.GB19286@met.reading.ac.uk> Message-ID: <4BA2B407.4060101@unidata.ucar.edu> Jonathan Gregory wrote: > Dear all > > "realization" is fine as a standard name. I had forgotten we had introduced it. > I withdraw my suggestion of ensemble_member_identifier. > > Thus, the standard name (of realization) can be used to identify an ensemble > axis. I think that providing an axis attribute as well could be helpful: with > spatiotemporal axes we have both methods of identification, and it is possible > there might be ensemble axes in which realization was a not a good choice of > standard name. > > Best wishes > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata using Tigge and ENSEMBLES datasets as examples (with GDS willing to modify their output), it sounds like a modest proposal is to recommend either of these attributes to identify the ensemble coordinate variable: axis = "ensemble"; standard_name = "realization"; with the idea of keeping it simple and follow paco's advice: > It was clear from the previous round of discussions that it would be very difficult to aggregate ensemble members produced with different grids using NetCDF3. other standard names suggested are: experiment_id, source, forcing, experiment, model, institution which would involve clarifying what they mean in this context, and try to answer jeremy's question: > what you do to maintain traceability back to the original model experiments. is there someone who is willing to take this on and marshall this through the process? From caron at unidata.ucar.edu Thu Mar 18 21:49:54 2010 From: caron at unidata.ucar.edu (John Caron) Date: Thu, 18 Mar 2010 21:49:54 -0600 Subject: [CF-metadata] missing value deprecation Message-ID: <4BA2F462.20809@unidata.ucar.edu> In 2.5.1 of CF 1.4: "The missing_value attribute is considered deprecated by the NUG and we do not recommend its use. However for backwards compatibility with COARDS this standard continues to recognize the use of the missing_value attribute to indicate undefined or missing data." Although there was a short time when a version of the User Guide deprecated the missing_value attribute, this is no longer the case. We decided that the deprecation was a mistake, and that deprecation hasnt been in the NUG for a long time now. What it now says is http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html (Appendix B) : missing_value This attribute is not treated in any special way by the library or conforming generic applications, but is often useful documentation and may be used by specific applications. The missing_value attribute can be a scalar or vector containing values indicating missing data. These values should all be outside the valid range so that generic applications will treat them as missing. I get enough questions about this that id like to propose removing this paragraph from the CF standard. If no one objects, ill open a ticket. From j.m.gregory at reading.ac.uk Fri Mar 19 02:16:32 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 19 Mar 2010 08:16:32 +0000 Subject: [CF-metadata] missing value deprecation In-Reply-To: <4BA2F462.20809@unidata.ucar.edu> References: <4BA2F462.20809@unidata.ucar.edu> Message-ID: <20100319081632.GA9409@met.reading.ac.uk> Dear John On Thu, Mar 18, 2010 at 09:49:54PM -0600, John Caron wrote: > I get enough questions about this that id like to propose removing this > paragraph from the CF standard. If no one objects, ill open a ticket. That sounds sensible to me. I think you could raise it as a defect. Cheers Jonathan From tomas.kral at ecmwf.int Fri Mar 19 04:13:32 2010 From: tomas.kral at ecmwf.int (Tomas Kral) Date: Fri, 19 Mar 2010 10:13:32 +0000 Subject: [CF-metadata] new standard names for momentum fluxes In-Reply-To: <20100317121835.GA19286@met.reading.ac.uk> References: <4B9FDA4E.9040109@ecmwf.int> <20100317121835.GA19286@met.reading.ac.uk> Message-ID: <4BA34E4C.1010205@ecmwf.int> Dear Jonathan, >> u and v components of momentum fluxes due to vertical >> diffusion (rho*u'w' and rho*v'w'). >> >> I checked the CF list and found the following two possible naming >> alternatives: >> >> 1) downward_eastward_momentum_flux_in_air_due_to_diffusion [Pa] >> downward_northward_momentum_flux_in_air_due_to_diffusion [Pa] >> >> 2) atmosphere_eastward_stress_due_to_diffusion [Pa] >> atmosphere_northward_stress_due_to_diffusion [Pa] > > If it's a flux that you want, I think (1) is the right choice. > (2) is more intended for the difference in flux, corresponding to > an acceleration. Thanks for advice. Personally I was also giving preference to the first option. Hence I would be very grateful if the two standard names mentioned in (1) could be added to the CF table. Thanks. Kind Regards, Tomas From j.m.gregory at reading.ac.uk Fri Mar 19 05:51:23 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 19 Mar 2010 11:51:23 +0000 Subject: [CF-metadata] new standard names for momentum fluxes In-Reply-To: <4BA34E4C.1010205@ecmwf.int> References: <4B9FDA4E.9040109@ecmwf.int> <20100317121835.GA19286@met.reading.ac.uk> <4BA34E4C.1010205@ecmwf.int> Message-ID: <20100319115122.GA10164@met.reading.ac.uk> Dear Tomas > >>1) downward_eastward_momentum_flux_in_air_due_to_diffusion [Pa] > >> downward_northward_momentum_flux_in_air_due_to_diffusion [Pa] I'm glad we agree. Alison makes updates to the standard name table periodically, so these will be added in due course, I expect, subject to further discussion. But if no-one objects soon, I guess you can assume they will be added. Best wishes Jonathan From a.heil at fz-juelich.de Tue Mar 23 05:48:33 2010 From: a.heil at fz-juelich.de (Heil, Angelika) Date: Tue, 23 Mar 2010 12:48:33 +0100 Subject: [CF-metadata] New standard names for emission sectors Message-ID: <2E9C45494F78A3498A77616E7C2DBB4C01C58A51@icg217.icg-ii-w2k.kfa-juelich.de> Dear all, I would like to propose new CF standard names for different emission sectors. It was agreed some time ago "that "emission" is a general term that includes sources located anywhere in the atmosphere, such as aircraft, and sources located at the earth's surface." (Posting J.A.Pamment May 4 2007, 07:21:23) The new gridded emission files which have been prepared for the IPCC AR5 simulations are subdivided into 12 emission sectors (see also Lamarque et al. 2010, www.atmos-chem-phys-discuss.net/10/4963/2010/ and, in more detail, ftp://ftp-ipcc.fz-juelich.de/pub/emissions/ancillary_data/IPCC_AR5_Emission_Sectors_v02.xls) and we would need specific standard names for them. (The issue was once raised by Martin Schultz - see Alison's mail from May 20 2009 15:06:26 +0100). I would therefore like to expand the "due_to_" syntax with = emission. For the moment, I'm proposing the expansion for carbon dioxide, only. Other species will follow. Here are the CF standard names that I propose for the 12 IPCC AR5 emission sectors: 1) tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_energy_production_and_distribution kg m-2 s-1 2) tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_industrial_processes_and_combustion kg m-2 s-1 3) tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_residential_and_commercial_combustion kg m-2 s-1 4) tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_solvent_production_and_use kg m-2 s-1 5) tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_agricultural_production kg m-2 s-1 6) tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_agricultural_waste_burning kg m-2 s-1 7) tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_waste_treatment_and_disposal kg m-2 s-1 8) tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_forest_fires kg m-2 s-1 9) tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_savanna_and_grassland_fires kg m-2 s-1 10) tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_land_transport kg m-2 s-1 11) tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_maritime_transport kg m-2 s-1 12) tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_aviation kg m-2 s-1 Best regards Angelika ============================================= Angelika Heil ICG-II, Forschungszentrum J?lich D-52425 J?lich, Germany phone: +49(0)2461 61 6864 fax: +49(0)2461 61 5346 email: a.heil at fz-juelich.de (for visitors: Wilhelm Johnen Str., Building 05.2 Room 3030) ============================================= ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ From j.m.gregory at reading.ac.uk Tue Mar 23 11:27:29 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 23 Mar 2010 17:27:29 +0000 Subject: [CF-metadata] New standard names for emission sectors In-Reply-To: <2E9C45494F78A3498A77616E7C2DBB4C01C58A51@icg217.icg-ii-w2k.kfa-juelich.de> References: <2E9C45494F78A3498A77616E7C2DBB4C01C58A51@icg217.icg-ii-w2k.kfa-juelich.de> Message-ID: <20100323172729.GB26382@met.reading.ac.uk> Dear Angelika I support this proposal. I think the pattern of these names is sensible and they are clearly described. Best wishes Jonathan From support-udunits at unidata.ucar.edu Tue Mar 23 09:17:21 2010 From: support-udunits at unidata.ucar.edu (Unidata UDUNITS Support) Date: Tue, 23 Mar 2010 09:17:21 -0600 Subject: [CF-metadata] [UDUNITS #UVU-592022]: information Message-ID: Cristina, > I've notice I made a type mistake in the previuos mail! this is my > "correct question": > > ------------------------------------------------------------------------------ > I'm creating a netcdf for Chlorophyll data. Usually oceanographic file > were in hdf and chlorophyll is expressed in "micro Kilogram" that is > 1e-06 kg also known as milligram (usually named: mg). Ah! That's better. :-) > As I must be compliant with CF convention, > I need to be sure to put the right name for "micro > Kilogram"="milligram" into the netcdf file. > > I installed the UDUNITS-2 package our workstation and using udunits2 I obtain: > > udunits2: Using default XML database > You have: microkg > You want: kg > 1 microkg = 1e-06 kg > x/kg = 1e-06*(x/microkg) > You have: mg > You want: kg > 1 mg = 1e-06 kg > x/kg = 1e-06*(x/mg) > > > So....the question is: > > 1) Is it correct to use both "microKg" and "mg" for 1e-06 kg "microkg" mixes a spelled-out prefix (micro) with a symbol (kg), which is not good. > 2) does it exist any alias? > 3) up to your experience which is the most used? I strongly suggest using "milligram" because of its clarity. > Thanks in advance > > Cristina tronconi > > p.s. > We don't want to change our data in order to use "kg". If I understand correctly, then if you set the unit attribute to "milligram", then you shouldn't have to change the data. > ------------------------------------------------------------------- > Cristina Tronconi > Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma > Consiglio Nazionale delle Ricerche > Via Fosso del Cavaliere 100 > 00133 Roma, Italy > Tel: +39 06 49934342 > cell: '39 349 1242954 > Fax: +39 06 20660291 > e-mail: cristina.tronconi at artov.isac.cnr.it Regards, Steve Emmerson Ticket Details =================== Ticket ID: UVU-592022 Department: Support UDUNITS Priority: Normal Status: Closed From support-udunits at unidata.ucar.edu Tue Mar 23 12:02:18 2010 From: support-udunits at unidata.ucar.edu (Unidata UDUNITS Support) Date: Tue, 23 Mar 2010 12:02:18 -0600 Subject: [CF-metadata] [UDUNITS #UVU-592022]: information Message-ID: Cristina, > Only a further clarification: you can read in the CF convention "the > value of the units attribute is a string that can be recognized by > UNIDATA"s Udunits package [UDUNITS]". > So, in order to be compliant with CF specification I need to be sure > that "milligram" is recognized by UNIDATA"s Udunits package. > > Can you reassure me about this? The UDUNITS-2 package understands milligrams: $ udunits2 udunits2: Using default XML database You have: milligram You want: 1e-06 kg You have: > Best regards! > > cristina > > p.s. > About our data....you are right! if "milligram" is recognized by the > UDUUNITS, then we can use "milligram" as unit for our chlorophyll, > then we needn't make any change to our data, but simply put the > correct string into the "units" attribute for the variable CHL. > > p.p.s. > Sorry for my english! Don't be. Your English is vastly superior to my Italian! > ------------------------------------------------------------------- > Cristina Tronconi > Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma > Consiglio Nazionale delle Ricerche > Via Fosso del Cavaliere 100 > 00133 Roma, Italy > Tel: +39 06 49934342 > cell: '39 349 1242954 > Fax: +39 06 20660291 > e-mail: cristina.tronconi at artov.isac.cnr.it Regards, Steve Emmerson Ticket Details =================== Ticket ID: UVU-592022 Department: Support UDUNITS Priority: Normal Status: Closed From j.m.gregory at reading.ac.uk Tue Mar 23 13:11:19 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 23 Mar 2010 19:11:19 +0000 Subject: [CF-metadata] ensemble dimension In-Reply-To: <4BA2B407.4060101@unidata.ucar.edu> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> <4B9FFBB4.1060003@unidata.ucar.edu> <20100317122447.GB19286@met.reading.ac.uk> <4BA2B407.4060101@unidata.ucar.edu> Message-ID: <20100323191119.GA27175@met.reading.ac.uk> Dear John > it sounds like a modest proposal is to recommend either of > these attributes to identify the ensemble coordinate variable: > > axis = "ensemble"; > standard_name = "realization"; > > with the idea of keeping it simple. For auxiliary coordinate variables of the ensemble axis, > other standard names suggested are: > > experiment_id, source, forcing, experiment, model, institution To keep it simple again, I'd vote for just source and institution, which correspond to these existing global attributes of CF: institution Specifies where the original data was produced. source The method of production of the original data. If it was model-generated, source should name the model and its version, as specifically as could be useful. But that doesn't have to be part of the trac proposal, as these are proposals for new standard names. The trac proposal could just say that the ensemble axis could have auxiliary coordinate variables supplying information about the ensemble members. When they come from different models, aux coord variables are probably a better way to describe than a coord variable of "realization", I suppose. > is there someone who is willing to take this on and marshall this through > the process? I hereby propose standard names of institution and source, for string-valued auxiliary coordinate variables, with the above meanings! Could someone please make the trac proposal for the ensemble axis above? Best wishes Jonathan From jbgraybeal at mindspring.com Tue Mar 23 17:12:13 2010 From: jbgraybeal at mindspring.com (John Graybeal) Date: Tue, 23 Mar 2010 16:12:13 -0700 Subject: [CF-metadata] ensemble dimension In-Reply-To: <20100323191119.GA27175@met.reading.ac.uk> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> <4B9FFBB4.1060003@unidata.ucar.edu> <20100317122447.GB19286@met.reading.ac.uk> <4BA2B407.4060101@unidata.ucar.edu> <20100323191119.GA27175@met.reading.ac.uk> Message-ID: <78D330D0-587A-4850-8558-2CF8F5E5BC96@mindspring.com> based on the definitions it would be nice to see source_institution (or institution_where_produced) and source_method (or source_provenance), in order to avoid collisions. just a thought, I know it's not CF-ish to imagine far-flung-future problems so feel free to ignore it! john On Mar 23, 2010, at 12:11, Jonathan Gregory wrote: > Dear John > >> it sounds like a modest proposal is to recommend either of >> these attributes to identify the ensemble coordinate variable: >> >> axis = "ensemble"; >> standard_name = "realization"; >> >> with the idea of keeping it simple. > > For auxiliary coordinate variables of the ensemble axis, >> other standard names suggested are: >> >> experiment_id, source, forcing, experiment, model, institution > > To keep it simple again, I'd vote for just source and institution, > which > correspond to these existing global attributes of CF: > institution > Specifies where the original data was produced. > source > The method of production of the original data. If it was model- > generated, > source should name the model and its version, as specifically as > could be > useful. > But that doesn't have to be part of the trac proposal, as these are > proposals > for new standard names. The trac proposal could just say that the > ensemble > axis could have auxiliary coordinate variables supplying information > about the > ensemble members. When they come from different models, aux coord > variables > are probably a better way to describe than a coord variable of > "realization", > I suppose. > From mcginnis at ucar.edu Tue Mar 23 17:59:56 2010 From: mcginnis at ucar.edu (Seth McGinnis) Date: Tue, 23 Mar 2010 17:59:56 -0600 Subject: [CF-metadata] ensemble dimension In-Reply-To: <78D330D0-587A-4850-8558-2CF8F5E5BC96@mindspring.com> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> <4B9FFBB4.1060003@unidata.ucar.edu> <20100317122447.GB19286@met.reading.ac.uk> <4BA2B407.4060101@unidata.ucar.edu> <20100323191119.GA27175@met.reading.ac.uk> <78D330D0-587A-4850-8558-2CF8F5E5BC96@mindspring.com> Message-ID: This may be complicating the issue more than resolving it, but how about in some way applying the ensemble dimension to the CF global attributes for source and institution, rather than transplanting the information into auxiliary coordinates? It could also be done for the global history attribute, which carries a lot of provenance information. If we're talking about ensemble files with data compiled from many different sources, it would be nice to be able to incorporate the history associated with each member of the ensemble, rather than just having data about the creation of the ensemble itself. It may not be technically feasible to apply a dimension to a global attribute per se, but I think something that aims in that general direction would have a lot of benefits. --Seth Seth McGinnis Associate Scientist NARCCAP Data Manager ISSE / IMAGe / NCAR On Tue, 23 Mar 2010 16:12:13 -0700 John Graybeal wrote: >based on the definitions it would be nice to see source_institution (or >institution_where_produced) and source_method (or source_provenance), in >order to avoid collisions. just a thought, I know it's not CF-ish to imagine >far-flung-future problems so feel free to ignore it! > >john > >On Mar 23, 2010, at 12:11, Jonathan Gregory wrote: > >> Dear John >> >>> it sounds like a modest proposal is to recommend either of >>> these attributes to identify the ensemble coordinate variable: >>> >>> axis = "ensemble"; >>> standard_name = "realization"; >>> >>> with the idea of keeping it simple. >> >> For auxiliary coordinate variables of the ensemble axis, >>> other standard names suggested are: >>> >>> experiment_id, source, forcing, experiment, model, institution >> >> To keep it simple again, I'd vote for just source and institution, which >> correspond to these existing global attributes of CF: >> institution >> Specifies where the original data was produced. >> source >> The method of production of the original data. If it was model- >generated, >> source should name the model and its version, as specifically as could >be >> useful. >> But that doesn't have to be part of the trac proposal, as these are > proposals >> for new standard names. The trac proposal could just say that the ensemble >> axis could have auxiliary coordinate variables supplying information about >the >> ensemble members. When they come from different models, aux coord variables >> are probably a better way to describe than a coord variable of > "realization", >> I suppose. >> >_______________________________________________ >CF-metadata mailing list >CF-metadata at cgd.ucar.edu >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From alison.pamment at stfc.ac.uk Tue Mar 23 19:23:26 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Wed, 24 Mar 2010 01:23:26 -0000 Subject: [CF-metadata] CMIP5 ocean biogeochemistry standard names Message-ID: Dear All, There is a need to introduce quite a number of new standard names to describe the output which will be produced by ocean biogeochemistry models as part of the CMIP5 project. The attached spreadsheet lists the proposed name, unit and a brief explanation for each model output quantity. The list was coordinated by John Dunne and arises from lengthy discussions within the ocean biogeochemistry community. Jonathan and I have both spent time looking at these names and we have taken care to ensure that they are as consistent as possible with existing names and units. Comments on these names are now invited. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. -------------- next part -------------- A non-text attachment was scrubbed... Name: cf_ocean_biogeochem_names.xlsx Type: application/octet-stream Size: 19061 bytes Desc: cf_ocean_biogeochem_names.xlsx URL: From rkl at bodc.ac.uk Wed Mar 24 03:13:31 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Wed, 24 Mar 2010 09:13:31 +0000 Subject: [CF-metadata] CMIP5 ocean biogeochemistry standard names In-Reply-To: References: Message-ID: <40829B0E077C1145A6DE44D39B3830A90887C1EFD0@nerckwmb1.ad.nerc.ac.uk> Hello Alison, Some (ended up quite a lot) comments. Any discussion of this lot could well descend into chaos. Could I suggest that responses are made separately to each of the 11 numbered comments so we end up with 11 threads that individually stand some chance of closure. (1) I don't understand what the definition of picophytoplankton (carbon concentration from the picophytoplankton (<2 um; < 5um) component alone) means Does it mean cells between 2 and 5 um in size, in which case it should be expressed as 2-5um, or does it mean something else? (2) 'mole_concentration_of_miscellaneous_phytoplankton_expressed_as_carbon_in_sea_water' is a very imprecise term that I think needs specifying more precisely. Once the definition is tightened up finding a better phrase for the Standard Name should be possible. Likewise for 'mole_concentration_of_miscellaneous_zooplankton_expressed_as_carbon_in_sea_water', ' mass_concentration_of_miscellaneous_phytoplankton_expressed_as_chlorophyll_in_sea_water', . (3) 'mole_concenration_of_dissolved_iron_in_sea_water'. Besides the typo (concentration), does this refer to iron in all oxidation states (Fe2+/Fe3+) and chemical environments. If so, calling it 'total iron' might be better. (4) There are a number of standard names for elemental concentrations in the particulate phase where the long names are very familiar to me, but the Standard Names seem counter-intuitive, such as ' mole_concentration_of_particulate_organic_matter_expressed_as_nitrogen_in_sea_water' for the parameter commonly known as particulate organic nitrogen or more usually PON. I guess what is bugging me is that the standard name describes the primary quantity as the suspended particulate material (SPM) concentration, whereas in fact the chemical composition of the SPM is of at least equal importance. (5) I have much deeper rooted problems with ' tendency_of_mole_concentration_of_organic_carbon_in_sea_water_due_to_net_primary_production' for primary production. In a nutshell, the process of primary production involves the transition of primarily inorganic carbon in the dissolved phase into organic carbon in the particulate phase (in the form of plant cells). The standard name gives no indication that the organic carbon quantity change is in the particulate phase. At the very least I think we need 'tendency_of_mole_concentration_of_particulate_organic_carbon_in_sea_water_due_to_net_primary_production', which with the existing syntax form would in fact become ' tendency_of_mole_concentration_of_particulate_organic_matter_expressed_as_carbon_in_sea_water_due_to_net_primary_production'. Ditto for new production, biogenic iron production and biogenic silica production, but this doesn't apply to calcite and aragonite which are be definition part of the particulate phase being crystalline forma of calcium carbonate. Also affects primary production by phytoplankton groups such as diatoms (lines 53-57 of the spreadsheet). (6) I now see, 'sinking_mole_flux_of_particulate_organic_carbon_in_sea_water', which if for consistency with the POC standard name would need to be 'sinking_mole_flux_of_ particulate_organic_matter_expressed_as_carbon_in_sea_water'. Personally, I much prefer 'particulate_organic_carbon'. (7) 'tendency_of_mole_concentration_of_dissolved_iron_in_sea_water_due_to_scavenging_by_particles' should be ' tendency_of_mole_concentration_of_dissolved_iron_in_sea_water_due_to_scavenging_by_inorganic_particles'. 'particles' could easily be taken to include plankton. Similarly for ' tendency_of_mole_concentration_of_dissolved_iron_in_sea_water_due_to_dissolution_from_particles'. (8) When we come to integrated primary production the standard name syntax becomes ' net_primary_mole_productivity_of_carbon' instead of 'net_tendency_of_mole_concentration_of_particulate_organic_carbon_in_sea_water_due_to_net_primary_production' (which in itself needs revising: see above). I'm not sure how comfortable biogeochemists would be with the use of 'net' to signify depth integration. 'net' tends to have other meanings such as the result of competing processes like photosynthesis and respiration in oxygen budgets. I would much prefer 'depth_integrated'. (9) When we come to 'tendency_of_ocean_mole_content_of_iron_due_to_biological_production', there is no indication at all that the quantity is depth integrated. Ditto for lines 75-78, 86, 95-106. (10) 'surface_downward_mass_flux_of_carbon_dioxide_expressed_as_carbon' doesn't indicate to me the that it's a flux from atmosphere to water body that's involved. It could equally well be a chemical flux between two layers of the atmosphere, or is 'surface' explicitly defined as the ocean/atmosphere interface? (11) Rows 95-106 refer to the rate of change of depth integrated values in the upper 100m of the water column, but the standard name gives no indication that it's depth integrated (see above) or that the region of interest is confined to the top 100m. I can appreciate the quandry here that standard names shouldn't indicate spatial coverage, but might it be possible to argue that the top 100m of the water column approximates to a layer (euphotic zone?) of the ocean that should be treated in the same way as layers of the atmosphere? Well that's it for now..... Cheers, Roy. -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of alison.pamment at stfc.ac.uk Sent: 24 March 2010 01:23 To: cf-metadata at cgd.ucar.edu; John.Dunne at noaa.gov Cc: chris.d.jones at metoffice.gov.uk; pierre.friedlingstein at lsce.ipsl.fr; James.Orr at lsce.ipsl.fr; ernst.maier-reimer at zmaw.de; doutriaux1 at llnl.gov Subject: [CF-metadata] CMIP5 ocean biogeochemistry standard names Dear All, There is a need to introduce quite a number of new standard names to describe the output which will be produced by ocean biogeochemistry models as part of the CMIP5 project. The attached spreadsheet lists the proposed name, unit and a brief explanation for each model output quantity. The list was coordinated by John Dunne and arises from lengthy discussions within the ocean biogeochemistry community. Jonathan and I have both spent time looking at these names and we have taken care to ensure that they are as consistent as possible with existing names and units. Comments on these names are now invited. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From alison.pamment at stfc.ac.uk Wed Mar 24 05:35:21 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Wed, 24 Mar 2010 11:35:21 -0000 Subject: [CF-metadata] new standard names for momentum fluxes In-Reply-To: <20100319115122.GA10164@met.reading.ac.uk> References: <4B9FDA4E.9040109@ecmwf.int><20100317121835.GA19286@met.reading.ac.uk><4BA34E4C.1010205@ecmwf.int> <20100319115122.GA10164@met.reading.ac.uk> Message-ID: Dear Tomas, Thank you for your proposals for two new momentum flux names. I think these names look fine. If there are no further comments over the next seven days then the names downward_eastward_momentum_flux_in_air_due_to_diffusion [Pa] downward_northward_momentum_flux_in_air_due_to_diffusion [Pa] will be accepted for inclusion in the standard name table. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. From alison.pamment at stfc.ac.uk Wed Mar 24 07:54:47 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Wed, 24 Mar 2010 13:54:47 -0000 Subject: [CF-metadata] New standard names for emission sectors In-Reply-To: <2E9C45494F78A3498A77616E7C2DBB4C01C58A51@icg217.icg-ii-w2k.kfa-juelich.de> References: <2E9C45494F78A3498A77616E7C2DBB4C01C58A51@icg217.icg-ii-w2k.kfa-juelich.de> Message-ID: Dear Angelika, Thank you for your proposals for standard names to describe emissions from different sectors of activity. The use and definition of the term "emission" is indeed well established in standard names and I agree that extending the syntax to "due_to_emission_from_sector" is sensible. I agree with Jonathan that the wording of the names is fine and the units of kg m-2 s-1 are also correct for "tendency_of_atmosphere_mass_content" names. The names will need accompanying definitions so that they can be added to the standard name table. I have spent a short time looking through your references but I didn't see clear definitions of the various sectors or the relationships between them. Looking at the names I suspect that the sectors should be regarded as separate sources but, for example, is "commercial combustion" separate to "industrial combustion" or is it a superset? Also, is there a list of specific chemical species that would usually be used in models to represent "solvents"? If you could provide some brief descriptions of each sector or point me to an appropriate reference that would be very helpful. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > bounces at cgd.ucar.edu] On Behalf Of Heil, Angelika > Sent: 23 March 2010 11:49 > To: cf-metadata at cgd.ucar.edu > Subject: [CF-metadata] New standard names for emission sectors > > Dear all, > > I would like to propose new CF standard names for different emission > sectors. It was agreed some time ago "that "emission" is a general term > that includes sources located anywhere in the atmosphere, such as > aircraft, and sources located at the earth's surface." (Posting > J.A.Pamment May 4 2007, 07:21:23) > > The new gridded emission files which have been prepared for the IPCC > AR5 simulations are subdivided into 12 emission sectors (see also > Lamarque et al. 2010, www.atmos-chem-phys-discuss.net/10/4963/2010/ > and, in more detail, ftp://ftp-ipcc.fz- > juelich.de/pub/emissions/ancillary_data/IPCC_AR5_Emission_Sectors_v02.x > ls) and we would need specific standard names for them. (The issue was > once raised by Martin Schultz - see Alison's mail from May 20 2009 > 15:06:26 +0100). > > I would therefore like to expand the "due_to_" syntax with > = emission. > For the moment, I'm proposing the expansion for carbon dioxide, only. > Other species will follow. > > Here are the CF standard names that I propose for the 12 IPCC AR5 > emission sectors: > > 1) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_f > rom_energy_production_and_distribution kg m-2 s-1 > 2) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_f > rom_industrial_processes_and_combustion kg m-2 s-1 > 3) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_f > rom_residential_and_commercial_combustion kg m-2 s-1 > 4) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_f > rom_solvent_production_and_use kg m-2 s-1 > 5) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_f > rom_agricultural_production kg m-2 s-1 > 6) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_f > rom_agricultural_waste_burning kg m-2 s-1 > 7) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_f > rom_waste_treatment_and_disposal kg m-2 s-1 > 8) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_f > rom_forest_fires kg m-2 s-1 > 9) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_f > rom_savanna_and_grassland_fires kg m-2 s-1 > 10) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_f > rom_land_transport kg m-2 s-1 > 11) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_f > rom_maritime_transport kg m-2 s-1 > 12) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_f > rom_aviation kg m-2 s-1 > > Best regards > > Angelika > > ============================================= > Angelika Heil > ICG-II, Forschungszentrum J?lich > D-52425 J?lich, Germany > phone: +49(0)2461 61 6864 > fax: +49(0)2461 61 5346 > email: a.heil at fz-juelich.de > (for visitors: > Wilhelm Johnen Str., Building 05.2 Room 3030) > ============================================= > > ----------------------------------------------------------------------- > ------------------------- > ----------------------------------------------------------------------- > ------------------------- > Forschungszentrum Juelich GmbH > 52425 Juelich > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe > Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), > Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, > Prof. Dr. Sebastian M. Schmidt > ----------------------------------------------------------------------- > ------------------------- > ----------------------------------------------------------------------- > ------------------------- > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Scanned by iCritical. From cameronsmith1 at llnl.gov Wed Mar 24 19:53:12 2010 From: cameronsmith1 at llnl.gov (Philip J. Cameronsmith1) Date: Wed, 24 Mar 2010 18:53:12 -0700 (PDT) Subject: [CF-metadata] New standard names for emission sectors In-Reply-To: <2E9C45494F78A3498A77616E7C2DBB4C01C58A51@icg217.icg-ii-w2k.kfa-juelich.de> References: <2E9C45494F78A3498A77616E7C2DBB4C01C58A51@icg217.icg-ii-w2k.kfa-juelich.de> Message-ID: Hi Angelika, Are your emissions separated into 2D surface and 3D emissions (eg aircraft emissions)? I assume so, because that is what I usually see. If so, your proposed quantities (tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_) may not be what you want. "atmosphere_content of a quantity refers to the vertical integral from the surface to the top of the atmosphere." [from CF standard name table] [For non-specialists: There are three related emission quantities: 2D surface emissions (kg/m2/s), 3D volume emissions (kg/m3/s), and the column integral tendency_of_atmosphere_mass_content_of_X_due_to_emission (kg/m2/s). These three quantities are simply related by: tendency_of_atmosphere_mass_content_of_X_due_to_emissions = surface emissions + vertical integral of 3D volume emissions. Usually people specify the surface and volume emissions, but in CF we ended up with mostly the column integral tendency_of_atmosphere_mass_content_of_X_due_to_emissions. Usually this isn't a big deal because the volume emissions for most species are zero, so the tendency_of_atmosphere_mass_content is equal to the surface emissions. However, this isn't true for CO2. Volume emissions are also often used for other aircraft emissions (eg CO, SO2, and NOx) and lightning emissions (primarily NOx).] Searching through the standard name table I can find only two surface flux quantities for species: surface_carbon_dioxide_mole_flux, and surface_downward_water_flux. However, there are lots surface flux quantities for radiation and heat. I can't find any volume emission quantities. For your 3D emissions I suspect you will want something like: tendency_of_mass_fraction_of_X_in_air_due_to_emission_from_[sector] Or, instead of mass_fraction (kg/kg) you might use mass_concentration (kg/m3), mole_concentration (mol/m3), or mole_fraction (mol/mol). For your 2D surface emissions it would be most logical to me to expand the surface_flux constructs mentioned above, although we haven't established a good pattern, since I think those two quantities were introduced before we started talking about chemistry. Note: none of my comments relate to the proposed from_sector construct, which seems fine to me. Best wishes, Philip Heil, Angelika wrote: > Dear all, > > I would like to propose new CF standard names for different emission sectors. It was agreed some time ago "that "emission" is a general term that includes sources located anywhere in the atmosphere, such as aircraft, and sources located at the earth's surface." (Posting J.A.Pamment May 4 2007, 07:21:23) > > The new gridded emission files which have been prepared for the IPCC AR5 simulations are subdivided into 12 emission sectors (see also Lamarque et al. 2010, www.*atmos-chem-phys-discuss.net/10/4963/2010/ and, in more detail, ftp://*ftp-ipcc.fz-juelich.de/pub/emissions/ancillary_data/IPCC_AR5_Emission_Sectors_v02.xls) and we would need specific standard names for them. (The issue was once raised by Martin Schultz - see Alison's mail from May 20 2009 15:06:26 +0100). > > I would therefore like to expand the "due_to_" syntax with = emission. > For the moment, I'm proposing the expansion for carbon dioxide, only. Other species will follow. > > Here are the CF standard names that I propose for the 12 IPCC AR5 emission sectors: > > 1) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_energy_production_and_distribution kg m-2 s-1 > 2) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_industrial_processes_and_combustion kg m-2 s-1 > 3) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_residential_and_commercial_combustion kg m-2 s-1 > 4) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_solvent_production_and_use kg m-2 s-1 > 5) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_agricultural_production kg m-2 s-1 > 6) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_agricultural_waste_burning kg m-2 s-1 > 7) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_waste_treatment_and_disposal kg m-2 s-1 > 8) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_forest_fires kg m-2 s-1 > 9) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_savanna_and_grassland_fires kg m-2 s-1 > 10) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_land_transport kg m-2 s-1 > 11) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_maritime_transport kg m-2 s-1 > 12) > tendency_of_atmosphere_mass_content_of_carbon_dioxide_due_to_emission_from_aviation kg m-2 s-1 > > Best regards > > Angelika > > ============================================= > Angelika Heil > ICG-II, Forschungszentrum J?lich > D-52425 J?lich, Germany > phone: +49(0)2461 61 6864 > fax: +49(0)2461 61 5346 > email: a.heil at fz-juelich.de > (for visitors: > Wilhelm Johnen Str., Building 05.2 Room 3030) > ============================================= > > ------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------ > Forschungszentrum Juelich GmbH > 52425 Juelich > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe > Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), > Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, > Prof. Dr. Sebastian M. Schmidt > ------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------ > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > ------------------------------------------------------------------------ Dr Philip Cameron-Smith Atmospheric, Earth, and Energy Division pjc at llnl.gov Lawrence Livermore National Laboratory +1 925 4236634 7000 East Avenue, Livermore, CA94550, USA ------------------------------------------------------------------------ From j.m.gregory at reading.ac.uk Thu Mar 25 02:34:39 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Thu, 25 Mar 2010 08:34:39 +0000 Subject: [CF-metadata] ensemble dimension In-Reply-To: References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> <4B9FFBB4.1060003@unidata.ucar.edu> <20100317122447.GB19286@met.reading.ac.uk> <4BA2B407.4060101@unidata.ucar.edu> <20100323191119.GA27175@met.reading.ac.uk> <78D330D0-587A-4850-8558-2CF8F5E5BC96@mindspring.com> Message-ID: <20100325083439.GD4539@met.reading.ac.uk> Dear Seth > This may be complicating the issue more than resolving it, but how about in > some way applying the ensemble dimension to the CF global attributes for source > and institution, rather than transplanting the information into auxiliary > coordinates? This could be done, but isn't there a general preference for using variables in netCDF rather than giving dimensions to attributes? I believe there is, and it is what CF does. I would instead see the use of global attributes as a kind of special case, for when there is no ensemble dimension. Best wishes Jonathan From reyna at uvic.ca Thu Mar 25 18:01:23 2010 From: reyna at uvic.ca (Reyna Jenkyns) Date: Thu, 25 Mar 2010 17:01:23 -0700 Subject: [CF-metadata] clarification of sound_intensity_level_in_water Message-ID: <66BB71CEF54C4B41B80690B9B9CAAC0E2638C81F04@EMC4.uvic.ca> Hi, I'm new to both netcdf and CF. I'm trying to make a netcdf data product for our RDI adcps. I noticed that there is an existing standard name for sound_intensity_level_in_air, and I figure this would apply to the intensity returned from the adcp. I have corrected for two-way beam spreading (2*20*log10), and figured a comment attribute would suffice to explain that. Is that a valid interpretation of this standard name, or should I leave it uncorrected for beam spreading? By the way, I welcome sample cdls from anyone who's made cf-compliant netcdfs for rdi adcps. Thanks, Reyna Jenkyns Scientific Programmer NEPTUNE Canada reyna at uvic.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: From alison.pamment at stfc.ac.uk Fri Mar 26 08:35:15 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Fri, 26 Mar 2010 14:35:15 -0000 Subject: [CF-metadata] CMIP5 ocean biogeochemistry standard names In-Reply-To: <40829B0E077C1145A6DE44D39B3830A90887C1EFD0@nerckwmb1.ad.nerc.ac.uk> References: <40829B0E077C1145A6DE44D39B3830A90887C1EFD0@nerckwmb1.ad.nerc.ac.uk> Message-ID: Dear Roy, > > Some (ended up quite a lot) comments. Any discussion of this lot could > well descend into chaos. Could I suggest that responses are made > separately to each of the 11 numbered comments so we end up with 11 > threads that individually stand some chance of closure. > If possible, I would prefer not to create a large number of separate threads as that can sometimes make it difficult to follow complete conversations when looking back through the mailing list archives. Names can be accepted as they are agreed which will allow them to be added to the standard name table, even if others are still under discussion. Regarding your specific comments, I have tried to address each one in turn. > > (1) I don't understand what the definition of picophytoplankton (carbon > concentration from the picophytoplankton (<2 um; < 5um) component > alone) means Does it mean cells between 2 and 5 um in size, in which > case it should be expressed as 2-5um, or does it mean something else? > I agree that this definition doesn't make sense as it stands - I'll check with John Dunne. > > (2) > 'mole_concentration_of_miscellaneous_phytoplankton_expressed_as_carbon_ > in_sea_water' is a very imprecise term that I think needs specifying > more precisely. Once the definition is tightened up finding a better > phrase for the Standard Name should be possible. Likewise for > 'mole_concentration_of_miscellaneous_zooplankton_expressed_as_carbon_in > _sea_water', ' > mass_concentration_of_miscellaneous_phytoplankton_expressed_as_chloroph > yll_in_sea_water', . > My understanding of "miscellaneous" is that it means all the other phytoplankton that are not mentioned in the names for specific categories such as diatoms, diazatrophs, picophytoplankton, etc. In that sense it is intended to allow a looser definition than some of the other names. I think that diatoms + diazotrophs + calcareous phytoplankton + picophytoplankton + miscellaneous phytoplankton = total phytoplankton. This information will certainly be included in the definitions of all the relevant names. However, if we can come up with a more meaningful collective noun than "miscellaneous" then I'd welcome suggestions. > > (3) 'mole_concenration_of_dissolved_iron_in_sea_water'. Besides the > typo (concentration), does this refer to iron in all oxidation states > (Fe2+/Fe3+) and chemical environments. If so, calling it 'total iron' > might be better. Thanks for pointing out the typo - I'll correct it. I think whenever the word "total" has come up in standard names proposals in the past that we have tried to avoid using it. Indeed, there are no standard names that use the term. I think "iron" essentially should be understood to mean "total iron" and if we want more specific names for Fe2+, etc, we should introduce terms such as "divalent iron" in the way that we have done for elemental and divalent mercury in the atmosphere. Having said all that, I think it would be helpful if John could clarify the definition. > > (4) There are a number of standard names for elemental concentrations > in the particulate phase where the long names are very familiar to me, > but the Standard Names seem counter-intuitive, such as ' > mole_concentration_of_particulate_organic_matter_expressed_as_nitrogen_ > in_sea_water' for the parameter commonly known as particulate organic > nitrogen or more usually PON. I guess what is bugging me is that the > standard name describes the primary quantity as the suspended > particulate material (SPM) concentration, whereas in fact the chemical > composition of the SPM is of at least equal importance. I think the main reason for arriving at this particular wording was to be consistent with existing standard names. We use particulate_organic_matter in quite a number of existing atmosphere names. The "expressed_as_species" construction and its position within the standard name was also something that we arrived at after lengthy discussion with the atmospheric chemists. I think that we should try, as far as is practicable, to keep the wording and construction of standard names consistent between the different components of the climate system. I don't think the order of the wording is intended to imply that the particulate state is more or less important than the name of the chemical species. > > (5) I have much deeper rooted problems with ' > tendency_of_mole_concentration_of_organic_carbon_in_sea_water_due_to_ne > t_primary_production' for primary production. In a nutshell, the > process of primary production involves the transition of primarily > inorganic carbon in the dissolved phase into organic carbon in the > particulate phase (in the form of plant cells). The standard name > gives no indication that the organic carbon quantity change is in the > particulate phase. At the very least I think we need > 'tendency_of_mole_concentration_of_particulate_organic_carbon_in_sea_wa > ter_due_to_net_primary_production', which with the existing syntax form > would in fact become ' > tendency_of_mole_concentration_of_particulate_organic_matter_expressed_ > as_carbon_in_sea_water_due_to_net_primary_production'. Ditto for new > production, biogenic iron production and biogenic silica production, > but this doesn't apply to calcite and aragonite which are be definition > part of the particulate phase being crystalline forma of calcium > carbonate. Also affects primary production by phytoplankton groups such > as diatoms (lines 53-57 of the spreadsheet). Thank you for clarifying the production process. Personally, I would be happy with the addition of the word "particulate", as you suggest. > > (6) I now see, > 'sinking_mole_flux_of_particulate_organic_carbon_in_sea_water', which > if for consistency with the POC standard name would need to be > 'sinking_mole_flux_of_ > particulate_organic_matter_expressed_as_carbon_in_sea_water'. > Personally, I much prefer 'particulate_organic_carbon'. I see your point. Having argued for consistency of naming conventions above, I would actually tend to favour sinking_mole_flux_of_particulate_organic_matter_expressed_as_carbon_in_s ea_water. > > (7) > 'tendency_of_mole_concentration_of_dissolved_iron_in_sea_water_due_to_s > cavenging_by_particles' should be ' > tendency_of_mole_concentration_of_dissolved_iron_in_sea_water_due_to_sc > avenging_by_inorganic_particles'. 'particles' could easily be taken to > include plankton. Similarly for ' > tendency_of_mole_concentration_of_dissolved_iron_in_sea_water_due_to_di > ssolution_from_particles'. That sounds fine to me. > > (8) When we come to integrated primary production the standard name > syntax becomes ' net_primary_mole_productivity_of_carbon' instead of > 'net_tendency_of_mole_concentration_of_particulate_organic_carbon_in_se > a_water_due_to_net_primary_production' (which in itself needs revising: > see above). I'm not sure how comfortable biogeochemists would be with > the use of 'net' to signify depth integration. 'net' tends to have > other meanings such as the result of competing processes like > photosynthesis and respiration in oxygen budgets. I would much prefer > 'depth_integrated'. I think "net" refers to the productivity (i.e. net productivity = gross productivity minus destruction) rather than to the vertical integration. The vertical integration is implied by the fact that the units of this quantity are mol m-2 s-1, rather than mol m-3 s-1 for 3-D tendencies. In fact, Jonathan's idea was to reserve the term "productivity" specifically to mean this type of vertically integrated quantity (as in the atmosphere names gross_primary_productivity_of_carbon and net_primary_productivity_of_carbon) and use "production" for the 3-D quantities. The definition of the name needs to make this clear. If we wanted to make the vertical integration part of the name itself the correct syntax would be integral_wrt_depth_of_tendency_of_mole_concentration_of_particulate_orga nic_carbon_in_sea_water_due_to_net_primary_production. Would that be better? > > (9) When we come to > 'tendency_of_ocean_mole_content_of_iron_due_to_biological_production', > there is no indication at all that the quantity is depth integrated. > Ditto for lines 75-78, 86, 95-106. The term "content" is well established in standard names to mean a vertically integrated quantity, for example, there are many "atmosphere_content" names with precisely this interpretation. This is really just a convention that has been adopted within CF but it is one that has been used pretty much from the inception of standard names, I believe. > > (10) 'surface_downward_mass_flux_of_carbon_dioxide_expressed_as_carbon' > doesn't indicate to me the that it's a flux from atmosphere to water > body that's involved. It could equally well be a chemical flux between > two layers of the atmosphere, or is 'surface' explicitly defined as the > ocean/atmosphere interface? The definition of "surface" in standard names is "the surface called "surface" means the lower boundary of the atmosphere" which in this case does indeed mean the atmosphere interface with the sea surface, although it could also mean the interface with dry land, land-ice, sea-ice, etc., depending on the quantity being described. If we were talking about a layer interface within a medium then we would need to adopt some new terminology to describe it. > > (11) Rows 95-106 refer to the rate of change of depth integrated values > in the upper 100m of the water column, but the standard name gives no > indication that it's depth integrated (see above) or that the region of > interest is confined to the top 100m. I can appreciate the quandry > here that standard names shouldn't indicate spatial coverage, but might > it be possible to argue that the top 100m of the water column > approximates to a layer (euphotic zone?) of the ocean that should be > treated in the same way as layers of the atmosphere? As in point (9), the use of the term "content" and the units of mol m-2 s-1 indicate that the quantities are vertical integrals. In practice, variables containing these quantities would also need to have vertical coordinate bounds to specify the limits of integration and this fact can be indicated in the definitions of the names. Thanks very much for taking the time to look through all these names and for posting your comments. I think that with a small number of adjustments these names are generally in pretty good shape. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. From beate.geyer at gkss.de Fri Mar 26 01:19:09 2010 From: beate.geyer at gkss.de (beate.geyer at gkss.de) Date: Fri, 26 Mar 2010 08:19:09 +0100 Subject: [CF-metadata] proposals for two new standard_names Message-ID: Dear Jonathan, Ingeborg Noehren and I'd like to propose 2 new standard_names: Sea_surface_wave_skewness Sea surface wave skewness of the directional energy distribution per frequency D() is obtained from second order and third order circular moments of D(). Unit: [1] Sea_surface_wave_kurtosis Sea surface wave kurtosis of the directional energy distribution per frequency D() is obtained from second order and fourth order circular moments of D(). Unit: [1] Since they are not very common, Ingeborg wrote an explanation: Best regards, Beate ==================================================== Dr. Beate Geyer Institut f?r K?stenforschung *** DEPARTMENT DISCLAIMER *** -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wave_directional_characteristics_V02.doc Type: application/octet-stream Size: 61440 bytes Desc: not available URL: From julien.demaria at acri-st.fr Fri Mar 26 05:38:03 2010 From: julien.demaria at acri-st.fr (Julien Demaria) Date: Fri, 26 Mar 2010 12:38:03 +0100 Subject: [CF-metadata] Units micro prefix "u" deprecated in udunits-2 Message-ID: <4BAC9C9B.4050802@acri-st.fr> Hi, I found the "u" micro prefix abbreviation in the current CF-1.4 documentation on units: http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#units but it seems this prefix is not available in the last udunits-2 (udunits-1 is now deprecated) and in udunits-2 they break backward compatibility because the "u" symbol is now used for a new unit "unified_atomic_mass_unit", see in http://www.unidata.ucar.edu/software/udunits/udunits-2/udunits2-accepted.xml http://www.unidata.ucar.edu/software/udunits/udunits-2/udunits2-prefixes.xml So what is the position of the CF community concerning this point, is the "u" micro prefix CF-1.4 compliant or not? Thanks in advance, Julien From ancl at pml.ac.uk Fri Mar 26 09:52:31 2010 From: ancl at pml.ac.uk (Andrew Clegg) Date: Fri, 26 Mar 2010 15:52:31 +0000 Subject: [CF-metadata] Units micro prefix "u" deprecated in udunits-2 In-Reply-To: <4BAC9C9B.4050802@acri-st.fr> References: <4BAC9C9B.4050802@acri-st.fr> Message-ID: <4BACD83F.9010900@pml.ac.uk> Hi Julien, I'm glad you brought this up. We had a discussion about this recently (look for any threads with 'udunits 1 or 2 for CF' in the title): http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2010/thread.html The best solution (in my opinion) was to use expanded names rather than shortened, so instead of using 'u' (which has been replaced by '?' in udunits2) you would use 'micro' (which is compatible with both). However it would be nice to get a consensus on this or another solution, and some text added to the conventions. Cheers, Andrew Clegg Julien Demaria wrote: > Hi, > > I found the "u" micro prefix abbreviation in the current CF-1.4 > documentation on units: > http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#units > > > but it seems this prefix is not available in the last udunits-2 > (udunits-1 is now deprecated) > > and in udunits-2 they break backward compatibility because the "u" > symbol is now used for a new unit "unified_atomic_mass_unit", see in > http://www.unidata.ucar.edu/software/udunits/udunits-2/udunits2-accepted.xml > > http://www.unidata.ucar.edu/software/udunits/udunits-2/udunits2-prefixes.xml > > > So what is the position of the CF community concerning this point, is > the "u" micro prefix CF-1.4 compliant or not? > > > Thanks in advance, > > Julien > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -------------------------------------------------------------------------------- Plymouth Marine Laboratory Registered Office: Prospect Place The Hoe Plymouth PL1 3DH Website: www.pml.ac.uk Registered Charity No. 1091222 PML is a company limited by guarantee registered in England & Wales company number 4178503 PML is a member of the Plymouth Marine Sciences Partnership Website: www.pmsp.org.uk -------------------------------------------------------------------------------- This e-mail, its content and any file attachments are confidential. If you have received this e-mail in error please do not copy, disclose it to any third party or use the contents or attachments in any way. Please notify the sender by replying to this e-mail or e-mail forinfo at pml.ac.uk and then delete the email without making any copies or using it in any other way. The content of this message may contain personal views which are not the views of Plymouth Marine Laboratory unless specifically stated. You are reminded that e-mail communications are not secure and may contain viruses. Plymouth Marine Laboratory accepts no liability for any loss or damage which may be caused by viruses. -------------------------------------------------------------------------------- From rkl at bodc.ac.uk Fri Mar 26 09:59:29 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Fri, 26 Mar 2010 15:59:29 +0000 Subject: [CF-metadata] CMIP5 ocean biogeochemistry standard names In-Reply-To: References: <40829B0E077C1145A6DE44D39B3830A90887C1EFD0@nerckwmb1.ad.nerc.ac.uk> Message-ID: <40829B0E077C1145A6DE44D39B3830A90887D1C5B2@nerckwmb1.ad.nerc.ac.uk> Thanks Alison, The one point I think you have possibly misunderstood is the one about 'miscellaneous'. It's not the word, so much as the possibility of the concept having meaning that changes with time that worries me. This can be addressed through the definition by a statement that 'miscellaneous means phytoplankton that are not diatoms, diazotrophs, calcareous phytoplankton or picophytoplankton'. I did briefly consider the phrase 'phytoplankton_not_diatom_diazotroph_calcareous_pico' in the standard name, but then thought better of it. Cheers, Roy. -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of alison.pamment at stfc.ac.uk Sent: 26 March 2010 14:35 To: cf-metadata at cgd.ucar.edu; John.Dunne at noaa.gov Cc: chris.d.jones at metoffice.gov.uk; pierre.friedlingstein at lsce.ipsl.fr; James.Orr at lsce.ipsl.fr; ernst.maier-reimer at zmaw.de; doutriaux1 at llnl.gov Subject: Re: [CF-metadata] CMIP5 ocean biogeochemistry standard names Dear Roy, > > Some (ended up quite a lot) comments. Any discussion of this lot could > well descend into chaos. Could I suggest that responses are made > separately to each of the 11 numbered comments so we end up with 11 > threads that individually stand some chance of closure. > If possible, I would prefer not to create a large number of separate threads as that can sometimes make it difficult to follow complete conversations when looking back through the mailing list archives. Names can be accepted as they are agreed which will allow them to be added to the standard name table, even if others are still under discussion. Regarding your specific comments, I have tried to address each one in turn. > > (1) I don't understand what the definition of picophytoplankton (carbon > concentration from the picophytoplankton (<2 um; < 5um) component > alone) means Does it mean cells between 2 and 5 um in size, in which > case it should be expressed as 2-5um, or does it mean something else? > I agree that this definition doesn't make sense as it stands - I'll check with John Dunne. > > (2) > 'mole_concentration_of_miscellaneous_phytoplankton_expressed_as_carbon_ > in_sea_water' is a very imprecise term that I think needs specifying > more precisely. Once the definition is tightened up finding a better > phrase for the Standard Name should be possible. Likewise for > 'mole_concentration_of_miscellaneous_zooplankton_expressed_as_carbon_in > _sea_water', ' > mass_concentration_of_miscellaneous_phytoplankton_expressed_as_chloroph > yll_in_sea_water', . > My understanding of "miscellaneous" is that it means all the other phytoplankton that are not mentioned in the names for specific categories such as diatoms, diazatrophs, picophytoplankton, etc. In that sense it is intended to allow a looser definition than some of the other names. I think that diatoms + diazotrophs + calcareous phytoplankton + picophytoplankton + miscellaneous phytoplankton = total phytoplankton. This information will certainly be included in the definitions of all the relevant names. However, if we can come up with a more meaningful collective noun than "miscellaneous" then I'd welcome suggestions. > > (3) 'mole_concenration_of_dissolved_iron_in_sea_water'. Besides the > typo (concentration), does this refer to iron in all oxidation states > (Fe2+/Fe3+) and chemical environments. If so, calling it 'total iron' > might be better. Thanks for pointing out the typo - I'll correct it. I think whenever the word "total" has come up in standard names proposals in the past that we have tried to avoid using it. Indeed, there are no standard names that use the term. I think "iron" essentially should be understood to mean "total iron" and if we want more specific names for Fe2+, etc, we should introduce terms such as "divalent iron" in the way that we have done for elemental and divalent mercury in the atmosphere. Having said all that, I think it would be helpful if John could clarify the definition. > > (4) There are a number of standard names for elemental concentrations > in the particulate phase where the long names are very familiar to me, > but the Standard Names seem counter-intuitive, such as ' > mole_concentration_of_particulate_organic_matter_expressed_as_nitrogen_ > in_sea_water' for the parameter commonly known as particulate organic > nitrogen or more usually PON. I guess what is bugging me is that the > standard name describes the primary quantity as the suspended > particulate material (SPM) concentration, whereas in fact the chemical > composition of the SPM is of at least equal importance. I think the main reason for arriving at this particular wording was to be consistent with existing standard names. We use particulate_organic_matter in quite a number of existing atmosphere names. The "expressed_as_species" construction and its position within the standard name was also something that we arrived at after lengthy discussion with the atmospheric chemists. I think that we should try, as far as is practicable, to keep the wording and construction of standard names consistent between the different components of the climate system. I don't think the order of the wording is intended to imply that the particulate state is more or less important than the name of the chemical species. > > (5) I have much deeper rooted problems with ' > tendency_of_mole_concentration_of_organic_carbon_in_sea_water_due_to_ne > t_primary_production' for primary production. In a nutshell, the > process of primary production involves the transition of primarily > inorganic carbon in the dissolved phase into organic carbon in the > particulate phase (in the form of plant cells). The standard name > gives no indication that the organic carbon quantity change is in the > particulate phase. At the very least I think we need > 'tendency_of_mole_concentration_of_particulate_organic_carbon_in_sea_wa > ter_due_to_net_primary_production', which with the existing syntax form > would in fact become ' > tendency_of_mole_concentration_of_particulate_organic_matter_expressed_ > as_carbon_in_sea_water_due_to_net_primary_production'. Ditto for new > production, biogenic iron production and biogenic silica production, > but this doesn't apply to calcite and aragonite which are be definition > part of the particulate phase being crystalline forma of calcium > carbonate. Also affects primary production by phytoplankton groups such > as diatoms (lines 53-57 of the spreadsheet). Thank you for clarifying the production process. Personally, I would be happy with the addition of the word "particulate", as you suggest. > > (6) I now see, > 'sinking_mole_flux_of_particulate_organic_carbon_in_sea_water', which > if for consistency with the POC standard name would need to be > 'sinking_mole_flux_of_ > particulate_organic_matter_expressed_as_carbon_in_sea_water'. > Personally, I much prefer 'particulate_organic_carbon'. I see your point. Having argued for consistency of naming conventions above, I would actually tend to favour sinking_mole_flux_of_particulate_organic_matter_expressed_as_carbon_in_s ea_water. > > (7) > 'tendency_of_mole_concentration_of_dissolved_iron_in_sea_water_due_to_s > cavenging_by_particles' should be ' > tendency_of_mole_concentration_of_dissolved_iron_in_sea_water_due_to_sc > avenging_by_inorganic_particles'. 'particles' could easily be taken to > include plankton. Similarly for ' > tendency_of_mole_concentration_of_dissolved_iron_in_sea_water_due_to_di > ssolution_from_particles'. That sounds fine to me. > > (8) When we come to integrated primary production the standard name > syntax becomes ' net_primary_mole_productivity_of_carbon' instead of > 'net_tendency_of_mole_concentration_of_particulate_organic_carbon_in_se > a_water_due_to_net_primary_production' (which in itself needs revising: > see above). I'm not sure how comfortable biogeochemists would be with > the use of 'net' to signify depth integration. 'net' tends to have > other meanings such as the result of competing processes like > photosynthesis and respiration in oxygen budgets. I would much prefer > 'depth_integrated'. I think "net" refers to the productivity (i.e. net productivity = gross productivity minus destruction) rather than to the vertical integration. The vertical integration is implied by the fact that the units of this quantity are mol m-2 s-1, rather than mol m-3 s-1 for 3-D tendencies. In fact, Jonathan's idea was to reserve the term "productivity" specifically to mean this type of vertically integrated quantity (as in the atmosphere names gross_primary_productivity_of_carbon and net_primary_productivity_of_carbon) and use "production" for the 3-D quantities. The definition of the name needs to make this clear. If we wanted to make the vertical integration part of the name itself the correct syntax would be integral_wrt_depth_of_tendency_of_mole_concentration_of_particulate_orga nic_carbon_in_sea_water_due_to_net_primary_production. Would that be better? > > (9) When we come to > 'tendency_of_ocean_mole_content_of_iron_due_to_biological_production', > there is no indication at all that the quantity is depth integrated. > Ditto for lines 75-78, 86, 95-106. The term "content" is well established in standard names to mean a vertically integrated quantity, for example, there are many "atmosphere_content" names with precisely this interpretation. This is really just a convention that has been adopted within CF but it is one that has been used pretty much from the inception of standard names, I believe. > > (10) 'surface_downward_mass_flux_of_carbon_dioxide_expressed_as_carbon' > doesn't indicate to me the that it's a flux from atmosphere to water > body that's involved. It could equally well be a chemical flux between > two layers of the atmosphere, or is 'surface' explicitly defined as the > ocean/atmosphere interface? The definition of "surface" in standard names is "the surface called "surface" means the lower boundary of the atmosphere" which in this case does indeed mean the atmosphere interface with the sea surface, although it could also mean the interface with dry land, land-ice, sea-ice, etc., depending on the quantity being described. If we were talking about a layer interface within a medium then we would need to adopt some new terminology to describe it. > > (11) Rows 95-106 refer to the rate of change of depth integrated values > in the upper 100m of the water column, but the standard name gives no > indication that it's depth integrated (see above) or that the region of > interest is confined to the top 100m. I can appreciate the quandry > here that standard names shouldn't indicate spatial coverage, but might > it be possible to argue that the top 100m of the water column > approximates to a layer (euphotic zone?) of the ocean that should be > treated in the same way as layers of the atmosphere? As in point (9), the use of the term "content" and the units of mol m-2 s-1 indicate that the quantities are vertical integrals. In practice, variables containing these quantities would also need to have vertical coordinate bounds to specify the limits of integration and this fact can be indicated in the definitions of the names. Thanks very much for taking the time to look through all these names and for posting your comments. I think that with a small number of adjustments these names are generally in pretty good shape. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From taylor13 at llnl.gov Fri Mar 26 10:32:17 2010 From: taylor13 at llnl.gov (Karl Taylor) Date: Fri, 26 Mar 2010 09:32:17 -0700 Subject: [CF-metadata] Units micro prefix "u" deprecated in udunits-2 In-Reply-To: <4BACD83F.9010900@pml.ac.uk> References: <4BAC9C9B.4050802@acri-st.fr> <4BACD83F.9010900@pml.ac.uk> Message-ID: <4BACE191.6070109@llnl.gov> Hi all, Should I use microatm instead of uatm for a pressure unit in the CMIP5 requested output list? Apparently this is the preferred unit for partial pressure of CO2 in seawater. Will the latest versions of udunits recognize it? thanks for any guidance, Karl On 26-Mar-10 8:52 AM, Andrew Clegg wrote: > Hi Julien, > > I'm glad you brought this up. We had a discussion about this recently > (look for any threads with 'udunits 1 or 2 for CF' in the title): > http://*mailman.cgd.ucar.edu/pipermail/cf-metadata/2010/thread.html > > The best solution (in my opinion) was to use expanded names rather > than shortened, so instead of using 'u' (which has been replaced by > '?' in udunits2) you would use 'micro' (which is compatible with > both). However it would be nice to get a consensus on this or another > solution, and some text added to the conventions. > > Cheers, > Andrew Clegg > > > Julien Demaria wrote: >> Hi, >> >> I found the "u" micro prefix abbreviation in the current CF-1.4 >> documentation on units: >> http://*cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#units >> >> >> but it seems this prefix is not available in the last udunits-2 >> (udunits-1 is now deprecated) >> >> and in udunits-2 they break backward compatibility because the "u" >> symbol is now used for a new unit "unified_atomic_mass_unit", see in >> http://*www.*unidata.ucar.edu/software/udunits/udunits-2/udunits2-accepted.xml >> >> http://*www.*unidata.ucar.edu/software/udunits/udunits-2/udunits2-prefixes.xml >> >> >> So what is the position of the CF community concerning this point, is >> the "u" micro prefix CF-1.4 compliant or not? >> >> >> Thanks in advance, >> >> Julien >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > -------------------------------------------------------------------------------- > > Plymouth Marine Laboratory > > Registered Office: > Prospect Place The Hoe > Plymouth PL1 3DH > > Website: www.*pml.ac.uk > Registered Charity No. 1091222 > PML is a company limited by guarantee > registered in England & Wales > company number 4178503 > > PML is a member of the Plymouth Marine Sciences Partnership > Website: www.*pmsp.org.uk > -------------------------------------------------------------------------------- > > This e-mail, its content and any file attachments are confidential. > > If you have received this e-mail in error please do not copy, disclose > it to any third party or use the contents or attachments in any way. > Please notify the sender by replying to this e-mail or e-mail > forinfo at pml.ac.uk and then delete the email without making any copies > or using it in any other way. > > The content of this message may contain personal views which are not > the views of Plymouth Marine Laboratory unless specifically stated. > > You are reminded that e-mail communications are not secure and may > contain viruses. Plymouth Marine Laboratory accepts no liability for > any loss or damage which may be caused by viruses. > -------------------------------------------------------------------------------- > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > From ancl at pml.ac.uk Fri Mar 26 10:52:15 2010 From: ancl at pml.ac.uk (Andrew Clegg) Date: Fri, 26 Mar 2010 16:52:15 +0000 Subject: [CF-metadata] Units micro prefix "u" deprecated in udunits-2 In-Reply-To: <4BACE191.6070109@llnl.gov> References: <4BAC9C9B.4050802@acri-st.fr> <4BACD83F.9010900@pml.ac.uk> <4BACE191.6070109@llnl.gov> Message-ID: <4BACE63F.5020906@pml.ac.uk> Hi Karl, udunits 1 and 2 both recognise 'microatm' as '0.101325 m???kg?s??'. You may be better off using 'microatmospheres', to be consistent between using abbreviations and full names. ('microatmospheres' is recognised by both udunits 1 & 2). Again, this is the sort of thing that it would be nice to get a consensus on. Cheers, Andrew Karl Taylor wrote: > Hi all, > > Should I use microatm instead of uatm for a pressure unit in the CMIP5 > requested output list? Apparently this is the preferred unit for > partial pressure of CO2 in seawater. > > Will the latest versions of udunits recognize it? > > thanks for any guidance, > Karl > > On 26-Mar-10 8:52 AM, Andrew Clegg wrote: >> Hi Julien, >> >> I'm glad you brought this up. We had a discussion about this recently >> (look for any threads with 'udunits 1 or 2 for CF' in the title): >> http://*mailman.cgd.ucar.edu/pipermail/cf-metadata/2010/thread.html >> >> The best solution (in my opinion) was to use expanded names rather >> than shortened, so instead of using 'u' (which has been replaced by >> '?' in udunits2) you would use 'micro' (which is compatible with >> both). However it would be nice to get a consensus on this or another >> solution, and some text added to the conventions. >> >> Cheers, >> Andrew Clegg >> >> >> Julien Demaria wrote: >>> Hi, >>> >>> I found the "u" micro prefix abbreviation in the current CF-1.4 >>> documentation on units: >>> http://*cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#units >>> >>> >>> but it seems this prefix is not available in the last udunits-2 >>> (udunits-1 is now deprecated) >>> >>> and in udunits-2 they break backward compatibility because the "u" >>> symbol is now used for a new unit "unified_atomic_mass_unit", see in >>> http://*www.*unidata.ucar.edu/software/udunits/udunits-2/udunits2-accepted.xml >>> >>> http://*www.*unidata.ucar.edu/software/udunits/udunits-2/udunits2-prefixes.xml >>> >>> >>> So what is the position of the CF community concerning this point, >>> is the "u" micro prefix CF-1.4 compliant or not? >>> >>> >>> Thanks in advance, >>> >>> Julien >>> >>> _______________________________________________ >>> CF-metadata mailing list >>> CF-metadata at cgd.ucar.edu >>> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> >> -------------------------------------------------------------------------------- >> >> Plymouth Marine Laboratory >> >> Registered Office: >> Prospect Place The Hoe >> Plymouth PL1 3DH >> >> Website: www.*pml.ac.uk >> Registered Charity No. 1091222 >> PML is a company limited by guarantee >> registered in England & Wales >> company number 4178503 >> >> PML is a member of the Plymouth Marine Sciences Partnership >> Website: www.*pmsp.org.uk >> -------------------------------------------------------------------------------- >> >> This e-mail, its content and any file attachments are confidential. >> >> If you have received this e-mail in error please do not copy, >> disclose it to any third party or use the contents or attachments in >> any way. Please notify the sender by replying to this e-mail or >> e-mail forinfo at pml.ac.uk and then delete the email without making any >> copies or using it in any other way. >> >> The content of this message may contain personal views which are not >> the views of Plymouth Marine Laboratory unless specifically stated. >> >> You are reminded that e-mail communications are not secure and may >> contain viruses. Plymouth Marine Laboratory accepts no liability for >> any loss or damage which may be caused by viruses. >> -------------------------------------------------------------------------------- >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> > -------------------------------------------------------------------------------- Plymouth Marine Laboratory Registered Office: Prospect Place The Hoe Plymouth PL1 3DH Website: www.pml.ac.uk Registered Charity No. 1091222 PML is a company limited by guarantee registered in England & Wales company number 4178503 PML is a member of the Plymouth Marine Sciences Partnership Website: www.pmsp.org.uk -------------------------------------------------------------------------------- This e-mail, its content and any file attachments are confidential. If you have received this e-mail in error please do not copy, disclose it to any third party or use the contents or attachments in any way. Please notify the sender by replying to this e-mail or e-mail forinfo at pml.ac.uk and then delete the email without making any copies or using it in any other way. The content of this message may contain personal views which are not the views of Plymouth Marine Laboratory unless specifically stated. You are reminded that e-mail communications are not secure and may contain viruses. Plymouth Marine Laboratory accepts no liability for any loss or damage which may be caused by viruses. -------------------------------------------------------------------------------- From steve at unidata.ucar.edu Fri Mar 26 10:53:09 2010 From: steve at unidata.ucar.edu (Steven Emmerson) Date: Fri, 26 Mar 2010 10:53:09 -0600 Subject: [CF-metadata] Units micro prefix "u" deprecated in udunits-2 In-Reply-To: <4BACD83F.9010900@pml.ac.uk> References: <4BAC9C9B.4050802@acri-st.fr> <4BACD83F.9010900@pml.ac.uk> Message-ID: <4BACE675.90504@unidata.ucar.edu> Hi, Just to let you know, I've added "u" to the UDUNITS-2 prefix database as a symbol for "micro" to make UDUNITS-2 more backward-compatible with UDUNITS (alias UDUNITS-1). This addition will be in the next release. It's still a good idea, however, to use unit names (which are case insensitive and unambiguous) rather than symbols (which are case sensitive and potentially ambiguous). Regards, Steve Emmerson On 3/26/2010 9:52 AM, Andrew Clegg wrote: > Hi Julien, > > I'm glad you brought this up. We had a discussion about this recently > (look for any threads with 'udunits 1 or 2 for CF' in the title): > http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2010/thread.html > > The best solution (in my opinion) was to use expanded names rather than > shortened, so instead of using 'u' (which has been replaced by '?' in > udunits2) you would use 'micro' (which is compatible with both). However > it would be nice to get a consensus on this or another solution, and > some text added to the conventions. > > Cheers, > Andrew Clegg > > > Julien Demaria wrote: >> Hi, >> >> I found the "u" micro prefix abbreviation in the current CF-1.4 >> documentation on units: >> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#units >> >> >> but it seems this prefix is not available in the last udunits-2 >> (udunits-1 is now deprecated) >> >> and in udunits-2 they break backward compatibility because the "u" >> symbol is now used for a new unit "unified_atomic_mass_unit", see in >> http://www.unidata.ucar.edu/software/udunits/udunits-2/udunits2-accepted.xml >> >> http://www.unidata.ucar.edu/software/udunits/udunits-2/udunits2-prefixes.xml >> >> >> So what is the position of the CF community concerning this point, is >> the "u" micro prefix CF-1.4 compliant or not? >> >> >> Thanks in advance, >> >> Julien >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > -------------------------------------------------------------------------------- > > Plymouth Marine Laboratory > > Registered Office: > Prospect Place The Hoe > Plymouth PL1 3DH > > Website: www.pml.ac.uk > Registered Charity No. 1091222 > PML is a company limited by guarantee > registered in England & Wales > company number 4178503 > > PML is a member of the Plymouth Marine Sciences Partnership > Website: www.pmsp.org.uk > -------------------------------------------------------------------------------- > > This e-mail, its content and any file attachments are confidential. > > If you have received this e-mail in error please do not copy, disclose > it to any third party or use the contents or attachments in any way. > Please notify the sender by replying to this e-mail or e-mail > forinfo at pml.ac.uk and then delete the email without making any copies or > using it in any other way. > > The content of this message may contain personal views which are not the > views of Plymouth Marine Laboratory unless specifically stated. > > You are reminded that e-mail communications are not secure and may > contain viruses. Plymouth Marine Laboratory accepts no liability for any > loss or damage which may be caused by viruses. > -------------------------------------------------------------------------------- > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From steve at unidata.ucar.edu Fri Mar 26 11:09:31 2010 From: steve at unidata.ucar.edu (Steven Emmerson) Date: Fri, 26 Mar 2010 11:09:31 -0600 Subject: [CF-metadata] Units micro prefix "u" deprecated in udunits-2 In-Reply-To: <4BACE191.6070109@llnl.gov> References: <4BAC9C9B.4050802@acri-st.fr> <4BACD83F.9010900@pml.ac.uk> <4BACE191.6070109@llnl.gov> Message-ID: <4BACEA4B.3060008@unidata.ucar.edu> Karl, As a scientist, you should use "pascal". I note that one microatmosphere is about one tenth of one pascal. "microatm" mixes a word (micro) with a symbol (atm). In general, this is not a good idea. The official guidelines from the NIST recommend against it, for example, and so do I (for whatever that's worth :-). If you must use atmospheres, then a better alternative would be "microatmosphere". Regardless, the UDUNITS-2 package does recognize "microatm" (ugly, deformed hybrid that it is :-). Regards, Steve Emmerson On 3/26/2010 10:32 AM, Karl Taylor wrote: > Hi all, > > Should I use microatm instead of uatm for a pressure unit in the CMIP5 > requested output list? Apparently this is the preferred unit for partial > pressure of CO2 in seawater. > > Will the latest versions of udunits recognize it? > > thanks for any guidance, > Karl > > On 26-Mar-10 8:52 AM, Andrew Clegg wrote: >> Hi Julien, >> >> I'm glad you brought this up. We had a discussion about this recently >> (look for any threads with 'udunits 1 or 2 for CF' in the title): >> http://*mailman.cgd.ucar.edu/pipermail/cf-metadata/2010/thread.html >> >> The best solution (in my opinion) was to use expanded names rather >> than shortened, so instead of using 'u' (which has been replaced by >> '?' in udunits2) you would use 'micro' (which is compatible with >> both). However it would be nice to get a consensus on this or another >> solution, and some text added to the conventions. >> >> Cheers, >> Andrew Clegg >> >> >> Julien Demaria wrote: >>> Hi, >>> >>> I found the "u" micro prefix abbreviation in the current CF-1.4 >>> documentation on units: >>> http://*cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#units >>> >>> >>> but it seems this prefix is not available in the last udunits-2 >>> (udunits-1 is now deprecated) >>> >>> and in udunits-2 they break backward compatibility because the "u" >>> symbol is now used for a new unit "unified_atomic_mass_unit", see in >>> http://*www.*unidata.ucar.edu/software/udunits/udunits-2/udunits2-accepted.xml >>> >>> http://*www.*unidata.ucar.edu/software/udunits/udunits-2/udunits2-prefixes.xml >>> >>> >>> So what is the position of the CF community concerning this point, is >>> the "u" micro prefix CF-1.4 compliant or not? >>> >>> >>> Thanks in advance, >>> >>> Julien >>> >>> _______________________________________________ >>> CF-metadata mailing list >>> CF-metadata at cgd.ucar.edu >>> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> >> -------------------------------------------------------------------------------- >> >> Plymouth Marine Laboratory >> >> Registered Office: >> Prospect Place The Hoe >> Plymouth PL1 3DH >> >> Website: www.*pml.ac.uk >> Registered Charity No. 1091222 >> PML is a company limited by guarantee >> registered in England & Wales >> company number 4178503 >> >> PML is a member of the Plymouth Marine Sciences Partnership >> Website: www.*pmsp.org.uk >> -------------------------------------------------------------------------------- >> >> This e-mail, its content and any file attachments are confidential. >> >> If you have received this e-mail in error please do not copy, disclose >> it to any third party or use the contents or attachments in any way. >> Please notify the sender by replying to this e-mail or e-mail >> forinfo at pml.ac.uk and then delete the email without making any copies >> or using it in any other way. >> >> The content of this message may contain personal views which are not >> the views of Plymouth Marine Laboratory unless specifically stated. >> >> You are reminded that e-mail communications are not secure and may >> contain viruses. Plymouth Marine Laboratory accepts no liability for >> any loss or damage which may be caused by viruses. >> -------------------------------------------------------------------------------- >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From toyoda at gfd-dennou.org Fri Mar 26 18:49:11 2010 From: toyoda at gfd-dennou.org (Eizi TOYODA) Date: Sat, 27 Mar 2010 09:49:11 +0900 Subject: [CF-metadata] Units micro prefix "u" deprecated in udunits-2 In-Reply-To: <4BACD83F.9010900@pml.ac.uk> References: <4BAC9C9B.4050802@acri-st.fr> <4BACD83F.9010900@pml.ac.uk> Message-ID: <1b3c57e41003261749l2ca7d3b1lf87bc30587787e70@mail.gmail.com> Hi all, Nobody here is trying to discourage the use of micro sign. What character encoding are you going to use? Micro sign (http://www.fileformat.info/info/unicode/char/00b5/index.htm) is single byte 0xB5 in Latin-1 (aka ISO-8859-1) but becomes double-byte 0xC2 0xB5 in UTF-8. There is also confusing Greek small letter mu (http://www.fileformat.info/info/unicode/char/03bc/index.htm) which is 0xCE 0xBC. In short this letter is bad for computer processing if we don't have mechanism to specify character encoding. UDUNITS 2 API has "encoding" argument, and users can choose either ASCII, Latin-1, or UTF-8. Accordingly "udunits2" command has options -A -L and -U. It is enough for library that users have control and responsibility. But CF is a standard of metadata that is exchanged among people to avoid confusion. The CF community can choose many ways. I'd like to see views on the community: (1) Create a global attribute to specify character encoding (like XML) I believe this won't work. (2) Declare that CF uses UTF-8 Probably many people simply ignore that and put single 0xB5 as micro sign. (3) Recommends only US-ASCII letters in "units" attribute Very conservative, but that is consistent with allowing only English in standardized attributes. (4) Do nothing I have to warn programmers to anticipate any byte pattern above. That would work if only micro sign is an extension to ASCII. Best Regards, -- Eiji (aka Eizi) TOYODA Japan Meteorological Agency / WMO/CBS/IPET-MDI On Sat, Mar 27, 2010 at 00:52, Andrew Clegg wrote: > Hi Julien, > > I'm glad you brought this up. We had a discussion about this recently (look > for any threads with 'udunits 1 or 2 for CF' in the title): > ? http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2010/thread.html > > The best solution (in my opinion) was to use expanded names rather than > shortened, so instead of using 'u' (which has been replaced by '?' in > udunits2) you would use 'micro' (which is compatible with both). However it > would be nice to get a consensus on this or another solution, and some text > added to the conventions. > > Cheers, > Andrew Clegg > > > Julien Demaria wrote: >> >> Hi, >> >> I found the "u" micro prefix abbreviation in the current CF-1.4 >> documentation on units: >> >> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#units >> >> but it seems this prefix is not available in the last udunits-2 (udunits-1 >> is now deprecated) >> >> and in udunits-2 they break backward compatibility because the "u" symbol >> is now used for a new unit "unified_atomic_mass_unit", see in >> >> http://www.unidata.ucar.edu/software/udunits/udunits-2/udunits2-accepted.xml >> >> http://www.unidata.ucar.edu/software/udunits/udunits-2/udunits2-prefixes.xml >> >> So what is the position of the CF community concerning this point, is the >> "u" micro prefix CF-1.4 compliant or not? >> >> >> Thanks in advance, >> >> Julien >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > -------------------------------------------------------------------------------- > Plymouth Marine Laboratory > > Registered Office: > Prospect Place The Hoe > Plymouth ?PL1 3DH > > Website: www.pml.ac.uk > Registered Charity No. 1091222 > PML is a company limited by guarantee > registered in England & Wales > company number 4178503 > > PML is a member of the Plymouth Marine Sciences Partnership > Website: www.pmsp.org.uk > -------------------------------------------------------------------------------- > This e-mail, its content and any file attachments are confidential. > > If you have received this e-mail in error please do not copy, disclose it to > any third party or use the contents or attachments in any way. Please notify > the sender by replying to this e-mail or e-mail forinfo at pml.ac.uk and then > delete the email without making any copies or using it in any other way. > > The content of this message may contain personal views which are not the > views of Plymouth Marine Laboratory unless specifically stated. > > You are reminded that e-mail communications are not secure and may contain > viruses. Plymouth Marine Laboratory accepts no liability for any loss or > damage which may be caused by viruses. > -------------------------------------------------------------------------------- > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > From rkl at bodc.ac.uk Sat Mar 27 03:07:22 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Sat, 27 Mar 2010 09:07:22 +0000 Subject: [CF-metadata] Units micro prefix "u" deprecated in udunits-2 In-Reply-To: <1b3c57e41003261749l2ca7d3b1lf87bc30587787e70@mail.gmail.com> References: <4BAC9C9B.4050802@acri-st.fr> <4BACD83F.9010900@pml.ac.uk>, <1b3c57e41003261749l2ca7d3b1lf87bc30587787e70@mail.gmail.com> Message-ID: <40829B0E077C1145A6DE44D39B3830A90886AB7315@nerckwmb1.ad.nerc.ac.uk> Dear All, A further watch-point is that a some character mappings convert the micro sign to 'm' which has caused us some embarrassing errors in the past when interpreted as 'milli'. As Eizi so comprehensively points out, we either need to either ensure that character encodings are either explicitly stated and rigorously managed by applications or stick to the abbreviation 'u' for micro. Our current policy is the latter. Cheers, Roy. ________________________________________ From: cf-metadata-bounces at cgd.ucar.edu [cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Eizi TOYODA [toyoda at gfd-dennou.org] Sent: 27 March 2010 00:49 To: Andrew Clegg Cc: cf-metadata at cgd.ucar.edu; Julien Demaria Subject: Re: [CF-metadata] Units micro prefix "u" deprecated in udunits-2 Hi all, Nobody here is trying to discourage the use of micro sign. What character encoding are you going to use? Micro sign (http://www.fileformat.info/info/unicode/char/00b5/index.htm) is single byte 0xB5 in Latin-1 (aka ISO-8859-1) but becomes double-byte 0xC2 0xB5 in UTF-8. There is also confusing Greek small letter mu (http://www.fileformat.info/info/unicode/char/03bc/index.htm) which is 0xCE 0xBC. In short this letter is bad for computer processing if we don't have mechanism to specify character encoding. UDUNITS 2 API has "encoding" argument, and users can choose either ASCII, Latin-1, or UTF-8. Accordingly "udunits2" command has options -A -L and -U. It is enough for library that users have control and responsibility. But CF is a standard of metadata that is exchanged among people to avoid confusion. The CF community can choose many ways. I'd like to see views on the community: (1) Create a global attribute to specify character encoding (like XML) I believe this won't work. (2) Declare that CF uses UTF-8 Probably many people simply ignore that and put single 0xB5 as micro sign. (3) Recommends only US-ASCII letters in "units" attribute Very conservative, but that is consistent with allowing only English in standardized attributes. (4) Do nothing I have to warn programmers to anticipate any byte pattern above. That would work if only micro sign is an extension to ASCII. Best Regards, -- Eiji (aka Eizi) TOYODA Japan Meteorological Agency / WMO/CBS/IPET-MDI On Sat, Mar 27, 2010 at 00:52, Andrew Clegg wrote: > Hi Julien, > > I'm glad you brought this up. We had a discussion about this recently (look > for any threads with 'udunits 1 or 2 for CF' in the title): > http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2010/thread.html > > The best solution (in my opinion) was to use expanded names rather than > shortened, so instead of using 'u' (which has been replaced by '?' in > udunits2) you would use 'micro' (which is compatible with both). However it > would be nice to get a consensus on this or another solution, and some text > added to the conventions. > > Cheers, > Andrew Clegg > > > Julien Demaria wrote: >> >> Hi, >> >> I found the "u" micro prefix abbreviation in the current CF-1.4 >> documentation on units: >> >> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#units >> >> but it seems this prefix is not available in the last udunits-2 (udunits-1 >> is now deprecated) >> >> and in udunits-2 they break backward compatibility because the "u" symbol >> is now used for a new unit "unified_atomic_mass_unit", see in >> >> http://www.unidata.ucar.edu/software/udunits/udunits-2/udunits2-accepted.xml >> >> http://www.unidata.ucar.edu/software/udunits/udunits-2/udunits2-prefixes.xml >> >> So what is the position of the CF community concerning this point, is the >> "u" micro prefix CF-1.4 compliant or not? >> >> >> Thanks in advance, >> >> Julien >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > -------------------------------------------------------------------------------- > Plymouth Marine Laboratory > > Registered Office: > Prospect Place The Hoe > Plymouth PL1 3DH > > Website: www.pml.ac.uk > Registered Charity No. 1091222 > PML is a company limited by guarantee > registered in England & Wales > company number 4178503 > > PML is a member of the Plymouth Marine Sciences Partnership > Website: www.pmsp.org.uk > -------------------------------------------------------------------------------- > This e-mail, its content and any file attachments are confidential. > > If you have received this e-mail in error please do not copy, disclose it to > any third party or use the contents or attachments in any way. Please notify > the sender by replying to this e-mail or e-mail forinfo at pml.ac.uk and then > delete the email without making any copies or using it in any other way. > > The content of this message may contain personal views which are not the > views of Plymouth Marine Laboratory unless specifically stated. > > You are reminded that e-mail communications are not secure and may contain > viruses. Plymouth Marine Laboratory accepts no liability for any loss or > damage which may be caused by viruses. > -------------------------------------------------------------------------------- > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From caron at unidata.ucar.edu Sat Mar 27 08:40:20 2010 From: caron at unidata.ucar.edu (john caron) Date: Sat, 27 Mar 2010 08:40:20 -0600 Subject: [CF-metadata] Units micro prefix "u" deprecated in udunits-2 In-Reply-To: <1b3c57e41003261749l2ca7d3b1lf87bc30587787e70@mail.gmail.com> References: <4BAC9C9B.4050802@acri-st.fr> <4BACD83F.9010900@pml.ac.uk> <1b3c57e41003261749l2ca7d3b1lf87bc30587787e70@mail.gmail.com> Message-ID: <4BAE18D4.8080409@unidata.ucar.edu> Eizi TOYODA wrote: > Hi all, > > Nobody here is trying to discourage the use of micro sign. What > character encoding are you going to use? > > Micro sign (http://www.fileformat.info/info/unicode/char/00b5/index.htm) > is single byte 0xB5 in Latin-1 (aka ISO-8859-1) but becomes > double-byte 0xC2 0xB5 in UTF-8. There is also confusing Greek small > letter mu (http://www.fileformat.info/info/unicode/char/03bc/index.htm) > which is 0xCE 0xBC. In short this letter is bad for computer > processing if we don't have mechanism to specify character encoding. > > UDUNITS 2 API has "encoding" argument, and users can choose either > ASCII, Latin-1, or UTF-8. Accordingly "udunits2" command has options > -A -L and -U. It is enough for library that users have control and > responsibility. But CF is a standard of metadata that is exchanged > among people to avoid confusion. > > The CF community can choose many ways. I'd like to see views on the community: > > (1) Create a global attribute to specify character encoding (like XML) > I believe this won't work. > (2) Declare that CF uses UTF-8 > Probably many people simply ignore that and put single 0xB5 as micro sign. > (3) Recommends only US-ASCII letters in "units" attribute > Very conservative, but that is consistent with allowing only > English in standardized attributes. > (4) Do nothing > I have to warn programmers to anticipate any byte pattern above. > That would work if only micro sign is an extension to ASCII. > > Best Regards, > Strings stored in netCDF (eg variable names, attributes, String data in netCDF-4) are interpreted as UTF-8, and theres no standard way to indicate a different encoding. CF could add such a mechanism, but unless they do, by default "CF uses UTF-8". It would probably be worth speaking to this explicitly in the CF doc; I would advocate sticking with UTF-8. Requiring US-ASCII for attributes that CF defines is reasonable also. As always, there's a tension between CF creating "best practices" for new file writers vs trying to define conformance (and staying backwards compatible). I think spelling out the unit should be best practice, but keeping a "backwards compatible" version of udunits-2 seems necessary. From John.Dunne at noaa.gov Fri Mar 26 11:45:00 2010 From: John.Dunne at noaa.gov (John.Dunne at noaa.gov) Date: Fri, 26 Mar 2010 13:45:00 -0400 Subject: [CF-metadata] CMIP5 ocean biogeochemistry standard names Message-ID: <207d37820784b1.20784b1207d378@noaa.gov> Hi Alison, Here are the responses you requested... > > (1) I don't understand what the definition of picophytoplankton > (carbon > > concentration from the picophytoplankton (<2 um; < 5um) component > > alone) means Does it mean cells between 2 and 5 um in size, in > which> case it should be expressed as 2-5um, or does it mean > something else? > > > > I agree that this definition doesn't make sense as it stands - I'll > check with John Dunne. The wishy-washiness of this definition was intended to account for the fact that some groups make their distinction of smallest phytoplankton class at the <2um size, while others do it at the <5um size. I agree that it would be better to have a single cut off for clarity. Perhaps we should use the '2um' designation to be consistent with the traditional definition of 'picoplankton' (where nanoplankton is the 2-5 umclass), and leave the individual participants to determine whether they think their definition is consistent with this designation. > > (3) 'mole_concenration_of_dissolved_iron_in_sea_water'. Besides the > > typo (concentration), does this refer to iron in all oxidation > states> (Fe2+/Fe3+) and chemical environments. If so, calling it > 'total iron' > > might be better. > > Thanks for pointing out the typo - I'll correct it. I think whenever > the word "total" has come up in standard names proposals in the past > that we have tried to avoid using it. Indeed, there are no standard > names that use the term. I think "iron" essentially should be > understood to mean "total iron" and if we want more specific names for > Fe2+, etc, we should introduce terms such as "divalent iron" in the > waythat we have done for elemental and divalent mercury in the > atmosphere.Having said all that, I think it would be helpful if > John could clarify > the definition. In the geochemical literature, 'total' iron refers to the sum of iron associated with the particulate organic, particulate inorganic, dissolved organic and dissolved inorganic components (both Fe2+ and Fe3+). As we treat phytoplankton iron and particulate detrital iron separately from dissolved, 'total' does not equal 'dissolved'. As most, if not all, of the models do not distinguish between Fe2+ and Fe3+, I think we could simply add a note in the definition to the effect that 'dissolved' is intended to represent both Fe2+ and Fe3+. Cheers, John From j.m.gregory at reading.ac.uk Mon Mar 29 06:15:55 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Mon, 29 Mar 2010 13:15:55 +0100 Subject: [CF-metadata] Units micro prefix "u" deprecated in udunits-2 In-Reply-To: <4BAE18D4.8080409@unidata.ucar.edu> References: <4BAC9C9B.4050802@acri-st.fr> <4BACD83F.9010900@pml.ac.uk> <1b3c57e41003261749l2ca7d3b1lf87bc30587787e70@mail.gmail.com> <4BAE18D4.8080409@unidata.ucar.edu> Message-ID: <20100329121555.GB1694@met.reading.ac.uk> Dear all I agree with John that > spelling out the unit should be best practice but in real practice people will not always do this, and therefore we should provide CF versions of the udunits-2 xml files that define u as micro. We need to provide CF versions anyway to add some non-standard units, as we agreed to do but never did for the old udunits.dat. If we provide these files, can we then recommend that udunits-2 is used as the standard for units strings? Should we put a general convention in CF that text attributes can only contain US ASCII characters? I think that would avoid some problems. Cheers Jonathan From Upendra.Dadi at noaa.gov Mon Mar 29 06:56:42 2010 From: Upendra.Dadi at noaa.gov (Upendra Dadi) Date: Mon, 29 Mar 2010 08:56:42 -0400 Subject: [CF-metadata] CF convention for point data Message-ID: <4BB0A38A.2020207@noaa.gov> Hi, Can anyone in this group please point me to an authoritative website showing CF conventions for point data, specifically trajectories? I have been googling for the right web page, but came across couple of documents which have different attribute names for defining point features. For example, one document uses: :CF\:pointFeature = "trajectory"; and another uses :CF\:featureType = "trajectory"; to convey the same feature type. Which is correct? Upendra From russ at unidata.ucar.edu Mon Mar 29 10:43:25 2010 From: russ at unidata.ucar.edu (Russ Rew) Date: Mon, 29 Mar 2010 10:43:25 -0600 Subject: [CF-metadata] Units micro prefix "u" deprecated in udunits-2 In-Reply-To: Message from Jonathan Gregory of "Mon, 29 Mar 2010 13:15:55 BST." <20100329121555.GB1694@met.reading.ac.uk> Message-ID: <13249.1269881005@buddy.unidata.ucar.edu> Jonathan, > Should we put a general convention in CF that text attributes can only > contain US ASCII characters? I think that would avoid some problems. However it would also appear to place a new restriction on variable (and dimension) names that is not currently in CF, namely that only US ASCII characters could be used in such names. I don't believe the current CF has any such restriction on the characters used in variable names. This new restriction follows, because variable and dimension names are used in text attribute values for attributes such as coordinates, bounds, cell_measures, cell_methods, and formula_terms. Unidata added support for UTF-8 names some time ago to permit non-English variable, attribute, and dimension names in netCDF files. This was done is a way that did not break backward compatibility: http://www.unidata.ucar.edu/netcdf/docs/faq.html#fv22 That means there may already be CF-compliant data that makes use of non-ASCII characters in variable and dimension names and hence in text attributes such as coordinates. --Russ From John.Dunne at noaa.gov Tue Mar 30 06:55:56 2010 From: John.Dunne at noaa.gov (John.Dunne at noaa.gov) Date: Tue, 30 Mar 2010 08:55:56 -0400 Subject: [CF-metadata] HAMOCC variablen Message-ID: <20fabc420f5a0a.20f5a0a20fabc4@noaa.gov> Hi Corinne, Good question! Given that we're bound to be using different solubility fractions (mine are a climatology variable in space after Fan et al, 2006), I'd prefer the definition be renamed to "Surface downward net flux of dissolved iron", unless there are models that include subsurface dissolution of dust, in which case I would suggest we add another variable called "Surface downward net flux of total iron". Though I would not want to fill this field for my model in order to avoid confusion. Cheers, John ----- Original Message ----- From: Corinne Le Quere Date: Tuesday, March 30, 2010 4:17 am Subject: Re: {Spam?} Re: HAMOCC variablen > Hi John, > > I'm forwarding you a question from Stephanie Legutke regarding on > the > CMIP5 variable definition. The "Surface downward net flux of iron", > does > that means soluble iron or total iron? can you please specify. Thanks. > > Best wishes, > Corinne > > On Tue, 30 Mar 2010, Stephanie Legutke wrote: > > > Hi Corinne, > > as far as I know you are in some sense involved in the specification > > of the list of marine bgc variables that is requested for the CMIP5 > > archive. > > There is a question regarding the iron flux into the ocean (see > below).> Are you the right person to be addressed? If not you > certainly know > > whom to ask. > > If you prefer the question to be formulated in English the best > would be > > to contact Katharina Six who wrote the mail below. > > best regards, Stephanie > > > > katharina six wrote: > >> Hallo Stephanie, > >> > >> Bei einer Variablen sind wir uns nicht sicher, was gewollt ist: > "Surface>> downward net flux of iron " > >> Der Eiseneintrag wird aus dem Staubeintrag berechnet, aber fuer die > >> Biologie ist es wesentlich, welcher Form das Eisens vorliegt. Im > >> allgemeinen nehmen die Modelle an, > >> dass nur zwischen 1-10 % des eingetragenen Eisens biologisch > genutzt>> werden kann. Fuer die Vergleichbarkeit des Outputs ist es > also wichtig , > >> ob angegeben werden > >> soll, wieviel Gesamteisen oder wieviel "bioavailable iron" > eingetragen>> wird. Falls du dazu naehere Informationen bekommen > kannst, lass es mich > >> wissen. > >> Gruss Tinka > >> > >> Stephanie Legutke schrieb: > >>> Hallo Tinka, > >>> es gibt eine neue liste der verlangten variablen vom PCMDI > >>> mit einigen neuen bgc variablen. > > > > ___________________________________________ > ........................................... > > Corinne Le Quere > Professor, School of Environmental Sciences > University of East Anglia > Norwich NR4 7TJ, UK > Tel: +44 1603 592840 > > c.lequere at uea.ac.uk > http://lgmacweb.env.uea.ac.uk/lequere/ > > Also at: The British Antarctic Survey > High Cross, Madingley Road > Cambridge CB3 0ET, UK > Tel: +44 1223 221258 > ........................................... > ___________________________________________ > > -------------------------------------------------------------------- > ------ > IMPORTANT NOTICE - This email is intended for the named recipient > only. It > may contain privileged and confidential information. If you are not > the > intended recipient, notify the sender immediately and destroy this > email. > You must not copy, distribute or take action in reliance upon it. > Whilst > all efforts are made to safeguard emails, The School of > Environmental > Sciences cannot guarantee that attachments are virus free or > compatible > with your systems and does not accept liability in respect of > viruses or > computer problems experienced. > -------------------------------------------------------------------- > ------ > > From alison.pamment at stfc.ac.uk Thu Apr 1 06:27:41 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Thu, 1 Apr 2010 13:27:41 +0100 Subject: [CF-metadata] CMIP5 ocean biogeochemistry standard names In-Reply-To: <40829B0E077C1145A6DE44D39B3830A90887D1C5B2@nerckwmb1.ad.nerc.ac.uk> References: <40829B0E077C1145A6DE44D39B3830A90887C1EFD0@nerckwmb1.ad.nerc.ac.uk> <40829B0E077C1145A6DE44D39B3830A90887D1C5B2@nerckwmb1.ad.nerc.ac.uk> Message-ID: Dear Roy and John, Roy wrote: > The one point I think you have possibly misunderstood is the one about > 'miscellaneous'. It's not the word, so much as the possibility of the > concept having meaning that changes with time that worries me. This > can be addressed through the definition by a statement that > 'miscellaneous means phytoplankton that are not diatoms, diazotrophs, > calcareous phytoplankton or picophytoplankton'. I did briefly consider > the phrase 'phytoplankton_not_diatom_diazotroph_calcareous_pico' in the > standard name, but then thought better of it. > Yes, I see now. I agree that the definitions should contain a statement such as the one you suggest. Thanks for not suggesting the other version of the name :) John wrote: > > > (1) I don't understand what the definition of picophytoplankton > > (carbon > > > concentration from the picophytoplankton (<2 um; < 5um) component > > > alone) means Does it mean cells between 2 and 5 um in size, in > > which> case it should be expressed as 2-5um, or does it mean > > something else? > > > > > > > I agree that this definition doesn't make sense as it stands - I'll > > check with John Dunne. > > The wishy-washiness of this definition was intended to account for the > fact that some groups make their distinction of smallest phytoplankton > class at the <2um size, while others do it at the <5um size. I agree > that it would be better to have a single cut off for clarity. Perhaps > we should use the '2um' designation to be consistent with the > traditional definition of 'picoplankton' (where nanoplankton is the 2-5 > umclass), and leave the individual participants to determine whether > they think their definition is consistent with this designation. >From the CF point of view, adopting a single cut off of <2um for picophytoplankton would certainly be clear. However, will this cause problems for modelling groups with different cut off sizes? I.e. will it make intercomparison between models difficult? As an alternative, we could write the definitions to cope with the vagueness, for example: "Picophytoplankton are the smallest class of phytoplankton. The maximum size of picophytoplankton is in the range 2-5 um and may vary between models. A scalar coordinate variable should be used to specify the maximum size of picophytoplankton included in the data variable." This would then require the different modelling groups to specify the threshold they used, but would allow them all to write their data with the same standard name. (We could even give the coordinate variable a standard name such as 'plankton_size_threshold'). Would that be a suitable solution? Or do you still prefer to stick with the single cut off? John wrote: > > > (3) 'mole_concenration_of_dissolved_iron_in_sea_water'. Besides > the > > > typo (concentration), does this refer to iron in all oxidation > > states> (Fe2+/Fe3+) and chemical environments. If so, calling it > > 'total iron' > > > might be better. > > > > Thanks for pointing out the typo - I'll correct it. I think whenever > > the word "total" has come up in standard names proposals in the past > > that we have tried to avoid using it. Indeed, there are no standard > > names that use the term. I think "iron" essentially should be > > understood to mean "total iron" and if we want more specific names > for > > Fe2+, etc, we should introduce terms such as "divalent iron" in the > > waythat we have done for elemental and divalent mercury in the > > atmosphere.Having said all that, I think it would be helpful if > > John could clarify > > the definition. > > In the geochemical literature, 'total' iron refers to the sum of iron > associated with the particulate organic, particulate inorganic, > dissolved organic and dissolved inorganic components (both Fe2+ and > Fe3+). As we treat phytoplankton iron and particulate detrital iron > separately from dissolved, 'total' does not equal 'dissolved'. As > most, > if not all, of the models do not distinguish between Fe2+ and Fe3+, I > think we could simply add a note in the definition to the effect that > 'dissolved' is intended to represent both Fe2+ and Fe3+. Agreed. I'll add a sentence to the definitions. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. From alison.pamment at stfc.ac.uk Thu Apr 1 07:00:12 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Thu, 1 Apr 2010 14:00:12 +0100 Subject: [CF-metadata] HAMOCC variablen In-Reply-To: <20fabc420f5a0a.20f5a0a20fabc4@noaa.gov> References: <20fabc420f5a0a.20f5a0a20fabc4@noaa.gov> Message-ID: Dear John, According to the list of names attached to http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2010/003354.html, the quantity with long name "Surface Downward Net Flux of Iron" has the proposed standard name of tendency_of_ocean_mole_content_of_iron_due_to_deposition_and_runoff_and_ sediment_dissolution. We could certainly change this to tendency_of_ocean_mole_content_of_dissolved_iron_due_to_deposition_and_r unoff_and_sediment_dissolution (i.e. add "dissolved") if necessary. If you need both total and dissolved fluxes we could add separate standard names to the table, but the standard name for the total flux should then be the one that's already proposed (i.e., we would assume "iron" to mean "total iron" = organic/inorganic dissolved Fe2+/Fe3+ and organic/inorganic particulate Fe2+/Fe3+). Please could you let me know how you would like to proceed, i.e. whether we need one or two new standard names for the iron flux quantities. Best wishes, Alison > -----Original Message----- > From: John.Dunne at noaa.gov [mailto:John.Dunne at noaa.gov] > Sent: 30 March 2010 13:56 > To: Corinne Le Quere > Cc: cf-metadata at cgd.ucar.edu; Pamment, Alison (STFC,RAL,SSTD); > Stephanie Legutke; katharina six; Joachim Segschneider; Ernst Maier- > Reimer; Laurent Bopp > Subject: Re: HAMOCC variablen > > > Hi Corinne, > > Good question! Given that we're bound to be using different solubility > fractions (mine are a climatology variable in space after Fan et al, > 2006), I'd prefer the definition be renamed to "Surface downward net > flux of dissolved iron", unless there are models that include > subsurface > dissolution of dust, in which case I would suggest we add another > variable called "Surface downward net flux of total iron". Though I > would not want to fill this field for my model in order to avoid > confusion. > > Cheers, John > > ----- Original Message ----- > From: Corinne Le Quere > Date: Tuesday, March 30, 2010 4:17 am > Subject: Re: {Spam?} Re: HAMOCC variablen > > > Hi John, > > > > I'm forwarding you a question from Stephanie Legutke regarding on > > the > > CMIP5 variable definition. The "Surface downward net flux of iron", > > does > > that means soluble iron or total iron? can you please specify. > Thanks. > > > > Best wishes, > > Corinne > > > > On Tue, 30 Mar 2010, Stephanie Legutke wrote: > > > > > Hi Corinne, > > > as far as I know you are in some sense involved in the > specification > > > of the list of marine bgc variables that is requested for the CMIP5 > > > archive. > > > There is a question regarding the iron flux into the ocean (see > > below).> Are you the right person to be addressed? If not you > > certainly know > > > whom to ask. > > > If you prefer the question to be formulated in English the best > > would be > > > to contact Katharina Six who wrote the mail below. > > > best regards, Stephanie > > > > > > katharina six wrote: > > >> Hallo Stephanie, > > >> > > >> Bei einer Variablen sind wir uns nicht sicher, was gewollt ist: > > "Surface>> downward net flux of iron " > > >> Der Eiseneintrag wird aus dem Staubeintrag berechnet, aber fuer > die > > >> Biologie ist es wesentlich, welcher Form das Eisens vorliegt. Im > > >> allgemeinen nehmen die Modelle an, > > >> dass nur zwischen 1-10 % des eingetragenen Eisens biologisch > > genutzt>> werden kann. Fuer die Vergleichbarkeit des Outputs ist es > > also wichtig , > > >> ob angegeben werden > > >> soll, wieviel Gesamteisen oder wieviel "bioavailable iron" > > eingetragen>> wird. Falls du dazu naehere Informationen bekommen > > kannst, lass es mich > > >> wissen. > > >> Gruss Tinka > > >> > > >> Stephanie Legutke schrieb: > > >>> Hallo Tinka, > > >>> es gibt eine neue liste der verlangten variablen vom PCMDI > > >>> mit einigen neuen bgc variablen. > > > > > > > > ___________________________________________ > > ........................................... > > > > Corinne Le Quere > > Professor, School of Environmental Sciences > > University of East Anglia > > Norwich NR4 7TJ, UK > > Tel: +44 1603 592840 > > > > c.lequere at uea.ac.uk > > http://lgmacweb.env.uea.ac.uk/lequere/ > > > > Also at: The British Antarctic Survey > > High Cross, Madingley Road > > Cambridge CB3 0ET, UK > > Tel: +44 1223 221258 > > ........................................... > > ___________________________________________ > > > > -------------------------------------------------------------------- > > ------ > > IMPORTANT NOTICE - This email is intended for the named recipient > > only. It > > may contain privileged and confidential information. If you are not > > the > > intended recipient, notify the sender immediately and destroy this > > email. > > You must not copy, distribute or take action in reliance upon it. > > Whilst > > all efforts are made to safeguard emails, The School of > > Environmental > > Sciences cannot guarantee that attachments are virus free or > > compatible > > with your systems and does not accept liability in respect of > > viruses or > > computer problems experienced. > > -------------------------------------------------------------------- > > ------ > > > > ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. From alison.pamment at stfc.ac.uk Thu Apr 1 07:03:30 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Thu, 1 Apr 2010 14:03:30 +0100 Subject: [CF-metadata] new standard names for momentum fluxes In-Reply-To: References: <4B9FDA4E.9040109@ecmwf.int><20100317121835.GA19286@met.reading.ac.uk><4BA34E4C.1010205@ecmwf.int><20100319115122.GA10164@met.reading.ac.uk> Message-ID: Dear Tomas, There have been no further comments regarding the momentum flux names, hence these names are now accepted for inclusion in the CF standard name table. They will be added to the table at the next update. Best wishes, Alison > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > bounces at cgd.ucar.edu] On Behalf Of alison.pamment at stfc.ac.uk > Sent: 24 March 2010 11:35 > To: cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] new standard names for momentum fluxes > > Dear Tomas, > > Thank you for your proposals for two new momentum flux names. I think > these names look fine. If there are no further comments over the next > seven days then the names > > downward_eastward_momentum_flux_in_air_due_to_diffusion [Pa] > downward_northward_momentum_flux_in_air_due_to_diffusion [Pa] > > will be accepted for inclusion in the standard name table. > > Best wishes, > Alison > ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. From Steven.C.Hankin at noaa.gov Mon Apr 5 10:57:15 2010 From: Steven.C.Hankin at noaa.gov (Steve Hankin) Date: Mon, 05 Apr 2010 09:57:15 -0700 Subject: [CF-metadata] CF convention for point data In-Reply-To: <4BB0A38A.2020207@noaa.gov> References: <4BB0A38A.2020207@noaa.gov> Message-ID: <4BBA166B.2080806@noaa.gov> Hello Upendra, Section 5.5 of CF 1.4 (http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html) discusses the representation of trajectories. However this encoding is limited in that it requires a separate variable (in the netCDF sense) to represent each individual trajectory. Work is underway to develop representations suitable for large collections of trajectories in a single file. See https://cf-pcmdi.llnl.gov/trac/ticket/37 for discussions of that work. Similar considerations for collections of time series, vertical profiles, or scattered points found in this discussion. - Steve ==================================== Upendra Dadi wrote: > Hi, > Can anyone in this group please point me to an authoritative website > showing CF conventions for point data, specifically trajectories? I > have been googling for the right web page, but came across couple of > documents which have different attribute names for defining point > features. For example, one document uses: :CF\:pointFeature = > "trajectory"; and another uses :CF\:featureType = "trajectory"; to > convey the same feature type. Which is correct? > > Upendra > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From ngalbraith at whoi.edu Tue Apr 6 14:30:22 2010 From: ngalbraith at whoi.edu (Nan Galbraith) Date: Tue, 06 Apr 2010 16:30:22 -0400 Subject: [CF-metadata] ensemble dimension In-Reply-To: <4BA2B407.4060101@unidata.ucar.edu> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> <4B9FFBB4.1060003@unidata.ucar.edu> <20100317122447.GB19286@met.reading.ac.uk> <4BA2B407.4060101@unidata.ucar.edu> Message-ID: <4BBB99DE.7060505@whoi.edu> Hi All - The term realization is, apparently, *perfectly* clear to you modelers, but it conveys no information at all to me. Since it looks like it's going to be adopted, I hope you'll provide a really clear definition in the standard - something that even an oceanographer will understand. Thanks! - Nan John Caron wrote: > Jonathan Gregory wrote: >> Dear all >> >> "realization" is fine as a standard name. I had forgotten we had >> introduced it. >> I withdraw my suggestion of ensemble_member_identifier. >> >> Thus, the standard name (of realization) can be used to identify an >> ensemble >> axis. I think that providing an axis attribute as well could be >> helpful: with >> spatiotemporal axes we have both methods of identification, and it is >> possible >> there might be ensemble axes in which realization was a not a good >> choice of >> standard name. -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* From Steven.C.Hankin at noaa.gov Tue Apr 6 15:50:47 2010 From: Steven.C.Hankin at noaa.gov (Steve Hankin) Date: Tue, 06 Apr 2010 14:50:47 -0700 Subject: [CF-metadata] ensemble dimension In-Reply-To: <4BBB99DE.7060505@whoi.edu> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> <4B9FFBB4.1060003@unidata.ucar.edu> <20100317122447.GB19286@met.reading.ac.uk> <4BA2B407.4060101@unidata.ucar.edu> <4BBB99DE.7060505@whoi.edu> Message-ID: <4BBBACB7.7010204@noaa.gov> All, Nan's point deserves consideration. Well-chosen names should help the uninitiated to understand the concepts that CF is encoding. "Realization" is arguably the opposite sort of term; the sort of term that clicks as being sensible only _after_ one understands the range of concepts that can be encoded by CF. In the spirit of usability testing for user interfaces, the measure of quality should not be whether the UI (or terminology) seems sensible to the designers; it should be whether the UI leads the uninitiated user to proper understanding. Nan's comment speaks to that point. Doesn't "ensemble_member_identifier" seem to be a more self-evident term that would better enable a new-comer to grasp the contents of a CF ensemble dataset? Admittedly, a small point .... - Steve ======================================== Nan Galbraith wrote: > Hi All - > > The term realization is, apparently, *perfectly* clear to you > modelers, but it conveys no information at all to me. > > Since it looks like it's going to be adopted, I hope you'll provide > a really clear definition in the standard - something that even an > oceanographer will understand. > > Thanks! > > - Nan > > > John Caron wrote: >> Jonathan Gregory wrote: >>> Dear all >>> >>> "realization" is fine as a standard name. I had forgotten we had >>> introduced it. >>> I withdraw my suggestion of ensemble_member_identifier. >>> >>> Thus, the standard name (of realization) can be used to identify an >>> ensemble >>> axis. I think that providing an axis attribute as well could be >>> helpful: with >>> spatiotemporal axes we have both methods of identification, and it >>> is possible >>> there might be ensemble axes in which realization was a not a good >>> choice of >>> standard name. > -- Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov 7600 Sand Point Way NE, Seattle, WA 98115-0070 ph. (206) 526-6080, FAX (206) 526-6744 "The only thing necessary for the triumph of evil is for good men to do nothing." -- Edmund Burke -------------- next part -------------- An HTML attachment was scrubbed... URL: From taylor13 at llnl.gov Tue Apr 6 15:59:04 2010 From: taylor13 at llnl.gov (Karl Taylor) Date: Tue, 06 Apr 2010 14:59:04 -0700 Subject: [CF-metadata] ensemble dimension In-Reply-To: <4BBBACB7.7010204@noaa.gov> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> <4B9FFBB4.1060003@unidata.ucar.edu> <20100317122447.GB19286@met.reading.ac.uk> <4BA2B407.4060101@unidata.ucar.edu> <4BBB99DE.7060505@whoi.edu> <4BBBACB7.7010204@noaa.gov> Message-ID: <4BBBAEA8.4020302@llnl.gov> All, Another option might be "ensemble_realization". At least if you search the web you will find reasonable guidance (whereas this is likely not the case for "realization" alone). Karl On 06-Apr-10 2:50 PM, Steve Hankin wrote: > All, > > Nan's point deserves consideration. Well-chosen names should help the > uninitiated to understand the concepts that CF is encoding. > "Realization" is arguably the opposite sort of term; the sort of term > that clicks as being sensible only _after_ one understands the range > of concepts that can be encoded by CF. In the spirit of usability > testing for user interfaces, the measure of quality should not be > whether the UI (or terminology) seems sensible to the designers; it > should be whether the UI leads the uninitiated user to proper > understanding. Nan's comment speaks to that point. > > Doesn't "ensemble_member_identifier" seem to be a more self-evident > term that would better enable a new-comer to grasp the contents of a > CF ensemble dataset? Admittedly, a small point .... > > - Steve > > ======================================== > > Nan Galbraith wrote: >> Hi All - >> >> The term realization is, apparently, *perfectly* clear to you >> modelers, but it conveys no information at all to me. >> >> Since it looks like it's going to be adopted, I hope you'll provide >> a really clear definition in the standard - something that even an >> oceanographer will understand. >> >> Thanks! >> >> - Nan >> >> >> John Caron wrote: >>> Jonathan Gregory wrote: >>>> Dear all >>>> >>>> "realization" is fine as a standard name. I had forgotten we had >>>> introduced it. >>>> I withdraw my suggestion of ensemble_member_identifier. >>>> >>>> Thus, the standard name (of realization) can be used to identify an >>>> ensemble >>>> axis. I think that providing an axis attribute as well could be >>>> helpful: with >>>> spatiotemporal axes we have both methods of identification, and it >>>> is possible >>>> there might be ensemble axes in which realization was a not a good >>>> choice of >>>> standard name. >> > > -- > Steve Hankin, NOAA/PMEL --Steven.C.Hankin at noaa.gov > 7600 Sand Point Way NE, Seattle, WA 98115-0070 > ph. (206) 526-6080, FAX (206) 526-6744 > > "The only thing necessary for the triumph of evil is for good men > to do nothing." -- Edmund Burke > > > _______________________________________________ > 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: From j.m.gregory at reading.ac.uk Wed Apr 7 00:56:08 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Wed, 7 Apr 2010 07:56:08 +0100 Subject: [CF-metadata] ensemble dimension In-Reply-To: <4BBBAEA8.4020302@llnl.gov> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> <4B9FFBB4.1060003@unidata.ucar.edu> <20100317122447.GB19286@met.reading.ac.uk> <4BA2B407.4060101@unidata.ucar.edu> <4BBB99DE.7060505@whoi.edu> <4BBBACB7.7010204@noaa.gov> <4BBBAEA8.4020302@llnl.gov> Message-ID: <20100407065607.GA12480@met.reading.ac.uk> Dear all I agree that "ensemble_member_identifier" is likely to be more self-explanatory than "realization". I withdrew my suggestion of the former because I'd forgotten, when I made it, that we already had the latter as a standard name. If ensemble_member_identifier is preferred, we could change the standard name in the usual way, using an alias. I am less happy with "ensemble_realization", although I think it is a term which is used, because it sounds vague to me. It could mean an instance of an entire ensemble, rather than a member of an ensemble. Best wishes Jonathan From jamie.kettleborough at metoffice.gov.uk Wed Apr 7 05:14:06 2010 From: jamie.kettleborough at metoffice.gov.uk (Kettleborough, Jamie) Date: Wed, 7 Apr 2010 12:14:06 +0100 Subject: [CF-metadata] ensemble dimension In-Reply-To: <4BBB99DE.7060505@whoi.edu> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> <4B9FFBB4.1060003@unidata.ucar.edu> <20100317122447.GB19286@met.reading.ac.uk><4BA2B407.4060101@unidata.ucar.edu> <4BBB99DE.7060505@whoi.edu> Message-ID: Hello Nan, one of the aims of using 'realization' was to make this term less tied to models, though it looks as though this isn't working. So a review is a good idea. I'm still not sure about tying this to the term 'ensemble' though. I think there are a set of problems around representing errors that are closely related, and so treating them in a similar way in CF **may** make CF meta-data easier to use for both human users (fewer concepts to remember and possible concept transfer from one context to another) and applications (through reuse of code in slightly different contexts). The underlying class of problem is something like: some things have errors in them, and these errors have complex distributions (not represented by an analytic function, possibly with covariances between variables), how do we represent these complex error distributions in CF? So this could include model based forecasts, forecasts based on statistical fits to empirical data, and also observations of quantities (though I'm less clear about the subtleties of obs - and we didn't think about these in the original proposal). If the error characteristics are sufficiently complex that simple summary statistics (like standard deviations) are not enough then a one way of representing these errors is through a set of sample points, and their weights - from these you can generate moments of the error distribution, or cumulative distribution functions, or probability distribution functions. The term 'realization' was introduced to try and capture the dimension of the 'sample points'. In the context of a model based forecast each ensemble member provides a 'sample point'. The original proposal we considered using the term 'sample' rather than 'realization', but thought this was too overloaded a term e.g. grab sample. We also proposed the standard name 'realization_weight' to represent the other part of the error characterisation, but I'm not sure it ever made it through the process. Though I guess things aren't quite as clear cut as I've tried to make them - especially in the context of observations. In some cases the sample dimension is actually just one of the other dimensions - like time or space (or both). I don't have enough experience of observations to say how widely used other ways of generate error characteristics are (e.g. through computer simulation of an instrument), and if there are how you would represent the errors and the terms you'd use to talk about them. Another possible complication is that not all uses of ensembles result directly in a quantitative error estimate of some quantity - so loading the 'ensemble' dimension towards this use may not be helpful. So I think it comes down to something like: 1. what is the main use of ensembles? 2. is the main use of ensembles a special case of a broader problem? if yes... 3. does CF gain by accommodating the broader problem? if yes... 4. what are the most useful terms for talking about the broader problem. 5. if the initial answers to any of the above are wrong, does CF have the mechanisms to recover - how well would users and applications cope with 'aliased' dimensions? Sorry, there are no concrete proposals in this mail, but I figured a bit of context behind why we didn't use a standard name based on the term 'ensemble' might be useful. Jamie > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu > [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Nan Galbraith > Sent: 06 April 2010 21:30 > To: John Caron > Cc: cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] ensemble dimension > > Hi All - > > The term realization is, apparently, *perfectly* clear to you > modelers, but it conveys no information at all to me. > > Since it looks like it's going to be adopted, I hope you'll > provide a really clear definition in the standard - something > that even an oceanographer will understand. > > Thanks! > > - Nan > > > John Caron wrote: > > Jonathan Gregory wrote: > >> Dear all > >> > >> "realization" is fine as a standard name. I had forgotten we had > >> introduced it. > >> I withdraw my suggestion of ensemble_member_identifier. > >> > >> Thus, the standard name (of realization) can be used to > identify an > >> ensemble axis. I think that providing an axis attribute as > well could > >> be > >> helpful: with > >> spatiotemporal axes we have both methods of > identification, and it is > >> possible there might be ensemble axes in which realization > was a not > >> a good choice of standard name. > > -- > ******************************************************* > * Nan Galbraith (508) 289-2444 * > * Upper Ocean Processes Group Mail Stop 29 * > * Woods Hole Oceanographic Institution * > * Woods Hole, MA 02543 * > ******************************************************* > > > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > From taylor13 at llnl.gov Wed Apr 7 09:53:27 2010 From: taylor13 at llnl.gov (Karl Taylor) Date: Wed, 07 Apr 2010 08:53:27 -0700 Subject: [CF-metadata] ensemble dimension In-Reply-To: <20100407065607.GA12480@met.reading.ac.uk> References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> <4B9FFBB4.1060003@unidata.ucar.edu> <20100317122447.GB19286@met.reading.ac.uk> <4BA2B407.4060101@unidata.ucar.edu> <4BBB99DE.7060505@whoi.edu> <4BBBACB7.7010204@noaa.gov> <4BBBAEA8.4020302@llnl.gov> <20100407065607.GA12480@met.reading.ac.uk> Message-ID: <4BBCAA77.2020306@llnl.gov> Dear all, Jonathan points out that the term "ensemble_realization" is ambiguous. I agree and withdraw the suggestion. Karl On 06-Apr-10 11:56 PM, Jonathan Gregory wrote: > Dear all > > I agree that "ensemble_member_identifier" is likely to be more self-explanatory > than "realization". I withdrew my suggestion of the former because I'd > forgotten, when I made it, that we already had the latter as a standard name. > If ensemble_member_identifier is preferred, we could change the standard name > in the usual way, using an alias. > > I am less happy with "ensemble_realization", although I think it is a term > which is used, because it sounds vague to me. It could mean an instance of > an entire ensemble, rather than a member of an ensemble. > > Best wishes > > Jonathan > > From support-udunits at unidata.ucar.edu Wed Apr 7 11:24:34 2010 From: support-udunits at unidata.ucar.edu (Unidata UDUNITS Support) Date: Wed, 07 Apr 2010 11:24:34 -0600 Subject: [CF-metadata] [UDUNITS #UVU-592022]: information Message-ID: Christina, > Sorry for the delay in this new question...(I was ill!). I hope you're feeling better. > If you use udunits2 you can find what follows: > > udunits2: Using default XML database > You have: 1mg > You want: kg > 1 mg = 1e-06 kg > x/kg = 1e-06*(x/mg) > You have: milligrams > You want: kg > 1 milligrams = 1e-06 kg > x/kg = 1e-06*(x/milligrams) > You have: microkg > You want: kg > 1 microkg = 1e-06 kg > x/kg = 1e-06*(x/microkg) > > In a previous email you suggested me not to use "microkg" and to use > "milligram"......but....."mg" is wildspread used as it is shorter than > "milligram" and it seems to me that is recognized by udunits as > well..... > > Why should we prefer "milligram"? You should favour "milligram" over "mg" because the former is understood by more people than the latter. Yes, the UDUNITS package understands both, but netCDF files are also printed-out sometimes by utilities like ncdump(1). Also, people sometimes use odd abbreviations (e.g. "mcg" for microgram), so using the fully-spelled-out name is a good habit to adopt to prevent you from using an abbreviation that is common in your field but not so common elsewhere. > thanks in advanced > > Sorry for all these doubts, but we are trying to harmonize Ocean color > data produced by 5 different production centers.Nobody would want to > change anything......they are currently use "mg m-3" for chloropyll > and wnat to know why the should now use "milligram". If they're already using "mg m-3", then they don't have to change: those symbols are ISO-compliant. I recommend that future usage favour fully-spelled-out names, however, when possible. > BUT WE NEED TO BE COMPLIANT WITH CF SPECIFICATION...AND SO....WE MUST > BE SURE TO USE A UNITS RECOGNIZE BY UDUNIT..... The UDUNITS package understands all ISO unit specifications. As far as I know, the CF members have not yet decided to recommend fully-spelled-out units. That's something that I recommend. > LET ME KNOW! > > SINCERERLY > > CRISTINA > > ------------------------------------------------------------------- > Cristina Tronconi > Istituto di Scienze dell'Atmosfera e del Clima - sezione di Roma > Consiglio Nazionale delle Ricerche > Via Fosso del Cavaliere 100 > 00133 Roma, Italy > Tel: +39 06 49934342 > cell: '39 349 1242954 > Fax: +39 06 20660291 > e-mail: cristina.tronconi at artov.isac.cnr.it Regards, Steve Emmerson Ticket Details =================== Ticket ID: UVU-592022 Department: Support UDUNITS Priority: Normal Status: Closed From mcginnis at ucar.edu Fri Apr 9 18:40:49 2010 From: mcginnis at ucar.edu (Seth McGinnis) Date: Fri, 09 Apr 2010 18:40:49 -0600 Subject: [CF-metadata] ensemble dimension In-Reply-To: References: <4B9A9435.4060100@unidata.ucar.edu> <20100316172209.GC13911@met.reading.ac.uk> <4B9FFBB4.1060003@unidata.ucar.edu> <20100317122447.GB19286@met.reading.ac.uk> <4BA2B407.4060101@unidata.ucar.edu> <4BBB99DE.7060505@whoi.edu> Message-ID: Thinking about the ensemble dimension as capturing error is very different from how I would be likely to use it working with regional climate models. When I see the term 'ensemble', I think of running a model multiple times and then grouping the outputs from those runs together. If the runs differ only in their seed states, then one could interpret the ensemble as representing a particular kind of error (which it sounds like is the case with forecast ensembles), but it's easy to imagine wanting to group together runs that have the same spatio-temporal coverage and resolution but different boundary conditions or model physics, or even ones that come from different models, in which cases 'error' may not really be well-defined or meaningful. Certainly one could calculate the agreement or disagreement associated with whatever it is the ensemble members differ by, but I think that's secondary to the bundling together of a group of identically-structured data sets that have some kind of familial relationship. So I think 'ensemble' is a special case of "I did the same thing a bunch of times, and these outputs all go together" and that it would be more helpful to support that broader usage than to load the definition toward error. Cheers, --Seth **** Seth McGinnis NARCCAP Data Manager Associate Scientist IMAGe / NCAR **** On Wed, 7 Apr 2010 12:14:06 +0100 "Kettleborough, Jamie" wrote: >Hello Nan, > >one of the aims of using 'realization' was to make this term less tied >to models, though it looks as though this isn't working. So a review is >a good idea. I'm still not sure about tying this to the term 'ensemble' >though. > >I think there are a set of problems around representing errors that are >closely related, and so treating them in a similar way in CF **may** >make CF meta-data easier to use for both human users (fewer concepts to >remember and possible concept transfer from one context to another) and >applications (through reuse of code in slightly different contexts). > >The underlying class of problem is something like: some things have >errors in them, and these errors have complex distributions (not >represented by an analytic function, possibly with covariances between >variables), how do we represent these complex error distributions in CF? >So this could include model based forecasts, forecasts based on >statistical fits to empirical data, and also observations of quantities >(though I'm less clear about the subtleties of obs - and we didn't think >about these in the original proposal). If the error characteristics are >sufficiently complex that simple summary statistics (like standard >deviations) are not enough then a one way of representing these errors >is through a set of sample points, and their weights - from these you >can generate moments of the error distribution, or cumulative >distribution functions, or probability distribution functions. > >The term 'realization' was introduced to try and capture the dimension >of the 'sample points'. In the context of a model based forecast each >ensemble member provides a 'sample point'. The original proposal we >considered using the term 'sample' rather than 'realization', but >thought this was too overloaded a term e.g. grab sample. We also >proposed the standard name 'realization_weight' to represent the other >part of the error characterisation, but I'm not sure it ever made it >through the process. > >Though I guess things aren't quite as clear cut as I've tried to make >them - especially in the context of observations. In some cases the >sample dimension is actually just one of the other dimensions - like >time or space (or both). I don't have enough experience of observations >to say how widely used other ways of generate error characteristics are >(e.g. through computer simulation of an instrument), and if there are >how you would represent the errors and the terms you'd use to talk about >them. > >Another possible complication is that not all uses of ensembles result >directly in a quantitative error estimate of some quantity - so loading >the 'ensemble' dimension towards this use may not be helpful. > >So I think it comes down to something like: > >1. what is the main use of ensembles? >2. is the main use of ensembles a special case of a broader problem? if >yes... >3. does CF gain by accommodating the broader problem? if yes... >4. what are the most useful terms for talking about the broader >problem. >5. if the initial answers to any of the above are wrong, does CF have >the mechanisms to recover - how well would users and applications cope >with 'aliased' dimensions? > >Sorry, there are no concrete proposals in this mail, but I figured a bit >of context behind why we didn't use a standard name based on the term >'ensemble' might be useful. > >Jamie > >> -----Original Message----- >> From: cf-metadata-bounces at cgd.ucar.edu >> [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Nan Galbraith >> Sent: 06 April 2010 21:30 >> To: John Caron >> Cc: cf-metadata at cgd.ucar.edu >> Subject: Re: [CF-metadata] ensemble dimension >> >> Hi All - >> >> The term realization is, apparently, *perfectly* clear to you >> modelers, but it conveys no information at all to me. >> >> Since it looks like it's going to be adopted, I hope you'll >> provide a really clear definition in the standard - something >> that even an oceanographer will understand. >> >> Thanks! >> >> - Nan >> >> >> John Caron wrote: >> > Jonathan Gregory wrote: >> >> Dear all >> >> >> >> "realization" is fine as a standard name. I had forgotten we had >> >> introduced it. >> >> I withdraw my suggestion of ensemble_member_identifier. >> >> >> >> Thus, the standard name (of realization) can be used to >> identify an >> >> ensemble axis. I think that providing an axis attribute as >> well could >> >> be >> >> helpful: with >> >> spatiotemporal axes we have both methods of >> identification, and it is >> >> possible there might be ensemble axes in which realization >> was a not >> >> a good choice of standard name. >> >> -- >> ******************************************************* >> * Nan Galbraith (508) 289-2444 * >> * Upper Ocean Processes Group Mail Stop 29 * >> * Woods Hole Oceanographic Institution * >> * Woods Hole, MA 02543 * >> ******************************************************* >> >> >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >_______________________________________________ >CF-metadata mailing list >CF-metadata at cgd.ucar.edu >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From caron at unidata.ucar.edu Mon Apr 12 15:25:13 2010 From: caron at unidata.ucar.edu (John Caron) Date: Mon, 12 Apr 2010 15:25:13 -0600 Subject: [CF-metadata] longitude wrapping creates non-monotonic coordinate values Message-ID: <4BC38FB9.4000002@unidata.ucar.edu> I have a file with a longitude coordinate variable whose values stay withhin [0,360] and therefore are not monotonic: double lon(lon=359); :units = "degrees_east"; :long_name = "longitude coordinate"; :standard_name = "longitude"; lon = {258.0, 259.0, 260.0, 261.0, 262.0, 263.0, 264.0, 265.0, 266.0, 267.0, 268.0, 269.0, 270.0, 271.0, 272.0, 273.0, 274.0, 275.0, 276.0, 277.0, 278.0, 279.0, 280.0, 281.0, 282.0, 283.0, 284.0, 285.0, 286.0, 287.0, 288.0, 289.0, 290.0, 291.0, 292.0, 293.0, 294.0, 295.0, 296.0, 297.0, 298.0, 299.0, 300.0, 301.0, 302.0, 303.0, 304.0, 305.0, 306.0, 307.0, 308.0, 309.0, 310.0, 311.0, 312.0, 313.0, 314.0, 315.0, 316.0, 317.0, 318.0, 319.0, 320.0, 321.0, 322.0, 323.0, 324.0, 325.0, 326.0, 327.0, 328.0, 329.0, 330.0, 331.0, 332.0, 333.0, 334.0, 335.0, 336.0, 337.0, 338.0, 339.0, 340.0, 341.0, 342.0, 343.0, 344.0, 345.0, 346.0, 347.0, 348.0, 349.0, 350.0, 351.0, 352.0, 353.0, 354.0, 355.0, 356.0, 357.0, 358.0, 359.0, 0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0, 11.0, 12.0, 13.0, 14.0, 15.0, 16.0, 17.0, 18.0, 19.0, 20.0, 21.0, 22.0, 23.0, 24.0, 25.0, 26.0, 27.0, 28.0, 29.0, 30.0, 31.0, 32.0, 33.0, 34.0, 35.0, 36.0, 37.0, 38.0, 39.0, 40.0, 41.0, 42.0, 43.0, 44.0, 45.0, 46.0, 47.0, 48.0, 49.0, 50.0, 51.0, 52.0, 53.0, 54.0, 55.0, 56.0, 57.0, 58.0, 59.0, 60.0, 61.0, 62.0, 63.0, 64.0, 65.0, 66.0, 67.0, 68.0, 69.0, 70.0, 71.0, 72.0, 73.0, 74.0, 75.0, 76.0, 77.0, 78.0, 79.0, 80.0, 81.0, 82.0, 83.0, 84.0, 85.0, 86.0, 87.0, 88.0, 89.0, 90.0, 91.0, 92.0, 93.0, 94.0, 95.0, 96.0, 97.0, 98.0, 99.0, 100.0, 101.0, 102.0, 103.0, 104.0, 105.0, 106.0, 107.0, 108.0, 109.0, 110.0, 111.0, 112.0, 113.0, 114.0, 115.0, 116.0, 117.0, 118.0, 119.0, 120.0, 121.0, 122.0, 123.0, 124.0, 125.0, 126.0, 127.0, 128.0, 129.0, 130.0, 131.0, 132.0, 133.0, 134.0, 135.0, 136.0, 137.0, 138.0, 139.0, 140.0, 141.0, 142.0, 143.0, 144.0, 145.0, 146.0, 147.0, 148.0, 149.0, 150.0, 151.0, 152.0, 153.0, 154.0, 155.0, 156.0, 157.0, 158.0, 159.0, 160.0, 161.0, 162.0, 163.0, 164.0, 165.0, 166.0, 167.0, 168.0, 169.0, 170.0, 171.0, 172.0, 173.0, 174.0, 175.0, 176.0, 177.0, 178.0, 179.0, 180.0, 181.0, 182.0, 183.0, 184.0, 185.0, 186.0, 187.0, 188.0, 189.0, 190.0, 191.0, 192.0, 193.0, 194.0, 195.0, 196.0, 197.0, 198.0, 199.0, 200.0, 201.0, 202.0, 203.0, 204.0, 205.0, 206.0, 207.0, 208.0, 209.0, 210.0, 211.0, 212.0, 213.0, 214.0, 215.0, 216.0, 217.0, 218.0, 219.0, 220.0, 221.0, 222.0, 223.0, 224.0, 225.0, 226.0, 227.0, 228.0, 229.0, 230.0, 231.0, 232.0, 233.0, 234.0, 235.0, 236.0, 237.0, 238.0, 239.0, 240.0, 241.0, 242.0, 243.0, 244.0, 245.0, 246.0, 247.0, 248.0, 249.0, 250.0, 251.0, 252.0, 253.0, 254.0, 255.0, 256.0} my code considers this a defective file, and im considering workarounds. I have in the past recomended that the writer change the file to go from 258 to 616 (or -102 to 256). should CF consider this file valid or not? Its probably a common enough problem. From Steven.C.Hankin at noaa.gov Mon Apr 12 16:28:24 2010 From: Steven.C.Hankin at noaa.gov (Steve Hankin) Date: Mon, 12 Apr 2010 15:28:24 -0700 Subject: [CF-metadata] longitude wrapping creates non-monotonic coordinate values In-Reply-To: <4BC38FB9.4000002@unidata.ucar.edu> References: <4BC38FB9.4000002@unidata.ucar.edu> Message-ID: <4BC39E88.6040205@noaa.gov> Yes indeed -- the question arises in one form or another often. My take would be exactly what you have suggested -- that t_o define a contiguous grid one should define a monotonic longitude coordinate encoding._ The 360 degree discontinuity (branch point) should be placed at the boundary of the grid. The CF 1.4 document states that coordinate axes must be monotonic. I would interpret that intention to mean "numerically monotonic". I don't believe there is any loss of generality in following this approach. - Steve ---------------------------------------- John Caron wrote: > I have a file with a longitude coordinate variable whose values stay > withhin [0,360] and therefore are not monotonic: > > double lon(lon=359); > :units = "degrees_east"; > :long_name = "longitude coordinate"; > :standard_name = "longitude"; > > > lon = > {258.0, 259.0, 260.0, 261.0, 262.0, 263.0, 264.0, 265.0, 266.0, > 267.0, 268.0, 269.0, 270.0, 271.0, 272.0, 273.0, 274.0, 275.0, 276.0, > 277.0, 278.0, 279.0, 280.0, 281.0, 282.0, 283.0, 284.0, 285.0, 286.0, > 287.0, 288.0, 289.0, 290.0, 291.0, 292.0, 293.0, 294.0, 295.0, 296.0, > 297.0, 298.0, 299.0, 300.0, 301.0, 302.0, 303.0, 304.0, 305.0, 306.0, > 307.0, 308.0, 309.0, 310.0, 311.0, 312.0, 313.0, 314.0, 315.0, 316.0, > 317.0, 318.0, 319.0, 320.0, 321.0, 322.0, 323.0, 324.0, 325.0, 326.0, > 327.0, 328.0, 329.0, 330.0, 331.0, 332.0, 333.0, 334.0, 335.0, 336.0, > 337.0, 338.0, 339.0, 340.0, 341.0, 342.0, 343.0, 344.0, 345.0, 346.0, > 347.0, 348.0, 349.0, 350.0, 351.0, 352.0, 353.0, 354.0, 355.0, 356.0, > 357.0, 358.0, 359.0, 0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, > 10.0, 11.0, 12.0, 13.0, 14.0, 15.0, 16.0, 17.0, 18.0, 19.0, 20.0, > 21.0, 22.0, 23.0, 24.0, 25.0, 26.0, 27.0, 28.0, 29.0, 30.0, 31.0, > 32.0, 33.0, 34.0, 35.0, 36.0, 37.0, 38.0, 39.0, 40.0, 41.0, 42.0, > 43.0, 44.0, 45.0, 46.0, 47.0, 48.0, 49.0, 50.0, 51.0, 52.0, 53.0, > 54.0, 55.0, 56.0, 57.0, 58.0, 59.0, 60.0, 61.0, 62.0, 63.0, 64.0, > 65.0, 66.0, 67.0, 68.0, 69.0, 70.0, 71.0, 72.0, 73.0, 74.0, 75.0, > 76.0, 77.0, 78.0, 79.0, 80.0, 81.0, 82.0, 83.0, 84.0, 85.0, 86.0, > 87.0, 88.0, 89.0, 90.0, 91.0, 92.0, 93.0, 94.0, 95.0, 96.0, 97.0, > 98.0, 99.0, 100.0, 101.0, 102.0, 103.0, 104.0, 105.0, 106.0, 107.0, > 108.0, 109.0, 110.0, 111.0, 112.0, 113.0, 114.0, 115.0, 116.0, 117.0, > 118.0, 119.0, 120.0, 121.0, 122.0, 123.0, 124.0, 125.0, 126.0, 127.0, > 128.0, 129.0, 130.0, 131.0, 132.0, 133.0, 134.0, 135.0, 136.0, 137.0, > 138.0, 139.0, 140.0, 141.0, 142.0, 143.0, 144.0, 145.0, 146.0, 147.0, > 148.0, 149.0, 150.0, 151.0, 152.0, 153.0, 154.0, 155.0, 156.0, 157.0, > 158.0, 159.0, 160.0, 161.0, 162.0, 163.0, 164.0, 165.0, 166.0, 167.0, > 168.0, 169.0, 170.0, 171.0, 172.0, 173.0, 174.0, 175.0, 176.0, 177.0, > 178.0, 179.0, 180.0, 181.0, 182.0, 183.0, 184.0, 185.0, 186.0, 187.0, > 188.0, 189.0, 190.0, 191.0, 192.0, 193.0, 194.0, 195.0, 196.0, 197.0, > 198.0, 199.0, 200.0, 201.0, 202.0, 203.0, 204.0, 205.0, 206.0, 207.0, > 208.0, 209.0, 210.0, 211.0, 212.0, 213.0, 214.0, 215.0, 216.0, 217.0, > 218.0, 219.0, 220.0, 221.0, 222.0, 223.0, 224.0, 225.0, 226.0, 227.0, > 228.0, 229.0, 230.0, 231.0, 232.0, 233.0, 234.0, 235.0, 236.0, 237.0, > 238.0, 239.0, 240.0, 241.0, 242.0, 243.0, 244.0, 245.0, 246.0, 247.0, > 248.0, 249.0, 250.0, 251.0, 252.0, 253.0, 254.0, 255.0, 256.0} > > my code considers this a defective file, and im considering > workarounds. I have in the past recomended that the writer change the > file to go from 258 to 616 (or -102 to 256). > > should CF consider this file valid or not? Its probably a common > enough problem. > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov 7600 Sand Point Way NE, Seattle, WA 98115-0070 ph. (206) 526-6080, FAX (206) 526-6744 "The only thing necessary for the triumph of evil is for good men to do nothing." -- Edmund Burke -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.m.gregory at reading.ac.uk Tue Apr 13 01:13:15 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 13 Apr 2010 08:13:15 +0100 Subject: [CF-metadata] longitude wrapping creates non-monotonic coordinate values In-Reply-To: <4BC38FB9.4000002@unidata.ucar.edu> References: <4BC38FB9.4000002@unidata.ucar.edu> Message-ID: <20100413071315.GD6618@met.reading.ac.uk> Dear John I agree with you and Steve, and that is the approach I too have taken in analysis software. "Monotonic" means the numbers must uniformly increase or decrease, and some of them will have to be wrapped round to achieve this. The CF checker should give an error for the file as it stands, because monotonicity is a requirement in section 5 of http://cf-pcmdi.llnl.gov/conformance/requirements-and-recommendations/1.4/ Best wishes Jonathan From j.d.blower at reading.ac.uk Tue Apr 13 02:57:10 2010 From: j.d.blower at reading.ac.uk (Jonathan Blower) Date: Tue, 13 Apr 2010 09:57:10 +0100 Subject: [CF-metadata] longitude wrapping creates non-monotoniccoordinate values In-Reply-To: <20100413071315.GD6618@met.reading.ac.uk> References: <4BC38FB9.4000002@unidata.ucar.edu> <20100413071315.GD6618@met.reading.ac.uk> Message-ID: <7CD7F00F17085C4EBB045A35177C85FDD9835F@VIME-VS1.rdg-home.ad.rdg.ac.uk> Yes, I agree too that axis values should be monotonic. I wonder if this requirement can/should be extended to two-dimensional coordinate variables? (http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.ht ml#id2984605) It seems much more difficult in this case because in certain convoluted cases, values that are next to each other in grid space are not necessarily close in real space. Jon -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory Sent: 13 April 2010 08:13 To: John Caron Cc: cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] longitude wrapping creates non-monotoniccoordinate values Dear John I agree with you and Steve, and that is the approach I too have taken in analysis software. "Monotonic" means the numbers must uniformly increase or decrease, and some of them will have to be wrapped round to achieve this. The CF checker should give an error for the file as it stands, because monotonicity is a requirement in section 5 of http://cf-pcmdi.llnl.gov/conformance/requirements-and-recommendations/1. 4/ Best wishes Jonathan _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From caron at unidata.ucar.edu Tue Apr 13 07:54:53 2010 From: caron at unidata.ucar.edu (john caron) Date: Tue, 13 Apr 2010 07:54:53 -0600 Subject: [CF-metadata] longitude wrapping creates non-monotoniccoordinate values In-Reply-To: <7CD7F00F17085C4EBB045A35177C85FDD9835F@VIME-VS1.rdg-home.ad.rdg.ac.uk> References: <4BC38FB9.4000002@unidata.ucar.edu> <20100413071315.GD6618@met.reading.ac.uk> <7CD7F00F17085C4EBB045A35177C85FDD9835F@VIME-VS1.rdg-home.ad.rdg.ac.uk> Message-ID: <4BC477AD.1050200@unidata.ucar.edu> Hi Jon: Ive thought a lot about what the generalization of monotonicity to nD coordinates must be. It turns out the monotonic 1d coordinate values are necessary and sufficient to make the coordinate function invertible. The condition we want on nD coordinates is that these are invertible as functions from index space to coordinate space. I havent been able to formulate a simple algebraic test for that, but i have a simple geometric one. If you draw a mesh connecting the coordinate values (eg a 2d curvilinear case), the lines of the mesh must not cross. I think in topology they call this a "conformal mapping", where you get to distort a rubber sheet (contianing the mesh) as much as you want, but cant tear or fold the sheet over on itself. i wrote this up some years ago, though my math is a bit limited: http://www.unidata.ucar.edu/staff/caron/papers/CoordMath.htm Jonathan Blower wrote: > Yes, I agree too that axis values should be monotonic. > > I wonder if this requirement can/should be extended to two-dimensional > coordinate variables? > (http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.ht > ml#id2984605) It seems much more difficult in this case because in > certain convoluted cases, values that are next to each other in grid > space are not necessarily close in real space. > > Jon > > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu > [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory > Sent: 13 April 2010 08:13 > To: John Caron > Cc: cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] longitude wrapping creates > non-monotoniccoordinate values > > Dear John > > I agree with you and Steve, and that is the approach I too have taken in > analysis software. "Monotonic" means the numbers must uniformly increase > or > decrease, and some of them will have to be wrapped round to achieve > this. > The CF checker should give an error for the file as it stands, because > monotonicity is a requirement in section 5 of > http://cf-pcmdi.llnl.gov/conformance/requirements-and-recommendations/1. > 4/ > > Best wishes > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > From John.Dunne at noaa.gov Thu Apr 15 07:05:08 2010 From: John.Dunne at noaa.gov (John.Dunne at noaa.gov) Date: Thu, 15 Apr 2010 09:05:08 -0400 Subject: [CF-metadata] FW: HAMOCC variablen Message-ID: <23f940e23fc528.23fc52823f940e@noaa.gov> Hi Karl and Alison, With reference to Karl's question about the appropriateness of the variable standard name for iron supply to the ocean, I was asked to supply my thoughts. The current variable in the 4/2 tables is: tendency_of_ocean_mole_content_of_iron_due_to_deposition_and_runoff_and_sediment_dissolution which, I think, works as a catch-all for all sources of available iron. Due to the late timing, I think we are now forced to leave it to the groups to contribute model-specific supply terms beyond this catchall. My only suggestion for an optional change would be to make the long names for nitrogen and iron, "Surface downward net flux of Nitrogen" and "Surface downward net flux of Iron" more consistent with their definitions (as was done for Carbon) and changed to "Flux of Nitrogen into Ocean by runoff, deposition and nitrogen fixation" and "Flux of Iron into Ocean by runoff, deposition, coasts and sediments" Cheers, John > -----Original Message----- > From: Karl Taylor [mailto:taylor13 at llnl.gov] > Sent: 02 April 2010 18:50 > To: John.Dunne at noaa.gov; Pamment, Alison (STFC,RAL,SSTD); Stephanie > Legutke; John.Dunne at noaa.gov > Cc: Corrine Le Quere; Ernst Maier-Reimer; Laurent Bopp; > joachim.segschneider at zmaw.de; James Orr > Subject: Re: [CF-metadata] HAMOCC variablen > > Dear all, > > [Here is some input from someone with a weak grasp of this area.] > This seems very confusing. It doesn't seem to me that it makes > sense to > > talk about surface flux of dissolved iron (except in rain drops I > suppose). We could have a downward surface flux of iron that might > (quickly, partially or completely) dissolve. If there is some > component > of the surface flux of iron that never dissolves (as perhaps is the > case > for the iron contained in dust particles), then there really is no > need > to keep track of that iron (i.e., it is effectively "inert"). [I > note, > however, we are requesting a 3-d field tentatively referred to as > tendency_of_mole_concentration_of_dissolved_inorganic_iron_in_sea_water_ > due_to_biological_processes, > which would indicate that there might be some flux of iron from the > atmosphere that doesn't dissolve immediately, but might later at > deeper > depths.] > > As noted above I don't think it makes sense to call it "flux of > dissolved iron", but would be o.k. with "flux of dissolvable iron", > but > this asks the model to know what iron will eventually dissolve, > which > seems impossible. But someone who knows more about this than I > should > weigh in. > > So first we need to decide what we want to ask for. Then we need > to > name it. > > One option might be to request > "tendency_of_mole_concentration_of_dissolved_inorganic_iron_in_sea_water > _due_to_surface_flux_of_iron" > (or something similar). > > What say you all? > > Best regards, > Karl > > On 30-Mar-10 5:55 AM, John.Dunne at noaa.gov wrote: > > Hi Corinne, > > > > Good question! Given that we're bound to be using different > solubility > > fractions (mine are a climatology variable in space after Fan et al, > > 2006), I'd prefer the definition be renamed to "Surface downward net > > flux of dissolved iron", unless there are models that include > subsurface > > dissolution of dust, in which case I would suggest we add another > > variable called "Surface downward net flux of total iron". > Though I > > would not want to fill this field for my model in order to avoid > confusion. > > > > Cheers, John > > > > ----- Original Message ----- > > From: Corinne Le Quere > > Date: Tuesday, March 30, 2010 4:17 am > > Subject: Re: {Spam?} Re: HAMOCC variablen > > > > > >> Hi John, > >> > >> I'm forwarding you a question from Stephanie Legutke regarding on > >> the > >> CMIP5 variable definition. The "Surface downward net flux of iron", > >> does > >> that means soluble iron or total iron? can you please specify. > Thanks. > >> > >> Best wishes, > >> Corinne > >> > >> On Tue, 30 Mar 2010, Stephanie Legutke wrote: > >> > >> > >>> Hi Corinne, > >>> as far as I know you are in some sense involved in the > specification>>> of the list of marine bgc variables that is > requested for the CMIP5 > >>> archive. > >>> There is a question regarding the iron flux into the ocean (see > >>> > >> below).> Are you the right person to be addressed? If not you > >> certainly know > >> > >>> whom to ask. > >>> If you prefer the question to be formulated in English the best > >>> > >> would be > >> > >>> to contact Katharina Six who wrote the mail below. > >>> best regards, Stephanie > >>> > >>> katharina six wrote: > >>> > >>>> Hallo Stephanie, > >>>> > >>>> Bei einer Variablen sind wir uns nicht sicher, was gewollt ist: > >>>> > >> "Surface>> downward net flux of iron " > >> > >>>> Der Eiseneintrag wird aus dem Staubeintrag berechnet, aber > fuer die > >>>> Biologie ist es wesentlich, welcher Form das Eisens vorliegt. Im > >>>> allgemeinen nehmen die Modelle an, > >>>> dass nur zwischen 1-10 % des eingetragenen Eisens biologisch > >>>> > >> genutzt>> werden kann. Fuer die Vergleichbarkeit des Outputs > ist es > >> also wichtig , > >> > >>>> ob angegeben werden > >>>> soll, wieviel Gesamteisen oder wieviel "bioavailable iron" > >>>> > >> eingetragen>> wird. Falls du dazu naehere Informationen bekommen > >> kannst, lass es mich > >> > >>>> wissen. > >>>> Gruss Tinka > >>>> > >>>> Stephanie Legutke schrieb: > >>>> > >>>>> Hallo Tinka, > >>>>> es gibt eine neue liste der verlangten variablen vom PCMDI > >>>>> mit einigen neuen bgc variablen. > >>>>> From ngalbraith at whoi.edu Thu Apr 15 14:00:42 2010 From: ngalbraith at whoi.edu (Nan Galbraith) Date: Thu, 15 Apr 2010 16:00:42 -0400 Subject: [CF-metadata] Standard name table version dates? Message-ID: <4BC7706A.6090800@whoi.edu> Hi all - There is an appendix in the conventions document that describes changes to the standard, and gives the dates of those changes, at cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html Is there likewise a document somewhere that either gives the dates of the different versions of the standard name table, or describes what's been added to each of the revisions? This was asked by a group that's looking at terms they've adopted for variables that were not in the table back in 2004, which might now be represented in the CF names. I have no idea what version would have been current back then, and it does seem like a useful bit of metadata to have on the site. Thanks - Nan -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* From rkl at bodc.ac.uk Fri Apr 16 01:03:22 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Fri, 16 Apr 2010 08:03:22 +0100 Subject: [CF-metadata] Standard name table version dates? In-Reply-To: <4BC7706A.6090800@whoi.edu> References: <4BC7706A.6090800@whoi.edu> Message-ID: <40829B0E077C1145A6DE44D39B3830A90887FDEB7F@nerckwmb1.ad.nerc.ac.uk> Hi Nan, The following are the past version dates I have for the version changes since I started following CF Standard Names closely, which was in September 2006 when version 2 was current: VERSION TO_CHAR(VRS_DATE,'YYYY-MM-DD') 3 "2007-02-20" 4 "2007-03-13" 5 "2007-05-15" 6 "2007-07-17" 7 "2007-11-21" 8 "2008-04-15" 10 "2008-10-21" 11 "2008-11-11" 12 "2009-07-07" For versions between 2 and 13 I also have change audit trails stored and a tool that I can use to produce difference reports between any two specified versions. Cheers, Roy. -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Nan Galbraith Sent: 15 April 2010 21:01 To: cf-metadata at cgd.ucar.edu Subject: [CF-metadata] Standard name table version dates? Hi all - There is an appendix in the conventions document that describes changes to the standard, and gives the dates of those changes, at cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html Is there likewise a document somewhere that either gives the dates of the different versions of the standard name table, or describes what's been added to each of the revisions? This was asked by a group that's looking at terms they've adopted for variables that were not in the table back in 2004, which might now be represented in the CF names. I have no idea what version would have been current back then, and it does seem like a useful bit of metadata to have on the site. Thanks - Nan -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From j.m.gregory at reading.ac.uk Fri Apr 16 07:01:44 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 16 Apr 2010 14:01:44 +0100 Subject: [CF-metadata] proposal for two new standard names Message-ID: <20100416130144.GA25996@met.reading.ac.uk> Dear all I'd like to propose the following two standard names, which conform to existing patterns: stratiform_cloud_liquid_water_content_of_atmosphere_layer (kg m-2) square_of_height (m2) Thanks Jonathan From ngalbraith at whoi.edu Fri Apr 16 10:19:02 2010 From: ngalbraith at whoi.edu (Nan Galbraith) Date: Fri, 16 Apr 2010 12:19:02 -0400 Subject: [CF-metadata] Standard name table version dates? In-Reply-To: <40829B0E077C1145A6DE44D39B3830A90887FDEB7F@nerckwmb1.ad.nerc.ac.uk> References: <4BC7706A.6090800@whoi.edu> <40829B0E077C1145A6DE44D39B3830A90887FDEB7F@nerckwmb1.ad.nerc.ac.uk> Message-ID: <4BC88DF6.5060208@whoi.edu> Thanks, Roy - This is just what we were looking for. Cheers - Nan > Hi Nan, > > The following are the past version dates I have for the version changes since I started following CF Standard Names closely, which was in September 2006 when version 2 was current: > > VERSION TO_CHAR(VRS_DATE,'YYYY-MM-DD') > > 3 "2007-02-20" > 4 "2007-03-13" > 5 "2007-05-15" > 6 "2007-07-17" > 7 "2007-11-21" > 8 "2008-04-15" > 10 "2008-10-21" > 11 "2008-11-11" > 12 "2009-07-07" > > For versions between 2 and 13 I also have change audit trails stored and a tool that I can use to produce difference reports between any two specified versions. > > Cheers, Roy. > > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Nan Galbraith > Sent: 15 April 2010 21:01 > To: cf-metadata at cgd.ucar.edu > Subject: [CF-metadata] Standard name table version dates? > > Hi all - > > There is an appendix in the conventions document that describes > changes to the standard, and gives the dates of those changes, at > cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html > > Is there likewise a document somewhere that either gives the dates of > the different versions of the standard name table, or describes what's > been added to each of the revisions? > > This was asked by a group that's looking at terms they've adopted > for variables that were not in the table back in 2004, which might > now be represented in the CF names. I have no idea what version > would have been current back then, and it does seem like a useful > bit of metadata to have on the site. > > Thanks - > Nan > > -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* From jgraybeal at ucsd.edu Thu Apr 15 09:51:05 2010 From: jgraybeal at ucsd.edu (John Graybeal) Date: Thu, 15 Apr 2010 08:51:05 -0700 Subject: [CF-metadata] CF branding Message-ID: All, especially CF governance folks (separate list?), MMI was writing up a little story on the netCDF-CF standardization activities, and we thought we'd put the CF logo on it to help identify it. Lo and behold, we can't seem to find an explicit CF logo! Except for the header at the site -- perhaps you are using that, or we could use it anyway? If not, then I admire the technical focus of the effort, but I'm still thinking a logo would be a helpful thing for those of us that want to reference or cite CF in a visual way. Let me know if that could be provided. John ---------------- John Graybeal phone: 858-534-2162 System Development Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org From j.d.blower at reading.ac.uk Mon Apr 19 08:43:49 2010 From: j.d.blower at reading.ac.uk (Jonathan Blower) Date: Mon, 19 Apr 2010 15:43:49 +0100 Subject: [CF-metadata] Default datum for latitude and longitude? Message-ID: <7CD7F00F17085C4EBB045A35177C85FDD98684@VIME-VS1.rdg-home.ad.rdg.ac.uk> Hi all, The CF conventions define a means to specify the datum used in certain map projections (http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.ht ml#grid-mappings-and-projections). In the (common) case of a data file containing latitude and longitude axes, but no explicit datum specification, which datum should be assumed? Spherical Earth? WGS84? The horizontal error resulting from use of an incorrect datum can be significant for high-resolution and/or local dataset (hundreds of metres). Cheers, Jon -- Dr Jon Blower Technical Director, Reading e-Science Centre Environmental Systems Science Centre University of Reading Harry Pitt Building, 3 Earley Gate Reading RG6 6AL. UK Tel: +44 (0)118 378 5213 Fax: +44 (0)118 378 6413 j.d.blower at reading.ac.uk http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm From mggr at pml.ac.uk Mon Apr 19 09:06:57 2010 From: mggr at pml.ac.uk (Mike Grant) Date: Mon, 19 Apr 2010 16:06:57 +0100 Subject: [CF-metadata] Default datum for latitude and longitude? In-Reply-To: <7CD7F00F17085C4EBB045A35177C85FDD98684@VIME-VS1.rdg-home.ad.rdg.ac.uk> References: <7CD7F00F17085C4EBB045A35177C85FDD98684@VIME-VS1.rdg-home.ad.rdg.ac.uk> Message-ID: <4BCC7191.60006@pml.ac.uk> On 19/04/10 15:43, Jonathan Blower wrote: > specification, which datum should be assumed? Spherical Earth? WGS84? If you're picking one at random, I'd go for WGS84 - that's a pretty safe bet for a lot of remote sensed and GPS related data. Cheers, Mike. -------------------------------------------------------------------------------- Plymouth Marine Laboratory Registered Office: Prospect Place The Hoe Plymouth PL1 3DH Website: www.pml.ac.uk Registered Charity No. 1091222 PML is a company limited by guarantee registered in England & Wales company number 4178503 PML is a member of the Plymouth Marine Sciences Partnership Website: www.pmsp.org.uk -------------------------------------------------------------------------------- This e-mail, its content and any file attachments are confidential. If you have received this e-mail in error please do not copy, disclose it to any third party or use the contents or attachments in any way. Please notify the sender by replying to this e-mail or e-mail forinfo at pml.ac.uk and then delete the email without making any copies or using it in any other way. The content of this message may contain personal views which are not the views of Plymouth Marine Laboratory unless specifically stated. You are reminded that e-mail communications are not secure and may contain viruses. Plymouth Marine Laboratory accepts no liability for any loss or damage which may be caused by viruses. -------------------------------------------------------------------------------- From j.d.blower at reading.ac.uk Mon Apr 19 09:23:22 2010 From: j.d.blower at reading.ac.uk (Jonathan Blower) Date: Mon, 19 Apr 2010 16:23:22 +0100 Subject: [CF-metadata] Default datum for latitude and longitude? In-Reply-To: <4BCC7191.60006@pml.ac.uk> References: <7CD7F00F17085C4EBB045A35177C85FDD98684@VIME-VS1.rdg-home.ad.rdg.ac.uk> <4BCC7191.60006@pml.ac.uk> Message-ID: <7CD7F00F17085C4EBB045A35177C85FDD98696@VIME-VS1.rdg-home.ad.rdg.ac.uk> Hi Mike, Yes, that's what I've been doing so far, but I seem to remember someone telling me that models tend to be formulated on a spherical earth. But maybe if the precise geolocation of the model grid points is important (e.g. for small-scale models) the datum will always be specified, or a different projection used. Cheers, Jon -----Original Message----- From: Mike Grant [mailto:mggr at pml.ac.uk] Sent: 19 April 2010 16:07 To: Jonathan Blower Cc: cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] Default datum for latitude and longitude? On 19/04/10 15:43, Jonathan Blower wrote: > specification, which datum should be assumed? Spherical Earth? WGS84? If you're picking one at random, I'd go for WGS84 - that's a pretty safe bet for a lot of remote sensed and GPS related data. Cheers, Mike. ------------------------------------------------------------------------ -------- Plymouth Marine Laboratory Registered Office: Prospect Place The Hoe Plymouth PL1 3DH Website: www.pml.ac.uk Registered Charity No. 1091222 PML is a company limited by guarantee registered in England & Wales company number 4178503 PML is a member of the Plymouth Marine Sciences Partnership Website: www.pmsp.org.uk ------------------------------------------------------------------------ -------- This e-mail, its content and any file attachments are confidential. If you have received this e-mail in error please do not copy, disclose it to any third party or use the contents or attachments in any way. Please notify the sender by replying to this e-mail or e-mail forinfo at pml.ac.uk and then delete the email without making any copies or using it in any other way. The content of this message may contain personal views which are not the views of Plymouth Marine Laboratory unless specifically stated. You are reminded that e-mail communications are not secure and may contain viruses. Plymouth Marine Laboratory accepts no liability for any loss or damage which may be caused by viruses. ------------------------------------------------------------------------ -------- From ngalbraith at whoi.edu Mon Apr 19 09:48:38 2010 From: ngalbraith at whoi.edu (Nan Galbraith) Date: Mon, 19 Apr 2010 11:48:38 -0400 Subject: [CF-metadata] Default datum for latitude and longitude? In-Reply-To: <4BCC7191.60006@pml.ac.uk> References: <7CD7F00F17085C4EBB045A35177C85FDD98684@VIME-VS1.rdg-home.ad.rdg.ac.uk> <4BCC7191.60006@pml.ac.uk> Message-ID: <4BCC7B56.4040709@whoi.edu> Just want to point out that many of our older datasets, which are still available - and actually still used - predate the routine use of GPS on ships. These datasets are from buoys that were set using dead reckoning. And, although we now have pretty nearly exact anchor positions, the buoys on our moorings deployed in about 5 km of water typically have 5 km watch circle diameters. So, although the datum specification should be encouraged, there's a definite drawback to assuming a default. And, the position's accuracy is probably more significant than the datum spec for a lot of in situ data- so we should really encourage the use of QC terms for all coordinates. Thanks - Nan Mike Grant wrote: > On 19/04/10 15:43, Jonathan Blower wrote: > >> specification, which datum should be assumed? Spherical Earth? WGS84? >> > > If you're picking one at random, I'd go for WGS84 - that's a pretty safe > bet for a lot of remote sensed and GPS related data. > > Cheers, > > Mike. > > > >> Hi all, >> >> The CF conventions define a means to specify the datum used in certain >> map projections >> (http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.ht >> ml#grid-mappings-and-projections). In the (common) case of a data file >> containing latitude and longitude axes, but no explicit datum >> specification, which datum should be assumed? Spherical Earth? WGS84? >> >> The horizontal error resulting from use of an incorrect datum can be >> significant for high-resolution and/or local dataset (hundreds of >> metres). >> >> Cheers, Jon -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* From philip.bentley at metoffice.gov.uk Mon Apr 19 09:51:49 2010 From: philip.bentley at metoffice.gov.uk (Bentley, Philip) Date: Mon, 19 Apr 2010 16:51:49 +0100 Subject: [CF-metadata] Default datum for latitude and longitude? In-Reply-To: <7CD7F00F17085C4EBB045A35177C85FDD98696@VIME-VS1.rdg-home.ad.rdg.ac.uk> References: <7CD7F00F17085C4EBB045A35177C85FDD98684@VIME-VS1.rdg-home.ad.rdg.ac.uk><4BCC7191.60006@pml.ac.uk> <7CD7F00F17085C4EBB045A35177C85FDD98696@VIME-VS1.rdg-home.ad.rdg.ac.uk> Message-ID: Hi Jon, Indeed, the UM global climate model, for example, assumes a spherical earth. In the absence of specific datum information I think I would probably caution against assuming any particular datum is applicable. I can understand the temptation to use WGS 1984 as a default because it is widely known and used. However, this implies a degree of accuracy in the coordinate data which in many instances may well not be justified - indeed its use might even compound any relative location errors. As you rightly suggest, if the end-use/application demands a particular spatial accuracy then any datasets which demonstrably do not not meet those requirements should probably not be included in the analysis - or else should be with appropriate caveats, provisos and disclaimers! Regards, Phil > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu > [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Blower > Sent: 19 April 2010 16:23 > To: Mike Grant > Cc: cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] Default datum for latitude and longitude? > > Hi Mike, > > Yes, that's what I've been doing so far, but I seem to > remember someone telling me that models tend to be formulated > on a spherical earth. But maybe if the precise geolocation > of the model grid points is important (e.g. for small-scale > models) the datum will always be specified, or a different > projection used. > > Cheers, Jon > > -----Original Message----- > From: Mike Grant [mailto:mggr at pml.ac.uk] > Sent: 19 April 2010 16:07 > To: Jonathan Blower > Cc: cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] Default datum for latitude and longitude? > > On 19/04/10 15:43, Jonathan Blower wrote: > > specification, which datum should be assumed? Spherical Earth? > WGS84? > > If you're picking one at random, I'd go for WGS84 - that's a > pretty safe bet for a lot of remote sensed and GPS related data. > > Cheers, > > Mike. > > -------------------------------------------------------------- > ---------- > -------- > Plymouth Marine Laboratory > > Registered Office: > Prospect Place > The Hoe > Plymouth PL1 3DH > > Website: www.pml.ac.uk > Registered Charity No. 1091222 > PML is a company limited by guarantee > registered in England & Wales > company number 4178503 > > PML is a member of the Plymouth Marine Sciences Partnership > Website: www.pmsp.org.uk > -------------------------------------------------------------- > ---------- > -------- > This e-mail, its content and any file attachments are confidential. > > If you have received this e-mail in error please do not copy, > disclose it to any third party or use the contents or > attachments in any way. > Please notify the sender by replying to this e-mail or e-mail > forinfo at pml.ac.uk and then delete the email without making > any copies or using it in any other way. > > The content of this message may contain personal views which > are not the views of Plymouth Marine Laboratory unless > specifically stated. > > You are reminded that e-mail communications are not secure > and may contain viruses. Plymouth Marine Laboratory accepts > no liability for any loss or damage which may be caused by viruses. > -------------------------------------------------------------- > ---------- > -------- > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > From j.d.blower at reading.ac.uk Mon Apr 19 10:04:49 2010 From: j.d.blower at reading.ac.uk (Jonathan Blower) Date: Mon, 19 Apr 2010 17:04:49 +0100 Subject: [CF-metadata] Default datum for latitude and longitude? In-Reply-To: References: <7CD7F00F17085C4EBB045A35177C85FDD98684@VIME-VS1.rdg-home.ad.rdg.ac.uk><4BCC7191.60006@pml.ac.uk> <7CD7F00F17085C4EBB045A35177C85FDD98696@VIME-VS1.rdg-home.ad.rdg.ac.uk> Message-ID: <7CD7F00F17085C4EBB045A35177C85FDD986A2@VIME-VS1.rdg-home.ad.rdg.ac.uk> Hi Phil, Yes, I think strictly this is correct. But it does mean that, for data that do not specify a datum, the only legitimate way to plot such data as a map is as a latitude-longitude plot. Projection to any other coordinate system would require knowledge of the datum in order to do the mathematical transformation accurately (I think... possibly there are some exceptions). The suggestion for applications to print "health warnings" for underspecified data is a good one. Maybe future versions of CF should make the datum specification mandatory, where it is known? Jon -----Original Message----- From: Bentley, Philip [mailto:philip.bentley at metoffice.gov.uk] Sent: 19 April 2010 16:52 To: Jonathan Blower; Mike Grant Cc: cf-metadata at cgd.ucar.edu Subject: RE: [CF-metadata] Default datum for latitude and longitude? Hi Jon, Indeed, the UM global climate model, for example, assumes a spherical earth. In the absence of specific datum information I think I would probably caution against assuming any particular datum is applicable. I can understand the temptation to use WGS 1984 as a default because it is widely known and used. However, this implies a degree of accuracy in the coordinate data which in many instances may well not be justified - indeed its use might even compound any relative location errors. As you rightly suggest, if the end-use/application demands a particular spatial accuracy then any datasets which demonstrably do not not meet those requirements should probably not be included in the analysis - or else should be with appropriate caveats, provisos and disclaimers! Regards, Phil > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu > [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Blower > Sent: 19 April 2010 16:23 > To: Mike Grant > Cc: cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] Default datum for latitude and longitude? > > Hi Mike, > > Yes, that's what I've been doing so far, but I seem to > remember someone telling me that models tend to be formulated > on a spherical earth. But maybe if the precise geolocation > of the model grid points is important (e.g. for small-scale > models) the datum will always be specified, or a different > projection used. > > Cheers, Jon > > -----Original Message----- > From: Mike Grant [mailto:mggr at pml.ac.uk] > Sent: 19 April 2010 16:07 > To: Jonathan Blower > Cc: cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] Default datum for latitude and longitude? > > On 19/04/10 15:43, Jonathan Blower wrote: > > specification, which datum should be assumed? Spherical Earth? > WGS84? > > If you're picking one at random, I'd go for WGS84 - that's a > pretty safe bet for a lot of remote sensed and GPS related data. > > Cheers, > > Mike. > > -------------------------------------------------------------- > ---------- > -------- > Plymouth Marine Laboratory > > Registered Office: > Prospect Place > The Hoe > Plymouth PL1 3DH > > Website: www.pml.ac.uk > Registered Charity No. 1091222 > PML is a company limited by guarantee > registered in England & Wales > company number 4178503 > > PML is a member of the Plymouth Marine Sciences Partnership > Website: www.pmsp.org.uk > -------------------------------------------------------------- > ---------- > -------- > This e-mail, its content and any file attachments are confidential. > > If you have received this e-mail in error please do not copy, > disclose it to any third party or use the contents or > attachments in any way. > Please notify the sender by replying to this e-mail or e-mail > forinfo at pml.ac.uk and then delete the email without making > any copies or using it in any other way. > > The content of this message may contain personal views which > are not the views of Plymouth Marine Laboratory unless > specifically stated. > > You are reminded that e-mail communications are not secure > and may contain viruses. Plymouth Marine Laboratory accepts > no liability for any loss or damage which may be caused by viruses. > -------------------------------------------------------------- > ---------- > -------- > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > From j.d.blower at reading.ac.uk Mon Apr 19 10:06:02 2010 From: j.d.blower at reading.ac.uk (Jonathan Blower) Date: Mon, 19 Apr 2010 17:06:02 +0100 Subject: [CF-metadata] Default datum for latitude and longitude? In-Reply-To: <4BCC7B56.4040709@whoi.edu> References: <7CD7F00F17085C4EBB045A35177C85FDD98684@VIME-VS1.rdg-home.ad.rdg.ac.uk> <4BCC7191.60006@pml.ac.uk> <4BCC7B56.4040709@whoi.edu> Message-ID: <7CD7F00F17085C4EBB045A35177C85FDD986A3@VIME-VS1.rdg-home.ad.rdg.ac.uk> Thanks Nan, this is a good point. I wonder how such QC information could be recorded (I guess this would be a new thread of discussion? ;-) Jon -----Original Message----- From: Nan Galbraith [mailto:ngalbraith at whoi.edu] Sent: 19 April 2010 16:49 To: Mike Grant Cc: Jonathan Blower; cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] Default datum for latitude and longitude? Just want to point out that many of our older datasets, which are still available - and actually still used - predate the routine use of GPS on ships. These datasets are from buoys that were set using dead reckoning. And, although we now have pretty nearly exact anchor positions, the buoys on our moorings deployed in about 5 km of water typically have 5 km watch circle diameters. So, although the datum specification should be encouraged, there's a definite drawback to assuming a default. And, the position's accuracy is probably more significant than the datum spec for a lot of in situ data- so we should really encourage the use of QC terms for all coordinates. Thanks - Nan Mike Grant wrote: > On 19/04/10 15:43, Jonathan Blower wrote: > >> specification, which datum should be assumed? Spherical Earth? WGS84? >> > > If you're picking one at random, I'd go for WGS84 - that's a pretty safe > bet for a lot of remote sensed and GPS related data. > > Cheers, > > Mike. > > > >> Hi all, >> >> The CF conventions define a means to specify the datum used in certain >> map projections >> (http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.ht >> ml#grid-mappings-and-projections). In the (common) case of a data file >> containing latitude and longitude axes, but no explicit datum >> specification, which datum should be assumed? Spherical Earth? WGS84? >> >> The horizontal error resulting from use of an incorrect datum can be >> significant for high-resolution and/or local dataset (hundreds of >> metres). >> >> Cheers, Jon -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* From mlankhorst at ucsd.edu Mon Apr 19 11:16:16 2010 From: mlankhorst at ucsd.edu (Matthias Lankhorst) Date: Mon, 19 Apr 2010 10:16:16 -0700 Subject: [CF-metadata] request CF standard name for chlorophyll-a concentration in sea water Message-ID: <201004191016.16336.mlankhorst@ucsd.edu> All, on behalf of the OceanSITES project (www.oceansites.org), I would like to introduce a new standard name for the chlorophyll-a concentration in sea water. I have found an existing standard name for chlorophyll concentration in sea water, but not explicitly chlorophyll-a. I know that there are measurement techniques that measure one but not the other, not to mention possible inclusion of phaeopigments. Hence the need to be more specific. The existing name is: mass_concentration_of_chlorophyll_in_sea_water I found it on: http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name- table/13/cf-standard-name-table.html Based on that, I would propose the following new standard name: mass_concentration_of_chlorophyll_a_in_sea_water Canonical units would be: kg m-3 Any objections? Regards, MATT LANKHORST -- _______________________________________ Dr. Matthias Lankhorst Scripps Institution of Oceanography 9500 Gilman Drive, Mail Code 0230 La Jolla, CA 92093-0230 USA Phone: +1 858 822 5013 Fax: +1 858 534 9820 E-Mail: mlankhorst at ucsd.edu http://www-pord.ucsd.edu/~mlankhorst/ From caron at unidata.ucar.edu Mon Apr 19 12:40:03 2010 From: caron at unidata.ucar.edu (John Caron) Date: Mon, 19 Apr 2010 12:40:03 -0600 Subject: [CF-metadata] Default datum for latitude and longitude? In-Reply-To: <7CD7F00F17085C4EBB045A35177C85FDD986A3@VIME-VS1.rdg-home.ad.rdg.ac.uk> References: <7CD7F00F17085C4EBB045A35177C85FDD98684@VIME-VS1.rdg-home.ad.rdg.ac.uk> <4BCC7191.60006@pml.ac.uk> <4BCC7B56.4040709@whoi.edu> <7CD7F00F17085C4EBB045A35177C85FDD986A3@VIME-VS1.rdg-home.ad.rdg.ac.uk> Message-ID: <4BCCA383.90109@unidata.ucar.edu> In the CDM, we assume a spherical earth when no other info is given. This reflects the early history of CF and CDM in dealing mostly with global models. WGS84 is the default ellipsoid used eg for UTM projection. It would be well worth CF specifying default assumptions as well as how to do datums correctly. One of the main goals of TDS/NcML is the ability to add/change attribute information in legacy datasets, so at least for the TDS, data providers could quickly correct their datasets if it only involves attributes. On 4/19/2010 10:06 AM, Jonathan Blower wrote: > Thanks Nan, this is a good point. I wonder how such QC information > could be recorded (I guess this would be a new thread of discussion? ;-) > > Jon > > -----Original Message----- > From: Nan Galbraith [mailto:ngalbraith at whoi.edu] > Sent: 19 April 2010 16:49 > To: Mike Grant > Cc: Jonathan Blower; cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] Default datum for latitude and longitude? > > Just want to point out that many of our older datasets, which are > still available - and actually still used - predate the routine use of > GPS on ships. These datasets are from buoys that were set using > dead reckoning. > > And, although we now have pretty nearly exact anchor positions, > the buoys on our moorings deployed in about 5 km of water > typically have 5 km watch circle diameters. > > So, although the datum specification should be encouraged, there's > a definite drawback to assuming a default. And, the position's accuracy > is probably more significant than the datum spec for a lot of in situ > data- > so we should really encourage the use of QC terms for all coordinates. > > Thanks - Nan > > Mike Grant wrote: > >> On 19/04/10 15:43, Jonathan Blower wrote: >> >> >>> specification, which datum should be assumed? Spherical Earth? >>> > WGS84? > >>> >>> >> If you're picking one at random, I'd go for WGS84 - that's a pretty >> > safe > >> bet for a lot of remote sensed and GPS related data. >> >> Cheers, >> >> Mike. >> >> >> >> >>> Hi all, >>> >>> The CF conventions define a means to specify the datum used in >>> > certain > >>> map projections >>> >>> > (http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.ht > >>> ml#grid-mappings-and-projections). In the (common) case of a data >>> > file > >>> containing latitude and longitude axes, but no explicit datum >>> specification, which datum should be assumed? Spherical Earth? >>> > WGS84? > >>> The horizontal error resulting from use of an incorrect datum can be >>> significant for high-resolution and/or local dataset (hundreds of >>> metres). >>> >>> Cheers, Jon >>> > From jbgraybeal at mindspring.com Mon Apr 19 15:30:48 2010 From: jbgraybeal at mindspring.com (John Graybeal) Date: Mon, 19 Apr 2010 14:30:48 -0700 Subject: [CF-metadata] Default datum for latitude and longitude? In-Reply-To: <4BCC7B56.4040709@whoi.edu> References: <7CD7F00F17085C4EBB045A35177C85FDD98684@VIME-VS1.rdg-home.ad.rdg.ac.uk> <4BCC7191.60006@pml.ac.uk> <4BCC7B56.4040709@whoi.edu> Message-ID: Just because I say my parameter was measured relative to a particular datum, says nothing about the accuracy or the measurement itself. I don't think selection of a datum, whether as the de facto default or explicitly, can be construed in any way to imply accuracy of the coordinate data. Since potential error will be introduced by the assumption of *any* datum -- and the lack of assumption of a datum does nothing to get rid of the potential error -- I'm not sure there is value in avoiding a default value for datum. Well, other than saying in a loud voice "Don't do that", which people will probably do anyway. (Hmm, maybe there is value in this approach....) There is a pretty good analogy to the use of accuracy metadata with data. If this is truly important, than we accept no data without datum (in the analogy case, we accept no data without accuracy metadata -- note how rare this practice is in the real world). But rather than saying "data should not be accepted", do we want to say "data can be accepted at the option of the receiving process, and should be assumed in the default datum"? John On Apr 19, 2010, at 08:48, Nan Galbraith wrote: > Just want to point out that many of our older datasets, which are > still available - and actually still used - predate the routine use of > GPS on ships. These datasets are from buoys that were set using > dead reckoning. > > And, although we now have pretty nearly exact anchor positions, > the buoys on our moorings deployed in about 5 km of water > typically have 5 km watch circle diameters. > So, although the datum specification should be encouraged, there's > a definite drawback to assuming a default. And, the position's > accuracy > is probably more significant than the datum spec for a lot of in > situ data- > so we should really encourage the use of QC terms for all coordinates. > > Thanks - Nan n Apr 19, 2010, at 08:51, Bentley, Philip wrote: > Hi Jon, > > Indeed, the UM global climate model, for example, assumes a spherical > earth. > > In the absence of specific datum information I think I would probably > caution against assuming any particular datum is applicable. I can > understand the temptation to use WGS 1984 as a default because it is > widely known and used. However, this implies a degree of accuracy in > the > coordinate data which in many instances may well not be justified - > indeed its use might even compound any relative location errors. > > As you rightly suggest, if the end-use/application demands a > particular > spatial accuracy then any datasets which demonstrably do not not meet > those requirements should probably not be included in the analysis - > or > else should be with appropriate caveats, provisos and disclaimers! > > Regards, > Phil > > Mike Grant wrote: >> On 19/04/10 15:43, Jonathan Blower wrote: >> >>> specification, which datum should be assumed? Spherical Earth? >>> WGS84? >>> >> >> If you're picking one at random, I'd go for WGS84 - that's a pretty >> safe >> bet for a lot of remote sensed and GPS related data. >> >> Cheers, >> >> Mike. >> >> >> >>> Hi all, >>> >>> The CF conventions define a means to specify the datum used in >>> certain >>> map projections >>> (http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.ht >>> ml#grid-mappings-and-projections). In the (common) case of a data >>> file >>> containing latitude and longitude axes, but no explicit datum >>> specification, which datum should be assumed? Spherical Earth? >>> WGS84? >>> >>> The horizontal error resulting from use of an incorrect datum can be >>> significant for high-resolution and/or local dataset (hundreds of >>> metres). >>> >>> Cheers, Jon > > -- > ******************************************************* > * Nan Galbraith (508) 289-2444 * > * Upper Ocean Processes Group Mail Stop 29 * > * Woods Hole Oceanographic Institution * > * Woods Hole, MA 02543 * > ******************************************************* > > > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From j.d.blower at reading.ac.uk Tue Apr 20 03:24:19 2010 From: j.d.blower at reading.ac.uk (Jonathan Blower) Date: Tue, 20 Apr 2010 10:24:19 +0100 Subject: [CF-metadata] Default datum for latitude and longitude? In-Reply-To: References: <7CD7F00F17085C4EBB045A35177C85FDD98684@VIME-VS1.rdg-home.ad.rdg.ac.uk><4BCC7191.60006@pml.ac.uk> <4BCC7B56.4040709@whoi.edu> Message-ID: <7CD7F00F17085C4EBB045A35177C85FDD986E0@VIME-VS1.rdg-home.ad.rdg.ac.uk> Hi John, Yes, I guess there may be a difference in the way obs and model data are handled. In model data (and perhaps many remotely-sensed datasets), the precise geolocation data ought to be known, including the datum, and this should be transmitted. But where there is geolocation error (in in-situ obs for instance) specification of the datum may be less important than conveying the accuracy of the coordinate data in some way. So I agree, it's probably not helpful to insist that a datum is mandatory. But I think that guidelines and assumptions about how to interpret different kinds of geolocation error could be valuable. Jon -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of John Graybeal Sent: 19 April 2010 22:31 To: ngalbraith at whoi.edu Cc: cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] Default datum for latitude and longitude? Just because I say my parameter was measured relative to a particular datum, says nothing about the accuracy or the measurement itself. I don't think selection of a datum, whether as the de facto default or explicitly, can be construed in any way to imply accuracy of the coordinate data. Since potential error will be introduced by the assumption of *any* datum -- and the lack of assumption of a datum does nothing to get rid of the potential error -- I'm not sure there is value in avoiding a default value for datum. Well, other than saying in a loud voice "Don't do that", which people will probably do anyway. (Hmm, maybe there is value in this approach....) There is a pretty good analogy to the use of accuracy metadata with data. If this is truly important, than we accept no data without datum (in the analogy case, we accept no data without accuracy metadata -- note how rare this practice is in the real world). But rather than saying "data should not be accepted", do we want to say "data can be accepted at the option of the receiving process, and should be assumed in the default datum"? John On Apr 19, 2010, at 08:48, Nan Galbraith wrote: > Just want to point out that many of our older datasets, which are > still available - and actually still used - predate the routine use of > GPS on ships. These datasets are from buoys that were set using > dead reckoning. > > And, although we now have pretty nearly exact anchor positions, > the buoys on our moorings deployed in about 5 km of water > typically have 5 km watch circle diameters. > So, although the datum specification should be encouraged, there's > a definite drawback to assuming a default. And, the position's > accuracy > is probably more significant than the datum spec for a lot of in > situ data- > so we should really encourage the use of QC terms for all coordinates. > > Thanks - Nan n Apr 19, 2010, at 08:51, Bentley, Philip wrote: > Hi Jon, > > Indeed, the UM global climate model, for example, assumes a spherical > earth. > > In the absence of specific datum information I think I would probably > caution against assuming any particular datum is applicable. I can > understand the temptation to use WGS 1984 as a default because it is > widely known and used. However, this implies a degree of accuracy in > the > coordinate data which in many instances may well not be justified - > indeed its use might even compound any relative location errors. > > As you rightly suggest, if the end-use/application demands a > particular > spatial accuracy then any datasets which demonstrably do not not meet > those requirements should probably not be included in the analysis - > or > else should be with appropriate caveats, provisos and disclaimers! > > Regards, > Phil > > Mike Grant wrote: >> On 19/04/10 15:43, Jonathan Blower wrote: >> >>> specification, which datum should be assumed? Spherical Earth? >>> WGS84? >>> >> >> If you're picking one at random, I'd go for WGS84 - that's a pretty >> safe >> bet for a lot of remote sensed and GPS related data. >> >> Cheers, >> >> Mike. >> >> >> >>> Hi all, >>> >>> The CF conventions define a means to specify the datum used in >>> certain >>> map projections >>> (http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.ht >>> ml#grid-mappings-and-projections). In the (common) case of a data >>> file >>> containing latitude and longitude axes, but no explicit datum >>> specification, which datum should be assumed? Spherical Earth? >>> WGS84? >>> >>> The horizontal error resulting from use of an incorrect datum can be >>> significant for high-resolution and/or local dataset (hundreds of >>> metres). >>> >>> Cheers, Jon > > -- > ******************************************************* > * Nan Galbraith (508) 289-2444 * > * Upper Ocean Processes Group Mail Stop 29 * > * Woods Hole Oceanographic Institution * > * Woods Hole, MA 02543 * > ******************************************************* > > > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From olauret at cls.fr Tue Apr 20 04:13:16 2010 From: olauret at cls.fr (Lauret Olivier) Date: Tue, 20 Apr 2010 12:13:16 +0200 Subject: [CF-metadata] request CF standard name for chlorophyll-aconcentration in sea water In-Reply-To: <201004191016.16336.mlankhorst@ucsd.edu> References: <201004191016.16336.mlankhorst@ucsd.edu> Message-ID: <1240F43731C2EB4F8CC9BF70D233B51101AD263C@SRV-XCHANGE-2K3.pc.cls.fr> Hi Matt, I am also interested in this suggestion. My understanding of this story of chlorophyll//chlorophyll-a in CF was, approximately, that we may use the same standard name for both, precise the wavelength as a size-one coordinate variable. And then just add "Chlorophyll-A" in the long name attribute.. But I am absolutely not sure of that, it is something that could be clarified thanks to your request. I added Frederic Melin in copy, he may probably help us. Olivier. -----Message d'origine----- De?: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] De la part de Matthias Lankhorst Envoy??: lundi 19 avril 2010 19:16 ??: cf-metadata at cgd.ucar.edu Objet?: [CF-metadata] request CF standard name for chlorophyll-aconcentration in sea water All, on behalf of the OceanSITES project (www.oceansites.org), I would like to introduce a new standard name for the chlorophyll-a concentration in sea water. I have found an existing standard name for chlorophyll concentration in sea water, but not explicitly chlorophyll-a. I know that there are measurement techniques that measure one but not the other, not to mention possible inclusion of phaeopigments. Hence the need to be more specific. The existing name is: mass_concentration_of_chlorophyll_in_sea_water I found it on: http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name- table/13/cf-standard-name-table.html Based on that, I would propose the following new standard name: mass_concentration_of_chlorophyll_a_in_sea_water Canonical units would be: kg m-3 Any objections? Regards, MATT LANKHORST -- _______________________________________ Dr. Matthias Lankhorst Scripps Institution of Oceanography 9500 Gilman Drive, Mail Code 0230 La Jolla, CA 92093-0230 USA Phone: +1 858 822 5013 Fax: +1 858 534 9820 E-Mail: mlankhorst at ucsd.edu http://www-pord.ucsd.edu/~mlankhorst/ _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata Cliquez sur l'url suivante https://www.mailcontrol.com/sr/zAFL8!vIlijTndxI!oX7Uj5Un8Ja1WtLjMJ7o6+acjdZtNs5E0zmLW+A+g6rj8fhjpzs5bt6JT8LtzovJ!KJwA== si ce message est ind?sirable (pourriel). From frederic.melin at jrc.ec.europa.eu Tue Apr 20 10:44:52 2010 From: frederic.melin at jrc.ec.europa.eu (Frederic MELIN) Date: Tue, 20 Apr 2010 18:44:52 +0200 Subject: [CF-metadata] request CF standard name forchlorophyll-aconcentration in sea water In-Reply-To: <1240F43731C2EB4F8CC9BF70D233B51101AD263C@SRV-XCHANGE-2K3.pc.cls.fr> References: <201004191016.16336.mlankhorst@ucsd.edu> <1240F43731C2EB4F8CC9BF70D233B51101AD263C@SRV-XCHANGE-2K3.pc.cls.fr> Message-ID: <928FDE7390BB4A4AA67DA41F9F6E2AD5@gvm.ies.jrc.it> Dear all, Matthias' point is very appropriate. The name for chlorophyll has been defined for some time, and honestly I assumed that it was referring to chlorophyll-a. As Matthias mentions, to be more rigorous (and to be able to distinguish between chlorophylls (a, b, c1, c2 ...) , introducing mass_concentration_of_chlorophyll_a_in_sea_water is needed (this is a major pigment and the primary ocean colour remote sensing product). Best, frederic -----Message d'origine----- De?: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] De la part de Matthias Lankhorst Envoy??: lundi 19 avril 2010 19:16 ??: cf-metadata at cgd.ucar.edu Objet?: [CF-metadata] request CF standard name for chlorophyll-aconcentration in sea water All, on behalf of the OceanSITES project (www.oceansites.org), I would like to introduce a new standard name for the chlorophyll-a concentration in sea water. I have found an existing standard name for chlorophyll concentration in sea water, but not explicitly chlorophyll-a. I know that there are measurement techniques that measure one but not the other, not to mention possible inclusion of phaeopigments. Hence the need to be more specific. The existing name is: mass_concentration_of_chlorophyll_in_sea_water I found it on: http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name- table/13/cf-standard-name-table.html Based on that, I would propose the following new standard name: mass_concentration_of_chlorophyll_a_in_sea_water Canonical units would be: kg m-3 Any objections? Regards, MATT LANKHORST -- _______________________________________ Dr. Matthias Lankhorst Scripps Institution of Oceanography 9500 Gilman Drive, Mail Code 0230 La Jolla, CA 92093-0230 USA Phone: +1 858 822 5013 Fax: +1 858 534 9820 E-Mail: mlankhorst at ucsd.edu http://www-pord.ucsd.edu/~mlankhorst/ _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata Cliquez sur l'url suivante https://www.mailcontrol.com/sr/zAFL8!vIlijTndxI!oX7Uj5Un8Ja1WtLjMJ7o6+acjdZt Ns5E0zmLW+A+g6rj8fhjpzs5bt6JT8LtzovJ!KJwA== si ce message est ind?sirable (pourriel). _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From j.m.gregory at reading.ac.uk Tue Apr 20 10:48:25 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 20 Apr 2010 17:48:25 +0100 Subject: [CF-metadata] request CF standard name forchlorophyll-aconcentration in sea water In-Reply-To: <928FDE7390BB4A4AA67DA41F9F6E2AD5@gvm.ies.jrc.it> References: <201004191016.16336.mlankhorst@ucsd.edu> <1240F43731C2EB4F8CC9BF70D233B51101AD263C@SRV-XCHANGE-2K3.pc.cls.fr> <928FDE7390BB4A4AA67DA41F9F6E2AD5@gvm.ies.jrc.it> Message-ID: <20100420164825.GA13073@met.reading.ac.uk> Dear all > The name for chlorophyll has been defined for some time, and honestly I > assumed that it was referring to chlorophyll-a. > As Matthias mentions, to be more rigorous (and to be able to distinguish > between chlorophylls (a, b, c1, c2 ...) , introducing > mass_concentration_of_chlorophyll_a_in_sea_water is needed (this is a major > pigment and the primary ocean colour remote sensing product). It would seem fine to me to have standard names both for chlorophyll generically (as we have now) and chlorophyll_a etc. specifically as required. Different applications need different degrees of precision and standard names can accommodate this. Cheers Jonathan From John.Dunne at noaa.gov Wed Apr 21 09:20:18 2010 From: John.Dunne at noaa.gov (John.Dunne at noaa.gov) Date: Wed, 21 Apr 2010 11:20:18 -0400 Subject: [CF-metadata] BGC output for CMIP5 simulations Message-ID: <253e2562542791.2542791253e256@noaa.gov> Hi Keith, I see your point about the N2 production not being part of the regenerated production. However, I would say the same is true of NH4 from deposition, runoff or supply from below, and the opposite true with respect to NO3 nitrified in the euphotic zone - all of which leaving 'new' with ambiguous meaning. I have always treated N2 production separately from new production in my own thinking for model-data comparisons of new production traditionally being measured from NO3 incubations. Perhaps we should change the name from 'pnew' to 'pno3' to avoid confusion...? Cheers, John ----- Original Message ----- From: Keith Lindsay Date: Wednesday, April 21, 2010 10:48 am Subject: Re: BGC output for CMIP5 simulations > Hi, > > I have another request for clarification: > > The spreadsheet that has been passed around includes the variable > "pnew". The proposed standard name is "new_production". Based on > this > alone, one might include diazotroph production that is supported by > nitrogen fixation. However, the long name is "Primary Carbon > Production > by Phytoplankton Based on NO3 Alone". > > Is the long name intended to be definitive? > > Should production supported by nitrogen fixation by excluded from > pnew? > Thanks, > Keith Lindsay > > ****************************************************************** > Keith Lindsay http://www.cgd.ucar.edu/oce/klindsay/ > email: klindsay at ucar.edu phone: 303-497-1722 fax: 303-497-1700 > From klindsay at ucar.edu Wed Apr 21 10:29:38 2010 From: klindsay at ucar.edu (Keith Lindsay) Date: Wed, 21 Apr 2010 10:29:38 -0600 (MDT) Subject: [CF-metadata] BGC output for CMIP5 simulations In-Reply-To: <253e2562542791.2542791253e256@noaa.gov> References: <253e2562542791.2542791253e256@noaa.gov> Message-ID: On Wed, 21 Apr 2010, John.Dunne at noaa.gov wrote: > > Hi Keith, > > I see your point about the N2 production not being part of the > regenerated production. However, I would say the same is true of NH4 > from deposition, runoff or supply from below, and the opposite true with > respect to NO3 nitrified in the euphotic zone - all of which leaving > 'new' with ambiguous meaning. I have always treated N2 production > separately from new production in my own thinking for model-data > comparisons of new production traditionally being measured from NO3 > incubations. Perhaps we should change the name from 'pnew' to 'pno3' to > avoid confusion...? If this is consistent with how others are using this diagnostic, and if there is time for a change, I'd recommend it. It would imply changing "long name", "proposed standard name", and "CMOR variable name" for pnew, as well as for intpnew. For pnew, the proposed standard name is net_new_primary_mole_productivity_of_carbon. I propose changing it to net_primary_mole_productivity_of_carbon_from_no3, with an analogous change for intpnew. Keith ****************************************************************** Keith Lindsay http://www.cgd.ucar.edu/oce/klindsay/ email: klindsay at ucar.edu phone: 303-497-1722 fax: 303-497-1700 From cameronsmith1 at llnl.gov Wed Apr 21 17:04:51 2010 From: cameronsmith1 at llnl.gov (Philip J. Cameronsmith1) Date: Wed, 21 Apr 2010 16:04:51 -0700 (PDT) Subject: [CF-metadata] BGC output for CMIP5 simulations (fwd) Message-ID: Hi, It appears that the wrong email address for the CF list was used for some of the emails in the conversation below. Hence, I am forwarding the final email for the record. Best wishes, Philip ------------------------------------------------------------------------ Dr Philip Cameron-Smith Atmospheric, Earth, and Energy Division pjc at llnl.gov Lawrence Livermore National Laboratory +1 925 4236634 7000 East Avenue, Livermore, CA94550, USA ------------------------------------------------------------------------ ---------- Forwarded message ---------- Date: Wed, 21 Apr 2010 13:15:39 From: Keith Lindsay To: Philip J. Cameronsmith1 Cc: John.Dunne at noaa.gov, Ernst Maier-Reimer , Corinne Le Quere , Bruce Hackett , Thomas LOUBRIEU , Laurent Bopp , Pierre Friedlingstein , James Orr , Laurence Crosnier , Chris Jones , cf-metadata at ucar.edu, Karl Taylor , Yann BARZIC Subject: Re: [CF-metadata] BGC output for CMIP5 simulations On Wed, 21 Apr 2010, Philip J. Cameronsmith1 wrote: > Hi Keith, et al. > > By no3 I assume you mean the negatively charged nitrate ion (NO3-). In which > case I recommend using 'nitrate' in the standard name instead of 'no3'. This > will then be consistent with existing standard names, and avoid confusion > with the uncharged nitrate radical (NO3). > > In looking at the standard name table I think it would also be more > consistent to use _due_to_ instead of _from_. The latter is mainly used for > physical directions, eg _into_sea_water_from_rivers, while the former is > mainly used when when the quantity is changing _due_to_ another process, eg > tendency_of_air_temperature_due_to_shortwave_heating. > > Hence, I suggest you consider the following: > > net_primary_mole_productivity_of_carbon_due_to_nitrate > > Best wishes, > > Philip > Philip, Thanks for the feedback. Your comments are on target. I propose going with your standard name. Keith ****************************************************************** Keith Lindsay http://*www.*cgd.ucar.edu/oce/klindsay/ email: klindsay at ucar.edu phone: 303-497-1722 fax: 303-497-1700 From alison.pamment at stfc.ac.uk Fri Apr 23 05:14:56 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Fri, 23 Apr 2010 12:14:56 +0100 Subject: [CF-metadata] FW: HAMOCC variablen In-Reply-To: <23f940e23fc528.23fc52823f940e@noaa.gov> References: <23f940e23fc528.23fc52823f940e@noaa.gov> Message-ID: Dear John, Thanks for your comments on the iron flux standard name. Following your advice I think it makes sense to leave it as tendency_of_ocean_mole_content_of_iron_due_to_deposition_and_runoff_and_ sediment_dissolution. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. > -----Original Message----- > From: John.Dunne at noaa.gov [mailto:John.Dunne at noaa.gov] > Sent: 15 April 2010 14:05 > To: Karl Taylor; Pamment, Alison (STFC,RAL,SSTD) > Cc: cf-metadata at cgd.ucar.edu > Subject: Re: FW: [CF-metadata] HAMOCC variablen > > > Hi Karl and Alison, > > With reference to Karl's question about the appropriateness of the > variable standard name for iron supply to the ocean, I was asked to > supply my thoughts. The current variable in the 4/2 tables is: > > tendency_of_ocean_mole_content_of_iron_due_to_deposition_and_runoff_and > _sediment_dissolution > > which, I think, works as a catch-all for all sources of available iron. > Due to the late timing, I think we are now forced to leave it to the > groups to contribute model-specific supply terms beyond this catchall. > My only suggestion for an optional change would be to make the long > names for nitrogen and iron, "Surface downward net flux of Nitrogen" > and > "Surface downward net flux of Iron" more consistent with their > definitions (as was done for Carbon) and changed to "Flux of Nitrogen > into Ocean by runoff, deposition and nitrogen fixation" and "Flux of > Iron into Ocean by runoff, deposition, coasts and sediments" > > Cheers, John > > > -----Original Message----- > > From: Karl Taylor [mailto:taylor13 at llnl.gov] > > Sent: 02 April 2010 18:50 > > To: John.Dunne at noaa.gov; Pamment, Alison (STFC,RAL,SSTD); Stephanie > > Legutke; John.Dunne at noaa.gov > > Cc: Corrine Le Quere; Ernst Maier-Reimer; Laurent Bopp; > > joachim.segschneider at zmaw.de; James Orr > > Subject: Re: [CF-metadata] HAMOCC variablen > > > > Dear all, > > > > [Here is some input from someone with a weak grasp of this area.] > > This seems very confusing. It doesn't seem to me that it makes > > sense to > > > > talk about surface flux of dissolved iron (except in rain drops I > > suppose). We could have a downward surface flux of iron that might > > (quickly, partially or completely) dissolve. If there is some > > component > > of the surface flux of iron that never dissolves (as perhaps is the > > case > > for the iron contained in dust particles), then there really is no > > need > > to keep track of that iron (i.e., it is effectively "inert"). [I > > note, > > however, we are requesting a 3-d field tentatively referred to as > > > tendency_of_mole_concentration_of_dissolved_inorganic_iron_in_sea_water > _ > > due_to_biological_processes, > > which would indicate that there might be some flux of iron from the > > atmosphere that doesn't dissolve immediately, but might later at > > deeper > > depths.] > > > > As noted above I don't think it makes sense to call it "flux of > > dissolved iron", but would be o.k. with "flux of dissolvable iron", > > but > > this asks the model to know what iron will eventually dissolve, > > which > > seems impossible. But someone who knows more about this than I > > should > > weigh in. > > > > So first we need to decide what we want to ask for. Then we need > > to > > name it. > > > > One option might be to request > > > "tendency_of_mole_concentration_of_dissolved_inorganic_iron_in_sea_wate > r > > _due_to_surface_flux_of_iron" > > (or something similar). > > > > What say you all? > > > > Best regards, > > Karl > > > > On 30-Mar-10 5:55 AM, John.Dunne at noaa.gov wrote: > > > Hi Corinne, > > > > > > Good question! Given that we're bound to be using different > > solubility > > > fractions (mine are a climatology variable in space after Fan et > al, > > > 2006), I'd prefer the definition be renamed to "Surface downward > net > > > flux of dissolved iron", unless there are models that include > > subsurface > > > dissolution of dust, in which case I would suggest we add another > > > variable called "Surface downward net flux of total iron". > > Though I > > > would not want to fill this field for my model in order to avoid > > confusion. > > > > > > Cheers, John > > > > > > ----- Original Message ----- > > > From: Corinne Le Quere > > > Date: Tuesday, March 30, 2010 4:17 am > > > Subject: Re: {Spam?} Re: HAMOCC variablen > > > > > > > > >> Hi John, > > >> > > >> I'm forwarding you a question from Stephanie Legutke regarding on > > >> the > > >> CMIP5 variable definition. The "Surface downward net flux of > iron", > > >> does > > >> that means soluble iron or total iron? can you please specify. > > Thanks. > > >> > > >> Best wishes, > > >> Corinne > > >> > > >> On Tue, 30 Mar 2010, Stephanie Legutke wrote: > > >> > > >> > > >>> Hi Corinne, > > >>> as far as I know you are in some sense involved in the > > specification>>> of the list of marine bgc variables that is > > requested for the CMIP5 > > >>> archive. > > >>> There is a question regarding the iron flux into the ocean (see > > >>> > > >> below).> Are you the right person to be addressed? If not you > > >> certainly know > > >> > > >>> whom to ask. > > >>> If you prefer the question to be formulated in English the best > > >>> > > >> would be > > >> > > >>> to contact Katharina Six who wrote the mail below. > > >>> best regards, Stephanie > > >>> > > >>> katharina six wrote: > > >>> > > >>>> Hallo Stephanie, > > >>>> > > >>>> Bei einer Variablen sind wir uns nicht sicher, was gewollt ist: > > >>>> > > >> "Surface>> downward net flux of iron " > > >> > > >>>> Der Eiseneintrag wird aus dem Staubeintrag berechnet, aber > > fuer die > > >>>> Biologie ist es wesentlich, welcher Form das Eisens vorliegt. > Im > > >>>> allgemeinen nehmen die Modelle an, > > >>>> dass nur zwischen 1-10 % des eingetragenen Eisens biologisch > > >>>> > > >> genutzt>> werden kann. Fuer die Vergleichbarkeit des Outputs > > ist es > > >> also wichtig , > > >> > > >>>> ob angegeben werden > > >>>> soll, wieviel Gesamteisen oder wieviel "bioavailable iron" > > >>>> > > >> eingetragen>> wird. Falls du dazu naehere Informationen bekommen > > >> kannst, lass es mich > > >> > > >>>> wissen. > > >>>> Gruss Tinka > > >>>> > > >>>> Stephanie Legutke schrieb: > > >>>> > > >>>>> Hallo Tinka, > > >>>>> es gibt eine neue liste der verlangten variablen vom PCMDI > > >>>>> mit einigen neuen bgc variablen. > > >>>>> -- Scanned by iCritical. From alison.pamment at stfc.ac.uk Fri Apr 23 06:38:47 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Fri, 23 Apr 2010 13:38:47 +0100 Subject: [CF-metadata] CMIP5 ocean biogeochemistry standard names In-Reply-To: References: <40829B0E077C1145A6DE44D39B3830A90887C1EFD0@nerckwmb1.ad.nerc.ac.uk><40829B0E077C1145A6DE44D39B3830A90887D1C5B2@nerckwmb1.ad.nerc.ac.uk> Message-ID: Dear John and Roy, Apart from the iron flux name which was discussed and agreed in the 'HAMOCC variablen' thread, there have been no further comments during the last three weeks on the ocean biogeochemistry names. There is one outstanding question regarding the definition and naming of the picophytoplankton quantities: > > > > > (1) I don't understand what the definition of picophytoplankton > > > (carbon > > > > concentration from the picophytoplankton (<2 um; < 5um) component > > > > alone) means Does it mean cells between 2 and 5 um in size, in > > > which> case it should be expressed as 2-5um, or does it mean > > > something else? > > > > > > > > > > I agree that this definition doesn't make sense as it stands - I'll > > > check with John Dunne. > > > > The wishy-washiness of this definition was intended to account for > the > > fact that some groups make their distinction of smallest > phytoplankton > > class at the <2um size, while others do it at the <5um size. I agree > > that it would be better to have a single cut off for clarity. > Perhaps > > we should use the '2um' designation to be consistent with the > > traditional definition of 'picoplankton' (where nanoplankton is the > 2-5 > > umclass), and leave the individual participants to determine whether > > they think their definition is consistent with this designation. > > >From the CF point of view, adopting a single cut off of <2um for > picophytoplankton would certainly be clear. However, will this cause > problems for modelling groups with different cut off sizes? I.e. will > it > make intercomparison between models difficult? As an alternative, we > could write the definitions to cope with the vagueness, for example: > "Picophytoplankton are the smallest class of phytoplankton. The maximum > size of picophytoplankton is in the range 2-5 um and may vary between > models. A scalar coordinate variable should be used to specify the > maximum size of picophytoplankton included in the data variable." > > This would then require the different modelling groups to specify the > threshold they used, but would allow them all to write their data with > the same standard name. (We could even give the coordinate variable a > standard name such as 'plankton_size_threshold'). Would that be a > suitable solution? Or do you still prefer to stick with the single cut > off? I am hoping that John will advise on which is the best approach to take with these names as I think we are close to being able to accept them. I have temporarily removed these particular names from the attached spreadsheet. The remaining names, including those modified in response to Roy's comments are now accepted for inclusion in the standard name table and are listed in the attached spreadsheet. To summarize, the modifications relative to the original proposals are as follows: Row 13: correction to typo in 'concentration' Rows 37-38: 'organic_carbon' changed to 'particulate_organic_matter_expressed_as_carbon' Row 42: 'particulate_organic_carbon' changed to 'particulate_organic_matter_expressed_as_carbon' Rows 51-54: 'organic_carbon' changed to 'particulate_organic_matter_expressed_as_carbon' Rows 61-62: 'particles' changed to 'inorganic_particles' I should also say that the clarifications to the definitions that have been suggested by both Roy and John during the discussion of these names will be included when the names are added to the table. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > bounces at cgd.ucar.edu] On Behalf Of alison.pamment at stfc.ac.uk > Sent: 01 April 2010 13:28 > To: cf-metadata at cgd.ucar.edu; rkl at bodc.ac.uk; John.Dunne at noaa.gov > Cc: chris.d.jones at metoffice.gov.uk; pierre.friedlingstein at lsce.ipsl.fr; > doutriaux1 at llnl.gov; James.Orr at lsce.ipsl.fr; ernst.maier-reimer at zmaw.de > Subject: Re: [CF-metadata] CMIP5 ocean biogeochemistry standard names > > Dear Roy and John, > > Roy wrote: > > > The one point I think you have possibly misunderstood is the one > about > > 'miscellaneous'. It's not the word, so much as the possibility of > the > > concept having meaning that changes with time that worries me. This > > can be addressed through the definition by a statement that > > 'miscellaneous means phytoplankton that are not diatoms, diazotrophs, > > calcareous phytoplankton or picophytoplankton'. I did briefly > consider > > the phrase 'phytoplankton_not_diatom_diazotroph_calcareous_pico' in > the > > standard name, but then thought better of it. > > > > Yes, I see now. I agree that the definitions should contain a > statement > such as the one you suggest. Thanks for not suggesting the other > version of the name :) > > John wrote: > > > > > (1) I don't understand what the definition of picophytoplankton > > > (carbon > > > > concentration from the picophytoplankton (<2 um; < 5um) component > > > > alone) means Does it mean cells between 2 and 5 um in size, in > > > which> case it should be expressed as 2-5um, or does it mean > > > something else? > > > > > > > > > > I agree that this definition doesn't make sense as it stands - I'll > > > check with John Dunne. > > > > The wishy-washiness of this definition was intended to account for > the > > fact that some groups make their distinction of smallest > phytoplankton > > class at the <2um size, while others do it at the <5um size. I agree > > that it would be better to have a single cut off for clarity. > Perhaps > > we should use the '2um' designation to be consistent with the > > traditional definition of 'picoplankton' (where nanoplankton is the > 2-5 > > umclass), and leave the individual participants to determine whether > > they think their definition is consistent with this designation. > > >From the CF point of view, adopting a single cut off of <2um for > picophytoplankton would certainly be clear. However, will this cause > problems for modelling groups with different cut off sizes? I.e. will > it > make intercomparison between models difficult? As an alternative, we > could write the definitions to cope with the vagueness, for example: > "Picophytoplankton are the smallest class of phytoplankton. The maximum > size of picophytoplankton is in the range 2-5 um and may vary between > models. A scalar coordinate variable should be used to specify the > maximum size of picophytoplankton included in the data variable." > > This would then require the different modelling groups to specify the > threshold they used, but would allow them all to write their data with > the same standard name. (We could even give the coordinate variable a > standard name such as 'plankton_size_threshold'). Would that be a > suitable solution? Or do you still prefer to stick with the single cut > off? > > John wrote: > > > > > (3) 'mole_concenration_of_dissolved_iron_in_sea_water'. Besides > > the > > > > typo (concentration), does this refer to iron in all oxidation > > > states> (Fe2+/Fe3+) and chemical environments. If so, calling it > > > 'total iron' > > > > might be better. > > > > > > Thanks for pointing out the typo - I'll correct it. I think > whenever > > > the word "total" has come up in standard names proposals in the > past > > > that we have tried to avoid using it. Indeed, there are no > standard > > > names that use the term. I think "iron" essentially should be > > > understood to mean "total iron" and if we want more specific names > > for > > > Fe2+, etc, we should introduce terms such as "divalent iron" in the > > > waythat we have done for elemental and divalent mercury in the > > > atmosphere.Having said all that, I think it would be helpful if > > > John could clarify > > > the definition. > > > > In the geochemical literature, 'total' iron refers to the sum of iron > > associated with the particulate organic, particulate inorganic, > > dissolved organic and dissolved inorganic components (both Fe2+ and > > Fe3+). As we treat phytoplankton iron and particulate detrital iron > > separately from dissolved, 'total' does not equal 'dissolved'. As > > most, > > if not all, of the models do not distinguish between Fe2+ and Fe3+, I > > think we could simply add a note in the definition to the effect that > > 'dissolved' is intended to represent both Fe2+ and Fe3+. > > Agreed. I'll add a sentence to the definitions. > > Best wishes, > Alison > > ------ > Alison Pamment Tel: +44 1235 778065 > NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > Rutherford Appleton Laboratory Email: > alison.pamment at stfc.ac.uk > Chilton, Didcot, OX11 0QX, U.K. > > -- > Scanned by iCritical. > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Scanned by iCritical. -------------- next part -------------- A non-text attachment was scrubbed... Name: cf_ocean_biogeochem_names_20100423.xlsx Type: application/octet-stream Size: 18865 bytes Desc: cf_ocean_biogeochem_names_20100423.xlsx URL: From rkl at bodc.ac.uk Fri Apr 23 07:14:53 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Fri, 23 Apr 2010 14:14:53 +0100 Subject: [CF-metadata] CMIP5 ocean biogeochemistry standard names In-Reply-To: References: <40829B0E077C1145A6DE44D39B3830A90887C1EFD0@nerckwmb1.ad.nerc.ac.uk><40829B0E077C1145A6DE44D39B3830A90887D1C5B2@nerckwmb1.ad.nerc.ac.uk> Message-ID: <40829B0E077C1145A6DE44D39B3830A908880EFF2F@nerckwmb1.ad.nerc.ac.uk> Hi Alison, John's response got buried in my 'todo' pile. His 'flexible' definition almost works for me, but I would prefer to take 2um (the definition of field taxonomists) as the default, giving a definition like: 'Picophytoplankton are the smallest size class of phytoplankton with a maximum size of 2um for observational data and some models. Other models may specify the upper limit elsewhere in the range 2-5 um, in which case the actual upper limit used should be specified.' Whether this specification should be done through the long name or a scalar co-ordinate variable as John suggests is something I'm not sure about. Anybody any preferences? Cheers, Roy. -----Original Message----- From: alison.pamment at stfc.ac.uk [mailto:alison.pamment at stfc.ac.uk] Sent: 23 April 2010 13:39 To: cf-metadata at cgd.ucar.edu; Lowry, Roy K; John.Dunne at noaa.gov; taylor13 at llnl.gov Cc: chris.d.jones at metoffice.gov.uk; pierre.friedlingstein at lsce.ipsl.fr; doutriaux1 at llnl.gov; James.Orr at lsce.ipsl.fr; ernst.maier-reimer at zmaw.de Subject: RE: [CF-metadata] CMIP5 ocean biogeochemistry standard names Dear John and Roy, Apart from the iron flux name which was discussed and agreed in the 'HAMOCC variablen' thread, there have been no further comments during the last three weeks on the ocean biogeochemistry names. There is one outstanding question regarding the definition and naming of the picophytoplankton quantities: > > > > > (1) I don't understand what the definition of picophytoplankton > > > (carbon > > > > concentration from the picophytoplankton (<2 um; < 5um) component > > > > alone) means Does it mean cells between 2 and 5 um in size, in > > > which> case it should be expressed as 2-5um, or does it mean > > > something else? > > > > > > > > > > I agree that this definition doesn't make sense as it stands - I'll > > > check with John Dunne. > > > > The wishy-washiness of this definition was intended to account for > the > > fact that some groups make their distinction of smallest > phytoplankton > > class at the <2um size, while others do it at the <5um size. I agree > > that it would be better to have a single cut off for clarity. > Perhaps > > we should use the '2um' designation to be consistent with the > > traditional definition of 'picoplankton' (where nanoplankton is the > 2-5 > > umclass), and leave the individual participants to determine whether > > they think their definition is consistent with this designation. > > >From the CF point of view, adopting a single cut off of <2um for > picophytoplankton would certainly be clear. However, will this cause > problems for modelling groups with different cut off sizes? I.e. will > it make intercomparison between models difficult? As an alternative, > we could write the definitions to cope with the vagueness, for > example: > "Picophytoplankton are the smallest class of phytoplankton. The maximum > size of picophytoplankton is in the range 2-5 um and may vary between > models. A scalar coordinate variable should be used to specify the > maximum size of picophytoplankton included in the data variable." > > This would then require the different modelling groups to specify the > threshold they used, but would allow them all to write their data with > the same standard name. (We could even give the coordinate variable a > standard name such as 'plankton_size_threshold'). Would that be a > suitable solution? Or do you still prefer to stick with the single cut > off? I am hoping that John will advise on which is the best approach to take with these names as I think we are close to being able to accept them. I have temporarily removed these particular names from the attached spreadsheet. The remaining names, including those modified in response to Roy's comments are now accepted for inclusion in the standard name table and are listed in the attached spreadsheet. To summarize, the modifications relative to the original proposals are as follows: Row 13: correction to typo in 'concentration' Rows 37-38: 'organic_carbon' changed to 'particulate_organic_matter_expressed_as_carbon' Row 42: 'particulate_organic_carbon' changed to 'particulate_organic_matter_expressed_as_carbon' Rows 51-54: 'organic_carbon' changed to 'particulate_organic_matter_expressed_as_carbon' Rows 61-62: 'particles' changed to 'inorganic_particles' I should also say that the clarifications to the definitions that have been suggested by both Roy and John during the discussion of these names will be included when the names are added to the table. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > bounces at cgd.ucar.edu] On Behalf Of alison.pamment at stfc.ac.uk > Sent: 01 April 2010 13:28 > To: cf-metadata at cgd.ucar.edu; rkl at bodc.ac.uk; John.Dunne at noaa.gov > Cc: chris.d.jones at metoffice.gov.uk; pierre.friedlingstein at lsce.ipsl.fr; > doutriaux1 at llnl.gov; James.Orr at lsce.ipsl.fr; ernst.maier-reimer at zmaw.de > Subject: Re: [CF-metadata] CMIP5 ocean biogeochemistry standard names > > Dear Roy and John, > > Roy wrote: > > > The one point I think you have possibly misunderstood is the one > about > > 'miscellaneous'. It's not the word, so much as the possibility of > the > > concept having meaning that changes with time that worries me. This > > can be addressed through the definition by a statement that > > 'miscellaneous means phytoplankton that are not diatoms, diazotrophs, > > calcareous phytoplankton or picophytoplankton'. I did briefly > consider > > the phrase 'phytoplankton_not_diatom_diazotroph_calcareous_pico' in > the > > standard name, but then thought better of it. > > > > Yes, I see now. I agree that the definitions should contain a > statement such as the one you suggest. Thanks for not suggesting the > other version of the name :) > > John wrote: > > > > > (1) I don't understand what the definition of picophytoplankton > > > (carbon > > > > concentration from the picophytoplankton (<2 um; < 5um) component > > > > alone) means Does it mean cells between 2 and 5 um in size, in > > > which> case it should be expressed as 2-5um, or does it mean > > > something else? > > > > > > > > > > I agree that this definition doesn't make sense as it stands - I'll > > > check with John Dunne. > > > > The wishy-washiness of this definition was intended to account for > the > > fact that some groups make their distinction of smallest > phytoplankton > > class at the <2um size, while others do it at the <5um size. I agree > > that it would be better to have a single cut off for clarity. > Perhaps > > we should use the '2um' designation to be consistent with the > > traditional definition of 'picoplankton' (where nanoplankton is the > 2-5 > > umclass), and leave the individual participants to determine whether > > they think their definition is consistent with this designation. > > >From the CF point of view, adopting a single cut off of <2um for > picophytoplankton would certainly be clear. However, will this cause > problems for modelling groups with different cut off sizes? I.e. will > it make intercomparison between models difficult? As an alternative, > we could write the definitions to cope with the vagueness, for > example: > "Picophytoplankton are the smallest class of phytoplankton. The maximum > size of picophytoplankton is in the range 2-5 um and may vary between > models. A scalar coordinate variable should be used to specify the > maximum size of picophytoplankton included in the data variable." > > This would then require the different modelling groups to specify the > threshold they used, but would allow them all to write their data with > the same standard name. (We could even give the coordinate variable a > standard name such as 'plankton_size_threshold'). Would that be a > suitable solution? Or do you still prefer to stick with the single cut > off? > > John wrote: > > > > > (3) 'mole_concenration_of_dissolved_iron_in_sea_water'. Besides > > the > > > > typo (concentration), does this refer to iron in all oxidation > > > states> (Fe2+/Fe3+) and chemical environments. If so, calling it > > > 'total iron' > > > > might be better. > > > > > > Thanks for pointing out the typo - I'll correct it. I think > whenever > > > the word "total" has come up in standard names proposals in the > past > > > that we have tried to avoid using it. Indeed, there are no > standard > > > names that use the term. I think "iron" essentially should be > > > understood to mean "total iron" and if we want more specific names > > for > > > Fe2+, etc, we should introduce terms such as "divalent iron" in the > > > waythat we have done for elemental and divalent mercury in the > > > atmosphere.Having said all that, I think it would be helpful if > > > John could clarify the definition. > > > > In the geochemical literature, 'total' iron refers to the sum of iron > > associated with the particulate organic, particulate inorganic, > > dissolved organic and dissolved inorganic components (both Fe2+ and > > Fe3+). As we treat phytoplankton iron and particulate detrital iron > > separately from dissolved, 'total' does not equal 'dissolved'. As > > most, if not all, of the models do not distinguish between Fe2+ and > > Fe3+, I > > think we could simply add a note in the definition to the effect that > > 'dissolved' is intended to represent both Fe2+ and Fe3+. > > Agreed. I'll add a sentence to the definitions. > > Best wishes, > Alison > > ------ > Alison Pamment Tel: +44 1235 778065 > NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > Rutherford Appleton Laboratory Email: > alison.pamment at stfc.ac.uk > Chilton, Didcot, OX11 0QX, U.K. > > -- > Scanned by iCritical. > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Scanned by iCritical. -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From jbgraybeal at mindspring.com Fri Apr 23 08:14:54 2010 From: jbgraybeal at mindspring.com (John Graybeal) Date: Fri, 23 Apr 2010 07:14:54 -0700 Subject: [CF-metadata] CMIP5 ocean biogeochemistry standard names In-Reply-To: <40829B0E077C1145A6DE44D39B3830A908880EFF2F@nerckwmb1.ad.nerc.ac.uk> References: <40829B0E077C1145A6DE44D39B3830A90887C1EFD0@nerckwmb1.ad.nerc.ac.uk><40829B0E077C1145A6DE44D39B3830A90887D1C5B2@nerckwmb1.ad.nerc.ac.uk> <40829B0E077C1145A6DE44D39B3830A908880EFF2F@nerckwmb1.ad.nerc.ac.uk> Message-ID: Scalar coordinate value seems much more computable. I'm assuming if the coordinate value is absent, the default applies. john On Apr 23, 2010, at 06:14, Lowry, Roy K wrote: > Hi Alison, > > John's response got buried in my 'todo' pile. His 'flexible' > definition almost works for me, but I would prefer to take 2um (the > definition of field taxonomists) as the default, giving a definition > like: > > 'Picophytoplankton are the smallest size class of phytoplankton with > a maximum size of 2um for observational data and some models. Other > models may specify the upper limit elsewhere in the range 2-5 um, in > which case the actual upper limit used should be specified.' > > Whether this specification should be done through the long name or a > scalar co-ordinate variable as John suggests is something I'm not > sure about. Anybody any preferences? > > Cheers, Roy. > From John.Dunne at noaa.gov Fri Apr 23 18:02:01 2010 From: John.Dunne at noaa.gov (John.Dunne at noaa.gov) Date: Fri, 23 Apr 2010 20:02:01 -0400 Subject: [CF-metadata] CMIP5 ocean biogeochemistry standard names Message-ID: <25b583d25b6d01.25b6d0125b583d@noaa.gov> After mulling it over, I'd suggest restricting the picoplankton definition to <2, and having a separate definition for nanoplankton, if necessary. I think there is at least one model that has explicit nanoplankton, but not mine, so I'm not sure if it's necessary. ----- Original Message ----- From: "Lowry, Roy K" Date: Friday, April 23, 2010 9:14 am Subject: RE: [CF-metadata] CMIP5 ocean biogeochemistry standard names > Hi Alison, > > John's response got buried in my 'todo' pile. His 'flexible' > definition almost works for me, but I would prefer to take 2um (the > definition of field taxonomists) as the default, giving a > definition like: > > 'Picophytoplankton are the smallest size class of phytoplankton > with a maximum size of 2um for observational data and some models. > Other models may specify the upper limit elsewhere in the range 2-5 > um, in which case the actual upper limit used should be specified.' > > Whether this specification should be done through the long name or > a scalar co-ordinate variable as John suggests is something I'm not > sure about. Anybody any preferences? > > Cheers, Roy. > > > -----Original Message----- > From: alison.pamment at stfc.ac.uk [mailto:alison.pamment at stfc.ac.uk] > Sent: 23 April 2010 13:39 > To: cf-metadata at cgd.ucar.edu; Lowry, Roy K; John.Dunne at noaa.gov; > taylor13 at llnl.govCc: chris.d.jones at metoffice.gov.uk; > pierre.friedlingstein at lsce.ipsl.fr; doutriaux1 at llnl.gov; > James.Orr at lsce.ipsl.fr; ernst.maier-reimer at zmaw.de > Subject: RE: [CF-metadata] CMIP5 ocean biogeochemistry standard names > > Dear John and Roy, > > Apart from the iron flux name which was discussed and agreed in the > 'HAMOCC variablen' thread, there have been no further comments > during the last three weeks on the ocean biogeochemistry names. > There is one outstanding question regarding the definition and > naming of the picophytoplankton quantities: > > > > > > > > (1) I don't understand what the definition of > picophytoplankton> > > (carbon > > > > > concentration from the picophytoplankton (<2 um; < 5um) > component > > > > > alone) means Does it mean cells between 2 and 5 um in > size, in > > > > which> case it should be expressed as 2-5um, or does it mean > > > > something else? > > > > > > > > > > > > > I agree that this definition doesn't make sense as it stands - > I'll > > > > check with John Dunne. > > > > > > The wishy-washiness of this definition was intended to account for > > the > > > fact that some groups make their distinction of smallest > > phytoplankton > > > class at the <2um size, while others do it at the <5um size. I > agree > > > that it would be better to have a single cut off for clarity. > > Perhaps > > > we should use the '2um' designation to be consistent with the > > > traditional definition of 'picoplankton' (where nanoplankton is > the> 2-5 > > > umclass), and leave the individual participants to determine > whether > > > they think their definition is consistent with this designation. > > > > >From the CF point of view, adopting a single cut off of <2um for > > picophytoplankton would certainly be clear. However, will this > cause > > problems for modelling groups with different cut off sizes? I.e. > will > > it make intercomparison between models difficult? As an > alternative, > > we could write the definitions to cope with the vagueness, for > > example: > > "Picophytoplankton are the smallest class of phytoplankton. The > maximum > > size of picophytoplankton is in the range 2-5 um and may vary > between > > models. A scalar coordinate variable should be used to specify > the > > maximum size of picophytoplankton included in the data variable." > > > > This would then require the different modelling groups to specify > the > > threshold they used, but would allow them all to write their data > with > > the same standard name. (We could even give the coordinate > variable a > > standard name such as 'plankton_size_threshold'). Would that be a > > suitable solution? Or do you still prefer to stick with the > single cut > > off? > > I am hoping that John will advise on which is the best approach to > take with these names as I think we are close to being able to > accept them. > I have temporarily removed these particular names from the attached > spreadsheet. > The remaining names, including those modified in response to Roy's > comments are now accepted for inclusion in the standard name table > and are listed in the attached spreadsheet. To summarize, the > modifications relative to the original proposals are as follows: > Row 13: correction to typo in 'concentration' > Rows 37-38: 'organic_carbon' changed to > 'particulate_organic_matter_expressed_as_carbon' > Row 42: 'particulate_organic_carbon' changed to > 'particulate_organic_matter_expressed_as_carbon'Rows 51-54: > 'organic_carbon' changed to > 'particulate_organic_matter_expressed_as_carbon' > Rows 61-62: 'particles' changed to 'inorganic_particles' > > I should also say that the clarifications to the definitions that > have been suggested by both Roy and John during the discussion of > these names will be included when the names are added to the table. > > Best wishes, > Alison > > ------ > Alison Pamment Tel: +44 1235 778065 > NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > Rutherford Appleton Laboratory Email: > alison.pamment at stfc.ac.ukChilton, Didcot, OX11 0QX, U.K. > > > > -----Original Message----- > > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > > bounces at cgd.ucar.edu] On Behalf Of alison.pamment at stfc.ac.uk > > Sent: 01 April 2010 13:28 > > To: cf-metadata at cgd.ucar.edu; rkl at bodc.ac.uk; John.Dunne at noaa.gov > > Cc: chris.d.jones at metoffice.gov.uk; > pierre.friedlingstein at lsce.ipsl.fr; > > doutriaux1 at llnl.gov; James.Orr at lsce.ipsl.fr; > ernst.maier-reimer at zmaw.de > > Subject: Re: [CF-metadata] CMIP5 ocean biogeochemistry standard > names> > > Dear Roy and John, > > > > Roy wrote: > > > > > The one point I think you have possibly misunderstood is the one > > about > > > 'miscellaneous'. It's not the word, so much as the possibility of > > the > > > concept having meaning that changes with time that worries me. > This > > > can be addressed through the definition by a statement that > > > 'miscellaneous means phytoplankton that are not diatoms, > diazotrophs, > > > calcareous phytoplankton or picophytoplankton'. I did briefly > > consider > > > the phrase > 'phytoplankton_not_diatom_diazotroph_calcareous_pico' in > > the > > > standard name, but then thought better of it. > > > > > > > Yes, I see now. I agree that the definitions should contain a > > statement such as the one you suggest. Thanks for not suggesting > the > > other version of the name :) > > > > John wrote: > > > > > > > (1) I don't understand what the definition of > picophytoplankton> > > (carbon > > > > > concentration from the picophytoplankton (<2 um; < 5um) > component > > > > > alone) means Does it mean cells between 2 and 5 um in > size, in > > > > which> case it should be expressed as 2-5um, or does it mean > > > > something else? > > > > > > > > > > > > > I agree that this definition doesn't make sense as it stands - > I'll > > > > check with John Dunne. > > > > > > The wishy-washiness of this definition was intended to account for > > the > > > fact that some groups make their distinction of smallest > > phytoplankton > > > class at the <2um size, while others do it at the <5um size. I > agree > > > that it would be better to have a single cut off for clarity. > > Perhaps > > > we should use the '2um' designation to be consistent with the > > > traditional definition of 'picoplankton' (where nanoplankton is > the> 2-5 > > > umclass), and leave the individual participants to determine > whether > > > they think their definition is consistent with this designation. > > > > >From the CF point of view, adopting a single cut off of <2um for > > picophytoplankton would certainly be clear. However, will this > cause > > problems for modelling groups with different cut off sizes? I.e. > will > > it make intercomparison between models difficult? As an > alternative, > > we could write the definitions to cope with the vagueness, for > > example: > > "Picophytoplankton are the smallest class of phytoplankton. The > maximum > > size of picophytoplankton is in the range 2-5 um and may vary > between > > models. A scalar coordinate variable should be used to specify > the > > maximum size of picophytoplankton included in the data variable." > > > > This would then require the different modelling groups to specify > the > > threshold they used, but would allow them all to write their data > with > > the same standard name. (We could even give the coordinate > variable a > > standard name such as 'plankton_size_threshold'). Would that be a > > suitable solution? Or do you still prefer to stick with the > single cut > > off? > > > > John wrote: > > > > > > > (3) 'mole_concenration_of_dissolved_iron_in_sea_water'. > Besides> > the > > > > > typo (concentration), does this refer to iron in all oxidation > > > > states> (Fe2+/Fe3+) and chemical environments. If so, > calling it > > > > 'total iron' > > > > > might be better. > > > > > > > > Thanks for pointing out the typo - I'll correct it. I think > > whenever > > > > the word "total" has come up in standard names proposals in the > > past > > > > that we have tried to avoid using it. Indeed, there are no > > standard > > > > names that use the term. I think "iron" essentially should > be > > > > understood to mean "total iron" and if we want more specific > names> > for > > > > Fe2+, etc, we should introduce terms such as "divalent iron" in > the > > > > waythat we have done for elemental and divalent mercury in > the > > > > atmosphere.Having said all that, I think it would be helpful > if > > > > John could clarify the definition. > > > > > > In the geochemical literature, 'total' iron refers to the sum of > iron > > > associated with the particulate organic, particulate inorganic, > > > dissolved organic and dissolved inorganic components (both Fe2+ > and> > Fe3+). As we treat phytoplankton iron and particulate > detrital iron > > > separately from dissolved, 'total' does not equal 'dissolved'. > As > > > most, if not all, of the models do not distinguish between Fe2+ > and > > > Fe3+, > I > > > think we could simply add a note in the definition to the effect > that > > > 'dissolved' is intended to represent both Fe2+ and Fe3+. > > > > Agreed. I'll add a sentence to the definitions. > > > > Best wishes, > > Alison > > > > ------ > > Alison Pamment Tel: +44 1235 778065 > > NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > > Rutherford Appleton Laboratory Email: > > alison.pamment at stfc.ac.uk > > Chilton, Didcot, OX11 0QX, U.K. > > > > -- > > Scanned by iCritical. > > _______________________________________________ > > CF-metadata mailing list > > CF-metadata at cgd.ucar.edu > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > -- > Scanned by iCritical. > > > -- > This message (and any attachments) is for the recipient only. NERC > is subject to the Freedom of Information Act 2000 and the contents > of this email and any reply you make may be disclosed by NERC unless > it is exempt from release under the Act. Any material supplied to > NERC may be stored in an electronic records management system. > > From ogura at nies.go.jp Sun Apr 25 19:34:55 2010 From: ogura at nies.go.jp (Tomoo Ogura) Date: Mon, 26 Apr 2010 10:34:55 +0900 Subject: [CF-metadata] proposal for new standard names Message-ID: Dear all I'd like to propose the following 11 standard names, which conform to the existing pattens.They represent the tendency for the mass fraction of cloud condensed water in GCMs. Their units are in 1/s. We hope to use these variables in the Cloud Feedback Model Intercomparison Project (CFMIP). tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_microphysics tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_boundary_layer_mixing tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_Bergeron_Findeisen_process_to_cloud_ice tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_microphysics tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_boundary_layer_mixing tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_Bergeron_Findeisen_process_from_cloud_liquid tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due_to_microphysics tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due_to_boundary_layer_mixing Best wishes, Tomoo --- Tomoo OGURA National Institute for Environmental Studies 16-2 Onogawa, Tsukuba, Ibaraki 305-8506 Japan Phone +81-29-850-2484 Fax +81-29-850-2960 From j.m.gregory at reading.ac.uk Mon Apr 26 01:02:06 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Mon, 26 Apr 2010 08:02:06 +0100 Subject: [CF-metadata] proposal for new standard names In-Reply-To: References: Message-ID: <20100426070206.GB5626@met.reading.ac.uk> Dear Tomoo These names looks OK to me, except I'd suggest due_to_cloud_microphysics instead of just due_to_microphysics, in order to be more explicit; in any case, "cloud microphysics" is a commonly used phrase. Standard names are all lower case, so bergeron_findeisen, rather than Bergeron_Findeisen. Best wishes Jonathan From ogura at nies.go.jp Mon Apr 26 03:17:46 2010 From: ogura at nies.go.jp (Tomoo Ogura) Date: Mon, 26 Apr 2010 18:17:46 +0900 Subject: [CF-metadata] proposal for new standard names References: <20100426070206.GB5626@met.reading.ac.uk> Message-ID: Dear Jonathan Thanks for your reply. I agree with your suggestions and my proposal has been updated as follows: * microphysics replaced by cloud_microphysics * Bergeron_Findeisen written in lower case tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_cloud_microphysics tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_boundary_layer_mixing tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_bergeron_findeisen_process_to_cloud_ice tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_cloud_microphysics tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_boundary_layer_mixing tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_bergeron_findeisen_process_from_cloud_liquid tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due_to_cloud_microphysics tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due_to_boundary_layer_mixing Best wishes Tomoo --- Tomoo OGURA National Institute for Environmental Studies 16-2 Onogawa, Tsukuba, Ibaraki 305-8506 Japan Phone +81-29-850-2484 Fax +81-29-850-2960 ----- Original Message ----- From: "Jonathan Gregory" To: "Tomoo Ogura" ; Sent: Monday, April 26, 2010 4:02 PM Subject: [CF-metadata] proposal for new standard names > Dear Tomoo > > These names looks OK to me, except I'd suggest due_to_cloud_microphysics > instead of just due_to_microphysics, in order to be more explicit; in any > case, "cloud microphysics" is a commonly used phrase. Standard names are > all > lower case, so bergeron_findeisen, rather than Bergeron_Findeisen. > > Best wishes > > Jonathan > > From alison.pamment at stfc.ac.uk Mon Apr 26 04:59:53 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Mon, 26 Apr 2010 11:59:53 +0100 Subject: [CF-metadata] CMIP5 ocean biogeochemistry standard names In-Reply-To: <25b583d25b6d01.25b6d0125b583d@noaa.gov> References: <25b583d25b6d01.25b6d0125b583d@noaa.gov> Message-ID: Dear John D., Roy and John G., Thanks for your comments on the picophytoplankton names. It seems that we are able to go ahead with the simplest solution, which is to define picophytoplankton as having a size <2um to agree with general usage. Therefore the four names mole_concentration_of_picophytoplankton_expressed_as_carbon_in_sea_water ; mol m-3 mass_concentration_of_picophytoplankton_expressed_as_chlorophyll_in_sea_ water; kg m-3 tendency_of_mole_concentration_of_organic_carbon_in_sea_water_due_to_net _primary_production_by_picophytoplankton; mol m-3 s-1 net_primary_mole_productivity_of_carbon_by_picophytoplankton; mol m-2 s-1 are now accepted for inclusion in the standard name table. If anyone wishes to propose similar names for nanoplankton I'm sure they could be included too. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. > -----Original Message----- > From: John.Dunne at noaa.gov [mailto:John.Dunne at noaa.gov] > Sent: 24 April 2010 01:02 > To: Lowry, Roy K > Cc: Pamment, Alison (STFC,RAL,SSTD); cf-metadata at cgd.ucar.edu; > taylor13 at llnl.gov; chris.d.jones at metoffice.gov.uk; > pierre.friedlingstein at lsce.ipsl.fr; doutriaux1 at llnl.gov; > James.Orr at lsce.ipsl.fr; ernst.maier-reimer at zmaw.de > Subject: Re: RE: [CF-metadata] CMIP5 ocean biogeochemistry standard > names > > > After mulling it over, I'd suggest restricting the picoplankton > definition to <2, and having a separate definition for nanoplankton, if > necessary. I think there is at least one model that has explicit > nanoplankton, but not mine, so I'm not sure if it's necessary. > > ----- Original Message ----- > From: "Lowry, Roy K" > Date: Friday, April 23, 2010 9:14 am > Subject: RE: [CF-metadata] CMIP5 ocean biogeochemistry standard names > > > Hi Alison, > > > > John's response got buried in my 'todo' pile. His 'flexible' > > definition almost works for me, but I would prefer to take 2um (the > > definition of field taxonomists) as the default, giving a > > definition like: > > > > 'Picophytoplankton are the smallest size class of phytoplankton > > with a maximum size of 2um for observational data and some models. > > Other models may specify the upper limit elsewhere in the range 2-5 > > um, in which case the actual upper limit used should be specified.' > > > > Whether this specification should be done through the long name or > > a scalar co-ordinate variable as John suggests is something I'm not > > sure about. Anybody any preferences? > > > > Cheers, Roy. > > > > > > -----Original Message----- > > From: alison.pamment at stfc.ac.uk [mailto:alison.pamment at stfc.ac.uk] > > Sent: 23 April 2010 13:39 > > To: cf-metadata at cgd.ucar.edu; Lowry, Roy K; John.Dunne at noaa.gov; > > taylor13 at llnl.govCc: chris.d.jones at metoffice.gov.uk; > > pierre.friedlingstein at lsce.ipsl.fr; doutriaux1 at llnl.gov; > > James.Orr at lsce.ipsl.fr; ernst.maier-reimer at zmaw.de > > Subject: RE: [CF-metadata] CMIP5 ocean biogeochemistry standard names > > > > Dear John and Roy, > > > > Apart from the iron flux name which was discussed and agreed in the > > 'HAMOCC variablen' thread, there have been no further comments > > during the last three weeks on the ocean biogeochemistry names. > > There is one outstanding question regarding the definition and > > naming of the picophytoplankton quantities: > > > > > > > > > > > (1) I don't understand what the definition of > > picophytoplankton> > > (carbon > > > > > > concentration from the picophytoplankton (<2 um; < 5um) > > component > > > > > > alone) means Does it mean cells between 2 and 5 um in > > size, in > > > > > which> case it should be expressed as 2-5um, or does it mean > > > > > something else? > > > > > > > > > > > > > > > > I agree that this definition doesn't make sense as it stands - > > I'll > > > > > check with John Dunne. > > > > > > > > The wishy-washiness of this definition was intended to account > for > > > the > > > > fact that some groups make their distinction of smallest > > > phytoplankton > > > > class at the <2um size, while others do it at the <5um size. I > > agree > > > > that it would be better to have a single cut off for clarity. > > > Perhaps > > > > we should use the '2um' designation to be consistent with the > > > > traditional definition of 'picoplankton' (where nanoplankton is > > the> 2-5 > > > > umclass), and leave the individual participants to determine > > whether > > > > they think their definition is consistent with this designation. > > > > > > >From the CF point of view, adopting a single cut off of <2um for > > > picophytoplankton would certainly be clear. However, will this > > cause > > > problems for modelling groups with different cut off sizes? I.e. > > will > > > it make intercomparison between models difficult? As an > > alternative, > > > we could write the definitions to cope with the vagueness, for > > > example: > > > "Picophytoplankton are the smallest class of phytoplankton. The > > maximum > > > size of picophytoplankton is in the range 2-5 um and may vary > > between > > > models. A scalar coordinate variable should be used to specify > > the > > > maximum size of picophytoplankton included in the data variable." > > > > > > This would then require the different modelling groups to specify > > the > > > threshold they used, but would allow them all to write their data > > with > > > the same standard name. (We could even give the coordinate > > variable a > > > standard name such as 'plankton_size_threshold'). Would that be a > > > suitable solution? Or do you still prefer to stick with the > > single cut > > > off? > > > > I am hoping that John will advise on which is the best approach to > > take with these names as I think we are close to being able to > > accept them. > > I have temporarily removed these particular names from the attached > > spreadsheet. > > The remaining names, including those modified in response to Roy's > > comments are now accepted for inclusion in the standard name table > > and are listed in the attached spreadsheet. To summarize, the > > modifications relative to the original proposals are as follows: > > Row 13: correction to typo in 'concentration' > > Rows 37-38: 'organic_carbon' changed to > > 'particulate_organic_matter_expressed_as_carbon' > > Row 42: 'particulate_organic_carbon' changed to > > 'particulate_organic_matter_expressed_as_carbon'Rows 51-54: > > 'organic_carbon' changed to > > 'particulate_organic_matter_expressed_as_carbon' > > Rows 61-62: 'particles' changed to 'inorganic_particles' > > > > I should also say that the clarifications to the definitions that > > have been suggested by both Roy and John during the discussion of > > these names will be included when the names are added to the table. > > > > Best wishes, > > Alison > > > > ------ > > Alison Pamment Tel: +44 1235 778065 > > NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > > Rutherford Appleton Laboratory Email: > > alison.pamment at stfc.ac.ukChilton, Didcot, OX11 0QX, U.K. > > > > > > > -----Original Message----- > > > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > > > bounces at cgd.ucar.edu] On Behalf Of alison.pamment at stfc.ac.uk > > > Sent: 01 April 2010 13:28 > > > To: cf-metadata at cgd.ucar.edu; rkl at bodc.ac.uk; John.Dunne at noaa.gov > > > Cc: chris.d.jones at metoffice.gov.uk; > > pierre.friedlingstein at lsce.ipsl.fr; > > > doutriaux1 at llnl.gov; James.Orr at lsce.ipsl.fr; > > ernst.maier-reimer at zmaw.de > > > Subject: Re: [CF-metadata] CMIP5 ocean biogeochemistry standard > > names> > > > Dear Roy and John, > > > > > > Roy wrote: > > > > > > > The one point I think you have possibly misunderstood is the one > > > about > > > > 'miscellaneous'. It's not the word, so much as the possibility > of > > > the > > > > concept having meaning that changes with time that worries me. > > This > > > > can be addressed through the definition by a statement that > > > > 'miscellaneous means phytoplankton that are not diatoms, > > diazotrophs, > > > > calcareous phytoplankton or picophytoplankton'. I did briefly > > > consider > > > > the phrase > > 'phytoplankton_not_diatom_diazotroph_calcareous_pico' in > > > the > > > > standard name, but then thought better of it. > > > > > > > > > > Yes, I see now. I agree that the definitions should contain a > > > statement such as the one you suggest. Thanks for not suggesting > > the > > > other version of the name :) > > > > > > John wrote: > > > > > > > > > (1) I don't understand what the definition of > > picophytoplankton> > > (carbon > > > > > > concentration from the picophytoplankton (<2 um; < 5um) > > component > > > > > > alone) means Does it mean cells between 2 and 5 um in > > size, in > > > > > which> case it should be expressed as 2-5um, or does it mean > > > > > something else? > > > > > > > > > > > > > > > > I agree that this definition doesn't make sense as it stands - > > I'll > > > > > check with John Dunne. > > > > > > > > The wishy-washiness of this definition was intended to account > for > > > the > > > > fact that some groups make their distinction of smallest > > > phytoplankton > > > > class at the <2um size, while others do it at the <5um size. I > > agree > > > > that it would be better to have a single cut off for clarity. > > > Perhaps > > > > we should use the '2um' designation to be consistent with the > > > > traditional definition of 'picoplankton' (where nanoplankton is > > the> 2-5 > > > > umclass), and leave the individual participants to determine > > whether > > > > they think their definition is consistent with this designation. > > > > > > >From the CF point of view, adopting a single cut off of <2um for > > > picophytoplankton would certainly be clear. However, will this > > cause > > > problems for modelling groups with different cut off sizes? I.e. > > will > > > it make intercomparison between models difficult? As an > > alternative, > > > we could write the definitions to cope with the vagueness, for > > > example: > > > "Picophytoplankton are the smallest class of phytoplankton. The > > maximum > > > size of picophytoplankton is in the range 2-5 um and may vary > > between > > > models. A scalar coordinate variable should be used to specify > > the > > > maximum size of picophytoplankton included in the data variable." > > > > > > This would then require the different modelling groups to specify > > the > > > threshold they used, but would allow them all to write their data > > with > > > the same standard name. (We could even give the coordinate > > variable a > > > standard name such as 'plankton_size_threshold'). Would that be a > > > suitable solution? Or do you still prefer to stick with the > > single cut > > > off? > > > > > > John wrote: > > > > > > > > > (3) 'mole_concenration_of_dissolved_iron_in_sea_water'. > > Besides> > the > > > > > > typo (concentration), does this refer to iron in all > oxidation > > > > > states> (Fe2+/Fe3+) and chemical environments. If so, > > calling it > > > > > 'total iron' > > > > > > might be better. > > > > > > > > > > Thanks for pointing out the typo - I'll correct it. I think > > > whenever > > > > > the word "total" has come up in standard names proposals in the > > > past > > > > > that we have tried to avoid using it. Indeed, there are no > > > standard > > > > > names that use the term. I think "iron" essentially should > > be > > > > > understood to mean "total iron" and if we want more specific > > names> > for > > > > > Fe2+, etc, we should introduce terms such as "divalent iron" in > > the > > > > > waythat we have done for elemental and divalent mercury in > > the > > > > > atmosphere.Having said all that, I think it would be helpful > > if > > > > > John could clarify the definition. > > > > > > > > In the geochemical literature, 'total' iron refers to the sum of > > iron > > > > associated with the particulate organic, particulate inorganic, > > > > dissolved organic and dissolved inorganic components (both Fe2+ > > and> > Fe3+). As we treat phytoplankton iron and particulate > > detrital iron > > > > separately from dissolved, 'total' does not equal 'dissolved'. > > As > > > > most, if not all, of the models do not distinguish between Fe2+ > > and > > > > Fe3+, > > I > > > > think we could simply add a note in the definition to the effect > > that > > > > 'dissolved' is intended to represent both Fe2+ and Fe3+. > > > > > > Agreed. I'll add a sentence to the definitions. > > > > > > Best wishes, > > > Alison > > > > > > ------ > > > Alison Pamment Tel: +44 1235 778065 > > > NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > > > Rutherford Appleton Laboratory Email: > > > alison.pamment at stfc.ac.uk > > > Chilton, Didcot, OX11 0QX, U.K. > > > > > > -- > > > Scanned by iCritical. > > > _______________________________________________ > > > CF-metadata mailing list > > > CF-metadata at cgd.ucar.edu > > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > -- > > Scanned by iCritical. > > > > > > -- > > This message (and any attachments) is for the recipient only. NERC > > is subject to the Freedom of Information Act 2000 and the contents > > of this email and any reply you make may be disclosed by NERC unless > > it is exempt from release under the Act. Any material supplied to > > NERC may be stored in an electronic records management system. > > > > -- Scanned by iCritical. From alison.pamment at stfc.ac.uk Mon Apr 26 05:47:02 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Mon, 26 Apr 2010 12:47:02 +0100 Subject: [CF-metadata] CMIP5 ocean biogeochemistry standard names In-Reply-To: References: <25b583d25b6d01.25b6d0125b583d@noaa.gov> Message-ID: Sorry, the third name should read: tendency_of_mole_concentration_of_particulate_organic_matter_expressed_a s_carbon_in_sea_water_due_to_net_primary_production_by_picophytoplankton ; mol m-3 s-1 to follow the agreed pattern of the other primary production names. Best wishes, Alison > > Dear John D., Roy and John G., > > Thanks for your comments on the picophytoplankton names. It seems that > we are able to go ahead with the simplest solution, which is to define > picophytoplankton as having a size <2um to agree with general usage. > Therefore the four names > > mole_concentration_of_picophytoplankton_expressed_as_carbon_in_sea_water ; mol m-3 > mass_concentration_of_picophytoplankton_expressed_as_chlorophyll_in_sea_ water; kg m-3 > tendency_of_mole_concentration_of_organic_carbon_in_sea_water_due_to_net _primary_production_by_picophytoplankton; mol m-3 s-1 > net_primary_mole_productivity_of_carbon_by_picophytoplankton; mol m-2 s-1 > > are now accepted for inclusion in the standard name table. > > If anyone wishes to propose similar names for nanoplankton I'm sure > they > could be included too. > > Best wishes, > Alison > ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. From alison.pamment at stfc.ac.uk Tue Apr 27 06:10:47 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Tue, 27 Apr 2010 13:10:47 +0100 Subject: [CF-metadata] CMIP5 ocean biogeochemistry standard names In-Reply-To: References: <25b583d25b6d01.25b6d0125b583d@noaa.gov> Message-ID: Dear John, I was looking again at the biogeochemistry names in preparation for adding them to the CMIP5 output document as accepted standard names. I am concerned that we may have given the wrong names to some of the vertically integrated rates of change in the top 100m of the ocean. Please can you advise on the definitions. Currently the names are listed as: tendency_of_ocean_mole_content_of_dissolved_inorganic_carbon tendency_of_ocean_mole_content_of_dissolved_inorganic_nitrogen tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus tendency_of_ocean_mole_content_of_dissolved_inorganic_iron tendency_of_ocean_mole_content_of_dissolved_inorganic_silicon integral_wrt_depth_of_tendency_of_sea_water_alkalinity_expressed_as_mole _equivalent tendency_of_ocean_mole_content_of_dissolved_inorganic_carbon_due_to_biol ogical_processes tendency_of_ocean_mole_content_of_dissolved_inorganic_nitrogen_due_to_bi ological_processes tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus_due_to_ biological_processes tendency_of_ocean_mole_content_of_dissolved_inorganic_iron_due_to_biolog ical_processes tendency_of_ocean_mole_content_of_dissolved_inorganic_silicon_due_to_bio logical_processes integral_wrt_depth_of_tendency_of_sea_water_alkalinity_expressed_as_mole _equivalent_due_to_biological_processes The first two names are defined as follows: tendency_of_ocean_mole_content_of_dissolved_inorganic_nitrogen 'Net time rate of change of dissolved inorganic carbon in upper 100m' and tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus 'Net time rate of change of nitrogen nutrients (e.g. NO3+NH4) in upper 100m'. If these quantities should be interpreted as the time rate of change of the vertically integrated mole_concentration, then these names are correct. However, the remainder of the names have definitions along the lines of: tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus 'Vertical integral of net time rate of change of phosphate in upper 100m', which is clearly the vertical integral of the rate of change and not the rate of change of the vertical integral. I don't think those two things are identical, are they? If the order of the calculation is important then I think we should adopt the pattern used in the alkalinity names for all these names, i.e., integral_wrt_depth_of_tendency_of_mole_concentration_of_dissolved_inorga nic_phosphorus_in_sea_water, etc. Do you agree? Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. From John.Dunne at noaa.gov Tue Apr 27 12:56:26 2010 From: John.Dunne at noaa.gov (John.Dunne at noaa.gov) Date: Tue, 27 Apr 2010 14:56:26 -0400 Subject: [CF-metadata] CMIP5 ocean biogeochemistry standard names Message-ID: <2643cf42647c29.2647c292643cf4@noaa.gov> Hi Alison, Following the example of the European intercomparison (CARBOCEAN?), the intent was to have two sets of variables for inorganic C, N, P, Fe, Alk and Si for a tracer equation integrated over the upper 100m such as: dtracer/dt = Jtracer + tracer_physics where: 1) Jtracer = the net biological source sink terms integrated in the upper 100m in units of mol m2 s-1 2) dtracer = the time rate of change of the tracer(s) integrated in the upper 100m in units of mol m2 s-1 with the calculation of dtracer allows the back-calculation of the accumulated role of physical processes on the tracers. Make sense? - John ----- Original Message ----- From: alison.pamment at stfc.ac.uk Date: Tuesday, April 27, 2010 8:10 am Subject: RE: [CF-metadata] CMIP5 ocean biogeochemistry standard names > Dear John, > > I was looking again at the biogeochemistry names in preparation for > adding them to the CMIP5 output document as accepted standard > names. I > am concerned that we may have given the wrong names to some of the > vertically integrated rates of change in the top 100m of the ocean. > Please can you advise on the definitions. Currently the names are > listed as: > > tendency_of_ocean_mole_content_of_dissolved_inorganic_carbon > tendency_of_ocean_mole_content_of_dissolved_inorganic_nitrogen > tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus > tendency_of_ocean_mole_content_of_dissolved_inorganic_iron > tendency_of_ocean_mole_content_of_dissolved_inorganic_silicon > integral_wrt_depth_of_tendency_of_sea_water_alkalinity_expressed_as_mole > _equivalent > tendency_of_ocean_mole_content_of_dissolved_inorganic_carbon_due_to_biol > ogical_processes > tendency_of_ocean_mole_content_of_dissolved_inorganic_nitrogen_due_to_bi > ological_processes > tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus_due_to_ > biological_processes > tendency_of_ocean_mole_content_of_dissolved_inorganic_iron_due_to_biolog > ical_processes > tendency_of_ocean_mole_content_of_dissolved_inorganic_silicon_due_to_bio > logical_processes > integral_wrt_depth_of_tendency_of_sea_water_alkalinity_expressed_as_mole > _equivalent_due_to_biological_processes > > The first two names are defined as follows: > tendency_of_ocean_mole_content_of_dissolved_inorganic_nitrogen > 'Net time rate of change of dissolved inorganic carbon in upper 100m' > and > tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus > 'Net time rate of change of nitrogen nutrients (e.g. NO3+NH4) in upper > 100m'. > If these quantities should be interpreted as the time rate of > change of > the vertically integrated mole_concentration, then these names are > correct. > > However, the remainder of the names have definitions along the > lines of: > tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus > 'Vertical integral of net time rate of change of phosphate in upper > 100m', > which is clearly the vertical integral of the rate of change and > not the > rate of change of the vertical integral. I don't think those two > thingsare identical, are they? > > If the order of the calculation is important then I think we should > adopt the pattern used in the alkalinity names for all these names, > i.e., > integral_wrt_depth_of_tendency_of_mole_concentration_of_dissolved_inorga > nic_phosphorus_in_sea_water, etc. Do you agree? > > Best wishes, > Alison > > ------ > Alison Pamment Tel: +44 1235 778065 > NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > Rutherford Appleton Laboratory Email: > alison.pamment at stfc.ac.ukChilton, Didcot, OX11 0QX, U.K. > > > -- > Scanned by iCritical. > From taylor13 at llnl.gov Tue Apr 27 17:46:12 2010 From: taylor13 at llnl.gov (Karl Taylor) Date: Tue, 27 Apr 2010 16:46:12 -0700 Subject: [CF-metadata] CMIP5 ocean biogeochemistry standard names In-Reply-To: <2643cf42647c29.2647c292643cf4@noaa.gov> References: <2643cf42647c29.2647c292643cf4@noaa.gov> Message-ID: <4BD77744.4070603@llnl.gov> Hi Alison, If the column depth is time-invariant (in this case fixed as the uppermost 100 m), then the time-derivative of the vertical integral equals the vertical integral of the time-derivative, so the same name can be used in either case. Best regards, Karl On 27-Apr-10 11:56 AM, John.Dunne at noaa.gov wrote: > Hi Alison, > > Following the example of the European intercomparison (CARBOCEAN?), the > intent was to have two sets of variables for inorganic C, N, P, Fe, Alk > and Si for a tracer equation integrated over the upper 100m such as: > > dtracer/dt = Jtracer + tracer_physics > > where: > > 1) Jtracer = the net biological source sink terms integrated in the > upper 100m in units of mol m2 s-1 > 2) dtracer = the time rate of change of the tracer(s) integrated in the > upper 100m in units of mol m2 s-1 > > with the calculation of dtracer allows the back-calculation of the > accumulated role of physical processes on the tracers. > > Make sense? - John > > ----- Original Message ----- > From: alison.pamment at stfc.ac.uk > Date: Tuesday, April 27, 2010 8:10 am > Subject: RE: [CF-metadata] CMIP5 ocean biogeochemistry standard names > > >> Dear John, >> >> I was looking again at the biogeochemistry names in preparation for >> adding them to the CMIP5 output document as accepted standard >> names. I >> am concerned that we may have given the wrong names to some of the >> vertically integrated rates of change in the top 100m of the ocean. >> Please can you advise on the definitions. Currently the names are >> listed as: >> >> tendency_of_ocean_mole_content_of_dissolved_inorganic_carbon >> tendency_of_ocean_mole_content_of_dissolved_inorganic_nitrogen >> tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus >> tendency_of_ocean_mole_content_of_dissolved_inorganic_iron >> tendency_of_ocean_mole_content_of_dissolved_inorganic_silicon >> integral_wrt_depth_of_tendency_of_sea_water_alkalinity_expressed_as_mole >> _equivalent >> tendency_of_ocean_mole_content_of_dissolved_inorganic_carbon_due_to_biol >> ogical_processes >> tendency_of_ocean_mole_content_of_dissolved_inorganic_nitrogen_due_to_bi >> ological_processes >> tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus_due_to_ >> biological_processes >> tendency_of_ocean_mole_content_of_dissolved_inorganic_iron_due_to_biolog >> ical_processes >> tendency_of_ocean_mole_content_of_dissolved_inorganic_silicon_due_to_bio >> logical_processes >> integral_wrt_depth_of_tendency_of_sea_water_alkalinity_expressed_as_mole >> _equivalent_due_to_biological_processes >> >> The first two names are defined as follows: >> tendency_of_ocean_mole_content_of_dissolved_inorganic_nitrogen >> 'Net time rate of change of dissolved inorganic carbon in upper 100m' >> and >> tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus >> 'Net time rate of change of nitrogen nutrients (e.g. NO3+NH4) in upper >> 100m'. >> If these quantities should be interpreted as the time rate of >> change of >> the vertically integrated mole_concentration, then these names are >> correct. >> >> However, the remainder of the names have definitions along the >> lines of: >> tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus >> 'Vertical integral of net time rate of change of phosphate in upper >> 100m', >> which is clearly the vertical integral of the rate of change and >> not the >> rate of change of the vertical integral. I don't think those two >> thingsare identical, are they? >> >> If the order of the calculation is important then I think we should >> adopt the pattern used in the alkalinity names for all these names, >> i.e., >> integral_wrt_depth_of_tendency_of_mole_concentration_of_dissolved_inorga >> nic_phosphorus_in_sea_water, etc. Do you agree? >> >> Best wishes, >> Alison >> >> ------ >> Alison Pamment Tel: +44 1235 778065 >> NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 >> Rutherford Appleton Laboratory Email: >> alison.pamment at stfc.ac.ukChilton, Didcot, OX11 0QX, U.K. >> >> >> -- >> Scanned by iCritical. >> >> > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > From alison.pamment at stfc.ac.uk Wed Apr 28 04:22:54 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Wed, 28 Apr 2010 11:22:54 +0100 Subject: [CF-metadata] CMIP5 ocean biogeochemistry standard names In-Reply-To: <4BD77744.4070603@llnl.gov> References: <2643cf42647c29.2647c292643cf4@noaa.gov> <4BD77744.4070603@llnl.gov> Message-ID: Dear John, Jonathan and Karl, Thanks all for setting me straight! I see now that we are fine to stick with the tendency names as originally agreed. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > bounces at cgd.ucar.edu] On Behalf Of Karl Taylor > Sent: 28 April 2010 00:46 > To: cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] CMIP5 ocean biogeochemistry standard names > > Hi Alison, > > If the column depth is time-invariant (in this case fixed as the > uppermost 100 m), then the time-derivative of the vertical integral > equals the vertical integral of the time-derivative, so the same name > can be used in either case. > > Best regards, > Karl > > On 27-Apr-10 11:56 AM, John.Dunne at noaa.gov wrote: > > Hi Alison, > > > > Following the example of the European intercomparison (CARBOCEAN?), > the > > intent was to have two sets of variables for inorganic C, N, P, Fe, > Alk > > and Si for a tracer equation integrated over the upper 100m such as: > > > > dtracer/dt = Jtracer + tracer_physics > > > > where: > > > > 1) Jtracer = the net biological source sink terms integrated in the > > upper 100m in units of mol m2 s-1 > > 2) dtracer = the time rate of change of the tracer(s) integrated in > the > > upper 100m in units of mol m2 s-1 > > > > with the calculation of dtracer allows the back-calculation of the > > accumulated role of physical processes on the tracers. > > > > Make sense? - John > > > > ----- Original Message ----- > > From: alison.pamment at stfc.ac.uk > > Date: Tuesday, April 27, 2010 8:10 am > > Subject: RE: [CF-metadata] CMIP5 ocean biogeochemistry standard names > > > > > >> Dear John, > >> > >> I was looking again at the biogeochemistry names in preparation for > >> adding them to the CMIP5 output document as accepted standard > >> names. I > >> am concerned that we may have given the wrong names to some of the > >> vertically integrated rates of change in the top 100m of the ocean. > >> Please can you advise on the definitions. Currently the names are > >> listed as: > >> > >> tendency_of_ocean_mole_content_of_dissolved_inorganic_carbon > >> tendency_of_ocean_mole_content_of_dissolved_inorganic_nitrogen > >> tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus > >> tendency_of_ocean_mole_content_of_dissolved_inorganic_iron > >> tendency_of_ocean_mole_content_of_dissolved_inorganic_silicon > >> > integral_wrt_depth_of_tendency_of_sea_water_alkalinity_expressed_as_mol > e > >> _equivalent > >> > tendency_of_ocean_mole_content_of_dissolved_inorganic_carbon_due_to_bio > l > >> ogical_processes > >> > tendency_of_ocean_mole_content_of_dissolved_inorganic_nitrogen_due_to_b > i > >> ological_processes > >> > tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus_due_to > _ > >> biological_processes > >> > tendency_of_ocean_mole_content_of_dissolved_inorganic_iron_due_to_biolo > g > >> ical_processes > >> > tendency_of_ocean_mole_content_of_dissolved_inorganic_silicon_due_to_bi > o > >> logical_processes > >> > integral_wrt_depth_of_tendency_of_sea_water_alkalinity_expressed_as_mol > e > >> _equivalent_due_to_biological_processes > >> > >> The first two names are defined as follows: > >> tendency_of_ocean_mole_content_of_dissolved_inorganic_nitrogen > >> 'Net time rate of change of dissolved inorganic carbon in upper > 100m' > >> and > >> tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus > >> 'Net time rate of change of nitrogen nutrients (e.g. NO3+NH4) in > upper > >> 100m'. > >> If these quantities should be interpreted as the time rate of > >> change of > >> the vertically integrated mole_concentration, then these names are > >> correct. > >> > >> However, the remainder of the names have definitions along the > >> lines of: > >> tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus > >> 'Vertical integral of net time rate of change of phosphate in upper > >> 100m', > >> which is clearly the vertical integral of the rate of change and > >> not the > >> rate of change of the vertical integral. I don't think those two > >> thingsare identical, are they? > >> > >> If the order of the calculation is important then I think we should > >> adopt the pattern used in the alkalinity names for all these names, > >> i.e., > >> > integral_wrt_depth_of_tendency_of_mole_concentration_of_dissolved_inorg > a > >> nic_phosphorus_in_sea_water, etc. Do you agree? > >> > >> Best wishes, > >> Alison > >> > >> ------ > >> Alison Pamment Tel: +44 1235 778065 > >> NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > >> Rutherford Appleton Laboratory Email: > >> alison.pamment at stfc.ac.ukChilton, Didcot, OX11 0QX, U.K. > >> > >> > >> -- > >> Scanned by iCritical. > >> > >> > > _______________________________________________ > > CF-metadata mailing list > > CF-metadata at cgd.ucar.edu > > http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > > > > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Scanned by iCritical. From alison.pamment at stfc.ac.uk Wed Apr 28 06:23:34 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Wed, 28 Apr 2010 13:23:34 +0100 Subject: [CF-metadata] BGC output for CMIP5 simulations (fwd) In-Reply-To: References: Message-ID: Dear Philip, Thanks very much for forwarding these emails to the list and sorry for not picking up on this thread sooner. The standard names tendency_of_mole_concentration_of_particulate_organic_matter_expressed_a s_carbon_in_sea_water_due_to_net_new_primary_production; mol m-3 s-1 net_new_primary_mole_productivity_of_carbon; mol m-2 s-1 were accepted after discussion in the 'CMIP5 ocean biogeochemistry standard names' thread. However, the name net_primary_mole_productivity_of_carbon_due_to_nitrate is now being proposed for the second quantity because there is some confusion as to the precise meaning of 'new' production. As the accepted names have not yet been added to the standard name table I think we could change them provided everyone agrees. Both names should be changed to be consistent with one another. The phrase 'due_to' is reserved in standard names for describing a process, e.g. 'due_to_convection', so 'due_to_nitrate' doesn't really fit that pattern. Would net_primary_mole_productivity_of_carbon_from_nutrients_containing_nitrat e or just net_primary_mole_productivity_of_carbon_from_nitrate_nutrients be an accurate description? The first name could then be changed to tendency_of_mole_concentration_of_particulate_organic_matter_expressed_a s_carbon_in_sea_water_due_to_net_primary_production_from_{nutrients_cont aining_nitrate}|{nitrate_nutrients}. Perhaps John Dunne could also comment on these ideas. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > bounces at cgd.ucar.edu] On Behalf Of Philip J. Cameronsmith1 > Sent: 22 April 2010 00:05 > To: CF-metadata email list > Subject: Re: [CF-metadata] BGC output for CMIP5 simulations (fwd) > > > Hi, > > It appears that the wrong email address for the CF list was used for > some > of the emails in the conversation below. Hence, I am forwarding the > final email for the record. > > Best wishes, > > Philip > > ----------------------------------------------------------------------- > - > Dr Philip Cameron-Smith Atmospheric, Earth, and Energy Division > pjc at llnl.gov Lawrence Livermore National Laboratory > +1 925 4236634 7000 East Avenue, Livermore, CA94550, > USA > ----------------------------------------------------------------------- > - > > ---------- Forwarded message ---------- > Date: Wed, 21 Apr 2010 13:15:39 > From: Keith Lindsay > To: Philip J. Cameronsmith1 > Cc: John.Dunne at noaa.gov, Ernst Maier-Reimer reimer at zmaw.de>, > Corinne Le Quere , > Bruce Hackett , > Thomas LOUBRIEU , > Laurent Bopp , > Pierre Friedlingstein , > James Orr , Laurence Crosnier ocean.fr>, > Chris Jones , cf- > metadata at ucar.edu, > Karl Taylor , Yann BARZIC > > Subject: Re: [CF-metadata] BGC output for CMIP5 simulations > > On Wed, 21 Apr 2010, Philip J. Cameronsmith1 wrote: > > > Hi Keith, et al. > > > > By no3 I assume you mean the negatively charged nitrate ion (NO3-). > In which > > case I recommend using 'nitrate' in the standard name instead of > 'no3'. This > > will then be consistent with existing standard names, and avoid > confusion > > with the uncharged nitrate radical (NO3). > > > > In looking at the standard name table I think it would also be more > > consistent to use _due_to_ instead of _from_. The latter is mainly > used for > > physical directions, eg _into_sea_water_from_rivers, while the former > is > > mainly used when when the quantity is changing _due_to_ another > process, eg > > tendency_of_air_temperature_due_to_shortwave_heating. > > > > Hence, I suggest you consider the following: > > > > net_primary_mole_productivity_of_carbon_due_to_nitrate > > > > Best wishes, > > > > Philip > > > > Philip, > > Thanks for the feedback. Your comments are on target. I propose going > with your > standard name. > > Keith > > ****************************************************************** > Keith Lindsay http://*www.*cgd.ucar.edu/oce/klindsay/ > email: klindsay at ucar.edu phone: 303-497-1722 fax: 303-497-1700 > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Scanned by iCritical. From alison.pamment at stfc.ac.uk Wed Apr 28 06:48:09 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Wed, 28 Apr 2010 13:48:09 +0100 Subject: [CF-metadata] proposal for new standard names In-Reply-To: References: <20100426070206.GB5626@met.reading.ac.uk> Message-ID: Dear Tomoo, Thank you for your proposals for new cloud feedback standard names. I agree that the wording of the names is fine. I assume that 'cloud_microphysics' is the sum of many of the processes such as bergeron-findeison, heterogeneous and homogeneous nucleation, etc., but does it also include evaporation/condensation for example? If you could list which processes are included in cloud_microphysics that would be very helpful for writing the definitions of the names. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > bounces at cgd.ucar.edu] On Behalf Of Tomoo Ogura > Sent: 26 April 2010 10:18 > To: Jonathan Gregory; cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] proposal for new standard names > > Dear Jonathan > > Thanks for your reply. I agree with your suggestions and my proposal > has been updated as follows: > > * microphysics replaced by cloud_microphysics > * Bergeron_Findeisen written in lower case > > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_t > o_cloud_microphysics > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_t > o_boundary_layer_mixing > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_t > o_bergeron_findeisen_process_to_cloud_ice > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_cloud_m > icrophysics > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_boundar > y_layer_mixing > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_bergero > n_findeisen_process_from_cloud_liquid > tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air > tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_du > e_to_cloud_microphysics > tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_du > e_to_boundary_layer_mixing > > Best wishes > Tomoo > --- > Tomoo OGURA > National Institute for Environmental Studies > 16-2 Onogawa, Tsukuba, Ibaraki 305-8506 Japan > Phone +81-29-850-2484 Fax +81-29-850-2960 > > ----- Original Message ----- > From: "Jonathan Gregory" > To: "Tomoo Ogura" ; > Sent: Monday, April 26, 2010 4:02 PM > Subject: [CF-metadata] proposal for new standard names > > > > Dear Tomoo > > > > These names looks OK to me, except I'd suggest > due_to_cloud_microphysics > > instead of just due_to_microphysics, in order to be more explicit; in > any > > case, "cloud microphysics" is a commonly used phrase. Standard names > are > > all > > lower case, so bergeron_findeisen, rather than Bergeron_Findeisen. > > > > Best wishes > > > > Jonathan > > > > > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Scanned by iCritical. From alison.pamment at stfc.ac.uk Wed Apr 28 07:17:29 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Wed, 28 Apr 2010 14:17:29 +0100 Subject: [CF-metadata] request CF standard nameforchlorophyll-aconcentration in sea water In-Reply-To: <20100420164825.GA13073@met.reading.ac.uk> References: <201004191016.16336.mlankhorst@ucsd.edu><1240F43731C2EB4F8CC9BF70D233B51101AD263C@SRV-XCHANGE-2K3.pc.cls.fr><928FDE7390BB4A4AA67DA41F9F6E2AD5@gvm.ies.jrc.it> <20100420164825.GA13073@met.reading.ac.uk> Message-ID: Dear Matthias, Thank you for your proposal for the new standard name mass_concentration_of_chlorophyll_a_in_sea_water; kg m-3 and thank you to those who provided comments. There seems to be agreement that there is a need for this name and, as Jonathan says, it can be introduced alongside the existing more generic name. Therefore, the name is accepted for inclusion in the standard name table and it will be added at the next update. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory > Sent: 20 April 2010 17:48 > To: Frederic MELIN > Cc: cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] request CF standard nameforchlorophyll- > aconcentration in sea water > > Dear all > > > The name for chlorophyll has been defined for some time, and honestly > I > > assumed that it was referring to chlorophyll-a. > > As Matthias mentions, to be more rigorous (and to be able to > distinguish > > between chlorophylls (a, b, c1, c2 ...) , introducing > > mass_concentration_of_chlorophyll_a_in_sea_water is needed (this is a > major > > pigment and the primary ocean colour remote sensing product). > > It would seem fine to me to have standard names both for chlorophyll > generically (as we have now) and chlorophyll_a etc. specifically as > required. > Different applications need different degrees of precision and standard > names > can accommodate this. > > Cheers > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Scanned by iCritical. From SEmsley at argans.co.uk Wed Apr 28 08:14:04 2010 From: SEmsley at argans.co.uk (Stephen Emsley) Date: Wed, 28 Apr 2010 15:14:04 +0100 Subject: [CF-metadata] Separating geolocation/timing co-ordinates from measurement data Message-ID: <5B828D1373752F43A43240B3EBF08FF3012CC7F7F0@SVR-SBS2008.sbsnetwork.local> We have multiple satellite geophysical data products which share the same set of geo-location and timing co-ordinates. To avoid product bloat (e.g. from approx. 30GB to 90GB per orbit) we are considering the possibility of having a single file storing the co-ordinates but we think that this conflicts with our desire to be CF Convention conformant. Is that correct? Many thanks Steve -- Dr Stephen Emsley :: ARGANS Limited :: www.argans.co.uk T: +44 1752 764289 | M: +44 7912 515418 | SEmsley at argans.co.uk This message is to be treated as private and confidential, and the information in it may not be used or disclosed except for the purpose for which it has been sent. ARGANS is a limited company registered in England & Wales. Registered number: 6313966. Registered address: Thatchers, Russells Water, Henley on Thames, Oxon, RG9 6EU -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.m.gregory at reading.ac.uk Wed Apr 28 08:43:44 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Wed, 28 Apr 2010 15:43:44 +0100 Subject: [CF-metadata] Separating geolocation/timing co-ordinates from measurement data In-Reply-To: <5B828D1373752F43A43240B3EBF08FF3012CC7F7F0@SVR-SBS2008.sbsnetwork.local> References: <5B828D1373752F43A43240B3EBF08FF3012CC7F7F0@SVR-SBS2008.sbsnetwork.local> Message-ID: <20100428144344.GB23513@met.reading.ac.uk> Dear Steve > We have multiple satellite geophysical data products which share the > same set of geo-location and timing co-ordinates. To avoid product > bloat (e.g. from approx. 30GB to 90GB per orbit) we are considering > the possibility of having a single file storing the co-ordinates but > we think that this conflicts with our desire to be CF Convention > conformant. Is that correct? It is technically non-conformant but it has already been done in other applications, including CMIP5 in some respects. I think we need a convention for this, but we have not agreed one. My suggestion is that it should be OK to give the name of the coordinate variables in the file where they reside. Software will have to regard several files as one dataset, in which case it would be able to find the coordinate variables by name. Are they 1D (Unidata) coordinate variables, or auxiliary coordinate variable (named by the CF coordinates attr) that you want to omit? Best wishes Jonathan From Upendra.Dadi at noaa.gov Wed Apr 28 08:47:41 2010 From: Upendra.Dadi at noaa.gov (Upendra Dadi) Date: Wed, 28 Apr 2010 10:47:41 -0400 Subject: [CF-metadata] handling climatological bounds in CF Message-ID: <4BD84A8D.3060902@noaa.gov> Hello, I am trying to create a CF compliant NetCDF containing climatological statistics. The data consists of monthly means of a certain parameter which is calculated from data which starts on 1773-1-13 and ends on 2001-6-29. How do I represent this information using climatology variable ? The examples in the documentation don't tell how to represent this information. All the examples in the documentation have their climatological bounds which start and end exactly at the start date and end date of the climatology intervals. But in general this is not the case. Climatology variable tries to represent more than one piece information in a single variable - the climatology intervals(day, month, season,etc.) and the actual bounds (start date and end date). I am not sure if this is the reason for the problem. Also, is there any significance to year in the time variable when representing climatological information? Or can I start from any year? Any help is appreciated. Upendra From V.Balaji at noaa.gov Wed Apr 28 09:03:40 2010 From: V.Balaji at noaa.gov (V. Balaji) Date: Wed, 28 Apr 2010 11:03:40 -0400 (EDT) Subject: [CF-metadata] Separating geolocation/timing co-ordinates from measurement data In-Reply-To: <20100428144344.GB23513@met.reading.ac.uk> References: <5B828D1373752F43A43240B3EBF08FF3012CC7F7F0@SVR-SBS2008.sbsnetwork.local> <20100428144344.GB23513@met.reading.ac.uk> Message-ID: This returns to the associated_files attribute that has been discussed on this list. With that it would be possible to point to an auxiliary coordinate that resides in another file. Thanks, Jonathan Gregory writes: > Dear Steve > >> We have multiple satellite geophysical data products which share the >> same set of geo-location and timing co-ordinates. To avoid product >> bloat (e.g. from approx. 30GB to 90GB per orbit) we are considering >> the possibility of having a single file storing the co-ordinates but >> we think that this conflicts with our desire to be CF Convention >> conformant. Is that correct? > > It is technically non-conformant but it has already been done in other > applications, including CMIP5 in some respects. I think we need a convention > for this, but we have not agreed one. My suggestion is that it should be OK > to give the name of the coordinate variables in the file where they reside. > Software will have to regard several files as one dataset, in which case it > would be able to find the coordinate variables by name. Are they 1D (Unidata) > coordinate variables, or auxiliary coordinate variable (named by the CF > coordinates attr) that you want to omit? > > Best wishes > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -- 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 From j.m.gregory at reading.ac.uk Wed Apr 28 09:07:42 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Wed, 28 Apr 2010 16:07:42 +0100 Subject: [CF-metadata] Separating geolocation/timing co-ordinates from measurement data In-Reply-To: References: <5B828D1373752F43A43240B3EBF08FF3012CC7F7F0@SVR-SBS2008.sbsnetwork.local> <20100428144344.GB23513@met.reading.ac.uk> Message-ID: <20100428150742.GA23665@met.reading.ac.uk> Dear Balaji > This returns to the associated_files attribute that has been discussed > on this list. With that it would be possible to point to an auxiliary > coordinate that resides in another file. Yes, it does relate to that issue. As you know, I feel that it's better to avoid naming one file in another file, which is why I suggest just giving the name of the variable. But we really ought to decide a convention for this. Best wishes Jonathan From caron at unidata.ucar.edu Wed Apr 28 09:31:18 2010 From: caron at unidata.ucar.edu (John Caron) Date: Wed, 28 Apr 2010 09:31:18 -0600 Subject: [CF-metadata] Separating geolocation/timing co-ordinates from measurement data In-Reply-To: <5B828D1373752F43A43240B3EBF08FF3012CC7F7F0@SVR-SBS2008.sbsnetwork.local> References: <5B828D1373752F43A43240B3EBF08FF3012CC7F7F0@SVR-SBS2008.sbsnetwork.local> Message-ID: <4BD854C6.9030303@unidata.ucar.edu> On 4/28/2010 8:14 AM, Stephen Emsley wrote: > > We have multiple satellite geophysical data products which share the > same set of geo-location and timing co-ordinates. To avoid product > bloat (e.g. from approx. 30GB to 90GB per orbit) we are considering > the possibility of having a single file storing the co-ordinates but > we think that this conflicts with our desire to be CF Convention > conformant. Is that correct? > > Many thanks > > Steve > > -- > > Dr Stephen Emsley *::* ARGANS Limited *::* www.argans.co.uk > > T: +44 1752 764289 *|* M: +44 7912 515418 *|* SEmsley at argans.co.uk > > / / > > This message is to be treated as private and confidential, and the > information in it may not be used or disclosed except for the purpose > for which it has been sent. ARGANS is a limited company registered in > England & Wales. Registered number: 6313966. Registered address: > Thatchers, Russells Water, Henley on Thames, Oxon, RG9 6EU > > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > There are 2 classes of proposed solutions to this problem: 1) place metadata inside the netcdf files to associate different files together. Balaji's gridspec (at least some version of it) has a proposal for this. Other ideas in this category have also been proposed on this list. 2) create an external document that associates different files together. This is what NcML "union" aggregation does, and Im sure there are other mechanisms already in use that take this approach. The java-netcdf library currently is the only code that can deal fully with NcML, although other projects, including the netcdf-c library, have plans to add NcML support. The THREDDS Data Server (TDS) makes it reletively easy to use NcML on a server, allowing remote access. Each approach has pros and cons. It might be helpful to describe what use cases we want to cover. -------------- next part -------------- An HTML attachment was scrubbed... URL: From SEmsley at argans.co.uk Wed Apr 28 09:45:09 2010 From: SEmsley at argans.co.uk (Stephen Emsley) Date: Wed, 28 Apr 2010 16:45:09 +0100 Subject: [CF-metadata] Separating geolocation/timing co-ordinates from measurement data In-Reply-To: <20100428144344.GB23513@met.reading.ac.uk> References: <5B828D1373752F43A43240B3EBF08FF3012CC7F7F0@SVR-SBS2008.sbsnetwork.local> <20100428144344.GB23513@met.reading.ac.uk> Message-ID: <5B828D1373752F43A43240B3EBF08FF3012CC7F7FC@SVR-SBS2008.sbsnetwork.local> Dear Jonathan They are DEM corrected geodetic latitude, longitude, and altitude spatial co-ordinates as 2D arrays (n_pixels within swatch x n_lines in product) and measurement time as a 1D array (n_lines). So despite the naming the spatial co-ordinates are not Unidata ... and I assume will have to be renamed. The reason I asked is that I noted the discussion (swatch observational data >> multiple file datasets) last year but on re-reading the was uncertain whether this was work in progress or to be included when the next version of the convention is released. >From your, V.Balaji's and John Caron's response I guess that this is still under discussion. Many thanks for your help. I will follow up on the suggestions. Kind Regards Steve -- Dr Stephen Emsley??????? ??????????????????????????????????????????????T: +44 (0)1752 764 289 ? ARGANS Limited????????????????????????????????????????????????????? ?M: +44 (0)7912 515 418 -----Original Message----- From: Jonathan Gregory [mailto:jonathan at met.reading.ac.uk] On Behalf Of Jonathan Gregory Sent: 28 April 2010 15:44 To: Stephen Emsley Cc: cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] Separating geolocation/timing co-ordinates from measurement data Dear Steve > We have multiple satellite geophysical data products which share the > same set of geo-location and timing co-ordinates. To avoid product > bloat (e.g. from approx. 30GB to 90GB per orbit) we are considering > the possibility of having a single file storing the co-ordinates but > we think that this conflicts with our desire to be CF Convention > conformant. Is that correct? It is technically non-conformant but it has already been done in other applications, including CMIP5 in some respects. I think we need a convention for this, but we have not agreed one. My suggestion is that it should be OK to give the name of the coordinate variables in the file where they reside. Software will have to regard several files as one dataset, in which case it would be able to find the coordinate variables by name. Are they 1D (Unidata) coordinate variables, or auxiliary coordinate variable (named by the CF coordinates attr) that you want to omit? Best wishes Jonathan From j.m.gregory at reading.ac.uk Wed Apr 28 11:10:23 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Wed, 28 Apr 2010 18:10:23 +0100 Subject: [CF-metadata] Separating geolocation/timing co-ordinates from measurement data In-Reply-To: <5B828D1373752F43A43240B3EBF08FF3012CC7F7FC@SVR-SBS2008.sbsnetwork.local> References: <5B828D1373752F43A43240B3EBF08FF3012CC7F7F0@SVR-SBS2008.sbsnetwork.local> <20100428144344.GB23513@met.reading.ac.uk> <5B828D1373752F43A43240B3EBF08FF3012CC7F7FC@SVR-SBS2008.sbsnetwork.local> Message-ID: <20100428171023.GA24516@met.reading.ac.uk> Dear Steve > From your, V.Balaji's and John Caron's response I guess that this is still under discussion. I would say so, yes. Also, I think it is less problematic to omit auxiliary coordinate variables from a file than (Unidata) coordinate variables. Best wishes Jonathan From taylor13 at llnl.gov Wed Apr 28 11:25:09 2010 From: taylor13 at llnl.gov (Karl Taylor) Date: Wed, 28 Apr 2010 10:25:09 -0700 Subject: [CF-metadata] Separating geolocation/timing co-ordinates from measurement data In-Reply-To: <5B828D1373752F43A43240B3EBF08FF3012CC7F7F0@SVR-SBS2008.sbsnetwork.local> References: <5B828D1373752F43A43240B3EBF08FF3012CC7F7F0@SVR-SBS2008.sbsnetwork.local> Message-ID: <4BD86F75.7050101@llnl.gov> Dear Steve, If this coordinate information is to be stored as auxiliary coordinate variable, one option is to do something similar to what we've done in CMIP5. Like others, I'm not advocating this as the best solution for CF, but it seems useful until a convention for doing this is accepted. In CMIP5 we point to gridspec files and also files containing cell_measures, so that this information doesn't have to be encoded in each of the netCDF files. In your case for a variable, which I've named "irradiance", the information might look like: float irradiance(time, i, j) irradiance: coordinates = "lat lon" irradiance: associated_files = "baseURL: http://cmip-pcmdi.llnl.gov/CMIP5/dataLocation lat: latitude.nc lon: longitude.nc" The lat and lon variables would not be found in the file containing irradiance, but lat(time, i, j) would be found in latitude.nc and lon would be found in longitude.nc (or they both could be in a single file if you want with the obvious modification of associated_files -- e.g., lat: coord.nc lon: coord.nc). The files would be found at a location pointed to by baseURL. I've also provided an example of CMIP5 output below with the cell_measures reliance on associated_files. Best regards, Karl Example 1: Usual Treatment of a 2-D Field (surface latent heat flux; a function of longitude, latitude, month) netcdf hfls_Amon_GICCM1_abrupt4xCO2_r1i1p1_198001-198002 { dimensions: time = UNLIMITED ; // (2 currently) lat = 3 ; lon = 4 ; bnds = 2 ; variables: double time(time) ; time:bounds = "time_bnds" ; time:units = "days since 1980" ; time:calendar = "standard" ; time:axis = "T" ; time:long_name = "time" ; time:standard_name = "time" ; double time_bnds(time, bnds) ; double lat(lat) ; lat:bounds = "lat_bnds" ; lat:units = "degrees_north" ; lat:axis = "Y" ; lat:long_name = "latitude" ; lat:standard_name = "latitude" ; double lat_bnds(lat, bnds) ; double lon(lon) ; lon:bounds = "lon_bnds" ; lon:units = "degrees_east" ; lon:axis = "X" ; lon:long_name = "longitude" ; lon:standard_name = "longitude" ; double lon_bnds(lon, bnds) ; float hfls(time, lat, lon) ; hfls:standard_name = "surface_upward_latent_heat_flux" ; hfls:long_name = "Surface Upward Latent Heat Flux" ; hfls:comment = "comment from CMIP5 table: includes both evaporation and sublimation" ; hfls:units = "W m-2" ; hfls:original_name = "LATENT" ; hfls:history = "2010-04-21T21:05:23Z altered by CMOR: Changed sign. Inverted axis: lat." ; hfls:cell_methods = "time: mean" ; hfls:cell_measures = "area: areacella" ; hfls:associated_files = "baseURL: http://cmip-pcmdi.llnl.gov/CMIP5/dataLocation gridspecFile: gridspec_fx_GICCM1_abrupt4xCO2_r0i0p0.nc areacella: areacella_fx_GICCM1_abrupt4xCO2_r0i0p0.nc" ; hfls:_FillValue = 1.e+20f ; hfls:missing_value = 1.e+20f ; // global attributes: :institution = "GICC (Generic International Climate Center, Geneva, Switzerland)" ; :institute_id = "GICC" ; :experiment_id = "abrupt4xCO2" ; :source = "GICCM1 (2002): atmosphere: GICAM3 (gicam_0_brnchT_itea_2, T63L32); ocean: MOM (mom3_ver_3.5.2, 2x3L15); sea ice: GISIM4; land: GILSM2.5" ; :model_id = "GICCM1" ; :forcing = "GHG (CO2 only)" ; :parent_experiment_id = "piControl" ; :branch_time = 365. ; :contact = "Rusty Koder (koder at middle_earth.net)" ; :history = "Output from archive/giccm_03_std_2xCO2_2256. 2010-04-21T21:05:23Z CMOR rewrote data to comply with CF standards and CMIP5 requirements." ; :references = "Model described by Koder and Tolkien (J. Geophys. Res., 2001, 576-591). Also see http://www.GICC.su/giccm/doc/index.html 2XCO2 simulation described in Dorkey et al. \'(Clim. Dyn., 2003, 323-357.)" ; :initialization_method = 1 ; :physics_version = 1 ; :tracking_id = "c35a58c3-8978-4628-9103-9a7d61002e07" ; :product = "output" ; :experiment = "abrupt 4XCO2" ; :frequency = "mon" ; :creation_date = "2010-04-21T21:05:23Z" ; :Conventions = "CF-1.4" ; :project_id = "CMIP5" ; :table_id = "Table Amon (02 April 2010)" ; :title = "GICCM1 model output prepared for CMIP5 abrupt 4XCO2" ; :modeling_realm = "atmos" ; :realization = 1 ; data: time = 15.5, 45.5 ; time_bnds = 0, 31, 31, 60 ; lat = 10, 20, 30 ; lat_bnds = 5, 15, 15, 25, 25, 35 ; lon = 0, 90, 180, 270 ; lon_bnds = -45, 45, 45, 135, 135, 225, 225, 315 ; hfls = 120, 116, 112, 108, 104, 100, 96, 92, 88, 84, 80, 76, 119, 115, 111, 107, 103, 99, 95, 91, 87, 83, 79, 75 ; } On 28-Apr-10 7:14 AM, Stephen Emsley wrote: > > We have multiple satellite geophysical data products which share the > same set of geo-location and timing co-ordinates. To avoid product > bloat (e.g. from approx. 30GB to 90GB per orbit) we are considering > the possibility of having a single file storing the co-ordinates but > we think that this conflicts with our desire to be CF Convention > conformant. Is that correct? > > Many thanks > > Steve > > -- > > Dr Stephen Emsley *::* ARGANS Limited *::* www.*argans.co.uk > > T: +44 1752 764289 *|* M: +44 7912 515418 *|* SEmsley at argans.co.uk > > / / > > This message is to be treated as private and confidential, and the > information in it may not be used or disclosed except for the purpose > for which it has been sent. ARGANS is a limited company registered in > England & Wales. Registered number: 6313966. Registered address: > Thatchers, Russells Water, Henley on Thames, Oxon, RG9 6EU > > > _______________________________________________ > 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: From ngalbraith at whoi.edu Wed Apr 28 13:08:45 2010 From: ngalbraith at whoi.edu (Nan Galbraith) Date: Wed, 28 Apr 2010 15:08:45 -0400 Subject: [CF-metadata] [CF Metadata] #37: Conventions for Point Observation Data In-Reply-To: <075.4f3fd9715cccb361100233ef3a07bd74@lists.llnl.gov> References: <066.1ef3b408c50e7b83f958df680608e081@lists.llnl.gov> <075.4f3fd9715cccb361100233ef3a07bd74@lists.llnl.gov> Message-ID: <4BD887BD.2030501@whoi.edu> Hi Steve - Thanks for the reply; I'll look into the GHRSST data standards docs and see if that approach would work in this case - although, frankly, I'm not too optimistic. If the GHRSST data generation community isn't much smaller than that of in situ observational oceanographic data providers overall, I'd guess that it is at least far more homogeneous. Also, the fact that GHRSST has tools and a data portal gives you a fair amount of leverage in deciding on a standard approach. I'm looking for a more broad-based set of recommendations, something people might voluntarily adopt - and, just maybe, tools will be written to use it. While OceanSITES is working on the problem of metadata for in situ instruments, several other groups are, too - IOOS and possibly OOI (not sure about this, though). In any case, I don't think OceanSITES is in a position to create and support standards beyond our own project. And, since so many observational oceanographic projects are using CF, this list seems like the best place to start asking. So, I'll start a new ticket; your point about PointObs is well taken. You ARE volunteering to be the moderator, right? Thanks - Nan > -----------------------------+---------------------------------------------- > Comment (by stevehankin): > > Nan, > > It is an important subtlety that you've raised: defining a general > structure for in situ data versus meeting the needs of operational > oceanography. I'd argue that the role of CF, per se, should be limited to > the former -- to define the structures needed to carry in situ data > collections. It would then be the task of the oceanography community to > define a more detailed profile that builds upon CF and requires the > specific metadata elements that operational oceanographers need. (In the > satellite community the GHRSST data standards documents (the 'GDS') > provide an excellent example of this approach. Ocean-Sites is doing this, > too, isn't it?) > > The boundary between these two goals, however, is a gray area. It would > be a positive contribution to CF if we can add those attributes (metadata > content) into it that are generally applicable to many types of in situ > observations. I'd argue, though, that those discussions should take place > in a *separate* trac ticket from this one. This ticket already has a very > full plate in dealing with the general in situ data structure issues. > -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* From cameronsmith1 at llnl.gov Wed Apr 28 16:03:51 2010 From: cameronsmith1 at llnl.gov (Philip J. Cameronsmith1) Date: Wed, 28 Apr 2010 15:03:51 -0700 (PDT) Subject: [CF-metadata] BGC output for CMIP5 simulations (fwd) In-Reply-To: References: Message-ID: Hi Alison, Thanks for your email. I am not an expert on ecosystems, and so will defer to those who are. I had assumed that the variable was for carbon production CAUSED by nitrate through some process, in which case _due_to_ seemed to me to be appropriate. Going back to your spreadsheet, I see that the description for net_new_primary_mole_productivity_of_carbon was 'Vertically integrated primary (organic carbon) production by phytoplankton based on NO3 alone'. So now I'm not so sure, and need guidance from an expert. Is this quantity just being calculated using nitrate as a proxy data source, or is it production caused by nitrate? BTW, we might consider replacing NO3 and NH4 in the description with 'nitrate' and 'ammonium', or 'NO3-' and 'NH4+', or making it unambiguous in some other way, that these are ions and not radicals. Admittedly, this is probably obvious to most people with some familiarity with the chemistry or biology, but we might as well be precise. Best wishes, Philip On Wed, 28 Apr 2010, alison.pamment at stfc.ac.uk wrote: > Dear Philip, > > Thanks very much for forwarding these emails to the list and sorry for > not picking up on this thread sooner. > > The standard names > tendency_of_mole_concentration_of_particulate_organic_matter_expressed_a > s_carbon_in_sea_water_due_to_net_new_primary_production; mol m-3 s-1 > net_new_primary_mole_productivity_of_carbon; mol m-2 s-1 > were accepted after discussion in the 'CMIP5 ocean biogeochemistry > standard names' thread. > > However, the name > net_primary_mole_productivity_of_carbon_due_to_nitrate > is now being proposed for the second quantity because there is some > confusion as to the precise meaning of 'new' production. > > As the accepted names have not yet been added to the standard name table > I think we could change them provided everyone agrees. Both names should > be changed to be consistent with one another. The phrase 'due_to' is > reserved in standard names for describing a process, e.g. > 'due_to_convection', so 'due_to_nitrate' doesn't really fit that > pattern. Would > net_primary_mole_productivity_of_carbon_from_nutrients_containing_nitrat > e > or just > net_primary_mole_productivity_of_carbon_from_nitrate_nutrients > be an accurate description? > > The first name could then be changed to > tendency_of_mole_concentration_of_particulate_organic_matter_expressed_a > s_carbon_in_sea_water_due_to_net_primary_production_from_{nutrients_cont > aining_nitrate}|{nitrate_nutrients}. > > Perhaps John Dunne could also comment on these ideas. > > Best wishes, > Alison > > ------ > Alison Pamment Tel: +44 1235 778065 > NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk > Chilton, Didcot, OX11 0QX, U.K. > > >> -----Original Message----- >> From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- >> bounces at cgd.ucar.edu] On Behalf Of Philip J. Cameronsmith1 >> Sent: 22 April 2010 00:05 >> To: CF-metadata email list >> Subject: Re: [CF-metadata] BGC output for CMIP5 simulations (fwd) >> >> >> Hi, >> >> It appears that the wrong email address for the CF list was used for >> some >> of the emails in the conversation below. Hence, I am forwarding the >> final email for the record. >> >> Best wishes, >> >> Philip >> >> > ----------------------------------------------------------------------- >> - >> Dr Philip Cameron-Smith Atmospheric, Earth, and Energy Division >> pjc at llnl.gov Lawrence Livermore National Laboratory >> +1 925 4236634 7000 East Avenue, Livermore, CA94550, >> USA >> > ----------------------------------------------------------------------- >> - >> >> ---------- Forwarded message ---------- >> Date: Wed, 21 Apr 2010 13:15:39 >> From: Keith Lindsay >> To: Philip J. Cameronsmith1 >> Cc: John.Dunne at noaa.gov, Ernst Maier-Reimer > reimer at zmaw.de>, >> Corinne Le Quere , >> Bruce Hackett , >> Thomas LOUBRIEU , >> Laurent Bopp , >> Pierre Friedlingstein , >> James Orr , Laurence Crosnier > > ocean.fr>, >> Chris Jones , cf- >> metadata at ucar.edu, >> Karl Taylor , Yann BARZIC >> >> Subject: Re: [CF-metadata] BGC output for CMIP5 simulations >> >> On Wed, 21 Apr 2010, Philip J. Cameronsmith1 wrote: >> >>> Hi Keith, et al. >>> >>> By no3 I assume you mean the negatively charged nitrate ion (NO3-). >> In which >>> case I recommend using 'nitrate' in the standard name instead of >> 'no3'. This >>> will then be consistent with existing standard names, and avoid >> confusion >>> with the uncharged nitrate radical (NO3). >>> >>> In looking at the standard name table I think it would also be more >>> consistent to use _due_to_ instead of _from_. The latter is mainly >> used for >>> physical directions, eg _into_sea_water_from_rivers, while the > former >> is >>> mainly used when when the quantity is changing _due_to_ another >> process, eg >>> tendency_of_air_temperature_due_to_shortwave_heating. >>> >>> Hence, I suggest you consider the following: >>> >>> net_primary_mole_productivity_of_carbon_due_to_nitrate >>> >>> Best wishes, >>> >>> Philip >>> >> >> Philip, >> >> Thanks for the feedback. Your comments are on target. I propose going >> with your >> standard name. >> >> Keith >> >> ****************************************************************** >> Keith Lindsay http://**www.**cgd.ucar.edu/oce/klindsay/ >> email: klindsay at ucar.edu phone: 303-497-1722 fax: 303-497-1700 >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -- > Scanned by iCritical. > ------------------------------------------------------------------------ Dr Philip Cameron-Smith Atmospheric, Earth, and Energy Division pjc at llnl.gov Lawrence Livermore National Laboratory +1 925 4236634 7000 East Avenue, Livermore, CA94550, USA ------------------------------------------------------------------------ From ogura at nies.go.jp Wed Apr 28 23:29:43 2010 From: ogura at nies.go.jp (Tomoo Ogura) Date: Thu, 29 Apr 2010 14:29:43 +0900 Subject: [CF-metadata] proposal for new standard names Message-ID: Dear Alison, Thank you for your email. Yes, the variable 'cloud_microphysics' is the sum of many processes including evaporation/condensation. The processes included in the variable 'cloud_microphysics' are as follows; condensation and evaporation homogeneous nucleation heterogeneous nucleation deposition and sublimation Bergeron Findeisen process riming acrretion aggregation icefall melting autoconversion Please note that the above list is an example for one GCM 'MIROC5.0', and the processes in the list may be different in other GCMs depending on their modelling assuptions - I hope this will not be a problem when defining a standard name. Our current idea is to recommend the project (CFMIP) participants to submit model output 'cloud_microphysics', and also the list of processes included in that variable. Best wishes, Tomoo --- Tomoo OGURA National Institute for Environmental Studies 16-2 Onogawa, Tsukuba, Ibaraki 305-8506 Japan Phone +81-29-850-2484 Fax +81-29-850-2960 > -----Original Message----- > > Dear Tomoo, > > Thank you for your proposals for new cloud feedback standard names. I > agree that the wording of the names is fine. I assume that > 'cloud_microphysics' is the sum of many of the processes such as > bergeron-findeison, heterogeneous and homogeneous nucleation, etc., but > does it also include evaporation/condensation for example? If you could > list which processes are included in cloud_microphysics that would be > very helpful for writing the definitions of the names. > > Best wishes, > Alison > > ------ > Alison Pamment Tel: +44 1235 778065 > NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk >Chilton, Didcot, OX11 0QX, U.K. > > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > bounces at cgd.ucar.edu] On Behalf Of Tomoo Ogura > Sent: 26 April 2010 10:18 > To: Jonathan Gregory; cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] proposal for new standard names > > Dear Jonathan > > Thanks for your reply. I agree with your suggestions and my proposal > has been updated as follows: > > * microphysics replaced by cloud_microphysics > * Bergeron_Findeisen written in lower case > > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_t > o_cloud_microphysics > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_t > o_boundary_layer_mixing > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_t > o_bergeron_findeisen_process_to_cloud_ice > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_cloud_m > icrophysics > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_boundar > y_layer_mixing > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_bergero > n_findeisen_process_from_cloud_liquid > tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air > tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_du > e_to_cloud_microphysics > tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_du > e_to_boundary_layer_mixing > > Best wishes > Tomoo > --- > Tomoo OGURA > National Institute for Environmental Studies > 16-2 Onogawa, Tsukuba, Ibaraki 305-8506 Japan > Phone +81-29-850-2484 Fax +81-29-850-2960 > From alison.pamment at stfc.ac.uk Thu Apr 29 03:51:35 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Thu, 29 Apr 2010 10:51:35 +0100 Subject: [CF-metadata] proposal for new standard names In-Reply-To: References: Message-ID: Dear Tomoo, Thank you for supplying a list of processes. I propose to write the definition of the 'cloud_microphysics' names to include the following text: ' "cloud_microphysics" is the sum of many cloud processes such as condensation, evaporation, homogeneous nucleation, heterogeneous nucleation, deposition, sublimation, the Bergeron-Findeisen process, riming, accretion, aggregation and icefall. The precise list of processes that are included in "cloud_microphysics" can vary between models. Where possible, the data variable should be accompanied by a complete description of the processes included, for example, by using a comment attribute. Standard names also exist to describe the tendencies due to the separate processes.' Hopefully this definition gives enough information to be helpful, but allows for variation between models. There are existing standard names with similarly loose definitions, e.g. the chemical species included in "alkanes" can vary between different chemistry models, so I don't think there is any problem with treating cloud feedback names in this way. If you are happy with the definition then I think we can go ahead and accept all these names. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > bounces at cgd.ucar.edu] On Behalf Of Tomoo Ogura > Sent: 29 April 2010 06:30 > To: cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] proposal for new standard names > > Dear Alison, > > Thank you for your email. > Yes, the variable 'cloud_microphysics' is the sum of many processes > including evaporation/condensation. The processes included in the > variable 'cloud_microphysics' are as follows; > > condensation and evaporation > homogeneous nucleation > heterogeneous nucleation > deposition and sublimation > Bergeron Findeisen process > riming > acrretion > aggregation > icefall > melting > autoconversion > > Please note that the above list is an example for one GCM 'MIROC5.0', > and > the > processes in the list may be different in other GCMs depending on their > modelling > assuptions - I hope this will not be a problem when defining a standard > name. > Our current idea is to recommend the project (CFMIP) participants to > submit > model output 'cloud_microphysics', and also the list of processes > included > in > that variable. > > Best wishes, > Tomoo > > --- > Tomoo OGURA > National Institute for Environmental Studies > 16-2 Onogawa, Tsukuba, Ibaraki 305-8506 Japan > Phone +81-29-850-2484 Fax +81-29-850-2960 > > > -----Original Message----- > > > > Dear Tomoo, > > > > Thank you for your proposals for new cloud feedback standard names. I > > agree that the wording of the names is fine. I assume that > > 'cloud_microphysics' is the sum of many of the processes such as > > bergeron-findeison, heterogeneous and homogeneous nucleation, etc., > but > > does it also include evaporation/condensation for example? If you > could > > list which processes are included in cloud_microphysics that would be > > very helpful for writing the definitions of the names. > > > > Best wishes, > > Alison > > > > ------ > > Alison Pamment Tel: +44 1235 778065 > > NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > > Rutherford Appleton Laboratory Email: > alison.pamment at stfc.ac.uk > >Chilton, Didcot, OX11 0QX, U.K. > > > > > -----Original Message----- > > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > > bounces at cgd.ucar.edu] On Behalf Of Tomoo Ogura > > Sent: 26 April 2010 10:18 > > To: Jonathan Gregory; cf-metadata at cgd.ucar.edu > > Subject: Re: [CF-metadata] proposal for new standard names > > > > Dear Jonathan > > > > Thanks for your reply. I agree with your suggestions and my proposal > > has been updated as follows: > > > > * microphysics replaced by cloud_microphysics > > * Bergeron_Findeisen written in lower case > > > > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air > > > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_t > > o_cloud_microphysics > > > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_t > > o_boundary_layer_mixing > > > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_t > > o_bergeron_findeisen_process_to_cloud_ice > > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air > > > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_cloud_m > > icrophysics > > > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_boundar > > y_layer_mixing > > > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_bergero > > n_findeisen_process_from_cloud_liquid > > tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air > > > tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_du > > e_to_cloud_microphysics > > > tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_du > > e_to_boundary_layer_mixing > > > > Best wishes > > Tomoo > > --- > > Tomoo OGURA > > National Institute for Environmental Studies > > 16-2 Onogawa, Tsukuba, Ibaraki 305-8506 Japan > > Phone +81-29-850-2484 Fax +81-29-850-2960 > > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Scanned by iCritical. From rkl at bodc.ac.uk Thu Apr 29 04:35:29 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Thu, 29 Apr 2010 11:35:29 +0100 Subject: [CF-metadata] BGC output for CMIP5 simulations (fwd) In-Reply-To: References: Message-ID: <40829B0E077C1145A6DE44D39B3830A908881DBCFA@nerckwmb1.ad.nerc.ac.uk> Hello Philip/Alison Couple of points. (1) Radicals are more of relevance to the atmosphere than water bodies so I don't think confusion between them and ions is an issue. As standard names are becoming incorporated into URLs, the '+' character is best avoided. Also without semantic support (which is coming), very few datasets labelled 'NO3-' would get found as most oceanographers would search for 'nitrate' (2) 'net_primary_mole_productivity_of_carbon_due_to_nitrate_consumption' or 'net_primary_mole_productivity_of_carbon_due_to_nitrate_nutrition' would get around Alison's issue. 'due_to_nitrate' is simply lazy speak for the process. Cheers, Roy. -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Philip J. Cameronsmith1 Sent: 28 April 2010 23:04 To: alison.pamment at stfc.ac.uk Cc: Keith Lindsay; CF-metadata email list; John.Dunne at noaa.gov Subject: Re: [CF-metadata] BGC output for CMIP5 simulations (fwd) Hi Alison, Thanks for your email. I am not an expert on ecosystems, and so will defer to those who are. I had assumed that the variable was for carbon production CAUSED by nitrate through some process, in which case _due_to_ seemed to me to be appropriate. Going back to your spreadsheet, I see that the description for net_new_primary_mole_productivity_of_carbon was 'Vertically integrated primary (organic carbon) production by phytoplankton based on NO3 alone'. So now I'm not so sure, and need guidance from an expert. Is this quantity just being calculated using nitrate as a proxy data source, or is it production caused by nitrate? BTW, we might consider replacing NO3 and NH4 in the description with 'nitrate' and 'ammonium', or 'NO3-' and 'NH4+', or making it unambiguous in some other way, that these are ions and not radicals. Admittedly, this is probably obvious to most people with some familiarity with the chemistry or biology, but we might as well be precise. Best wishes, Philip On Wed, 28 Apr 2010, alison.pamment at stfc.ac.uk wrote: > Dear Philip, > > Thanks very much for forwarding these emails to the list and sorry for > not picking up on this thread sooner. > > The standard names > tendency_of_mole_concentration_of_particulate_organic_matter_expressed_a > s_carbon_in_sea_water_due_to_net_new_primary_production; mol m-3 s-1 > net_new_primary_mole_productivity_of_carbon; mol m-2 s-1 > were accepted after discussion in the 'CMIP5 ocean biogeochemistry > standard names' thread. > > However, the name > net_primary_mole_productivity_of_carbon_due_to_nitrate > is now being proposed for the second quantity because there is some > confusion as to the precise meaning of 'new' production. > > As the accepted names have not yet been added to the standard name table > I think we could change them provided everyone agrees. Both names should > be changed to be consistent with one another. The phrase 'due_to' is > reserved in standard names for describing a process, e.g. > 'due_to_convection', so 'due_to_nitrate' doesn't really fit that > pattern. Would > net_primary_mole_productivity_of_carbon_from_nutrients_containing_nitrat > e > or just > net_primary_mole_productivity_of_carbon_from_nitrate_nutrients > be an accurate description? > > The first name could then be changed to > tendency_of_mole_concentration_of_particulate_organic_matter_expressed_a > s_carbon_in_sea_water_due_to_net_primary_production_from_{nutrients_cont > aining_nitrate}|{nitrate_nutrients}. > > Perhaps John Dunne could also comment on these ideas. > > Best wishes, > Alison > > ------ > Alison Pamment Tel: +44 1235 778065 > NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk > Chilton, Didcot, OX11 0QX, U.K. > > >> -----Original Message----- >> From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- >> bounces at cgd.ucar.edu] On Behalf Of Philip J. Cameronsmith1 >> Sent: 22 April 2010 00:05 >> To: CF-metadata email list >> Subject: Re: [CF-metadata] BGC output for CMIP5 simulations (fwd) >> >> >> Hi, >> >> It appears that the wrong email address for the CF list was used for >> some >> of the emails in the conversation below. Hence, I am forwarding the >> final email for the record. >> >> Best wishes, >> >> Philip >> >> > ----------------------------------------------------------------------- >> - >> Dr Philip Cameron-Smith Atmospheric, Earth, and Energy Division >> pjc at llnl.gov Lawrence Livermore National Laboratory >> +1 925 4236634 7000 East Avenue, Livermore, CA94550, >> USA >> > ----------------------------------------------------------------------- >> - >> >> ---------- Forwarded message ---------- >> Date: Wed, 21 Apr 2010 13:15:39 >> From: Keith Lindsay >> To: Philip J. Cameronsmith1 >> Cc: John.Dunne at noaa.gov, Ernst Maier-Reimer > reimer at zmaw.de>, >> Corinne Le Quere , >> Bruce Hackett , >> Thomas LOUBRIEU , >> Laurent Bopp , >> Pierre Friedlingstein , >> James Orr , Laurence Crosnier > > ocean.fr>, >> Chris Jones , cf- >> metadata at ucar.edu, >> Karl Taylor , Yann BARZIC >> >> Subject: Re: [CF-metadata] BGC output for CMIP5 simulations >> >> On Wed, 21 Apr 2010, Philip J. Cameronsmith1 wrote: >> >>> Hi Keith, et al. >>> >>> By no3 I assume you mean the negatively charged nitrate ion (NO3-). >> In which >>> case I recommend using 'nitrate' in the standard name instead of >> 'no3'. This >>> will then be consistent with existing standard names, and avoid >> confusion >>> with the uncharged nitrate radical (NO3). >>> >>> In looking at the standard name table I think it would also be more >>> consistent to use _due_to_ instead of _from_. The latter is mainly >> used for >>> physical directions, eg _into_sea_water_from_rivers, while the > former >> is >>> mainly used when when the quantity is changing _due_to_ another >> process, eg >>> tendency_of_air_temperature_due_to_shortwave_heating. >>> >>> Hence, I suggest you consider the following: >>> >>> net_primary_mole_productivity_of_carbon_due_to_nitrate >>> >>> Best wishes, >>> >>> Philip >>> >> >> Philip, >> >> Thanks for the feedback. Your comments are on target. I propose going >> with your >> standard name. >> >> Keith >> >> ****************************************************************** >> Keith Lindsay http://**www.**cgd.ucar.edu/oce/klindsay/ >> email: klindsay at ucar.edu phone: 303-497-1722 fax: 303-497-1700 >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -- > Scanned by iCritical. > ------------------------------------------------------------------------ Dr Philip Cameron-Smith Atmospheric, Earth, and Energy Division pjc at llnl.gov Lawrence Livermore National Laboratory +1 925 4236634 7000 East Avenue, Livermore, CA94550, USA ------------------------------------------------------------------------ _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From John.Dunne at noaa.gov Thu Apr 29 07:10:08 2010 From: John.Dunne at noaa.gov (John.Dunne at noaa.gov) Date: Thu, 29 Apr 2010 09:10:08 -0400 Subject: [CF-metadata] BGC output for CMIP5 simulations (fwd) Message-ID: <26b1baa26b5394.26b539426b1baa@noaa.gov> Another suggestion would be 'net_primary_mole_productivity_of_carbon_utilizing_nitrate'. I agree that 'due_to_nitrate' doesn't really mean much in this instance given that it is the phytoplankton that are the causal factor, not the nitrate per se. ----- Original Message ----- From: "Lowry, Roy K" Date: Thursday, April 29, 2010 6:35 am Subject: RE: [CF-metadata] BGC output for CMIP5 simulations (fwd) > Hello Philip/Alison > > Couple of points. > > (1) Radicals are more of relevance to the atmosphere than water > bodies so I don't think confusion between them and ions is an > issue. As standard names are becoming incorporated into URLs, the > '+' character is best avoided. Also without semantic support > (which is coming), very few datasets labelled 'NO3-' would get > found as most oceanographers would search for 'nitrate' > > (2) > 'net_primary_mole_productivity_of_carbon_due_to_nitrate_consumption' or 'net_primary_mole_productivity_of_carbon_due_to_nitrate_nutrition' would get around Alison's issue. 'due_to_nitrate' is simply lazy speak for the process. > > Cheers, Roy. > > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > bounces at cgd.ucar.edu] On Behalf Of Philip J. Cameronsmith1 > Sent: 28 April 2010 23:04 > To: alison.pamment at stfc.ac.uk > Cc: Keith Lindsay; CF-metadata email list; John.Dunne at noaa.gov > Subject: Re: [CF-metadata] BGC output for CMIP5 simulations (fwd) > > > Hi Alison, > > Thanks for your email. > > I am not an expert on ecosystems, and so will defer to those who are. > > I had assumed that the variable was for carbon production CAUSED by > nitrate through some process, in which case _due_to_ seemed to me > to be > appropriate. > > Going back to your spreadsheet, I see that the description for > net_new_primary_mole_productivity_of_carbon was 'Vertically > integrated > primary (organic carbon) production by phytoplankton based on NO3 > alone'.So now I'm not so sure, and need guidance from an expert. > > Is this quantity just being calculated using nitrate as a proxy > data > source, or is it production caused by nitrate? > > BTW, we might consider replacing NO3 and NH4 in the description > with > 'nitrate' and 'ammonium', or 'NO3-' and 'NH4+', or making it > unambiguous > in some other way, that these are ions and not radicals. > Admittedly, this > is probably obvious to most people with some familiarity with the > chemistry or biology, but we might as well be precise. > > Best wishes, > > Philip > > On Wed, 28 Apr 2010, alison.pamment at stfc.ac.uk wrote: > > > Dear Philip, > > > > Thanks very much for forwarding these emails to the list and > sorry for > > not picking up on this thread sooner. > > > > The standard names > > > tendency_of_mole_concentration_of_particulate_organic_matter_expressed_a> s_carbon_in_sea_water_due_to_net_new_primary_production; mol m-3 s-1 > > net_new_primary_mole_productivity_of_carbon; mol m-2 s-1 > > were accepted after discussion in the 'CMIP5 ocean biogeochemistry > > standard names' thread. > > > > However, the name > > net_primary_mole_productivity_of_carbon_due_to_nitrate > > is now being proposed for the second quantity because there is some > > confusion as to the precise meaning of 'new' production. > > > > As the accepted names have not yet been added to the standard > name table > > I think we could change them provided everyone agrees. Both names > should> be changed to be consistent with one another. The phrase > 'due_to' is > > reserved in standard names for describing a process, e.g. > > 'due_to_convection', so 'due_to_nitrate' doesn't really fit that > > pattern. Would > > > net_primary_mole_productivity_of_carbon_from_nutrients_containing_nitrat> e > > or just > > net_primary_mole_productivity_of_carbon_from_nitrate_nutrients > > be an accurate description? > > > > The first name could then be changed to > > > tendency_of_mole_concentration_of_particulate_organic_matter_expressed_a> s_carbon_in_sea_water_due_to_net_primary_production_from_{nutrients_cont > > aining_nitrate}|{nitrate_nutrients}. > > > > Perhaps John Dunne could also comment on these ideas. > > > > Best wishes, > > Alison > > > > ------ > > Alison Pamment Tel: +44 1235 778065 > > NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > > Rutherford Appleton Laboratory Email: > alison.pamment at stfc.ac.uk> Chilton, Didcot, OX11 0QX, U.K. > > > > > >> -----Original Message----- > >> From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > >> bounces at cgd.ucar.edu] On Behalf Of Philip J. Cameronsmith1 > >> Sent: 22 April 2010 00:05 > >> To: CF-metadata email list > >> Subject: Re: [CF-metadata] BGC output for CMIP5 simulations (fwd) > >> > >> > >> Hi, > >> > >> It appears that the wrong email address for the CF list was used > for>> some > >> of the emails in the conversation below. Hence, I am forwarding > the>> final email for the record. > >> > >> Best wishes, > >> > >> Philip > >> > >> > > ------------------------------------------------------------------ > ----- > >> - > >> Dr Philip Cameron-Smith Atmospheric, Earth, and Energy > Division>> pjc at llnl.gov Lawrence Livermore > National Laboratory > >> +1 925 4236634 7000 East Avenue, Livermore, > CA94550,>> USA > >> > > ------------------------------------------------------------------ > ----- > >> - > >> > >> ---------- Forwarded message ---------- > >> Date: Wed, 21 Apr 2010 13:15:39 > >> From: Keith Lindsay > >> To: Philip J. Cameronsmith1 > >> Cc: John.Dunne at noaa.gov, Ernst Maier-Reimer >> reimer at zmaw.de>, > >> Corinne Le Quere , > >> Bruce Hackett , > >> Thomas LOUBRIEU , > >> Laurent Bopp , > >> Pierre Friedlingstein , > >> James Orr , Laurence Crosnier > > >> ocean.fr>, > >> Chris Jones , cf- > >> metadata at ucar.edu, > >> Karl Taylor , Yann BARZIC > >> > >> Subject: Re: [CF-metadata] BGC output for CMIP5 simulations > >> > >> On Wed, 21 Apr 2010, Philip J. Cameronsmith1 wrote: > >> > >>> Hi Keith, et al. > >>> > >>> By no3 I assume you mean the negatively charged nitrate ion > (NO3-). > >> In which > >>> case I recommend using 'nitrate' in the standard name instead of > >> 'no3'. This > >>> will then be consistent with existing standard names, and avoid > >> confusion > >>> with the uncharged nitrate radical (NO3). > >>> > >>> In looking at the standard name table I think it would also be > more>>> consistent to use _due_to_ instead of _from_. The latter > is mainly > >> used for > >>> physical directions, eg _into_sea_water_from_rivers, while the > > former > >> is > >>> mainly used when when the quantity is changing _due_to_ another > >> process, eg > >>> tendency_of_air_temperature_due_to_shortwave_heating. > >>> > >>> Hence, I suggest you consider the following: > >>> > >>> net_primary_mole_productivity_of_carbon_due_to_nitrate > >>> > >>> Best wishes, > >>> > >>> Philip > >>> > >> > >> Philip, > >> > >> Thanks for the feedback. Your comments are on target. I propose > going>> with your > >> standard name. > >> > >> Keith > >> > >> ****************************************************************** > >> Keith Lindsay > http://**www.**cgd.ucar.edu/oce/klindsay/>> email: > klindsay at ucar.edu phone: 303-497-1722 fax: 303-497-1700 > >> _______________________________________________ > >> CF-metadata mailing list > >> CF-metadata at cgd.ucar.edu > >> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > -- > > Scanned by iCritical. > > > > -------------------------------------------------------------------- > ---- > Dr Philip Cameron-Smith Atmospheric, Earth, and Energy Division > pjc at llnl.gov Lawrence Livermore National Laboratory > +1 925 4236634 7000 East Avenue, Livermore, > CA94550, USA > -------------------------------------------------------------------- > ---- > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > -- > This message (and any attachments) is for the recipient only. NERC > is subject to the Freedom of Information Act 2000 and the contents > of this email and any reply you make may be disclosed by NERC unless > it is exempt from release under the Act. Any material supplied to > NERC may be stored in an electronic records management system. > > From ogura at nies.go.jp Fri Apr 30 15:53:33 2010 From: ogura at nies.go.jp (Tomoo Ogura) Date: Sat, 1 May 2010 06:53:33 +0900 Subject: [CF-metadata] proposal for new standard names Message-ID: Hello Alison, I agree with your proposal. The definition of the 'cloud_microphysics' will be really helpful when preparing the model output - thank you for this ! Best wishes, Tomoo --- Tomoo OGURA National Institute for Environmental Studies 16-2 Onogawa, Tsukuba, Ibaraki 305-8506 Japan Phone +81-29-850-2484 Fax +81-29-850-2960 > -----Original Message----- > > Dear Tomoo, > > Thank you for supplying a list of processes. I propose to write the > definition of the 'cloud_microphysics' names to include the following > text: > > ' "cloud_microphysics" is the sum of many cloud processes such as > condensation, evaporation, homogeneous nucleation, heterogeneous > nucleation, deposition, sublimation, the Bergeron-Findeisen process, > riming, accretion, aggregation and icefall. The precise list of > processes that are included in "cloud_microphysics" can vary between > models. Where possible, the data variable should be accompanied by a > complete description of the processes included, for example, by using a > comment attribute. Standard names also exist to describe the tendencies > due to the separate processes.' > > Hopefully this definition gives enough information to be helpful, but > allows for variation between models. There are existing standard names > with similarly loose definitions, e.g. the chemical species included in > "alkanes" can vary between different chemistry models, so I don't think > there is any problem with treating cloud feedback names in this way. > > If you are happy with the definition then I think we can go ahead and > accept all these names. > > Best wishes, > Alison > > ------ > Alison Pamment Tel: +44 1235 778065 > NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk > Chilton, Didcot, OX11 0QX, U.K. > From j.m.gregory at reading.ac.uk Mon May 3 10:55:42 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Mon, 3 May 2010 17:55:42 +0100 Subject: [CF-metadata] standard name grammar Message-ID: <20100503165542.GA15064@met.reading.ac.uk> Dear all Stimulated by Robert Muetzelfeldt's initiative to produce a grammar for CF standard names based on the existing guidelines for construction of standard names, I have done some work on deriving a comprehensive grammar of the standard name table, described at http://www.met.rdg.ac.uk/~jonathan/CF_metadata/13/standard_name_grammar.html The grammar consists of a lexicon, which lists the phrases composing standard names and assigns each one a phrasetype (scalar, medium, component, surface, etc.), and a list of patterns which describe the syntax of standard names e.g. tendency_of_atmosphere_water_vapor_content_due_to_advection conforms to the pattern (function_of) (layer) (scalar) due_to_(phenomenon) In the web page I have described how I did the analysis. Attached to the web page are the files which define the lexicon and the patterns for version 13 of the standard name table (the present version), and two scripts for checking and processing standard names using the grammar. I don't know whether this will be useful, but I believe it could be. It ought to make it easier to devise new names based on existing lexicon and syntax, and to see how to extend the lexicon and syntax when necessary. Cheers Jonathan From j.m.gregory at reading.ac.uk Mon May 3 10:56:08 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Mon, 3 May 2010 17:56:08 +0100 Subject: [CF-metadata] proposed changes to seven standard names Message-ID: <20100503165608.GB15064@met.reading.ac.uk> Dear all In preparing the grammar for CF standard names that I describe in my last posting, I found I wanted to propose the following modifications to existing standard names: snow_soot_content -> soot_content_of_surface_snow snow_thermal_energy_content -> thermal_energy_content_of_surface_snow snow_temperature -> temperature_in_snow liquid_water_content_of_snow_layer -> liquid_water_content_of_surface_snow "snow" can refer both to lying snow (a medium) and falling snow (a species). Existing standard names generally use "surface_snow" for the former, but not always. I propose these changes to remove the ambiguity. water_vapor_pressure -> water_vapor_partial_pressure This quantity is really a partial pressure, and making this change is consistent with the use of "partial_pressure" for "carbon_dioxide" in other names. dissipation_in_atmosphere_boundary_layer -> kinetic_energy_dissipation_in_atmosphere_boundary_layer This change is proposed because "dissipation" alone is vague, and it makes the name consistent with other names that contain the phrase "kinetic_energy_dissipation" referring to the ocean. sea_ice_displacement -> magnitude_of_sea_ice_displacement This change is proposed so that "sea_ice_displacement" is definitely a vector, with components e.g. "eastward_sea_ice_displacement"; at present, it is both a scalar and a vector. Jonathan From r.muetzelfeldt at ed.ac.uk Mon May 3 14:33:40 2010 From: r.muetzelfeldt at ed.ac.uk (Robert Muetzelfeldt) Date: Mon, 03 May 2010 21:33:40 +0100 Subject: [CF-metadata] standard name grammar In-Reply-To: <20100503165542.GA15064@met.reading.ac.uk> References: <20100503165542.GA15064@met.reading.ac.uk> Message-ID: <4BDF3324.5050308@ed.ac.uk> This looks very impressive, Jonathan. I hope it helps to bring about a shift away from long atomic standard names. You refer to my earlier work on this topic. For anyone interested, here are links to my two relevant postings on the [CF-metadata] list: 28 Oct 2008: Re: [CF-metadata] a different (but perhaps unoriginal) approach to standard name construction http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2008/002511.html 2 Nov 2008: [CF-metadata] A grammar for Standard Names http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2008/002518.html The first of these two postings points to a web page which contains some more details of one approach I used, at http://envarml.pbworks.com/Prototype+grammar+for+CF-metadata+"standard+names" along with the grammar itself (in XSugar format). I subsequently replicated the same exercise using Prolog's grammar notation, though this has not been written up. I'm happy to provide details on request. Best wishes, Robert Jonathan Gregory wrote: > Dear all > > Stimulated by Robert Muetzelfeldt's initiative to produce a grammar for CF > standard names based on the existing guidelines for construction of standard > names, I have done some work on deriving a comprehensive grammar of the > standard name table, described at > http://www.met.rdg.ac.uk/~jonathan/CF_metadata/13/standard_name_grammar.html > The grammar consists of a lexicon, which lists the phrases composing standard > names and assigns each one a phrasetype (scalar, medium, component, surface, > etc.), and a list of patterns which describe the syntax of standard names e.g. > tendency_of_atmosphere_water_vapor_content_due_to_advection > conforms to the pattern > (function_of) (layer) (scalar) due_to_(phenomenon) > In the web page I have described how I did the analysis. Attached to the web > page are the files which define the lexicon and the patterns for version 13 of > the standard name table (the present version), and two scripts for checking > and processing standard names using the grammar. > > I don't know whether this will be useful, but I believe it could be. It ought > to make it easier to devise new names based on existing lexicon and syntax, > and to see how to extend the lexicon and syntax when necessary. > > Cheers > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From Steven.C.Hankin at noaa.gov Mon May 3 16:19:45 2010 From: Steven.C.Hankin at noaa.gov (Steve Hankin) Date: Mon, 03 May 2010 15:19:45 -0700 Subject: [CF-metadata] standard name grammar In-Reply-To: <20100503165542.GA15064@met.reading.ac.uk> References: <20100503165542.GA15064@met.reading.ac.uk> Message-ID: <4BDF4C01.9060809@noaa.gov> Hi Jon, This is an impressive contribution. :-) It strikes a compromise between human-readability today and future machine-processability. Are there particular forms of review or feedback that someone could give you without spending the kind of time that (I assume) you must have put into this? In a 10 minute look-over two questions that occurred to me were: 1. could/should the "water_source" vocabulary be subsumed under "phenomenon"? 2. wondering whether the "untyped" names might deserve to be treated a little differently (or at least given a name reflecting their dignity ;-) ). Many of the members of this group actually seem like top level semantic concepts (e.g. "derivative of"). Others seem like mere grammatical artifacts ("and") - Steve ============================ Jonathan Gregory wrote: > Dear all > > Stimulated by Robert Muetzelfeldt's initiative to produce a grammar for CF > standard names based on the existing guidelines for construction of standard > names, I have done some work on deriving a comprehensive grammar of the > standard name table, described at > http://www.met.rdg.ac.uk/~jonathan/CF_metadata/13/standard_name_grammar.html > The grammar consists of a lexicon, which lists the phrases composing standard > names and assigns each one a phrasetype (scalar, medium, component, surface, > etc.), and a list of patterns which describe the syntax of standard names e.g. > tendency_of_atmosphere_water_vapor_content_due_to_advection > conforms to the pattern > (function_of) (layer) (scalar) due_to_(phenomenon) > In the web page I have described how I did the analysis. Attached to the web > page are the files which define the lexicon and the patterns for version 13 of > the standard name table (the present version), and two scripts for checking > and processing standard names using the grammar. > > I don't know whether this will be useful, but I believe it could be. It ought > to make it easier to devise new names based on existing lexicon and syntax, > and to see how to extend the lexicon and syntax when necessary. > > Cheers > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -- Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov 7600 Sand Point Way NE, Seattle, WA 98115-0070 ph. (206) 526-6080, FAX (206) 526-6744 "The only thing necessary for the triumph of evil is for good men to do nothing." -- Edmund Burke -------------- next part -------------- An HTML attachment was scrubbed... URL: From cameronsmith1 at llnl.gov Mon May 3 18:00:02 2010 From: cameronsmith1 at llnl.gov (Cameron-smith, Philip) Date: Mon, 3 May 2010 17:00:02 -0700 Subject: [CF-metadata] standard name grammar In-Reply-To: <20100503165542.GA15064@met.reading.ac.uk> References: <20100503165542.GA15064@met.reading.ac.uk> Message-ID: Hi Jonathan, Thank you for taking this on, I think this is heading in a good direction. My hope is that we will get to a point where any proposed std name that fits these rules will just need to be rubber stamped (since nobody will bother proposing a green dog, and nobody will use it if they do, so little harm will be done if we don't catch it :-)). A couple of small suggestions: 1) In the phenomenon section, you list both 'due_to' and 'from'. However, from examining the patterns, the only time 'from_phenomenon' appears is as a secondary phenomenon, ie _due_to_phenomenon1_from_phenomenon2, eg, tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_condensation_and_evaporation_from_convection Would it be worth capturing this distinction between 'due_to' and 'from' in your lexicon? 2) Is it worth adding usage comments to the lexicon? For example, in the 'concentration' section you list both 'mole fraction of' and 'volume mixing ratio of'. These are often considered to be synonymous in the atmosphere, so someone just reading your lexicon might be unsure which to use. However, in CF practice, we have used 'volume mixing ratio of' exclusively for non-atmospheric quantities, and 'mole fraction of' for the atmosphere, which I think is for good, but subtle, reasons. Best wishes, Philip ------------------------------------------------------------------------ Dr Philip Cameron-Smith Atmospheric, Earth, and Energy Division pjc at llnl.gov Lawrence Livermore National Laboratory +1 925 4236634 7000 East Avenue, Livermore, CA94550, USA ------------------------------------------------------------------------ -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory Sent: Monday, May 03, 2010 9:56 AM To: cf-metadata at cgd.ucar.edu Subject: [CF-metadata] standard name grammar Dear all Stimulated by Robert Muetzelfeldt's initiative to produce a grammar for CF standard names based on the existing guidelines for construction of standard names, I have done some work on deriving a comprehensive grammar of the standard name table, described at http://*www.*met.rdg.ac.uk/~jonathan/CF_metadata/13/standard_name_grammar.html The grammar consists of a lexicon, which lists the phrases composing standard names and assigns each one a phrasetype (scalar, medium, component, surface, etc.), and a list of patterns which describe the syntax of standard names e.g. tendency_of_atmosphere_water_vapor_content_due_to_advection conforms to the pattern (function_of) (layer) (scalar) due_to_(phenomenon) In the web page I have described how I did the analysis. Attached to the web page are the files which define the lexicon and the patterns for version 13 of the standard name table (the present version), and two scripts for checking and processing standard names using the grammar. I don't know whether this will be useful, but I believe it could be. It ought to make it easier to devise new names based on existing lexicon and syntax, and to see how to extend the lexicon and syntax when necessary. Cheers Jonathan _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From j.m.gregory at reading.ac.uk Tue May 4 04:33:47 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 4 May 2010 11:33:47 +0100 Subject: [CF-metadata] standard name grammar In-Reply-To: References: <20100503165542.GA15064@met.reading.ac.uk> Message-ID: <20100504103347.GA18747@met.reading.ac.uk> Dear Philip, Steve and Robert Thanks for your comments. I think all comments are welcome, both detailed and general. The grammar has intellectual interest, but my main aim is to see whether we can produce something that'll help standard names to be agreed more quickly and with less effort, as Philip suggests. * "In the phenomenon section, you list both 'due_to' and 'from'. However, from examining the patterns, the only time 'from_phenomenon' appears is as a secondary phenomenon." That's right, and actually the primary phenomenon is always the same one! So I should really have just put the from phrases as part of the due_to and omitted the from category. Thanks. * "Is it worth adding usage comments to the lexicon?" Yes, absolutely. In fact, we could put explanatory text in the lexicon that could automatically be used to synthesise the full description of the standard name, by stringing together the text for the constituent phrases. The lexicon would have to be an xml file to make this manageable, I suppose, which is a pity because xml files are much less readable than plain files in columns! * "could/should the "water_source" vocabulary be subsumed under "phenomenon"?" That's a good idea. The from_(water_source) phrases really have the same kind of function as due_to_(phenomenon) and those types could be merged. * "wondering whether the "untyped" names might deserve to be treated a little differently ..." Quite right. I made some related comments in the "Directions" section about what could be done in future. Since there is only one level of parsing at present, the grammar cannot recognise that product_of X and Y is a higher-level pattern, in which "product_of" and "and" are essential syntactic elements. Several of the untyped phrases are used for such purposes. Others are used to generate scalar standard names from species etc. These would be recognised at a lower level of parsing. Best wishes Jonathan From caron at unidata.ucar.edu Tue May 4 07:20:45 2010 From: caron at unidata.ucar.edu (John Caron) Date: Tue, 04 May 2010 07:20:45 -0600 Subject: [CF-metadata] standard name grammar In-Reply-To: <20100503165542.GA15064@met.reading.ac.uk> References: <20100503165542.GA15064@met.reading.ac.uk> Message-ID: <4BE01F2D.4050302@unidata.ucar.edu> Dear Jonathan: Wow! That's a bit of work there. Ill let others comment on the technical details, but Ill just say thanks for all your time and deep effort. John On 5/3/2010 10:55 AM, Jonathan Gregory wrote: > Dear all > > Stimulated by Robert Muetzelfeldt's initiative to produce a grammar for CF > standard names based on the existing guidelines for construction of standard > names, I have done some work on deriving a comprehensive grammar of the > standard name table, described at > http://www.met.rdg.ac.uk/~jonathan/CF_metadata/13/standard_name_grammar.html > The grammar consists of a lexicon, which lists the phrases composing standard > names and assigns each one a phrasetype (scalar, medium, component, surface, > etc.), and a list of patterns which describe the syntax of standard names e.g. > tendency_of_atmosphere_water_vapor_content_due_to_advection > conforms to the pattern > (function_of) (layer) (scalar) due_to_(phenomenon) > In the web page I have described how I did the analysis. Attached to the web > page are the files which define the lexicon and the patterns for version 13 of > the standard name table (the present version), and two scripts for checking > and processing standard names using the grammar. > > I don't know whether this will be useful, but I believe it could be. It ought > to make it easier to devise new names based on existing lexicon and syntax, > and to see how to extend the lexicon and syntax when necessary. > > Cheers > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > From alison.pamment at stfc.ac.uk Wed May 5 04:18:33 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Wed, 5 May 2010 11:18:33 +0100 Subject: [CF-metadata] proposal for new standard names In-Reply-To: References: Message-ID: Dear Tomoo, I think all the cloud feedback names are now agreed: tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to _cloud_microphysics tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to _boundary_layer_mixing tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to _bergeron_findeisen_process_to_cloud_ice tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_cloud_mi crophysics tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_boundary _layer_mixing tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_bergeron _findeisen_process_from_cloud_liquid tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due _to_cloud_microphysics tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due _to_boundary_layer_mixing The names are accepted for inclusion in the standard name table and will be added at the next update. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > bounces at cgd.ucar.edu] On Behalf Of Tomoo Ogura > Sent: 30 April 2010 22:54 > To: cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] proposal for new standard names > > Hello Alison, > > I agree with your proposal. The definition of the > 'cloud_microphysics' > will be really helpful when preparing the model output - thank you for > this ! > > Best wishes, > Tomoo > > --- > Tomoo OGURA > National Institute for Environmental Studies > 16-2 Onogawa, Tsukuba, Ibaraki 305-8506 Japan > Phone +81-29-850-2484 Fax +81-29-850-2960 > > > -----Original Message----- > > > > Dear Tomoo, > > > > Thank you for supplying a list of processes. I propose to write the > > definition of the 'cloud_microphysics' names to include the following > > text: > > > > ' "cloud_microphysics" is the sum of many cloud processes such as > > condensation, evaporation, homogeneous nucleation, heterogeneous > > nucleation, deposition, sublimation, the Bergeron-Findeisen process, > > riming, accretion, aggregation and icefall. The precise list of > > processes that are included in "cloud_microphysics" can vary between > > models. Where possible, the data variable should be accompanied by a > > complete description of the processes included, for example, by using > a > > comment attribute. Standard names also exist to describe the > tendencies > > due to the separate processes.' > > > > Hopefully this definition gives enough information to be helpful, but > > allows for variation between models. There are existing standard > names > > with similarly loose definitions, e.g. the chemical species included > in > > "alkanes" can vary between different chemistry models, so I don't > think > > there is any problem with treating cloud feedback names in this way. > > > > If you are happy with the definition then I think we can go ahead and > > accept all these names. > > > > Best wishes, > > Alison > > > > ------ > > Alison Pamment Tel: +44 1235 778065 > > NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > > Rutherford Appleton Laboratory Email: > alison.pamment at stfc.ac.uk > > Chilton, Didcot, OX11 0QX, U.K. > > > > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Scanned by iCritical. From alison.pamment at stfc.ac.uk Wed May 5 05:57:37 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Wed, 5 May 2010 12:57:37 +0100 Subject: [CF-metadata] BGC output for CMIP5 simulations (fwd) In-Reply-To: <26b1baa26b5394.26b539426b1baa@noaa.gov> References: <26b1baa26b5394.26b539426b1baa@noaa.gov> Message-ID: Dear John, Roy, Philip, et al., Jonathan responded (offlist) to John's latest suggestion by saying that net_primary_mole_productivity_of_carbon_due_to_nitrate_utilization fits more closely to existing patterns of standard names. It differs from Roy's suggestion only in substituting "utilization" for "consumption". John has indicated (also offlist) that he is happy with Jonathan's version. I think we have converged enough to accept this name for inclusion in the table. For consistency, the other "new productivity" name should now be written as tendency_of_mole_concentration_of_particulte_organic_matter_expressed_as _carbon_in_sea_water_due_to_nitrate_utilization. This name is also accepted for inclusion in the standard name table. Thanks to all for the discussion - this means that all the proposed ocean biogeochemistry quantities have now been accepted. Best wishes, Alison > -----Original Message----- > From: John.Dunne at noaa.gov [mailto:John.Dunne at noaa.gov] > Sent: 29 April 2010 14:10 > To: Lowry, Roy K > Cc: Philip J. Cameronsmith1; Pamment, Alison (STFC,RAL,SSTD); Keith > Lindsay; CF-metadata email list > Subject: Re: RE: [CF-metadata] BGC output for CMIP5 simulations (fwd) > > > Another suggestion would be > 'net_primary_mole_productivity_of_carbon_utilizing_nitrate'. I agree > that 'due_to_nitrate' doesn't really mean much in this instance given > that it is the phytoplankton that are the causal factor, not the > nitrate > per se. > > ----- Original Message ----- > From: "Lowry, Roy K" > Date: Thursday, April 29, 2010 6:35 am > Subject: RE: [CF-metadata] BGC output for CMIP5 simulations (fwd) > > > Hello Philip/Alison > > > > Couple of points. > > > > (1) Radicals are more of relevance to the atmosphere than water > > bodies so I don't think confusion between them and ions is an > > issue. As standard names are becoming incorporated into URLs, the > > '+' character is best avoided. Also without semantic support > > (which is coming), very few datasets labelled 'NO3-' would get > > found as most oceanographers would search for 'nitrate' > > > > (2) > > 'net_primary_mole_productivity_of_carbon_due_to_nitrate_consumption' > or 'net_primary_mole_productivity_of_carbon_due_to_nitrate_nutrition' > would get around Alison's issue. 'due_to_nitrate' is simply lazy speak > for the process. > > > > Cheers, Roy. > > > > -----Original Message----- > > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > > bounces at cgd.ucar.edu] On Behalf Of Philip J. Cameronsmith1 > > Sent: 28 April 2010 23:04 > > To: alison.pamment at stfc.ac.uk > > Cc: Keith Lindsay; CF-metadata email list; John.Dunne at noaa.gov > > Subject: Re: [CF-metadata] BGC output for CMIP5 simulations (fwd) > > > > > > Hi Alison, > > > > Thanks for your email. > > > > I am not an expert on ecosystems, and so will defer to those who are. > > > > I had assumed that the variable was for carbon production CAUSED by > > nitrate through some process, in which case _due_to_ seemed to me > > to be > > appropriate. > > > > Going back to your spreadsheet, I see that the description for > > net_new_primary_mole_productivity_of_carbon was 'Vertically > > integrated > > primary (organic carbon) production by phytoplankton based on NO3 > > alone'.So now I'm not so sure, and need guidance from an expert. > > > > Is this quantity just being calculated using nitrate as a proxy > > data > > source, or is it production caused by nitrate? > > > > BTW, we might consider replacing NO3 and NH4 in the description > > with > > 'nitrate' and 'ammonium', or 'NO3-' and 'NH4+', or making it > > unambiguous > > in some other way, that these are ions and not radicals. > > Admittedly, this > > is probably obvious to most people with some familiarity with the > > chemistry or biology, but we might as well be precise. > > > > Best wishes, > > > > Philip > > > > On Wed, 28 Apr 2010, alison.pamment at stfc.ac.uk wrote: > > > > > Dear Philip, > > > > > > Thanks very much for forwarding these emails to the list and > > sorry for > > > not picking up on this thread sooner. > > > > > > The standard names > > > > > > tendency_of_mole_concentration_of_particulate_organic_matter_expressed_ > a> s_carbon_in_sea_water_due_to_net_new_primary_production; > mol m-3 s-1 > > > net_new_primary_mole_productivity_of_carbon; mol m-2 s-1 > > > were accepted after discussion in the 'CMIP5 ocean biogeochemistry > > > standard names' thread. > > > > > > However, the name > > > net_primary_mole_productivity_of_carbon_due_to_nitrate > > > is now being proposed for the second quantity because there is some > > > confusion as to the precise meaning of 'new' production. > > > > > > As the accepted names have not yet been added to the standard > > name table > > > I think we could change them provided everyone agrees. Both names > > should> be changed to be consistent with one another. The phrase > > 'due_to' is > > > reserved in standard names for describing a process, e.g. > > > 'due_to_convection', so 'due_to_nitrate' doesn't really fit that > > > pattern. Would > > > > > > net_primary_mole_productivity_of_carbon_from_nutrients_containing_nitra > t> e > > > or just > > > net_primary_mole_productivity_of_carbon_from_nitrate_nutrients > > > be an accurate description? > > > > > > The first name could then be changed to > > > > > > tendency_of_mole_concentration_of_particulate_organic_matter_expressed_ > a> > s_carbon_in_sea_water_due_to_net_primary_production_from_{nutrients_con > t > > > aining_nitrate}|{nitrate_nutrients}. > > > > > > Perhaps John Dunne could also comment on these ideas. > > > > > > Best wishes, > > > Alison > > > > > > ------ > > > Alison Pamment Tel: +44 1235 778065 > > > NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > > > Rutherford Appleton Laboratory Email: > > alison.pamment at stfc.ac.uk> Chilton, Didcot, OX11 0QX, U.K. > > > > > > > > >> -----Original Message----- > > >> From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > > >> bounces at cgd.ucar.edu] On Behalf Of Philip J. Cameronsmith1 > > >> Sent: 22 April 2010 00:05 > > >> To: CF-metadata email list > > >> Subject: Re: [CF-metadata] BGC output for CMIP5 simulations (fwd) > > >> > > >> > > >> Hi, > > >> > > >> It appears that the wrong email address for the CF list was used > > for>> some > > >> of the emails in the conversation below. Hence, I am forwarding > > the>> final email for the record. > > >> > > >> Best wishes, > > >> > > >> Philip > > >> > > >> > > > ------------------------------------------------------------------ > > ----- > > >> - > > >> Dr Philip Cameron-Smith Atmospheric, Earth, and Energy > > Division>> pjc at llnl.gov Lawrence Livermore > > National Laboratory > > >> +1 925 4236634 7000 East Avenue, Livermore, > > CA94550,>> USA > > >> > > > ------------------------------------------------------------------ > > ----- > > >> - > > >> > > >> ---------- Forwarded message ---------- > > >> Date: Wed, 21 Apr 2010 13:15:39 > > >> From: Keith Lindsay > > >> To: Philip J. Cameronsmith1 > > >> Cc: John.Dunne at noaa.gov, Ernst Maier-Reimer > >> reimer at zmaw.de>, > > >> Corinne Le Quere , > > >> Bruce Hackett , > > >> Thomas LOUBRIEU , > > >> Laurent Bopp , > > >> Pierre Friedlingstein , > > >> James Orr , Laurence Crosnier > > > > >> ocean.fr>, > > >> Chris Jones , cf- > > >> metadata at ucar.edu, > > >> Karl Taylor , Yann BARZIC > > >> > > >> Subject: Re: [CF-metadata] BGC output for CMIP5 simulations > > >> > > >> On Wed, 21 Apr 2010, Philip J. Cameronsmith1 wrote: > > >> > > >>> Hi Keith, et al. > > >>> > > >>> By no3 I assume you mean the negatively charged nitrate ion > > (NO3-). > > >> In which > > >>> case I recommend using 'nitrate' in the standard name instead of > > >> 'no3'. This > > >>> will then be consistent with existing standard names, and avoid > > >> confusion > > >>> with the uncharged nitrate radical (NO3). > > >>> > > >>> In looking at the standard name table I think it would also be > > more>>> consistent to use _due_to_ instead of _from_. The latter > > is mainly > > >> used for > > >>> physical directions, eg _into_sea_water_from_rivers, while the > > > former > > >> is > > >>> mainly used when when the quantity is changing _due_to_ another > > >> process, eg > > >>> tendency_of_air_temperature_due_to_shortwave_heating. > > >>> > > >>> Hence, I suggest you consider the following: > > >>> > > >>> net_primary_mole_productivity_of_carbon_due_to_nitrate > > >>> > > >>> Best wishes, > > >>> > > >>> Philip > > >>> > > >> > > >> Philip, > > >> > > >> Thanks for the feedback. Your comments are on target. I propose > > going>> with your > > >> standard name. > > >> > > >> Keith > > >> > > >> ****************************************************************** > > >> Keith Lindsay > > http://**www.**cgd.ucar.edu/oce/klindsay/>> email: > > klindsay at ucar.edu phone: 303-497-1722 fax: 303-497-1700 > > >> _______________________________________________ > > >> CF-metadata mailing list > > >> CF-metadata at cgd.ucar.edu > > >> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > -- > > > Scanned by iCritical. > > > > > > > -------------------------------------------------------------------- > > ---- > > Dr Philip Cameron-Smith Atmospheric, Earth, and Energy > Division > > pjc at llnl.gov Lawrence Livermore National Laboratory > > +1 925 4236634 7000 East Avenue, Livermore, > > CA94550, USA > > -------------------------------------------------------------------- > > ---- ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. From alison.pamment at stfc.ac.uk Thu May 6 04:06:06 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Thu, 6 May 2010 11:06:06 +0100 Subject: [CF-metadata] water level with/without datum In-Reply-To: <1240F43731C2EB4F8CC9BF70D233B511018C06A7@SRV-XCHANGE-2K3.pc.cls.fr> References: <1240F43731C2EB4F8CC9BF70D233B511018C0685@SRV-XCHANGE-2K3.pc.cls.fr><20100305132856.GA4832@met.reading.ac.uk> <1240F43731C2EB4F8CC9BF70D233B511018C06A7@SRV-XCHANGE-2K3.pc.cls.fr> Message-ID: Dear All, I have reviewed this thread which caused considerable discussion during February/March. There seems to be general agreement on introducing the name water_surface_height_above_reference_datum for the height of the surface of any water body, be it sea, lake or river above an arbitrary reference datum. During the discussion it was not established how the reference datum itself would be specified. Jonathan suggested that for an arbitrary but fixed reference datum we might add another standard name along the lines of: water_surface_reference_datum_altitude while for a temporally and spatially varying reference datum, e.g. geoid, reference ellipsoid, the datum should form part of the name as is the current practice for sea_surface_height names. I think this sounds like a reasonable approach, but no one else has commented on this idea. It was agreed to postpone the discussion of a general term to describe 'sea/lake/river' until such time as a use case emerges as part of a firm standard name proposal. However, for future reference, I note that the three ideas arising from this discussion (and which have found some support) are: 1) a compound term such as sea_lake_river or sea_or_lake_or_river (Jonathan); 2) water_body (Roy, Seth); 3) defining the unqualified term 'water' to mean water in a water body (Nan). I would like to draw this thread to a conclusion and it seems that the most pressing question is how to describe the datum. If there are no further comments within fourteen days, the name water_surface_height_above_reference_datum will be accepted for inclusion in the standard name table along with Jonathan's suggestion of water_surface_reference_datum_altitude. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. > -----Original Message----- > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > bounces at cgd.ucar.edu] On Behalf Of olivier lauret > Sent: 05 March 2010 13:52 > To: Jonathan Gregory > Cc: cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] water level with/without datum > > Hi Jonathan, > > All right! Thank you very much for the clarification, it sounds good to > me. I'm OK with that > > Olivier > > -----Message d'origine----- > De?: Jonathan Gregory [mailto:jonathan at met.reading.ac.uk] De la part de > Jonathan Gregory > Envoy??: vendredi 5 mars 2010 14:29 > ??: olivier lauret > Cc?: Seth McGinnis; cf-metadata at cgd.ucar.edu > Objet?: Re: [CF-metadata] water level with/without datum > > Dear Olivier > > > - In the satellite dataset, CF attribute would be > > sea_surface_height_above_.. > > > > - In the in-situ dataset, CF attribute would be > > water_body_surface_height_above.. > > I believe that we have agreed to call the latter > water_surface_height_above... > (John's suggestion). > > Are you happy with that? I think this general name could be used for > sea, > lake or river, but we also keep the sea_surface_height for sea > specifically. > I think sea_surface_height is the name which should be used for both > satellite altimetry and tide-gauge measurements (on the sea). It's the > same > geophysical quantity, whichever way it's measured, so it should have > the > same name. water_surface_height could equally be used for either > measurement > method, and is appropriate if the data are not just for the sea. > > This sidesteps the general issue of sea/lake/river terms. The use of > "surface" > in water_surface makes it clear enough where the water is. If someone > is > definitely asking for a standard name which refers to a property of > water in > in sea, lake or river in general, we can return to that discussion. Roy > gave a > use case, but I'm not sure if that's a definite need. At present, my > own > preference would be for the lengthy but clear phrase > sea_or_lake_or_river. > > Best wishes > > Jonathan > > > Cliquez sur l'url suivante > https://www.mailcontrol.com/sr/ROXy6RRVjiDTndxI!oX7UtECuJx2pP2xUXH5bYXq > 6nCtlOBZquI!qzF+!sGAiQv0NoXV7xPWi+wY6wpstbrpNg== > si ce message est ind?sirable (pourriel). > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Scanned by iCritical. From alison.pamment at stfc.ac.uk Thu May 6 04:36:48 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Thu, 6 May 2010 11:36:48 +0100 Subject: [CF-metadata] Proposal for additional CF biogeochemistry attributes In-Reply-To: <1240F43731C2EB4F8CC9BF70D233B5116D5EDF@SRV-XCHANGE-2K3.pc.cls.fr> References: <20090513071531.GA9703@met.reading.ac.uk> <1240F43731C2EB4F8CC9BF70D233B5115F888A@SRV-XCHANGE-2K3.pc.cls.fr> <20090513185353.GA23310@met.reading.ac.uk> <4A0BE7BE.8060707@met.no> <1240F43731C2EB4F8CC9BF70D233B5115F8A65@SRV-XCHANGE-2K3.pc.cls.fr><4A1BAA49.5020001@lsce.ipsl.fr> <1240F43731C2EB4F8CC9BF70D233B5116D5D4A@SRV-XCHANGE-2K3.pc.cls.fr> <39157.62.225.2.8.1244044026.squirrel@webmail.lsce.ipsl.fr> <1240F43731C2EB4F8CC9BF70D233B5116D5EDF@SRV-XCHANGE-2K3.pc.cls.fr> Message-ID: Dear All, There are three names that remain to be added to the standard name table from this thread that was discussed some time ago. They were delayed due to questions (now resolved) regarding their definitions. The following three names are accepted for inclusion in the standard name table: mass_concentration_of_inorganic_nitrogen_in_sea_water; kg m-3 mass_concentration_of_flagellates_expressed_as_nitrogen_in_sea_water; kg m-3 mass_concentration_of_flagellates_expressed_as_carbon_in_sea_water; kg m-3. All the names in this thread have now been accepted. Best wishes, Alison ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. > -----Original Message----- > From: olivier lauret [mailto:olauret at cls.fr] > Sent: 03 June 2009 17:48 > To: christiane.textor at lsce.ipsl.fr; Pamment, JA (Alison) > Subject: RE: [CF-metadata] Proposal for additionalCFbiogeochemistry > attributes > > Thank you Christiane and Alison! > > About 'inorganic nitrogen', I am going to check with B. Hackett if he > wants to clarify it definition with species like you suggested. I'll > keep you informed. > > Cheers > > -----Message d'origine----- > De?: Christiane.Textor at lsce.ipsl.fr > [mailto:Christiane.Textor at lsce.ipsl.fr] > Envoy??: mercredi 3 juin 2009 17:47 > ??: Pamment, JA (Alison); olivier lauret > Objet?: Re: [CF-metadata] Proposal for additionalCFbiogeochemistry > attributes > > Thanks to both of you :) > > Pamment, JA (Alison) a ?crit : > > Dear Olivier and Christiane, > > > > Sorry for not commenting on this earlier. Christiane is correct that > the 'expressed_as' needs to go with the species. This is something > that > was discussed and agreed recently in one of the atmospheric chemistry > threads. Aliases will be created for the existing names to change the > order of the terms, so for example, > mole_concentration_of_mesozooplankton_in_sea_water_expressed_as_nitroge > n > will become > mole_concentration_of_mesozooplankton_expressed_as_nitrogen_in_sea_wate > r. > The names proposed for biogeochemistry should follow the same order. > With this change, I think all the names proposed in this thread can now > be > accepted: > > > > mass_concentration_of_inorganic_nitrogen_in_sea_water; kg m-3 > > mass_concentration_of_phosphate_in_sea_water; kg m-3 > > mole_concentration_of_phosphate_in_sea_water; mol m-3 > > mass_concentration_of_silicate_in_sea_water; kg m-3 > > > mass_concentration_of_organic_detritus_expressed_as_nitrogen_in_sea_wat > er; > kg m-3 > > > mass_concentration_of_organic_detritus_expressed_as_carbon_in_sea_water > ; > kg m-3 > > mass_concentration_of_diatoms_expressed_as_nitrogen_in_sea_water; kg > m-3 > mass_concentration_of_diatoms_expressed_as_carbon_in_sea_water; kg m-3 > mass_concentration_of_flagellates_expressed_as_nitrogen_in_sea_water; > kg > m-3 > > mass_concentration_of_flagellates_expressed_as_carbon_in_sea_water; > kg > m-3 > > volume_fraction_of_oxygen_in_sea_water; l > > mole_ratio_of_nitrate_to_phosphate_in_sea_water; 1 > > > mass_concentration_of_phytoplankton_expressed_as_chlorophyll_in_sea_wat > er; > kg m-3 > > > > I had to look up what a 'flagellate' is in marine biology - will the > following description be suitable for use in the standard name > definitions, or can anyone suggest a (reasonably concise) alternative: > > "Flagellates" are a class of single celled organisms that use a > flagellum (whip-like structure) for feeding and locomotion. Some > flagellates can photosynthesize and others feed on bacteria, with a few > flagellates capable of both." > > > > Is there a particular list of chemical species included in 'inorganic > nitrogen' or is this something that will vary from one model to > another? > > > > If we can sort out these definitions then the names can be included > in > the next update to the standard name table. > > > > Best wishes, > > Alison > > > > ------ > > Alison Pamment Tel: +44 1235 778065 > > NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 > > Rutherford Appleton Laboratory Email: > alison.pamment at stfc.ac.uk > Chilton, Didcot, OX11 0QX, U.K. > > > > > >> -----Original Message----- > >> From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > >> bounces at cgd.ucar.edu] On Behalf Of olivier lauret > >> Sent: 02 June 2009 17:01 > >> To: christiane.textor at lsce.ipsl.fr; CF-metadata email list > >> Subject: Re: [CF-metadata] Proposal for additionalCFbiogeochemistry > attributes > >> Hi Christiane, > >> You must be right. In that case I have another problem, because > existing standard names are build like this: > >> mole_concentration_of_diatoms_in_sea_water_expressed_as_nitrogen > That's > the reason why we suggested the names in that way.. > >> What should we do? Should we keep "expressed_as_X" at the end, like > it > is? Because on the other hand we would be obliged to change several > existing standard names? > >> Cheers > >> -----Message d'origine----- > >> De : cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata- > >> bounces at cgd.ucar.edu] De la part de Christiane Textor > >> Envoy? : mardi 26 mai 2009 10:37 > >> ? : CF-metadata email list > >> Objet : Re: [CF-metadata] Proposal for additional CFbiogeochemistry > attributes > >> Dear Olivier , > >> I have one short remark concerning the "expressed_as_X" names: The > expressed_as_X should be next to the species, e.g.: > >> > mass_concentration_of_organic_detritus_expressed_as_nitrogen_in_sea_wat > er > >> and not > >> > mass_concentration_of_organic_detritus_in_sea_water_expressed_as_nitrog > en > >> Cheers, > >> Christiane > >> olivier lauret a ?crit : > >>> Dear all, > >>> Thank you Philip. What I understood is that everybody finally > agrees > >> on > >>> introducing a concept like mole_ratio_of_X_to_Y_in_medium. > >>> And in that case the standard name we are looking for would be: > 'mole_ratio_of_nitrate_to_phosphate_in_sea_water'. > >>> It sounds good. > >>> Synthesizing the iterations we had together, this leads us to make > >> the > >>> following addition proposal to CF Metadata: > >>> mass_concentration_of_inorganic_nitrogen_in_sea_water > >>> kg m-3 > >>> ug/l > >>> mass_concentration_of_phosphate_in_sea_water > >>> kg m-3 > >>> ug/l > >>> mole_concentration_of_phosphate_in_sea_water > >>> mol m-3 > >>> umol/l > >>> mass_concentration_of_silicate_in_sea_water > >>> kg m-3 > >>> ug/l > >> > mass_concentration_of_organic_detritus_in_sea_water_expressed_as_nitrog > en > >>> kg m-3 > >>> ug/l > >> > mass_concentration_of_organic_detritus_in_sea_water_expressed_as_carbon > >>> kg m-3 > >>> ug/l > >>> mass_concentration_of_diatoms_in_sea_water_expressed_as_nitrogen kg > m-3 > >>> ug/l > >>> mass_concentration_of_diatoms_in_sea_water_expressed_as_carbon kg > m-3 > >>> ug/l > >>> > mass_concentration_of_flagellates_in_sea_water_expressed_as_nitrogen > kg m-3 > >>> ug/l > >>> mass_concentration_of_flagellates_in_sea_water_expressed_as_carbon > kg m-3 > >>> ug/l > >>> volume_fraction_of_oxygen_in_sea_water > >>> l l-1 > >>> ml/l > >>> mole_ratio_of_nitrate_to_phosphate_in_sea_water > >>> 1 > >>> 1 > >> > mass_concentration_of_phytoplankton_in_sea_water_expressed_as_chlorophy > ll > >>> kg m-3 > >>> ug/l > >>> Many thanks, > >>> Best wishes > >>> Olivier. > >>> -----Message d'origine----- > >>> De : Philip Cameronsmith [mailto:cameronsmith1 at llnl.gov] > >>> Envoy? : jeudi 14 mai 2009 19:42 > >>> ? : Bruce Hackett > >>> Cc : Jonathan Gregory; olivier lauret; cf-metadata at cgd.ucar.edu; > Laurence Crosnier; Thomas LOUBRIEU; Yann BARZIC > >>> Objet : Re: [CF-metadata] Proposal for additional CF > biogeochemistry > attributes > >>> Hi All, > >>> To help bring this to a conclusion, let me reiterate and say that > mole_ratio_of_X_to_Y_in_medium is acceptable to me. > >>> Best wishes, > >>> Philip > >>> On Thu, 14 May 2009, Bruce Hackett wrote: > >>> > Dear all, > >>> > I don't have vote here, but if you're going for a new prefix, > then > >>> "mole_ratio_" sounds better > >>> > to me. > >>> > Cheers, Bruce > >>> > > >>> > Jonathan Gregory wrote: > >>> > > >>> > Dear Philip > >>> > > >>> > I would be happy with > >>> > > >>> > > >>> > mole_ratio_of_X_to_Y_in_medium > >>> > > >>> > > >>> > i.e. the same as what I suggested, without "mixing". I think > that > >>> mole_ratio > >>> > is better than mole_fraction. I don't think it sounds right to > say > >>> "fraction > >>> > of X to Y"; don't we normally say "ratio of X to Y"? > >>> > > >>> > Best wishes > >>> > > >>> > Jonathan > >>> > > >>> > > >>> > > >>> > > >>> > -- > >>> > ---------------------------------------------------------------- > -- > >> ------ > >>> > Bruce Hackett Senior Scientist > >>> > Norwegian Meteorological Institute (met.no), R & D Div. > >>> > P.O. Box 43 - Blindern e-mail: > >> Bruce.Hackett at met.no > >>> > N-0313 Oslo Phone: +47 22 96 33 39 > NORWAY Fax: +47 22 96 33 80 > >>> > Mob: +47 48 048 958 > >>> > URL: http:// > >> met.no/english/r_and_d_activities/people/bruceh.html > >>> > ---------------------------------------------------------------- > -- > >> ------ > >>> > > >>> > > >>> ------------------------------------------------------------------- > -- > >> --- > >>> Dr Philip Cameron-Smith Atmospheric, Earth, and Energy > >> Division > >>> pjc at llnl.gov Lawrence Livermore National > Laboratory > +1 925 4236634 7000 East Avenue, Livermore, CA94550, > >> USA > >>> ------------------------------------------------------------------- > -- > >> --- > >>> Cliquez sur l'url suivante > >> https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== > AQlmOfRDi0BnnJufttNIjUG4Q7gTHQSZVcthUYCj!eKynw== > >>> si ce message est ind?sirable (pourriel). > >>> ------------------------------------------------------------------- > -- > >> --- > >>> _______________________________________________ > >>> CF-metadata mailing list > >>> CF-metadata at cgd.ucar.edu > >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > >> -- > >> > ====================================================================== > Christiane Textor > >> Laboratoire des Sciences du Climat et de l'Environnement > >> Unite Mixte de Recherche CEA-CNRS-UVSQ > >> LSCE/IPSL laboratoire CEA/CNRS/UVSQ > >> Saclay, Orme des Merisiers, > >> Bat. 701, Piece 3b, Point Courrier 129 > >> F-91191 Gif-sur-Yvette Cedex > >> FRANCE > >> mailto: christiane.textor at lsce.ipsl.fr > >> Tel ++33 1 69 08 34 07 Fax ++33 1 69 08 77 16 > >> GEOmon scientific coordinator http://www.geomon.eu > >> > ====================================================================== > _______________________________________________ > >> CF-metadata mailing list > >> CF-metadata at cgd.ucar.edu > >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > >> _______________________________________________ > >> CF-metadata mailing list > >> CF-metadata at cgd.ucar.edu > >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > -- > ====================================================================== > Christiane Textor > Laboratoire des Sciences du Climat et de l'Environnement > Unite Mixte de Recherche CEA-CNRS-UVSQ > > LSCE/IPSL laboratoire CEA/CNRS/UVSQ > Saclay, Orme des Merisiers, > Bat. 701, Piece 3b, Point Courrier 129 > F-91191 Gif-sur-Yvette Cedex > FRANCE > > mailto: christiane.textor at lsce.ipsl.fr > Tel ++33 1 69 08 34 07 Fax ++33 1 69 08 77 16 > > GEOmon scientific coordinator http://www.geomon.eu > ====================================================================== > > > > > > > > Cliquez sur l'url suivante > https://www.mailcontrol.com/sr/e5IeiLvOic!TndxI!oX7Uox5a7D76txBIfssc3!R > GuurJii31BGxR!FS8C5vhh!5r0s3dE0!F2lEcZNy6HxKug== > si ce message est ind?sirable (pourriel). From alison.pamment at stfc.ac.uk Thu May 6 04:50:10 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Thu, 6 May 2010 11:50:10 +0100 Subject: [CF-metadata] Standard name table update Message-ID: Dear All, I am planning to update the standard name table on Tuesday 11th May to add a number of new names that have been agreed in recent weeks. Please see below for a full list of the planned changes. If anyone spots any errors in the list please contact me as soon as possible. Best wishes, Alison a. Momentum flux names. Proposed by Tomas Kral. downward_eastward_momentum_flux_in_air_due_to_diffusion;Pa downward_northward_momentum_flux_in_air_due_to_diffusion; Pa b. CMIP5 ocean biogeochemistry names. Proposed by John Dunne, Jonathan Gregory, Karl Taylor, Alison Pamment. mole_concentration_of_dissolved_inorganic_carbon_in_sea_water; mol m-3 mole_concentration_of_dissolved_organic_carbon_in_sea_water; mol m-3 mole_concentration_of_phytoplankton_expressed_as_carbon_in_sea_water; mol m-3 mole_concentration_of_zooplankton_expressed_as_carbon_in_sea_water; mol m-3 mole_concentration_of_bacteria_expressed_as_carbon_in_sea_water; mol m-3 mole_concentration_of_organic_detritus_expressed_as_carbon_in_sea_water; mol m-3 mole_concentration_of_calcite_expressed_as_carbon_in_sea_water; mol m-3 mole_concentration_of_aragonite_expressed_as_carbon_in_sea_water; mol m-3 mole_concentration_of_diatoms_expressed_as_carbon_in_sea_water; mol m-3 mole_concentration_of_diazotrophs_expressed_as_carbon_in_sea_water; mol m-3 mole_concentration_of_calcareous_phytoplankton_expressed_as_carbon_in_se a_water; mol m-3 mole_concentration_of_picophytoplankton_expressed_as_carbon_in_sea_water ; mol m-3 mole_concentration_of_miscellaneous_phytoplankton_expressed_as_carbon_in _sea_water; mol m-3 mole_concentration_of_microzooplankton_expressed_as_carbon_in_sea_water; mol m-3 mole_concentration_of_mesozooplankton_expressed_as_carbon_in_sea_water; mol m-3 mole_concentration_of_miscellaneous_zooplankton_expressed_as_carbon_in_s ea_water; mol m-3 sea_water_alkalinity_expressed_as_mole_equivalent; mol m-3 sea_water_ph_reported_on_total_scale; 1 mole_concentration_of_molecular_oxygen_in_sea_water; mol m-3 mole_concentration_of_dissolved_iron_in_sea_water; mol m-3 mass_concentration_of_diatoms_expressed_as_chlorophyll_in_sea_water; kg m-3 mass_concentration_of_diazotrophs_expressed_as_chlorophyll_in_sea_water; kg m-3 mass_concentration_of_calcareous_phytoplankton_expressed_as_chlorophyll_ in_sea_water; kg m-3 mass_concentration_of_picophytoplankton_expressed_as_chlorophyll_in_sea_ water; kg m-3 mass_concentration_of_miscellaneous_phytoplankton_expressed_as_chlorophy ll_in_sea_water; kg m-3 mole_concentration_of_particulate_organic_matter_expressed_as_nitrogen_i n_sea_water; mol m-3 mole_concentration_of_particulate_organic_matter_expressed_as_phosphorus _in_sea_water; mol m-3 mole_concentration_of_particulate_organic_matter_expressed_as_iron_in_se a_water; mol m-3 mole_concentration_of_particulate_matter_expressed_as_silicon_in_sea_wat er; mol m-3 mole_concentration_of_phytoplankton_expressed_as_phosphorus_in_sea_water ; mol m-3 mole_concentration_of_phytoplankton_expressed_as_iron_in_sea_water; mol m-3 mole_concentration_of_phytoplankton_expressed_as_silicon_in_sea_water; mol m-3 mole_concentration_of_dimethyl_sulfide_in_sea_water; mol m-3 mole_concentration_of_carbonate_expressed_as_carbon_in_sea_water; mol m-3 mole_concentration_of_calcite_expressed_as_carbon_in_sea_water_at_satura tion; mol m-3 mole_concentration_of_aragonite_expressed_as_carbon_in_sea_water_at_satu ration; mol m-3 tendency_of_mole_concentration_of_particulate_organic_matter_expressed_a s_carbon_in_sea_water_due_to_net_primary_production; mol m-3 s-1 tendency_of_mole_concentration_of_particulte_organic_matter_expressed_as _carbon_in_sea_water_due_to_nitrate_utilization; mol m-3 s-1 tendency_of_mole_concentration_of_iron_in_sea_water_due_to_biological_pr oduction; mol m-3 s-1 tendency_of_mole_concentration_of_silicon_in_sea_water_due_to_biological _production; mol m-3 s-1 tendency_of_mole_concentration_of_calcite_expressed_as_carbon_in_sea_wat er_due_to_biological_production; mol m-3 s-1 tendency_of_mole_concentration_of_aragonite_expressed_as_carbon_in_sea_w ater_due_to_biological_production; mol m-3 s-1 sinking_mole_flux_of_particulate_organic_matter_expressed_as_carbon_in_s ea_water; mol m-2 s-1 sinking_mole_flux_of_particulate_organic_nitrogen_in_sea_water; mol m-2 s-1 sinking_mole_flux_of_particulate_organic_phosphorus_in_sea_water; mol m-2 s-1 sinking_mole_flux_of_particulate_iron_in_sea_water; mol m-2 s-1 sinking_mole_flux_of_particulate_silicon_in_sea_water; mol m-2 s-1 sinking_mole_flux_of_calcite_expressed_as_carbon_in_sea_water; mol m-2 s-1 sinking_mole_flux_of_aragonite_expressed_as_carbon_in_sea_water; mol m-2 s-1 tendency_of_mole_concentration_of_calcite_expressed_as_carbon_in_sea_wat er_due_to_dissolution; mol m-3 s-1 tendency_of_mole_concentration_of_aragonite_expressed_as_carbon_in_sea_w ater_due_to_dissolution; mol m-3 s-1 tendency_of_mole_concentration_of_particulate_organic_matter_expressed_a s_carbon_in_sea_water_due_to_net_primary_production_by_diatoms; mol m-3 s-1 tendency_of_mole_concentration_of_particulate_organic_matter_expressed_a s_carbon_in_sea_water_due_to_net_primary_production_by_diazatrophs; mol m-3 s-1 tendency_of_mole_concentration_of_particulate_organic_matter_expressed_a s_carbon_in_sea_water_due_to_net_primary_production_by_calcareous_phytop lankton; mol m-3 s-1 tendency_of_mole_concentration_of_particulate_organic_matter_expressed_a s_carbon_in_sea_water_due_to_net_primary_production_by_picophytoplankton ; mol m-3 s-1 tendency_of_mole_concentration_of_particulate_organic_matter_expressed_a s_carbon_in_sea_water_due_to_net_primary_production_by_miscellaneous_phy toplankton; mol m-3 s-1 tendency_of_mole_concentration_of_dissolved_inorganic_carbon_in_sea_wate r_due_to_biological_processes; mol m-3 s-1 tendency_of_mole_concentration_of_dissolved_inorganic_nitrogen_in_sea_wa ter_due_to_biological_processes; mol m-3 s-1 tendency_of_mole_concentration_of_dissolved_inorganic_phosphate_in_sea_w ater_due_to_biological_processes; mol m-3 s-1 tendency_of_mole_concentration_of_dissolved_inorganic_iron_in_sea_water_ due_to_biological_processes; mol m-3 s-1 tendency_of_mole_concentration_of_dissolved_inorganic_silicate_in_sea_wa ter_due_to_biological_processes; mol m-3 s-1 tendency_of_sea_water_alkalinity_expressed_as_mole_equivalent_due_to_bio logical_processes; mol m-3 s-1 tendency_of_mole_concentration_of_dissolved_iron_in_sea_water_due_to_sca venging_by_inorganic_particles; mol m-3 s-1 tendency_of_mole_concentration_of_dissolved_iron_in_sea_water_due_to_dis solution_from_inorganic_particles; mol m-3 s-1 tendency_of_mole_concentration_of_dissolved_iron_in_sea_water_due_to_gra zing_of_phytoplankton; mol m-3 s-1 net_primary_mole_productivity_of_carbon; mol m-2 s-1 net_primary_mole_productivity_of_carbon_due_to_nitrate_utilization; mol m-2 s-1 net_primary_mole_productivity_of_carbon_by_diatoms; mol m-2 s-1 net_primary_mole_productivity_of_carbon_by_diazatrophs; mol m-2 s-1 net_primary_mole_productivity_of_carbon_by_calcareous_phytoplankton; mol m-2 s-1 net_primary_mole_productivity_of_carbon_by_picophytoplankton; mol m-2 s-1 net_primary_mole_productivity_of_carbon_by_miscellaneous_phytoplankton; mol m-2 s-1 tendency_of_ocean_mole_content_of_iron_due_to_biological_production; mol m-2 s-1 tendency_of_ocean_mole_content_of_silicon_due_to_biological_production; mol m-2 s-1 tendency_of_ocean_mole_content_of_calcite_expressed_as_carbon_due_to_bio logical_production; mol m-2 s-1 tendency_of_ocean_mole_content_of_aragonite_expressed_as_carbon_due_to_b iological_production; mol m-2 s-1 ocean_mass_content_of_dissolved_inorganic_carbon; kg m-2 surface_carbon_dioxide_partial_pressure_difference_between_sea_water_and _air; Pa surface_oxygen_partial_pressure_difference_between_sea_water_and_air; Pa surface_downward_mass_flux_of_carbon_dioxide_expressed_as_carbon; kg m-2 s-1 surface_downward_mole_flux_of_molecular_oxygen; mol m-2 s-1 surface_upward_mole_flux_of_dimethyl_sulfide; mol m-2 s-1 tendency_of_ocean_mole_content_of_carbon_due_to_runoff_and_sediment_diss olution; mol m-2 s-1 tendency_of_ocean_mole_content_of_carbon_due_to_sedimentation; mol m-2 s-1 tendency_of_ocean_mole_content_of_elemental_nitrogen_due_to_fixation; mol m-2 s-1 tendency_of_ocean_mole_content_of_elemental_nitrogen_due_to_deposition_a nd_fixation_and_runoff; mol m-2 s-1 tendency_of_ocean_mole_content_of_elemental_nitrogen_due_to_denitrificat ion_and_sedimentation; mol m-2 s-1 tendency_of_ocean_mole_content_of_iron_due_to_deposition_and_runoff_and_ sediment_dissolution; mol m-2 s-1 tendency_of_ocean_mole_content_of_iron_due_to_sedimentation; mol m-2 s-1 mole_concentration_of_molecular_oxygen_in_sea_water_at_shallowest_local_ minimum_in_vertical_profile; mol m-3 depth_at_shallowest_local_minimum_in_vertical_profile_of_mole_concentrat ion_of_molecular_oxygen_in_sea_water; m minimum_depth_of_calcite_undersaturation_in_sea_water; m minimum_depth_of_aragonite_undersaturation_in_sea_water; m tendency_of_ocean_mole_content_of_dissolved_inorganic_carbon; mol m-2 s-1 tendency_of_ocean_mole_content_of_dissolved_inorganic_nitrogen; mol m-2 s-1 tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus; mol m-2 s-1 tendency_of_ocean_mole_content_of_dissolved_inorganic_iron; mol m-2 s-1 tendency_of_ocean_mole_content_of_dissolved_inorganic_silicon; mol m-2 s-1 integral_wrt_depth_of_tendency_of_sea_water_alkalinity_expressed_as_mole _equivalent; mol m-2 s-1 tendency_of_ocean_mole_content_of_dissolved_inorganic_carbon_due_to_biol ogical_processes; mol m-2 s-1 tendency_of_ocean_mole_content_of_dissolved_inorganic_nitrogen_due_to_bi ological_processes; mol m-2 s-1 tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus_due_to_ biological_processes; mol m-2 s-1 tendency_of_ocean_mole_content_of_dissolved_inorganic_iron_due_to_biolog ical_processes; mol m-2 s-1 tendency_of_ocean_mole_content_of_dissolved_inorganic_silicon_due_to_bio logical_processes; mol m-2 s-1 integral_wrt_depth_of_tendency_of_sea_water_alkalinity_expressed_as_mole _equivalent_due_to_biological_processes; mol m-2 s-1 c. Ocean biogeochemistry names. Proposed by Bruce Hackett in 'Proposal for additional CF biogeochemistry attributes' thread. mass_concentration_of_inorganic_nitrogen_in_sea_water; kg m-3 mass_concentration_of_flagellates_expressed_as_nitrogen_in_sea_water; kg m-3 mass_concentration_of_flagellates_expressed_as_carbon_in_sea_water; kg m-3 d. Name for chlorophyll-a. Proposed by Matthias Lankhorst. mass_concentration_of_chlorophyll_a_in_sea_water; kg m-3 e. CMIP5/CFMIP cloud feedback names. Proposed by Tomoo Ogura. tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to _cloud_microphysics tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to _boundary_layer_mixing tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to _bergeron_findeisen_process_to_cloud_ice tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_cloud_mi crophysics tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_boundary _layer_mixing tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_bergeron _findeisen_process_from_cloud_liquid tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due _to_cloud_microphysics tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due _to_boundary_layer_mixing ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. From m.schultz at fz-juelich.de Tue May 11 02:20:19 2010 From: m.schultz at fz-juelich.de (Schultz, Martin) Date: Tue, 11 May 2010 10:20:19 +0200 Subject: [CF-metadata] New CF checker tool available Message-ID: <2E9C45494F78A3498A77616E7C2DBB4C02064B18@icg217.icg-ii-w2k.kfa-juelich.de> Dear colleagues, we would like to announce the availability of a new CF checker tool available at http://htap.icg.kfa-juelich.de:50080/upload Presently, it checks for CF-1.0 compliance, but upgrades are planned to include later revisions as well. The tool was developed in the context of the TFHTAP multi-model experiment analysis and is written in Python. The source code is available upon request from Michael Decker (m.decker at fz-juelich.de). The development was initiated, because we felt that the existing tools aren't checking rigourously enough. The log report of your file check will contain 3 sections: errors, warnings and info messages. Please note that the user interface is still preliminary and may change in the future. We would be happy if you could help us test this new tool and if it could be included in the list of CF checker tools on the CF web site. Best regards, Martin Schultz < Dr. Martin G. Schultz, ICG-2, Forschungszentrum J?lich > < D-52425 J?lich, Germany > < ph: +49 (0)2461 61 2831, fax: +49 (0)2461 61 8131 > < email: m.schultz at fz-juelich.de > < web: http://www.fz-juelich.de/icg/icg-2/m_schultz > ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ From j.m.gregory at reading.ac.uk Tue May 11 05:38:28 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 11 May 2010 12:38:28 +0100 Subject: [CF-metadata] New CF checker tool available Message-ID: <20100511113828.GB19374@met.reading.ac.uk> Dear Martin > we would like to announce the availability of a new CF checker tool available at > http://htap.icg.kfa-juelich.de:50080/upload The CF-checker already on the CF website at http://cf-pcmdi.llnl.gov/conformance/compliance-checker/ checks the file is consistent with the CF conformance document at http://cf-pcmdi.llnl.gov/conformance/requirements-and-recommendations/ This document is a digest of the requirements and recommendation from the CF conventions document. It would be helpful to know what further checks your tool makes. Do you think the conformance document itself is not sufficiently rigorous, for instance? Thanks and best wishes Jonathan From alison.pamment at stfc.ac.uk Wed May 12 04:50:12 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Wed, 12 May 2010 11:50:12 +0100 Subject: [CF-metadata] Standard name table update In-Reply-To: References: Message-ID: Dear All, The standard name table has been updated as previously detailed. The current version is now version 14, dated 12 May 2010. While every effort has been made to ensure that the names, units and definitions are correct, please let me know if you do spot any mistakes or omissions. Best wishes, Alison > > a. Momentum flux names. Proposed by Tomas Kral. > > downward_eastward_momentum_flux_in_air_due_to_diffusion;Pa > downward_northward_momentum_flux_in_air_due_to_diffusion; Pa > > b. CMIP5 ocean biogeochemistry names. Proposed by John Dunne, Jonathan > Gregory, Karl Taylor, Alison Pamment. > > mole_concentration_of_dissolved_inorganic_carbon_in_sea_water; mol m-3 > mole_concentration_of_dissolved_organic_carbon_in_sea_water; mol m-3 > mole_concentration_of_phytoplankton_expressed_as_carbon_in_sea_water; > mol m-3 > mole_concentration_of_zooplankton_expressed_as_carbon_in_sea_water; mol > m-3 > mole_concentration_of_bacteria_expressed_as_carbon_in_sea_water; mol m- > 3 > mole_concentration_of_organic_detritus_expressed_as_carbon_in_sea_water > ; mol m-3 > mole_concentration_of_calcite_expressed_as_carbon_in_sea_water; mol m-3 > mole_concentration_of_aragonite_expressed_as_carbon_in_sea_water; mol > m-3 > mole_concentration_of_diatoms_expressed_as_carbon_in_sea_water; mol m-3 > mole_concentration_of_diazotrophs_expressed_as_carbon_in_sea_water; mol > m-3 > mole_concentration_of_calcareous_phytoplankton_expressed_as_carbon_in_s > ea_water; mol m-3 > mole_concentration_of_picophytoplankton_expressed_as_carbon_in_sea_wate > r; mol m-3 > mole_concentration_of_miscellaneous_phytoplankton_expressed_as_carbon_i > n_sea_water; mol m-3 > mole_concentration_of_microzooplankton_expressed_as_carbon_in_sea_water > ; mol m-3 > mole_concentration_of_mesozooplankton_expressed_as_carbon_in_sea_water; > mol m-3 > mole_concentration_of_miscellaneous_zooplankton_expressed_as_carbon_in_ > sea_water; mol m-3 > sea_water_alkalinity_expressed_as_mole_equivalent; mol m-3 > sea_water_ph_reported_on_total_scale; 1 > mole_concentration_of_molecular_oxygen_in_sea_water; mol m-3 > mole_concentration_of_dissolved_iron_in_sea_water; mol m-3 > mass_concentration_of_diatoms_expressed_as_chlorophyll_in_sea_water; kg > m-3 > mass_concentration_of_diazotrophs_expressed_as_chlorophyll_in_sea_water > ; kg m-3 > mass_concentration_of_calcareous_phytoplankton_expressed_as_chlorophyll > _in_sea_water; kg m-3 > mass_concentration_of_picophytoplankton_expressed_as_chlorophyll_in_sea > _water; kg m-3 > mass_concentration_of_miscellaneous_phytoplankton_expressed_as_chloroph > yll_in_sea_water; kg m-3 > mole_concentration_of_particulate_organic_matter_expressed_as_nitrogen_ > in_sea_water; mol m-3 > mole_concentration_of_particulate_organic_matter_expressed_as_phosphoru > s_in_sea_water; mol m-3 > mole_concentration_of_particulate_organic_matter_expressed_as_iron_in_s > ea_water; mol m-3 > mole_concentration_of_particulate_matter_expressed_as_silicon_in_sea_wa > ter; mol m-3 > mole_concentration_of_phytoplankton_expressed_as_phosphorus_in_sea_wate > r; mol m-3 > mole_concentration_of_phytoplankton_expressed_as_iron_in_sea_water; mol > m-3 > mole_concentration_of_phytoplankton_expressed_as_silicon_in_sea_water; > mol m-3 > mole_concentration_of_dimethyl_sulfide_in_sea_water; mol m-3 > mole_concentration_of_carbonate_expressed_as_carbon_in_sea_water; mol > m-3 > mole_concentration_of_calcite_expressed_as_carbon_in_sea_water_at_satur > ation; mol m-3 > mole_concentration_of_aragonite_expressed_as_carbon_in_sea_water_at_sat > uration; mol m-3 > tendency_of_mole_concentration_of_particulate_organic_matter_expressed_ > as_carbon_in_sea_water_due_to_net_primary_production; mol m-3 s-1 > tendency_of_mole_concentration_of_particulte_organic_matter_expressed_a > s_carbon_in_sea_water_due_to_nitrate_utilization; mol m-3 s-1 > tendency_of_mole_concentration_of_iron_in_sea_water_due_to_biological_p > roduction; mol m-3 s-1 > tendency_of_mole_concentration_of_silicon_in_sea_water_due_to_biologica > l_production; mol m-3 s-1 > tendency_of_mole_concentration_of_calcite_expressed_as_carbon_in_sea_wa > ter_due_to_biological_production; mol m-3 s-1 > tendency_of_mole_concentration_of_aragonite_expressed_as_carbon_in_sea_ > water_due_to_biological_production; mol m-3 s-1 > sinking_mole_flux_of_particulate_organic_matter_expressed_as_carbon_in_ > sea_water; mol m-2 s-1 > sinking_mole_flux_of_particulate_organic_nitrogen_in_sea_water; mol m-2 > s-1 > sinking_mole_flux_of_particulate_organic_phosphorus_in_sea_water; mol > m-2 s-1 > sinking_mole_flux_of_particulate_iron_in_sea_water; mol m-2 s-1 > sinking_mole_flux_of_particulate_silicon_in_sea_water; mol m-2 s-1 > sinking_mole_flux_of_calcite_expressed_as_carbon_in_sea_water; mol m-2 > s-1 > sinking_mole_flux_of_aragonite_expressed_as_carbon_in_sea_water; mol m- > 2 s-1 > tendency_of_mole_concentration_of_calcite_expressed_as_carbon_in_sea_wa > ter_due_to_dissolution; mol m-3 s-1 > tendency_of_mole_concentration_of_aragonite_expressed_as_carbon_in_sea_ > water_due_to_dissolution; mol m-3 s-1 > tendency_of_mole_concentration_of_particulate_organic_matter_expressed_ > as_carbon_in_sea_water_due_to_net_primary_production_by_diatoms; mol m- > 3 s-1 > tendency_of_mole_concentration_of_particulate_organic_matter_expressed_ > as_carbon_in_sea_water_due_to_net_primary_production_by_diazotrophs; > mol m-3 s-1 > tendency_of_mole_concentration_of_particulate_organic_matter_expressed_ > as_carbon_in_sea_water_due_to_net_primary_production_by_calcareous_phyt > oplankton; mol m-3 s-1 > tendency_of_mole_concentration_of_particulate_organic_matter_expressed_ > as_carbon_in_sea_water_due_to_net_primary_production_by_picophytoplankt > on; mol m-3 s-1 > tendency_of_mole_concentration_of_particulate_organic_matter_expressed_ > as_carbon_in_sea_water_due_to_net_primary_production_by_miscellaneous_p > hytoplankton; mol m-3 s-1 > tendency_of_mole_concentration_of_dissolved_inorganic_carbon_in_sea_wat > er_due_to_biological_processes; mol m-3 s-1 > tendency_of_mole_concentration_of_dissolved_inorganic_nitrogen_in_sea_w > ater_due_to_biological_processes; mol m-3 s-1 > tendency_of_mole_concentration_of_dissolved_inorganic_phosphate_in_sea_ > water_due_to_biological_processes; mol m-3 s-1 > tendency_of_mole_concentration_of_dissolved_inorganic_iron_in_sea_water > _due_to_biological_processes; mol m-3 s-1 > tendency_of_mole_concentration_of_dissolved_inorganic_silicate_in_sea_w > ater_due_to_biological_processes; mol m-3 s-1 > tendency_of_sea_water_alkalinity_expressed_as_mole_equivalent_due_to_bi > ological_processes; mol m-3 s-1 > tendency_of_mole_concentration_of_dissolved_iron_in_sea_water_due_to_sc > avenging_by_inorganic_particles; mol m-3 s-1 > tendency_of_mole_concentration_of_dissolved_iron_in_sea_water_due_to_di > ssolution_from_inorganic_particles; mol m-3 s-1 > tendency_of_mole_concentration_of_dissolved_iron_in_sea_water_due_to_gr > azing_of_phytoplankton; mol m-3 s-1 > net_primary_mole_productivity_of_carbon_by_phytoplankton; mol m-2 s-1 > net_primary_mole_productivity_of_carbon_due_to_nitrate_utilization; mol > m-2 s-1 > net_primary_mole_productivity_of_carbon_by_diatoms; mol m-2 s-1 > net_primary_mole_productivity_of_carbon_by_diazotrophs; mol m-2 s-1 > net_primary_mole_productivity_of_carbon_by_calcareous_phytoplankton; > mol m-2 s-1 > net_primary_mole_productivity_of_carbon_by_picophytoplankton; mol m-2 > s-1 > net_primary_mole_productivity_of_carbon_by_miscellaneous_phytoplankton; > mol m-2 s-1 > tendency_of_ocean_mole_content_of_iron_due_to_biological_production; > mol m-2 s-1 > tendency_of_ocean_mole_content_of_silicon_due_to_biological_production; > mol m-2 s-1 > tendency_of_ocean_mole_content_of_calcite_expressed_as_carbon_due_to_bi > ological_production; mol m-2 s-1 > tendency_of_ocean_mole_content_of_aragonite_expressed_as_carbon_due_to_ > biological_production; mol m-2 s-1 > ocean_mass_content_of_dissolved_inorganic_carbon; kg m-2 > surface_carbon_dioxide_partial_pressure_difference_between_sea_water_an > d_air; Pa > surface_oxygen_partial_pressure_difference_between_sea_water_and_air; > Pa > surface_downward_mass_flux_of_carbon_dioxide_expressed_as_carbon; kg m- > 2 s-1 > surface_downward_mole_flux_of_molecular_oxygen; mol m-2 s-1 > surface_upward_mole_flux_of_dimethyl_sulfide; mol m-2 s-1 > tendency_of_ocean_mole_content_of_carbon_due_to_runoff_and_sediment_dis > solution; mol m-2 s-1 > tendency_of_ocean_mole_content_of_carbon_due_to_sedimentation; mol m-2 > s-1 > tendency_of_ocean_mole_content_of_elemental_nitrogen_due_to_fixation; > mol m-2 s-1 > tendency_of_ocean_mole_content_of_elemental_nitrogen_due_to_deposition_ > and_fixation_and_runoff; mol m-2 s-1 > tendency_of_ocean_mole_content_of_elemental_nitrogen_due_to_denitrifica > tion_and_sedimentation; mol m-2 s-1 > tendency_of_ocean_mole_content_of_iron_due_to_deposition_and_runoff_and > _sediment_dissolution; mol m-2 s-1 > tendency_of_ocean_mole_content_of_iron_due_to_sedimentation; mol m-2 s- > 1 > mole_concentration_of_dissolved_molecular_oxygen_in_sea_water_at_shallow est_local > _minimum_in_vertical_profile; mol m-3 > depth_at_shallowest_local_minimum_in_vertical_profile_of_mole_concentra > tion_of_dissolved_molecular_oxygen_in_sea_water; m > minimum_depth_of_calcite_undersaturation_in_sea_water; m > minimum_depth_of_aragonite_undersaturation_in_sea_water; m > tendency_of_ocean_mole_content_of_dissolved_inorganic_carbon; mol m-2 > s-1 > tendency_of_ocean_mole_content_of_dissolved_inorganic_nitrogen; mol m-2 > s-1 > tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus; mol > m-2 s-1 > tendency_of_ocean_mole_content_of_dissolved_inorganic_iron; mol m-2 s-1 > tendency_of_ocean_mole_content_of_dissolved_inorganic_silicon; mol m-2 > s-1 > integral_wrt_depth_of_tendency_of_sea_water_alkalinity_expressed_as_mol > e_equivalent; mol m-2 s-1 > tendency_of_ocean_mole_content_of_dissolved_inorganic_carbon_due_to_bio > logical_processes; mol m-2 s-1 > tendency_of_ocean_mole_content_of_dissolved_inorganic_nitrogen_due_to_b > iological_processes; mol m-2 s-1 > tendency_of_ocean_mole_content_of_dissolved_inorganic_phosphorus_due_to > _biological_processes; mol m-2 s-1 > tendency_of_ocean_mole_content_of_dissolved_inorganic_iron_due_to_biolo > gical_processes; mol m-2 s-1 > tendency_of_ocean_mole_content_of_dissolved_inorganic_silicon_due_to_bi > ological_processes; mol m-2 s-1 > integral_wrt_depth_of_tendency_of_sea_water_alkalinity_expressed_as_mol > e_equivalent_due_to_biological_processes; mol m-2 s-1 > > c. Ocean biogeochemistry names. Proposed by Bruce Hackett in 'Proposal > for additional CF biogeochemistry attributes' thread. > > mass_concentration_of_inorganic_nitrogen_in_sea_water; kg m-3 > mass_concentration_of_flagellates_expressed_as_nitrogen_in_sea_water; > kg m-3 > mass_concentration_of_flagellates_expressed_as_carbon_in_sea_water; kg > m-3 > > d. Name for chlorophyll-a. Proposed by Matthias Lankhorst. > > mass_concentration_of_chlorophyll_a_in_sea_water; kg m-3 > > e. CMIP5/CFMIP cloud feedback names. Proposed by Tomoo Ogura. > > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_t > o_cloud_microphysics > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_t > o_boundary_layer_mixing > tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_t > o_bergeron_findeisen_process_to_cloud_ice > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_cloud_m > icrophysics > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_boundar > y_layer_mixing > tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_bergero > n_findeisen_process_from_cloud_liquid > tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air > tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_du > e_to_cloud_microphysics > tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_du > e_to_boundary_layer_mixing > ------ Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data Centre Fax: +44 1235 446314 Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk Chilton, Didcot, OX11 0QX, U.K. -- Scanned by iCritical. From m.schultz at fz-juelich.de Wed May 12 06:33:29 2010 From: m.schultz at fz-juelich.de (Schultz, Martin) Date: Wed, 12 May 2010 14:33:29 +0200 Subject: [CF-metadata] non-standard standard_names Message-ID: <2E9C45494F78A3498A77616E7C2DBB4C02064B99@icg217.icg-ii-w2k.kfa-juelich.de> Dear all, we are currently cleaning all files on our TFHTAP multi-model experiment server to make them fully CF(1.0) conformant. It has been about 3 years since we had drafted the original format description of these experiments and also initiated the standard name discussion for chemical constituents (thanks again to Christiane Textor who did a lot of this initial work). Many standard names which we needed have now been defined (thanks to all who contributed and to Allison for maintaining the list!). Nevertheless, there are a number of model variables left for which no standard name has been agreed upon and where we (or the CF mailing list group) also felt that they are too specialized to deserve a "standard" name. From the perspective of the CF community this may not be an issue, but in the context of interoperability (we now operate a WCS server to share these files) the fact that some variables do have a standard_name attribute and others don't poses considerable challenges. The CF convention states that "either standard_name or long_name" should be present. In our view, the long_name attribute is a poor substitute for the standard_name, because it has no rules attached. We are now planning to substitute "illegal" standard_name attributes by a new "htap-_standard_name" attribute, which shall make clear that these names are derived according to the CF guidelines, but they are not accepted standard_names. Such a concept would enable software tools to easily scan additional standard_name tables and make use of the well-defined semantics that a standard_name provides without having to push additional standard_names through the discussion - in particular if they are no so "standard". I can see the danger that certain groups might think it no longer necessary to go through the tedious but ultimately worthwhile discussion process in this mailing list and the meaning of "standard" names could get diluted. However, in my view the advantage of having the possibility to extend the convention without breaking standard-conformance outweighs this potential disadvantage. Specifically I would thus propose to add an optional attribute to the CF documents such as: _standard_name: use this attribute to define the meaning of variables which have no accepted standard_name defined (yet). The project name should be a single string without blanks or underscore characters. These project-specific standard_names must follow the guidelines for the construction of standard_names, but they will not be evaluated by generic tools which test a data file for CF compliance. Groups who wish to define such project-specific standard names should first consider to submit their proposals to the CF mailing list for inclusion in the CF standard name table. A variable can contain either a standard_name or _standard_name attribute but not both. A long_name attribute is not needed when a _standard_name is given. Best regards, Martin ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ From jbgraybeal at mindspring.com Wed May 12 08:14:59 2010 From: jbgraybeal at mindspring.com (John Graybeal) Date: Wed, 12 May 2010 07:14:59 -0700 Subject: [CF-metadata] non-standard standard_names In-Reply-To: <2E9C45494F78A3498A77616E7C2DBB4C02064B99@icg217.icg-ii-w2k.kfa-juelich.de> References: <2E9C45494F78A3498A77616E7C2DBB4C02064B99@icg217.icg-ii-w2k.kfa-juelich.de> Message-ID: <578C5D37-91D9-43D6-97BF-FE452D10DA2E@mindspring.com> Martin et al, I like this approach. I think this is an important addition to the CF concept, it supports much more scalability and encourages much more adoption. There may be some concern that is not immediately obvious to me, but I have been thinking about a complementary solution from the semantic web standpoint. I'll send that to the list separately so it goes under a separate thread. Note your example has a hyphen in it, does 'htap_standard_name' more clearly represents your proposal? As an alternative approach, we might blend the concept of the alternative standard name with a more explicit project or vocabulary reference. Rather than a plethora of xyz_standard_name forms, and the need to do a regular expression search to find them, we could have one form like 'provisional_standard_name', with the requirement that a provisional vocabulary or project also be specified (e.g., 'provisional_name_project' with a string, or 'provisional_name_vocabulary' with a URL. These approaches avoid overloading the attribute name, which seems like a good practice; but I appreciate we might be asked to discuss them via TRAC. Thanks for bringing this idea forward. John On May 12, 2010, at 05:33, Schultz, Martin wrote: > Dear all, > > we are currently cleaning all files on our TFHTAP multi-model > experiment server to make them fully CF(1.0) conformant. It has been > about 3 years since we had drafted the original format description of > these experiments and also initiated the standard name discussion for > chemical constituents (thanks again to Christiane Textor who did a lot > of this initial work). Many standard names which we needed have now been > defined (thanks to all who contributed and to Allison for maintaining > the list!). Nevertheless, there are a number of model variables left for > which no standard name has been agreed upon and where we (or the CF > mailing list group) also felt that they are too specialized to deserve a > "standard" name. From the perspective of the CF community this may not > be an issue, but in the context of interoperability (we now operate a > WCS server to share these files) the fact that some variables do have a > standard_name attribute and others don't poses considerable challenges. > The CF convention states that "either standard_name or long_name" should > be present. In our view, the long_name attribute is a poor substitute > for the standard_name, because it has no rules attached. We are now > planning to substitute "illegal" standard_name attributes by a new > "htap-_standard_name" attribute, which shall make clear that these names > are derived according to the CF guidelines, but they are not accepted > standard_names. Such a concept would enable software tools to easily > scan additional standard_name tables and make use of the well-defined > semantics that a standard_name provides without having to push > additional standard_names through the discussion - in particular if they > are no so "standard". I can see the danger that certain groups might > think it no longer necessary to go through the tedious but ultimately > worthwhile discussion process in this mailing list and the meaning of > "standard" names could get diluted. However, in my view the advantage of > having the possibility to extend the convention without breaking > standard-conformance outweighs this potential disadvantage. > > Specifically I would thus propose to add an optional attribute to > the CF documents such as: > > _standard_name: use this attribute to define the meaning of > variables which have no accepted standard_name defined (yet). The > project name should be a single string without blanks or underscore > characters. These project-specific standard_names must follow the > guidelines for the construction of standard_names, but they will not be > evaluated by generic tools which test a data file for CF compliance. > Groups who wish to define such project-specific standard names should > first consider to submit their proposals to the CF mailing list for > inclusion in the CF standard name table. A variable can contain either a > standard_name or _standard_name attribute but not both. A > long_name attribute is not needed when a _standard_name is > given. > > > Best regards, > > Martin > From olauret at cls.fr Wed May 12 09:09:06 2010 From: olauret at cls.fr (Lauret Olivier) Date: Wed, 12 May 2010 17:09:06 +0200 Subject: [CF-metadata] non-standard standard_names In-Reply-To: <578C5D37-91D9-43D6-97BF-FE452D10DA2E@mindspring.com> References: <2E9C45494F78A3498A77616E7C2DBB4C02064B99@icg217.icg-ii-w2k.kfa-juelich.de> <578C5D37-91D9-43D6-97BF-FE452D10DA2E@mindspring.com> Message-ID: <1240F43731C2EB4F8CC9BF70D233B51101B96F71@SRV-XCHANGE-2K3.pc.cls.fr> Hello all I agree with you. We are currently experimenting a solution to that based on semantic language. We have the same need in the frame of a project (MyOcean, actually). I tell you the story: There is the need for MyOcean Information System (call it 'MIS') entities to share the same standard name table. As some standard name for MyOcean variables are missing, and as the process of updating CF official table is external to MyOcean project, the idea is: - to make a MyOcean internal copy of CF table to fulfill MIS requirements. Inside this copy MIS will keep up-to-date the list of official CF standard names combined with the list of proposed CF standard names, until each variable within MyOcean has one CF definition. - write this using standardized formalism. SKOS was identified as a good candidate for that. Actually some structures like MMI and BODC have already started to represent CF using semantic language. Instead of rewriting all CF and turn it into SKOS, we prefer re-use such existing works. Existing SKOS vocabularies for CF represent CF official table turned into a semantic way, and are provided on a web server; each of the SKOS resources has one URI. Actually we propose to manage an internal version of this which contains all existing resources needed for the MIS (maybe only 50 at the most standard names attributes), and, use URIs to map them with external reference. Once one CF standard name is accepted, I should only have to map my internal CF resource to official new one using "skos:exactMatch" relationship. That's the idea.. Best wishes Olivier. -----Message d'origine----- De : cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] De la part de John Graybeal Envoy? : mercredi 12 mai 2010 16:15 ? : Schultz, Martin Cc : cf-metadata at cgd.ucar.edu Objet : Re: [CF-metadata] non-standard standard_names Martin et al, I like this approach. I think this is an important addition to the CF concept, it supports much more scalability and encourages much more adoption. There may be some concern that is not immediately obvious to me, but I have been thinking about a complementary solution from the semantic web standpoint. I'll send that to the list separately so it goes under a separate thread. Note your example has a hyphen in it, does 'htap_standard_name' more clearly represents your proposal? As an alternative approach, we might blend the concept of the alternative standard name with a more explicit project or vocabulary reference. Rather than a plethora of xyz_standard_name forms, and the need to do a regular expression search to find them, we could have one form like 'provisional_standard_name', with the requirement that a provisional vocabulary or project also be specified (e.g., 'provisional_name_project' with a string, or 'provisional_name_vocabulary' with a URL. These approaches avoid overloading the attribute name, which seems like a good practice; but I appreciate we might be asked to discuss them via TRAC. Thanks for bringing this idea forward. John On May 12, 2010, at 05:33, Schultz, Martin wrote: > Dear all, > > we are currently cleaning all files on our TFHTAP multi-model > experiment server to make them fully CF(1.0) conformant. It has been > about 3 years since we had drafted the original format description of > these experiments and also initiated the standard name discussion for > chemical constituents (thanks again to Christiane Textor who did a lot > of this initial work). Many standard names which we needed have now been > defined (thanks to all who contributed and to Allison for maintaining > the list!). Nevertheless, there are a number of model variables left for > which no standard name has been agreed upon and where we (or the CF > mailing list group) also felt that they are too specialized to deserve a > "standard" name. From the perspective of the CF community this may not > be an issue, but in the context of interoperability (we now operate a > WCS server to share these files) the fact that some variables do have a > standard_name attribute and others don't poses considerable challenges. > The CF convention states that "either standard_name or long_name" should > be present. In our view, the long_name attribute is a poor substitute > for the standard_name, because it has no rules attached. We are now > planning to substitute "illegal" standard_name attributes by a new > "htap-_standard_name" attribute, which shall make clear that these names > are derived according to the CF guidelines, but they are not accepted > standard_names. Such a concept would enable software tools to easily > scan additional standard_name tables and make use of the well-defined > semantics that a standard_name provides without having to push > additional standard_names through the discussion - in particular if they > are no so "standard". I can see the danger that certain groups might > think it no longer necessary to go through the tedious but ultimately > worthwhile discussion process in this mailing list and the meaning of > "standard" names could get diluted. However, in my view the advantage of > having the possibility to extend the convention without breaking > standard-conformance outweighs this potential disadvantage. > > Specifically I would thus propose to add an optional attribute to > the CF documents such as: > > _standard_name: use this attribute to define the meaning of > variables which have no accepted standard_name defined (yet). The > project name should be a single string without blanks or underscore > characters. These project-specific standard_names must follow the > guidelines for the construction of standard_names, but they will not be > evaluated by generic tools which test a data file for CF compliance. > Groups who wish to define such project-specific standard names should > first consider to submit their proposals to the CF mailing list for > inclusion in the CF standard name table. A variable can contain either a > standard_name or _standard_name attribute but not both. A > long_name attribute is not needed when a _standard_name is > given. > > > Best regards, > > Martin > _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata Cliquez sur l'url suivante https://www.mailcontrol.com/sr/ABvmYQAiIdPTndxI!oX7UnkyRQ0MRq91WnKfcdbqy7umgMZ!HR+bcGckO!Kq9tCR!BRnKHvkql1LwdQMGDtFKA== si ce message est ind?sirable (pourriel). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 12859 bytes Desc: image002.jpg URL: From Steven.C.Hankin at noaa.gov Wed May 12 12:22:12 2010 From: Steven.C.Hankin at noaa.gov (Steve Hankin) Date: Wed, 12 May 2010 11:22:12 -0700 Subject: [CF-metadata] non-standard standard_names In-Reply-To: <2E9C45494F78A3498A77616E7C2DBB4C02064B99@icg217.icg-ii-w2k.kfa-juelich.de> References: <2E9C45494F78A3498A77616E7C2DBB4C02064B99@icg217.icg-ii-w2k.kfa-juelich.de> Message-ID: <4BEAF1D4.5050207@noaa.gov> Hi Martin, You've had two enthusiastic "yes" responses, so I guess I have the privilege to be the wet blanket. So it goes. I will give only a very cautious and limited "yes". Not an outright "no" ... but a suggestion for more thought and discussion. The proposal here is effectively the creation of 'private tables' as a means of achieving extensibility. We've had an opportunity to see the hazards embedded in this approach as a long-term evolutionary process in WMO. Over time the "custom" tables evolve to have an quasi-official status -- entire sub-communities rely upon them -- but without necessarily a corresponding methodical control over their creation and distribution. With BUFR and GRIB files the proliferation of distinct tables has lead to serious interoperability problems. To avoid repeating these problems with your proposal, CF clients must be provided with *iron-clad ways to be assured that they are referring to the same vocabulary tables that the data author was referring to at the time that the data were written*. Since we want CF files to ensure interoperability when there are *years separating the writing of data from reading it*, your strategy needs to ensure careful version control over the private tables. This imposes a significant burden on you as the creator of a "_standard_name" table -- essentially a requirement to retain and serve out older table versions "in perpetuity" (we could argue over what that means). The use of semantic web technologies will not alter these considerations for the foreseeable future (tho over the long term sophisticated inference engines might ...). The ontologies still need to be informed by correct information, which implies knowledge of the version-controlled private vocabularies. A "_standard_name" may have one of three life histories: it may never become accepted into the standard_name table; it may be accepted as-is; or it may be accepted with alterations. The following suggested restriction illustrates some of the difficulties: "A variable can contain either a standard_name or _standard_name attribute but not both." What's behind this restriction? Given the uncertain life history of a _standard_name, if it has been in use for (say) a year and is found in thousands of files that are being shared around the community, doesn't that generate a need to continue support for it. Two alternative approaches (both flawed, of course ... the nature of the beast): 1. Should the CF standard_name process, itself, include a "provisional fast-track", that allows names to be added very quickly with no guarantee that they will have a lasting status, but with an *iron-clad guarantee that the provisional names will be retained* (and so-identified) in version-stamped (older) CF vocabularies. or 2. Might you be better off using a *truly private* vocabulary of "_standard_name" strings. I.e. one that has no official status in CF at all? There is no violation to the CF standard through doing this. This approach makes it your private responsibility on behalf of your users to deal with files that are created in the period between proposing a CF standard_name and having it become part of the official table - Steve ==================== Schultz, Martin wrote: > Dear all, > > we are currently cleaning all files on our TFHTAP multi-model > experiment server to make them fully CF(1.0) conformant. It has been > about 3 years since we had drafted the original format description of > these experiments and also initiated the standard name discussion for > chemical constituents (thanks again to Christiane Textor who did a lot > of this initial work). Many standard names which we needed have now been > defined (thanks to all who contributed and to Allison for maintaining > the list!). Nevertheless, there are a number of model variables left for > which no standard name has been agreed upon and where we (or the CF > mailing list group) also felt that they are too specialized to deserve a > "standard" name. From the perspective of the CF community this may not > be an issue, but in the context of interoperability (we now operate a > WCS server to share these files) the fact that some variables do have a > standard_name attribute and others don't poses considerable challenges. > The CF convention states that "either standard_name or long_name" should > be present. In our view, the long_name attribute is a poor substitute > for the standard_name, because it has no rules attached. We are now > planning to substitute "illegal" standard_name attributes by a new > "htap-_standard_name" attribute, which shall make clear that these names > are derived according to the CF guidelines, but they are not accepted > standard_names. Such a concept would enable software tools to easily > scan additional standard_name tables and make use of the well-defined > semantics that a standard_name provides without having to push > additional standard_names through the discussion - in particular if they > are no so "standard". I can see the danger that certain groups might > think it no longer necessary to go through the tedious but ultimately > worthwhile discussion process in this mailing list and the meaning of > "standard" names could get diluted. However, in my view the advantage of > having the possibility to extend the convention without breaking > standard-conformance outweighs this potential disadvantage. > > Specifically I would thus propose to add an optional attribute to > the CF documents such as: > > _standard_name: use this attribute to define the meaning of > variables which have no accepted standard_name defined (yet). The > project name should be a single string without blanks or underscore > characters. These project-specific standard_names must follow the > guidelines for the construction of standard_names, but they will not be > evaluated by generic tools which test a data file for CF compliance. > Groups who wish to define such project-specific standard names should > first consider to submit their proposals to the CF mailing list for > inclusion in the CF standard name table. A variable can contain either a > standard_name or _standard_name attribute but not both. A > long_name attribute is not needed when a _standard_name is > given. > > > Best regards, > > Martin > > > ------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------ > Forschungszentrum Juelich GmbH > 52425 Juelich > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe > Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), > Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, > Prof. Dr. Sebastian M. Schmidt > ------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------ > _______________________________________________ > 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: From ngalbraith at whoi.edu Wed May 12 12:27:13 2010 From: ngalbraith at whoi.edu (Nan Galbraith) Date: Wed, 12 May 2010 14:27:13 -0400 Subject: [CF-metadata] non-standard standard_names In-Reply-To: <2E9C45494F78A3498A77616E7C2DBB4C02064B99@icg217.icg-ii-w2k.kfa-juelich.de> References: <2E9C45494F78A3498A77616E7C2DBB4C02064B99@icg217.icg-ii-w2k.kfa-juelich.de> Message-ID: <4BEAF301.3000806@whoi.edu> This seems like a good idea, but I have to disagree with one part of it. It looks like you want to change the CF convention so that a variable is not required to have either a long name or an un-prefixed standard name. This requirement seems like a very basic part of the standard to me, and one that isn't especially difficult to implement. I'd really like to see you require long names. You could use them to provide short definitions for your new _standard_name terms; so, each variable would have either a standard_name or a _standard_name, but all would have a long_name. This would keep a lot of code from needing to be re-written ... and leave the standard intact. Also, I hope anyone using the _standard_name technique will be 'strongly encouraged' to provide enough information about the term in the field so that in 10 years we're not all scratching our heads to figure out the acronyms. Just what that information should be, and how the terms allowed in the field would be controlled, should be discussed. At a bare minimum, you'd want to spell out the project name & provide a URI for the project and/or for the definitions (assuming they're too long to be supplied completely as long_names). We rely on CF being easily found on the web over the long haul, and that's just not true for every project. The open discussions on the CF list and the fact that the definitions can be relied upon to be available in the future are the strengths of the standard - this doesn't mean we can't move towards using other namespaces, but, in this case, it seems like we can easily do that in a way that doesn't require changes to the standard. Cheers - Nan > Dear all, > > we are currently cleaning all files on our TFHTAP multi-model > experiment server to make them fully CF(1.0) conformant. It has been > about 3 years since we had drafted the original format description of > these experiments and also initiated the standard name discussion for > chemical constituents (thanks again to Christiane Textor who did a lot > of this initial work). Many standard names which we needed have now been > defined (thanks to all who contributed and to Allison for maintaining > the list!). Nevertheless, there are a number of model variables left for > which no standard name has been agreed upon and where we (or the CF > mailing list group) also felt that they are too specialized to deserve a > "standard" name. From the perspective of the CF community this may not > be an issue, but in the context of interoperability (we now operate a > WCS server to share these files) the fact that some variables do have a > standard_name attribute and others don't poses considerable challenges. > The CF convention states that "either standard_name or long_name" should > be present. In our view, the long_name attribute is a poor substitute > for the standard_name, because it has no rules attached. We are now > planning to substitute "illegal" standard_name attributes by a new > "htap-_standard_name" attribute, which shall make clear that these names > are derived according to the CF guidelines, but they are not accepted > standard_names. Such a concept would enable software tools to easily > scan additional standard_name tables and make use of the well-defined > semantics that a standard_name provides without having to push > additional standard_names through the discussion - in particular if they > are no so "standard". I can see the danger that certain groups might > think it no longer necessary to go through the tedious but ultimately > worthwhile discussion process in this mailing list and the meaning of > "standard" names could get diluted. However, in my view the advantage of > having the possibility to extend the convention without breaking > standard-conformance outweighs this potential disadvantage. > > Specifically I would thus propose to add an optional attribute to > the CF documents such as: > > _standard_name: use this attribute to define the meaning of > variables which have no accepted standard_name defined (yet). The > project name should be a single string without blanks or underscore > characters. These project-specific standard_names must follow the > guidelines for the construction of standard_names, but they will not be > evaluated by generic tools which test a data file for CF compliance. > Groups who wish to define such project-specific standard names should > first consider to submit their proposals to the CF mailing list for > inclusion in the CF standard name table. A variable can contain either a > standard_name or _standard_name attribute but not both. A > long_name attribute is not needed when a _standard_name is > given. > > > Best regards, > > Martin > > -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* From jbgraybeal at mindspring.com Wed May 12 13:03:18 2010 From: jbgraybeal at mindspring.com (John Graybeal) Date: Wed, 12 May 2010 12:03:18 -0700 Subject: [CF-metadata] non-standard standard_names -- CF alternative names In-Reply-To: <4BEAF1D4.5050207@noaa.gov> References: <2E9C45494F78A3498A77616E7C2DBB4C02064B99@icg217.icg-ii-w2k.kfa-juelich.de> <4BEAF1D4.5050207@noaa.gov> Message-ID: <2463E084-3FDD-42FB-933B-FCB6BA4370C3@mindspring.com> OK, now I have to submit my other notion after all, which I think addresses some of Steve's concerns. But let me semi-agree with his first paragraph -- I'm enthusiastic, but I think there are a lot of details to be agreed on. I'll come back to that in a separate post. I had thought it was important to provide a way to enter proposed CF terms in a common way/place, so that they can (a) be used by the originators and the community in the meantime, (b) be seen by the CF folks, and (c) be dispositioned appropriately when CF either accepts them or rejects them. So my proposal was to create a vocabulary, or more precisely an RDF store, that lets us: 1) declare a name that may be proposed as a CF candidate 2) make a statement that the name has been (or even 'is being') submitted to CF for consideration 3a) make a statement that the name has been accepted as a CF name, and therefore is deprecated as a proposed name 3b) make a statement that the name has been rejected as a CF name, and therefore is deprecated as a proposed name In either 3a or 3b, 4) make a statement that the replacement representation of the name is xyz in some other vocabulary The relationship of this proposal to the previous thread is that it provides an implementation mechanism for the life cycle of the provisional terms. It also helps assure some of the things Steve is trying to ensure -- some of which only recently became possible with CF, and even that manually, not through any automatable utility, interface, or URI convention. Anyway, I don't want to encourage a detailed discussion of the above proposal, as it is secondary to Martin's original suggestion, and I feel sure it will have to be considered at some length in TRAC if we get that far. Just wanted to mention that the semantic technologies can enable some very useful views/approaches to some of these problems. John On May 12, 2010, at 11:22, Steve Hankin wrote: > Hi Martin, > > You've had two enthusiastic "yes" responses, so I guess I have the privilege to be the wet blanket. So it goes. I will give only a very cautious and limited "yes". Not an outright "no" ... but a suggestion for more thought and discussion. > > The proposal here is effectively the creation of 'private tables' as a means of achieving extensibility. We've had an opportunity to see the hazards embedded in this approach as a long-term evolutionary process in WMO. Over time the "custom" tables evolve to have an quasi-official status -- entire sub-communities rely upon them -- but without necessarily a corresponding methodical control over their creation and distribution. With BUFR and GRIB files the proliferation of distinct tables has lead to serious interoperability problems. > > To avoid repeating these problems with your proposal, CF clients must be provided with iron-clad ways to be assured that they are referring to the same vocabulary tables that the data author was referring to at the time that the data were written. Since we want CF files to ensure interoperability when there are years separating the writing of data from reading it, your strategy needs to ensure careful version control over the private tables. This imposes a significant burden on you as the creator of a "_standard_name" table -- essentially a requirement to retain and serve out older table versions "in perpetuity" (we could argue over what that means). The use of semantic web technologies will not alter these considerations for the foreseeable future (tho over the long term sophisticated inference engines might ...). The ontologies still need to be informed by correct information, which implies knowledge of the version-controlled private vocabularies. > > A "_standard_name" may have one of three life histories: it may never become accepted into the standard_name table; it may be accepted as-is; or it may be accepted with alterations. The following suggested restriction illustrates some of the difficulties: "A variable can contain either a standard_name or _standard_name attribute but not both." What's behind this restriction? Given the uncertain life history of a _standard_name, if it has been in use for (say) a year and is found in thousands of files that are being shared around the community, doesn't that generate a need to continue support for it. > > Two alternative approaches (both flawed, of course ... the nature of the beast): > Should the CF standard_name process, itself, include a "provisional fast-track", that allows names to be added very quickly with no guarantee that they will have a lasting status, but with an iron-clad guarantee that the provisional names will be retained (and so-identified) in version-stamped (older) CF vocabularies. > or > Might you be better off using a *truly private* vocabulary of "_standard_name" strings. I.e. one that has no official status in CF at all? There is no violation to the CF standard through doing this. This approach makes it your private responsibility on behalf of your users to deal with files that are created in the period between proposing a CF standard_name and having it become part of the official table > > - Steve > > ==================== > > Schultz, Martin wrote: >> >> Dear all, >> >> we are currently cleaning all files on our TFHTAP multi-model >> experiment server to make them fully CF(1.0) conformant. It has been >> about 3 years since we had drafted the original format description of >> these experiments and also initiated the standard name discussion for >> chemical constituents (thanks again to Christiane Textor who did a lot >> of this initial work). Many standard names which we needed have now been >> defined (thanks to all who contributed and to Allison for maintaining >> the list!). Nevertheless, there are a number of model variables left for >> which no standard name has been agreed upon and where we (or the CF >> mailing list group) also felt that they are too specialized to deserve a >> "standard" name. From the perspective of the CF community this may not >> be an issue, but in the context of interoperability (we now operate a >> WCS server to share these files) the fact that some variables do have a >> standard_name attribute and others don't poses considerable challenges. >> The CF convention states that "either standard_name or long_name" should >> be present. In our view, the long_name attribute is a poor substitute >> for the standard_name, because it has no rules attached. We are now >> planning to substitute "illegal" standard_name attributes by a new >> "htap-_standard_name" attribute, which shall make clear that these names >> are derived according to the CF guidelines, but they are not accepted >> standard_names. Such a concept would enable software tools to easily >> scan additional standard_name tables and make use of the well-defined >> semantics that a standard_name provides without having to push >> additional standard_names through the discussion - in particular if they >> are no so "standard". I can see the danger that certain groups might >> think it no longer necessary to go through the tedious but ultimately >> worthwhile discussion process in this mailing list and the meaning of >> "standard" names could get diluted. However, in my view the advantage of >> having the possibility to extend the convention without breaking >> standard-conformance outweighs this potential disadvantage. >> >> Specifically I would thus propose to add an optional attribute to >> the CF documents such as: >> >> _standard_name: use this attribute to define the meaning of >> variables which have no accepted standard_name defined (yet). The >> project name should be a single string without blanks or underscore >> characters. These project-specific standard_names must follow the >> guidelines for the construction of standard_names, but they will not be >> evaluated by generic tools which test a data file for CF compliance. >> Groups who wish to define such project-specific standard names should >> first consider to submit their proposals to the CF mailing list for >> inclusion in the CF standard name table. A variable can contain either a >> standard_name or _standard_name attribute but not both. A >> long_name attribute is not needed when a _standard_name is >> given. >> >> >> Best regards, >> >> Martin >> >> >> ------------------------------------------------------------------------------------------------ >> ------------------------------------------------------------------------------------------------ >> Forschungszentrum Juelich GmbH >> 52425 Juelich >> Sitz der Gesellschaft: Juelich >> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 >> Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe >> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), >> Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, >> Prof. Dr. Sebastian M. Schmidt >> ------------------------------------------------------------------------------------------------ >> ------------------------------------------------------------------------------------------------ >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -------------- I have my new work email address: jgraybeal at ucsd.edu -------------- John Graybeal phone: 858-534-2162 System Development Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.C.Hankin at noaa.gov Wed May 12 13:23:02 2010 From: Steven.C.Hankin at noaa.gov (Steve Hankin) Date: Wed, 12 May 2010 12:23:02 -0700 Subject: [CF-metadata] non-standard standard_names -- CF alternative names In-Reply-To: <2463E084-3FDD-42FB-933B-FCB6BA4370C3@mindspring.com> References: <2E9C45494F78A3498A77616E7C2DBB4C02064B99@icg217.icg-ii-w2k.kfa-juelich.de> <4BEAF1D4.5050207@noaa.gov> <2463E084-3FDD-42FB-933B-FCB6BA4370C3@mindspring.com> Message-ID: <4BEB0016.7@noaa.gov> Hi John, Would it be right to think of the strategy you've outlined as an elaboration on "Alternative 1": Should the CF standard_name process, *itself*, include a "provisional fast-track", that allows names to be added very quickly with no guarantee that they will have a lasting status, but with an *iron-clad guarantee that the provisional names will be retained* (and so-identified) in version-stamped (older) CF vocabularies. Presumably someone connected to CF would have to commit to maintaining the RDF store and (one assumes) provide an on-going, well-supported service that can query it. Is this the vision you are suggesting? - Steve ================================ John Graybeal wrote: > OK, now I have to submit my other notion after all, which I think > addresses some of Steve's concerns. But let me semi-agree with his > first paragraph -- I'm enthusiastic, but I think there are a lot of > details to be agreed on. I'll come back to that in a separate post. > > I had thought it was important to provide a way to enter proposed CF > terms in a common way/place, so that they can (a) be used by the > originators and the community in the meantime, (b) be seen by the CF > folks, and (c) be dispositioned appropriately when CF either accepts > them or rejects them. So my proposal was to create a vocabulary, or > more precisely an RDF store, that lets us: > 1) declare a name that may be proposed as a CF candidate > 2) make a statement that the name has been (or even 'is being') > submitted to CF for consideration > 3a) make a statement that the name has been accepted as a CF name, > and therefore is deprecated as a proposed name > 3b) make a statement that the name has been rejected as a CF name, > and therefore is deprecated as a proposed name > In either 3a or 3b, > 4) make a statement that the replacement representation of the name > is xyz in some other vocabulary > > The relationship of this proposal to the previous thread is that it > provides an implementation mechanism for the life cycle of the > provisional terms. It also helps assure some of the things Steve is > trying to ensure -- some of which only recently became possible with > CF, and even that manually, not through any automatable utility, > interface, or URI convention. > > Anyway, I don't want to encourage a detailed discussion of the above > proposal, as it is secondary to Martin's original suggestion, and I > feel sure it will have to be considered at some length in TRAC if we > get that far. Just wanted to mention that the semantic technologies > can enable some very useful views/approaches to some of these problems. > > John > > On May 12, 2010, at 11:22, Steve Hankin wrote: > >> Hi Martin, >> >> You've had two enthusiastic "yes" responses, so I guess I have the >> privilege to be the wet blanket. So it goes. I will give only a >> very cautious and limited "yes". Not an outright "no" ... but a >> suggestion for more thought and discussion. >> >> The proposal here is effectively the creation of 'private tables' as >> a means of achieving extensibility. We've had an opportunity to see >> the hazards embedded in this approach as a long-term evolutionary >> process in WMO. Over time the "custom" tables evolve to have an >> quasi-official status -- entire sub-communities rely upon them -- but >> without necessarily a corresponding methodical control over their >> creation and distribution. With BUFR and GRIB files the proliferation >> of distinct tables has lead to serious interoperability problems. >> >> To avoid repeating these problems with your proposal, CF clients must >> be provided with *iron-clad ways to be assured that they are >> referring to the same vocabulary tables that the data author was >> referring to at the time that the data were written*. Since we want >> CF files to ensure interoperability when there are *years separating >> the writing of data from reading it*, your strategy needs to ensure >> careful version control over the private tables. This imposes a >> significant burden on you as the creator of a >> "_standard_name" table -- essentially a requirement to >> retain and serve out older table versions "in perpetuity" (we could >> argue over what that means). The use of semantic web technologies >> will not alter these considerations for the foreseeable future (tho >> over the long term sophisticated inference engines might ...). The >> ontologies still need to be informed by correct information, which >> implies knowledge of the version-controlled private vocabularies. >> >> A "_standard_name" may have one of three life histories: it >> may never become accepted into the standard_name table; it may be >> accepted as-is; or it may be accepted with alterations. The >> following suggested restriction illustrates some of the difficulties: >> "A variable can contain either a standard_name or >> _standard_name attribute but not both." What's behind this >> restriction? Given the uncertain life history of a >> _standard_name, if it has been in use for (say) a year and >> is found in thousands of files that are being shared around the >> community, doesn't that generate a need to continue support for it. >> >> Two alternative approaches (both flawed, of course ... the nature of >> the beast): >> >> 1. Should the CF standard_name process, itself, include a >> "provisional fast-track", that allows names to be added very >> quickly with no guarantee that they will have a lasting status, >> but with an *iron-clad guarantee that the provisional names >> will be retained* (and so-identified) in version-stamped >> (older) CF vocabularies. >> or >> 2. Might you be better off using a *truly private* vocabulary of >> "_standard_name" strings. I.e. one that has no >> official status in CF at all? There is no violation to the CF >> standard through doing this. This approach makes it your >> private responsibility on behalf of your users to deal with >> files that are created in the period between proposing a CF >> standard_name and having it become part of the official table >> >> >> - Steve >> >> ==================== >> >> Schultz, Martin wrote: >>> Dear all, >>> >>> we are currently cleaning all files on our TFHTAP multi-model >>> experiment server to make them fully CF(1.0) conformant. It has been >>> about 3 years since we had drafted the original format description of >>> these experiments and also initiated the standard name discussion for >>> chemical constituents (thanks again to Christiane Textor who did a lot >>> of this initial work). Many standard names which we needed have now been >>> defined (thanks to all who contributed and to Allison for maintaining >>> the list!). Nevertheless, there are a number of model variables left for >>> which no standard name has been agreed upon and where we (or the CF >>> mailing list group) also felt that they are too specialized to deserve a >>> "standard" name. From the perspective of the CF community this may not >>> be an issue, but in the context of interoperability (we now operate a >>> WCS server to share these files) the fact that some variables do have a >>> standard_name attribute and others don't poses considerable challenges. >>> The CF convention states that "either standard_name or long_name" should >>> be present. In our view, the long_name attribute is a poor substitute >>> for the standard_name, because it has no rules attached. We are now >>> planning to substitute "illegal" standard_name attributes by a new >>> "htap-_standard_name" attribute, which shall make clear that these names >>> are derived according to the CF guidelines, but they are not accepted >>> standard_names. Such a concept would enable software tools to easily >>> scan additional standard_name tables and make use of the well-defined >>> semantics that a standard_name provides without having to push >>> additional standard_names through the discussion - in particular if they >>> are no so "standard". I can see the danger that certain groups might >>> think it no longer necessary to go through the tedious but ultimately >>> worthwhile discussion process in this mailing list and the meaning of >>> "standard" names could get diluted. However, in my view the advantage of >>> having the possibility to extend the convention without breaking >>> standard-conformance outweighs this potential disadvantage. >>> >>> Specifically I would thus propose to add an optional attribute to >>> the CF documents such as: >>> >>> _standard_name: use this attribute to define the meaning of >>> variables which have no accepted standard_name defined (yet). The >>> project name should be a single string without blanks or underscore >>> characters. These project-specific standard_names must follow the >>> guidelines for the construction of standard_names, but they will not be >>> evaluated by generic tools which test a data file for CF compliance. >>> Groups who wish to define such project-specific standard names should >>> first consider to submit their proposals to the CF mailing list for >>> inclusion in the CF standard name table. A variable can contain either a >>> standard_name or _standard_name attribute but not both. A >>> long_name attribute is not needed when a _standard_name is >>> given. >>> >>> >>> Best regards, >>> >>> Martin >>> >>> >>> ------------------------------------------------------------------------------------------------ >>> ------------------------------------------------------------------------------------------------ >>> Forschungszentrum Juelich GmbH >>> 52425 Juelich >>> Sitz der Gesellschaft: Juelich >>> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 >>> Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe >>> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), >>> Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, >>> Prof. Dr. Sebastian M. Schmidt >>> ------------------------------------------------------------------------------------------------ >>> ------------------------------------------------------------------------------------------------ >>> _______________________________________________ >>> CF-metadata mailing list >>> CF-metadata at cgd.ucar.edu >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > -------------- > I have my new work email address: jgraybeal at ucsd.edu > > -------------- > > John Graybeal > phone: 858-534-2162 > System Development Manager > Ocean Observatories Initiative Cyberinfrastructure Project: > http://ci.oceanobservatories.org > Marine Metadata Interoperability Project: http://marinemetadata.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ngalbraith at whoi.edu Wed May 12 13:35:16 2010 From: ngalbraith at whoi.edu (Nan Galbraith) Date: Wed, 12 May 2010 15:35:16 -0400 Subject: [CF-metadata] non-standard standard_names In-Reply-To: <4BEAF1D4.5050207@noaa.gov> References: <2E9C45494F78A3498A77616E7C2DBB4C02064B99@icg217.icg-ii-w2k.kfa-juelich.de> <4BEAF1D4.5050207@noaa.gov> Message-ID: <4BEB02F4.7000701@whoi.edu> The original proposal was to include names that have been rejected by CF for being "too specialized" - these would be permanent parts of the project vocabulary, not deprecated. Many in situ instruments produce non-geophysical variables that fall into this category; although this isn't what Martin had in mind, his proposal - or something along the same lines - would help us get to a standard naming scheme for this kind of data too. - Nan > So my proposal was to create a vocabulary, or more precisely an RDF > store, that lets us: > 1) declare a name that may be proposed as a CF candidate > 2) make a statement that the name has been (or even 'is being') > submitted to CF for consideration > 3a) make a statement that the name has been accepted as a CF name, > and therefore is deprecated as a proposed name > 3b) make a statement that the name has been rejected as a CF name, > and therefore is deprecated as a proposed name > In either 3a or 3b, > 4) make a statement that the replacement representation of the name > is xyz in some other vocabulary -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* From rkl at bodc.ac.uk Thu May 13 01:06:59 2010 From: rkl at bodc.ac.uk (Lowry, Roy K) Date: Thu, 13 May 2010 08:06:59 +0100 Subject: [CF-metadata] non-standard standard_names In-Reply-To: <4BEB02F4.7000701@whoi.edu> References: <2E9C45494F78A3498A77616E7C2DBB4C02064B99@icg217.icg-ii-w2k.kfa-juelich.de> <4BEAF1D4.5050207@noaa.gov>,<4BEB02F4.7000701@whoi.edu> Message-ID: <40829B0E077C1145A6DE44D39B3830A90886AB73B6@nerckwmb1.ad.nerc.ac.uk> Dear All, The 'fast track' approach being discussed has promise and is pretty much in line with the ISO vocabulary model (in which terms have proposed, accepted, deprecated or deleted) used in resources like the GEMET thesaurus. However, there are important details to consider, such as version management (what event triggers the publication of a new version of the vocabulary?). I am more uncomfortable with concept of community namespace Standard Name lists - I see this as the route to data ghettos (and don't truly believe that the Semantic Web would prevent this as nobody will bother doing the mappings)- and specialized standard names (in my view its either a Standard Name or it isn't and we have to accept that the nature of Standard Name is moving away from the purity of a geophysical phenomenon). Cheers, Roy ________________________________________ From: cf-metadata-bounces at cgd.ucar.edu [cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Nan Galbraith [ngalbraith at whoi.edu] Sent: 12 May 2010 20:35 To: cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] non-standard standard_names The original proposal was to include names that have been rejected by CF for being "too specialized" - these would be permanent parts of the project vocabulary, not deprecated. Many in situ instruments produce non-geophysical variables that fall into this category; although this isn't what Martin had in mind, his proposal - or something along the same lines - would help us get to a standard naming scheme for this kind of data too. - Nan > So my proposal was to create a vocabulary, or more precisely an RDF > store, that lets us: > 1) declare a name that may be proposed as a CF candidate > 2) make a statement that the name has been (or even 'is being') > submitted to CF for consideration > 3a) make a statement that the name has been accepted as a CF name, > and therefore is deprecated as a proposed name > 3b) make a statement that the name has been rejected as a CF name, > and therefore is deprecated as a proposed name > In either 3a or 3b, > 4) make a statement that the replacement representation of the name > is xyz in some other vocabulary -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. From j.m.gregory at reading.ac.uk Thu May 13 01:57:55 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Thu, 13 May 2010 08:57:55 +0100 Subject: [CF-metadata] non-standard standard_names In-Reply-To: <2E9C45494F78A3498A77616E7C2DBB4C02064B99@icg217.icg-ii-w2k.kfa-juelich.de> References: <2E9C45494F78A3498A77616E7C2DBB4C02064B99@icg217.icg-ii-w2k.kfa-juelich.de> Message-ID: <20100513075755.GA28310@met.reading.ac.uk> Dear Martin et al Some quantities are so specific to a particular dataset or model that it would not be worth the effect of defining a standard name for them, since they will never be compared with data from another source, the main reason for standard names being to indicate which quantities should be regarded as comparable. In those cases, I think having your own private attribute such as htap_standard_ name is the best solution. Other projects have done that before; for instance the aquaplanet model intercomparion project has APE_names. This is Steve's solution (2). The attribute is not standard and the vocabulary is private; it perfectly legal to have non-CF attributes in CF files. If the project is itself comparing data from different sources, it would be make sense to use standard names. As Roy says, CF standard names aren't purely geophysical quantities any more. There are others related to measurements and technical details. I think it's fine to have standard names for such things in cases where different data sources are dealing with comparable quantities and they have to work out how to identify them in a common way. I would much prefer keeping to a single attribute and namespace. It's much more convenient to look at one attribute than to search for many, as John says. Fragmentation of the namespace can in principle be resolved by mappings, but in practice that would not happen, I am sure and Roy also suggests, just because it would be a lot of work, and if it's not done, that would seriously undermine the usefulness of standard names. Part of the reason why agreeing them takes so long is that we have to understand what they mean, in order to be sure that the new ones are not duplicating existing ones, and that they are constructed in a consistent way, which will make it easier for future users to understand them too. Therefore, like others, I prefer a fast-track approach, like John's suggestion and Steve's (1), to deal with new standard names. I think we need a CF central repository for proposed standard names. That would be useful anyway to monitor their progress. I know that BADC have been working in this direction, although I don't know the status. The repository should be kept up to date by modifying it as proposed standard names are amended, accepted or rejected. We could say that some reasonable interval after a standard name has been proposed, such as a small number of weeks, and if it's still under discussion at that time (i.e. hasn't been rejected or accepted yet), it would be allowed to use it in the standard_name attribute, prefixed by "proposed" e.g. standard_name="proposed: mass_concentration_of_alcohol_in_beer". That means, as others have said, that the record of proposed names and their eventual fate would have to be maintained indefinitely, but this should be easier to manage if there's just one such repository - a central CF one - than many separate project websites. With such a system, it worries me that some projects might propose standard names and start to use them without making a serious effort to agree them as standard. I think that effort is well worthwhile, in terms of clarifying both the concepts and the vocabulary. Cheers Jonathan From j.m.gregory at reading.ac.uk Thu May 13 02:21:10 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Thu, 13 May 2010 09:21:10 +0100 Subject: [CF-metadata] standard name grammar for version 14 of the table Message-ID: <20100513082110.GA28454@met.reading.ac.uk> Dear all Encouraged by comments on my standard name grammar, I have updated it for version 14 of the standard name table, published yesterday. Doing the update was an interesting exercise. Initially most of the new names could not be parsed, but it was fairly straightforward to add new phrases to the lexicon until the parsing succeeded. The new version is at http://www.met.reading.ac.uk/~jonathan/CF_metadata/14.1/ You can imagine that proposals for standard names could be guided by such a grammar, in which proposers would indicate how the lexicon and syntax should be extended if required, as part of their proposal. If no such extensions are needed, an automatic tool could help proposers construct standard names from existing grammar, and you'd expect they would be acceptable once they'd passed through a manual anti-green-dog filter. In another email, I will comment on some specific issues with version 14. Cheers Jonathan From j.m.gregory at reading.ac.uk Thu May 13 02:31:45 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Thu, 13 May 2010 09:31:45 +0100 Subject: [CF-metadata] proposed changes to various standard names Message-ID: <20100513083145.GB28454@met.reading.ac.uk> Dear all In preparing the grammar for CF standard names for version 13 of the table, I made proposals to modify various existing standard names. These proposals apply to version 14 as well, and I repeat them below. In addition, version 14 raises some new issues. These are questions that I didn't think of when we were working on the proposed standard names; adding new phrases to the lexicon made them more obvious. I think that shows a benefit of having a lexicon. (But maybe we did discuss them, and I've forgotten! If so, apologies.) * We have introduced the phrase sinking_mole_flux. Could that be downwelling_mole_flux instead? I think "sinking" and "downwelling" mean the same thing, and "downwelling" was already in the lexicon. * What's the difference between inorganic_phosphorus and inorganic_phosphate, and likewise inorganic_silicon and inorganic_silicate? * For elemental_nitrogen, could we say molecular_nitrogen, which would be consistent with molecular_hydrogen and molecular_oxygen? * What's the difference between sulfate_dry_aerosol and sulfur_dry_aerosol? * What's the difference between large_scale and stratiform? * We have an existing name of surface_carbon_dioxide_mole_flux, whose sign convention is not clear. Could we change this to surface_up|downward_mole_flux_of_carbon_dioxide to be consistent with some newly introduced names? Proposals already made (on version 13, still applicable to version 14): snow_soot_content -> soot_content_of_surface_snow snow_thermal_energy_content -> thermal_energy_content_of_surface_snow snow_temperature -> temperature_in_snow liquid_water_content_of_snow_layer -> liquid_water_content_of_surface_snow "snow" can refer both to lying snow (a medium) and falling snow (a species). Existing standard names generally use "surface_snow" for the former, but not always. I propose these changes to remove the ambiguity. water_vapor_pressure -> water_vapor_partial_pressure This quantity is really a partial pressure, and making this change is consistent with the use of "partial_pressure" for "carbon_dioxide" in other names. dissipation_in_atmosphere_boundary_layer -> kinetic_energy_dissipation_in_atmosphere_boundary_layer This change is proposed because "dissipation" alone is vague, and it makes the name consistent with other names that contain the phrase "kinetic_energy_dissipation" referring to the ocean. sea_ice_displacement -> magnitude_of_sea_ice_displacement This change is proposed so that "sea_ice_displacement" is definitely a vector, with components e.g. "eastward_sea_ice_displacement"; at present, it is both a scalar and a vector. Cheers Jonathan From John.Dunne at noaa.gov Thu May 13 08:00:00 2010 From: John.Dunne at noaa.gov (John.Dunne at noaa.gov) Date: Thu, 13 May 2010 10:00:00 -0400 Subject: [CF-metadata] proposed changes to various standard names Message-ID: <299ec5629a3333.29a3333299ec56@noaa.gov> Hi Jonathan, Here are some thoughts: > * We have introduced the phrase sinking_mole_flux. Could that be > downwelling_mole_flux instead? I think "sinking" and "downwelling" > mean the > same thing, and "downwelling" was already in the lexicon. The two definitions have different reference frames - Sinking is a velocity relative to the fluid, while downwelling is a velocity of the fluid itself. > * What's the difference between inorganic_phosphorus and > inorganic_phosphate,and likewise inorganic_silicon and > inorganic_silicate? phosphorus and silicon is more general, but I think they are intended to mean the same things in each case. > * For elemental_nitrogen, could we say molecular_nitrogen, which > would be > consistent with molecular_hydrogen and molecular_oxygen? molecular nitrogen is only appropriate for N2 gas, like for H2 and O2, distinct from nitrogen in other forms. > * We have an existing name of surface_carbon_dioxide_mole_flux, > whose sign > convention is not clear. Could we change this to > surface_up|downward_mole_flux_of_carbon_dioxide > to be consistent with some newly introduced names? This flux was previously aggreed to be positive up from the atmospheric folks wanting consistency between the land and ocean estimates, but for an ocean output alone, seems like there would be more flexibility. Cheers, John From j.m.gregory at reading.ac.uk Thu May 13 08:55:46 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Thu, 13 May 2010 15:55:46 +0100 Subject: [CF-metadata] proposed changes to various standard names In-Reply-To: <299ec5629a3333.29a3333299ec56@noaa.gov> References: <299ec5629a3333.29a3333299ec56@noaa.gov> Message-ID: <20100513145546.GB29682@met.reading.ac.uk> Dear Jonathan > > downwelling_mole_flux instead? I think "sinking" and "downwelling" > > mean the same thing, and "downwelling" was already in the lexicon. > > The two definitions have different reference frames - Sinking is a > velocity relative to the fluid, while downwelling is a velocity of the > fluid itself. Fine. That is a clear distinction. > > * What's the difference between inorganic_phosphorus and > > inorganic_phosphate,and likewise inorganic_silicon and > > inorganic_silicate? > > phosphorus and silicon is more general, but I think they are intended to > mean the same things in each case. In that case, I think we should change inorganic phosphate and silicate (one occurrence of each) to inorganic phosphorus and silicon (two occurrences of each) in the newly added names. > > * For elemental_nitrogen, could we say molecular_nitrogen, which > > would be consistent with molecular_hydrogen and molecular_oxygen? > > molecular nitrogen is only appropriate for N2 gas, like for H2 and O2, > distinct from nitrogen in other forms. We say dissolved_molecular_oxygen_in_sea_water in some other standard names. Could we do the same for nitrogen? > > * We have an existing name of surface_carbon_dioxide_mole_flux, > > whose sign > > convention is not clear. Could we change this to > > surface_up|downward_mole_flux_of_carbon_dioxide > > to be consistent with some newly introduced names? > > This flux was previously aggreed to be positive up from the atmospheric > folks wanting consistency between the land and ocean estimates, but for > an ocean output alone, seems like there would be more flexibility. Yes, one could define it either way, and it would be fine to have standard names for both up and down. Which one to choose is an issue for the users of the standard, not the standard itself. If the existing ambiguous name is likely to mean "up", I suggest we make it an alias for surface_upward_mole_flux_of_carbon_dioxide Thanks for your advice and best wishes Jonathan From cameronsmith1 at llnl.gov Thu May 13 12:32:00 2010 From: cameronsmith1 at llnl.gov (Cameron-smith, Philip) Date: Thu, 13 May 2010 11:32:00 -0700 Subject: [CF-metadata] standard name grammar for version 14 of the table In-Reply-To: <20100513082110.GA28454@met.reading.ac.uk> References: <20100513082110.GA28454@met.reading.ac.uk> Message-ID: Hi Jonathan, In quickly looking over your updated grammar page, I noticed that the _due_to_(phenomenon) section contained the following: from icebergs from rivers from rivers and surface downward water flux Would it make sense to move these to the (preposition)(medium) section? Best wishes, Philip ------------------------------------------------------------------------ Dr Philip Cameron-Smith Atmospheric, Earth, and Energy Division pjc at llnl.gov Lawrence Livermore National Laboratory +1 925 4236634 7000 East Avenue, Livermore, CA94550, USA ------------------------------------------------------------------------ -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory Sent: Thursday, May 13, 2010 1:21 AM To: cf-metadata at cgd.ucar.edu Subject: [CF-metadata] standard name grammar for version 14 of the table Dear all Encouraged by comments on my standard name grammar, I have updated it for version 14 of the standard name table, published yesterday. Doing the update was an interesting exercise. Initially most of the new names could not be parsed, but it was fairly straightforward to add new phrases to the lexicon until the parsing succeeded. The new version is at http://*www.*met.reading.ac.uk/~jonathan/CF_metadata/14.1/ You can imagine that proposals for standard names could be guided by such a grammar, in which proposers would indicate how the lexicon and syntax should be extended if required, as part of their proposal. If no such extensions are needed, an automatic tool could help proposers construct standard names from existing grammar, and you'd expect they would be acceptable once they'd passed through a manual anti-green-dog filter. In another email, I will comment on some specific issues with version 14. Cheers Jonathan _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From cameronsmith1 at llnl.gov Thu May 13 12:40:44 2010 From: cameronsmith1 at llnl.gov (Cameron-smith, Philip) Date: Thu, 13 May 2010 11:40:44 -0700 Subject: [CF-metadata] proposed changes to various standard names In-Reply-To: <20100513083145.GB28454@met.reading.ac.uk> References: <20100513083145.GB28454@met.reading.ac.uk> Message-ID: Hi Jonathan, It looks like your grammar analyzer identified the following entities in error: sulfate_dry_aerosol and sulfur_dry_aerosol I assume that your grammar analyzer picked this up from standard names of the following form: atmosphere_mass_content_of_sulfate_expressed_as_sulfur_dry_aerosol This would be hard for an automatic grammar checker to understand. Perhaps it would be more logical and unambiguous to rearrange this name (and the other similar ones) to be: atmosphere_mass_content_of_sulfate_dry_aerosol_expressed_as_sulfur Best wishes, Philip ------------------------------------------------------------------------ Dr Philip Cameron-Smith Atmospheric, Earth, and Energy Division pjc at llnl.gov Lawrence Livermore National Laboratory +1 925 4236634 7000 East Avenue, Livermore, CA94550, USA ------------------------------------------------------------------------ -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory Sent: Thursday, May 13, 2010 1:32 AM To: cf-metadata at cgd.ucar.edu Cc: John.Dunne at noaa.gov Subject: [CF-metadata] proposed changes to various standard names Dear all In preparing the grammar for CF standard names for version 13 of the table, I made proposals to modify various existing standard names. These proposals apply to version 14 as well, and I repeat them below. In addition, version 14 raises some new issues. These are questions that I didn't think of when we were working on the proposed standard names; adding new phrases to the lexicon made them more obvious. I think that shows a benefit of having a lexicon. (But maybe we did discuss them, and I've forgotten! If so, apologies.) * We have introduced the phrase sinking_mole_flux. Could that be downwelling_mole_flux instead? I think "sinking" and "downwelling" mean the same thing, and "downwelling" was already in the lexicon. * What's the difference between inorganic_phosphorus and inorganic_phosphate, and likewise inorganic_silicon and inorganic_silicate? * For elemental_nitrogen, could we say molecular_nitrogen, which would be consistent with molecular_hydrogen and molecular_oxygen? * What's the difference between sulfate_dry_aerosol and sulfur_dry_aerosol? * What's the difference between large_scale and stratiform? * We have an existing name of surface_carbon_dioxide_mole_flux, whose sign convention is not clear. Could we change this to surface_up|downward_mole_flux_of_carbon_dioxide to be consistent with some newly introduced names? Proposals already made (on version 13, still applicable to version 14): snow_soot_content -> soot_content_of_surface_snow snow_thermal_energy_content -> thermal_energy_content_of_surface_snow snow_temperature -> temperature_in_snow liquid_water_content_of_snow_layer -> liquid_water_content_of_surface_snow "snow" can refer both to lying snow (a medium) and falling snow (a species). Existing standard names generally use "surface_snow" for the former, but not always. I propose these changes to remove the ambiguity. water_vapor_pressure -> water_vapor_partial_pressure This quantity is really a partial pressure, and making this change is consistent with the use of "partial_pressure" for "carbon_dioxide" in other names. dissipation_in_atmosphere_boundary_layer -> kinetic_energy_dissipation_in_atmosphere_boundary_layer This change is proposed because "dissipation" alone is vague, and it makes the name consistent with other names that contain the phrase "kinetic_energy_dissipation" referring to the ocean. sea_ice_displacement -> magnitude_of_sea_ice_displacement This change is proposed so that "sea_ice_displacement" is definitely a vector, with components e.g. "eastward_sea_ice_displacement"; at present, it is both a scalar and a vector. Cheers Jonathan _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From j.m.gregory at reading.ac.uk Fri May 14 00:54:26 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 14 May 2010 07:54:26 +0100 Subject: [CF-metadata] proposed changes to various standard names In-Reply-To: References: <20100513083145.GB28454@met.reading.ac.uk> Message-ID: <20100514065426.GA1873@met.reading.ac.uk> Dear Philip > It looks like your grammar analyzer identified the following entities in error: > > sulfate_dry_aerosol and sulfur_dry_aerosol > > I assume that your grammar analyzer picked this up from standard names of the following form: > > atmosphere_mass_content_of_sulfate_expressed_as_sulfur_dry_aerosol Ah, I see! Indeed, I find that confusing as a human parser of language, and had misunderstood it. So the intention of this name is atmosphere_mass_content_of_sulfate (expressed_as_sulfur) dry_aerosol I agree, it would be much clearer to change it to atmosphere_mass_content_of_sulfate_dry_aerosol_expressed_as_sulfur as you say. There are five existing names of this type. Thanks Jonathan From j.m.gregory at reading.ac.uk Fri May 14 01:09:15 2010 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 14 May 2010 08:09:15 +0100 Subject: [CF-metadata] standard name grammar for version 14 of the table In-Reply-To: References: <20100513082110.GA28454@met.reading.ac.uk> Message-ID: <20100514070915.GB1873@met.reading.ac.uk> Dear Philip > In quickly looking over your updated grammar page, I noticed that the _due_to_(phenomenon) section contained the following: > > from icebergs > from rivers > from rivers and surface downward water flux > > Would it make sense to move these to the (preposition)(medium) section? In version 13 I had these as phrasetype of their own, from_(water_source), and Steve suggested moving them to the phenomenon type. I tend to think that's better than medium, because these phrases occur after into_sea_water, which is already a (preposition)_(medium) construction. water_flux_into_sea_water_from_rivers is arguably analogous to heat_flux_into_sea_water_due_to_sea_ice_thermodynamics so it makes sense to regard from_rivers as a cause. Semantically it could be argued either way, but sytactically this is more economical. A possible guiding principle for adding new standard names could be to minimise the number of patterns, by using existing syntax if possible. Thanks Jonathan From t.lavergne at met.no Fri May 14 02:24:45 2010 From: t.lavergne at met.no (Thomas Lavergne) Date: Fri, 14 May 2010 08:24:45 +0000 (UTC) Subject: [CF-metadata] proposed changes to various standard names In-Reply-To: <911985405.18315.1273825206721.JavaMail.root@imap1a> Message-ID: <1356003301.18335.1273825485238.JavaMail.root@imap1a> Dear Jonathan, I would like to comment on the issue you are pointing out for sea_ice_displacement, as I introduced this standard name. ----- "Jonathan Gregory" wrote: > sea_ice_displacement -> magnitude_of_sea_ice_displacement > > This change is proposed so that "sea_ice_displacement" is definitely a > vector, > with components e.g. "eastward_sea_ice_displacement"; at present, it > is both a > scalar and a vector. You are right: "sea_ice_displacement" is a 2D vector with several types of components (eastward, etc...). It seems thus a good idea to use a "magnitude_of_" prefix for designing its magnitude. I do agree with your proposal of changing the 'sea_ice_displacement' standard name into 'magnitude_of_sea_ice_displacement'. regards, Thomas From m.schultz at fz-juelich.de Sat May 15 06:08:30 2010 From: m.schultz at fz-juelich.de (Schultz, Martin) Date: Sat, 15 May 2010 14:08:30 +0200 Subject: [CF-metadata] non-standard standard_names Message-ID: <2E9C45494F78A3498A77616E7C2DBB4C02064BC5@icg217.icg-ii-w2k.kfa-juelich.de> Dear all, first of all let me say that I truely appreciate the careful discussion my proposal has initiated. This indeed is probably the most convincing reason why CF has been accepted already in several parts of the community. Steve made a very nice distinction to clarify what my suggestion of _standard_names was really about. In fact it really had elements of his (1) and (2) approaches. Let me re-iterate on both of them: (1) for the process of defining new standard names, I believe the suggestions that were made all point into the right direction. Personally, I like the standard_name: "proposed: ...." approach. Any tool could then easily test if the string behind "proposed" exists in the current standard_name table or not. If it doesn't, a warning occurs but no error. Hence, no modification would be required to any existing data set, albeit these files could be upgraded by removing the "proposed" string once the name has been accepted. I also see the point that communities should enhance their efforts to have names defined before running their experiments. However, practical experience rarely allows for this and we can only hope that over time there will be enough standard names available to cover almost all aspects of such experiments (in the atmospheric chemistry domain we have already come quite far now). (2) the "private" name space was more central to my suggestion. Steve made cautioning comments about the development of non-standard GRIB tables, and indeed these are a great pain. However, there is a fundamental difference here in that netcdf files will always be amenable to at least some interpretation provided that "good" metadata is provided, while one is completely lost with a GRIB file if the code table cannot be found (we experienced this the hard way when we first added chemical species into the ECHAM model). The discussion so far has viewed my proposal mainly from the CF perspective. I would like to invite you again to take the view of the project coordinator for a minute. Experience shows that about 95% or more of the preparations for new experiments go into scientific validation of the model and making sure it runs at all and hopefully reasonably efficient. Then someone at a meeting gets up and displays a long list of seemingly glibberish semantic phrases which are to be proposed as standard names in some weird "convention". Typically this presentation is given during the last 5 minutes of a meeting and 50% of the audience have already left for the airport. Consequently, the coordinator (or some nice fellow supporting him/her) has to deal with this standardisation on his/her own (while at the same time preparing their own model). Finally, a proposal for new standard names is submitted and by the time the discussion is over 30% have passed unaltered, 60% require modification and 10% are rejected. At that point in time most model runs have been submitted. Now: what do you do? I guess each and every one of these coordinating fellows/fellas will be happy if he/she can assure that all data in the archive are not corrupted, the models have worked and the analysis that was planned can be performed. Proper archiving and interoperability (still) come as an afterthought. [I only hope this doesn't sound too negative, I may have been watching too much cabaret lately ;-)] -- back to the actual suggestion: what I wanted to express with my proposal is that we should find a way to acknowledge that someone has tried to establish new standard names while at the same time the "pure" standard should not be corrupted. The proposal of using "proposed:" actually captures this very nicely. By the same token we could even go as far as to allow the keyword "private:" in the standard_name string (instead of defining a new _standard_name). Yes: it does to some extent weaken the stringency of a standard_name, but only on the surface. In reality I believe such qualifiers could even strengthen the concept. We could require that a "project" attribute must be part of the global attributes if the "private" qualifier is used and the project attribute must point to a web resource where information on the project is given (perhaps one could even think of a central "project" database with a simple registration process to make eternity easier to achieve). As project manager you may be glad to surf on the well-designed concept that CF and the standard names provide and there is currently no standardized way to do this. By allowing such qualifier keywords to the standard_name attribute, nothing would change in terms of "official" standards (as these are the standard_names without any qualifier) while it would become a lot easier for newcomers and other groups to take advantage of the concept. In effect this would be a neat way to address the needs both of the operational community, where it is very important to rely on the long lifetime of a name and of the "experimental" community, which needs flexibility more than anything else, but where interoperability can also play a very important role in the future. Cheers, Martin ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ From alison.pamment at stfc.ac.uk Wed May 26 05:50:41 2010 From: alison.pamment at stfc.ac.uk (alison.pamment at stfc.ac.uk) Date: Wed, 26 May 2010 12:50:41 +0100 Subject: [CF-metadata] water level with/without datum In-Reply-To: References: <1240F43731C2EB4F8CC9BF70D233B511018C0685@SRV-XCHANGE-2K3.pc.cls.fr><20100305132856.GA4832@met.reading.ac.uk><1240F43731C2EB4F8CC9BF70D233B511018C06A7@SRV-XCHANGE-2K3.pc.cls.fr> Message-ID: Dear All, There have been no further comments in this thread since my last posting. Therefore the names > water_surface_height_above_reference_datum > water_surface_reference_datum_altitude are accepted for inclusion in the standard name table. Best wishes, Alison > > Dear All, > > I have reviewed this thread which caused considerable discussion during > February/March. There seems to be general agreement on introducing the > name > water_surface_height_above_reference_datum > for the height of the surface of any water body, be it sea, lake or > river above an arbitrary reference datum. > > During the discussion it was not established how the reference datum > itself would be specified. Jonathan suggested that for an arbitrary > but fixed reference datum we might add another standard name along the > lines of: > water_surface_reference_datum_altitude > while for a temporally and spatially varying reference datum, e.g. > geoid, reference ellipsoid, the datum should form part of the name as > is the current practice for sea_surface_height names. I think this > sounds like a reasonable approach, but no one else has commented on > this idea. > > It was agreed to postpone the discussion of a general term to describe > 'sea/lake/river' until such time as a use case emerges as part of a > firm standard name proposal. However, for future reference, I note > that the three ideas arising from this discussion (and which have found > some support) are: > 1) a compound term such as sea_lake_river or sea_or_lake_or_river > (Jonathan); > 2) water_body (Roy, Seth); > 3) defining the unqualified term 'water' to mean water in a water body > (Nan). > > I would like to draw this thread to a conclusion and it seems that the > most pressing question is how to describe the datum. If there are no > further comments within fourteen days, the name > water_surface_height_above_reference_dat