Re: [CF-metadata] new standard name proposal for total ozone in DU
Hi Alison and Roy, I think that the solution you proposed is suitable to the O3 community. Having the canonical unit (mol/m-2) for the O3 columns in the vocabulary server is fine as long as it is not a problem to use a different unit (Dobson Unit) in the NetCDF files. The important point is that the variables are expressed in the commonly used units so that the users can understand the file content at a glance. Best regards, Christophe On 5/12/2012 11:30, alison.pamm...@stfc.ac.uk wrote: Dear Roy and Christophe, As Roy says, we usually use SI units for the canonical unit in the standard name table. There are a few exceptions, for example, age_of_sea_ice has units of year and age_of_surface_snow has units of day, whereas the SI unit for both quantities would be the second. Also, we allowed some of the recently added salinity names to have canonical units of g kg-1 which I'm not sure adheres strictly to SI. I think the reason for having the exceptions was simply that they are the units that are always used with the named quantities. For Christophe's ozone name, atmosphere_mole_content_of_ozone, the proposed definition is ' Content indicates a quantity per unit area. The atmosphere content of a quantity refers to the vertical integral from the surface to the top of the atmosphere. For the content between specified levels in the atmosphere, standard names including content_of_atmosphere_layer are used. The construction atmosphere_mole_content_of_X means the vertically integrated number of moles of X above a unit area. The chemical formula for ozone is O3.' Whatever we decide about the units, I think we should add the sentence 'atmosphere_mole_content_of_ozone is usually measured in Dobson Units which are equivalent to 446.2 micromoles m-2'. Roy's proposed solution of having canonical units of mol m-2 while using Dobson Units in the data files is certainly consistent with the CF conventions. As long as UDUNITS knows how to convert the units in the file to the canonical units there is no problem. Christophe, would that be acceptable to the ozone community? Roy, is there any technical reason why we couldn't map to Dobson Units in the vocabulary server if that were the preferred solution? Best wishes, Alison -- Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data CentreEmail: alison.pamm...@stfc.ac.uk STFC Rutherford Appleton Laboratory R25, 2.22 Harwell Oxford, Didcot, OX11 0QX, U.K. -Original Message- From: Lowry, Roy K. [mailto:r...@bodc.ac.uk] Sent: 04 December 2012 10:23 To: Christophe Lerot Cc: Pamment, Alison (STFC,RAL,RALSP); cf-metadata@cgd.ucar.edu Subject: RE: [CF-metadata] new standard name proposal for total ozone in DU Hello Cristophe, To be absolutely clear, I'm saying the data should be stored in the NetCDF in Dobson Units, that the units parameter attribute in the NetCDF file should be Dobson Units, but that the canonical unit in the Standard Names List and therefore the units mapped in our server should be moles per square metre. Cheers, Roy. From: Christophe Lerot [christophe.le...@aeronomie.be] Sent: 04 December 2012 10:20 To: Lowry, Roy K. Cc: alison.pamm...@stfc.ac.uk; cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] new standard name proposal for total ozone in DU Dear Roy, Do you mean that the total ozone values should be given in moles per square metre in the NetCDF files themselves? Or do you mean that I should simply add a specific comment in the unit parameter attribute to make clear that the values are provided in Dobson Unit? The Dobson Unit is quite common for total ozone users and I'd prefer to stay with this unit if possible. Cheers, Christophe On 3/12/2012 15:39, Lowry, Roy K. wrote: Hello Alison, Surely the canonical unit for Dobson Units would be moles per square metre, with Dobson Units appearing as the scaled unit in the units parameter attribute. Making Dobson Units the canonical unit would be like having cm/s rather than m/s as a canonical unit. Cheers, Roy. From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of alison.pamm...@stfc.ac.uk [alison.pamm...@stfc.ac.uk] Sent: 03 December 2012 14:18 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] new standard name proposal for total ozone in DU Dear Christophe and Jonathan, I also support this proposal. We don't currently have any standard names that use Dobson Units - I think UDUnits1 didn't support it. However, since it is defined in UDunits2 I don't see any problem with adding it. Best wishes, Alison -- Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data CentreEmail: alison.pamm...@stfc.ac.uk STFC Rutherford Appleton Laboratory R25, 2.22 Harwell Oxford, Didcot, OX11 0QX, U.K. -Original Message- From: CF-metadata
Re: [CF-metadata] inclusion of GridSpec in CF?
Hi Alex, Our current GridSpec input file implementation is minimal at best, because we just did a single tile and anything distinctly GridSpeccian comes in with multiple tiles. It's as much intention as implementation at this point. Still, we have had to worry about multiple GridSpec flavors already. ESMF also supports the Common Information Model (CIM) grids package, a slightly different version of GridSpec, as a metadata output format. This is part of our general CIM XML output support. That's a pain, but not unworkable: the distinctions in our software could be made clearly, if we had versioned reference documents. We do on the CIM side. It's problematic for us to use the libCF implementation as a kind of substitute for a specification of the GridSpec convention. The convention needs to be able to evolve, and to support multiple reference implementations. Using libCF could be terrific and valuable for us (and something to talk more about offline) but unfortunately it doesn't address the problem at hand. We could say in our documentation that we support the version of GridSpec approved last May, but without a version number or static doc, and without a path to evolve the convention forward, the solution feels pretty shaky. I think there's an awkward question that needs to be answered about whether your team wants to keep managing and evolving the specification on your wiki - that evolution needs to be done somewhere. Or maybe the expectation is that the whole text will be incorporated into the main CF document and evolved there? There already seem to be some ideas, with respect to UGRID and staggering, about how GridSpec might grow or change. For GridSpec in CF it might make the most sense to resolve the question about where the thing lives (in a perfect world, the approach might be consistent for GridSpec, UGRID, and discrete geometries), and wherever that is, put an initial GridSpec version on it and generate a static doc, and then sit back and think about evolution. Best, - Cecelia On 12/6/2012 9:10 AM, Alexander Pletzer wrote: Hi Cecelia, Great to hear that ESMF is implementing gridspec. We're in the same boat, we had to settle on some specifics before implementing gridspec into libCF. Like Bert, I'm a little worried about a proliferation of gridspec flavours, even with versions attached. Another concern is that our funding for this particular work has stopped, we will not be able to provide continuous support for gridspec ad infinitum, in the short term this means fixing small things. The good news is the specification has been accepted by the CF committee in its present form, although suggestions for further improvement have since come, particularly in view of consolidating the syntax between ugrid and gridspec. This leaves a couple of options for ESMF: use libCF to handle the gridspec aggregation. We made an effort to make libCF compatible with the specification. The library is pure C so should be easy to link against and it is hosted on sourceforge. Or state that ESMF implements the gridspec approved by the committee last May. On our side, we can try to highlight any changes on the wiki. Cheers, --Alex On 12/05/2012 05:16 PM, Cecelia DeLuca wrote: Steve, I agree that solutions may be different in the near term and long term, that seems reasonable - and Alex, I understand about coordinating with Jeff. I still worry about maintaining versions on a wiki ... I think to work in practice it would need to be set up with some attention to navigation. Some more background... ESMF is already building versioned software based on UGRID and (sort of, in a single tile way) GridSpec. We need to cite distinct and static versions of the conventions for both developers and users, since our software may not work, or our documentation may be wrong, if the conventions evolve. Further, since we're committed to supporting ESMF versions for up to three years, we expect, at any given time, to have access to multiple static versions of these conventions. For the last couple ESMF releases, we used the URL of the UGRID wiki with an associated date as the version reference, but that's not the greatest solution. Hence the request for static versioned documents, but I know they are a pain to produce. At a minimum, if GridSpec and UGRID stay on wikis, it would be helpful to have a version table with links on the front wiki page so that someone who ended up there could quickly see and navigate to other versions. Does that make sense? Thanks, - Cecelia On 12/5/2012 2:17 PM, Steve Hankin wrote: Cecelia et. al., An important and somewhat awkward topic. I like your suggestion, myself. I might suggest slightly different terminology to describe it, though. I think we are proposing that _for the present_ *gridspec *and/or *ugrid *(there need not be the same answer for both) ought to be published as independent standards, and
Re: [CF-metadata] FW: Standard_name for cloud-cover by phenomenon
Hi Alison, This is now fine with me. Thank you for being so thorough :-). Philip --- Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab. --- -Original Message- From: alison.pamm...@stfc.ac.uk [mailto:alison.pamm...@stfc.ac.uk] Sent: Thursday, December 06, 2012 4:26 AM To: cf-metadata@cgd.ucar.edu Cc: heiko.kl...@met.no; Cameron-smith, Philip Subject: RE: [CF-metadata] FW: Standard_name for cloud-cover by phenomenon Dear Heiko, Philip, All, Earlier this year Heiko Klein proposed the following three standard names for cloud: high_type_cloud_area_fraction medium_type_cloud_area_fraction low_type_cloud_area_fraction which received a considerable amount of discussion regarding both the names and their definitions. Towards the end of the discussion (16th May) Philip Cameron-Smith asked two questions: Are there any other visual classification schemes in common use other than the current SYNOP one? Is the current SYNOP scheme likely to change significantly? This isn't my field, so I don't know the answers. If the answer to both questions is 'no', then I will drop all my objections. No one responded directly to Philip's questions and Heiko asked on 11th June whether we could regard the names as accepted. I have now reviewed the full discussion and note that Eizi Toyoda stated (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2012/055649.html) that the SYNOP scheme has remained unchanged since 1975 and was unlikely to do so in the near future, so I think we can take that as a 'no' to Philip's second question. Regarding Philip's first question, I note that Bruce Wright expressed the view (http://mailman.cgd.ucar.edu/pipermail/cf- metadata/2012/055642.html) that the classification scheme is sufficiently widely used that it doesn't need to be attributed to any particular 'owner'. I have also confirmed with Heiko (offlist) that there isn't any 'competitor' to the SYNOP classification, so I think we can also answer 'no' to the first question. As there are no further outstanding objections to these names, they are now accepted for addition to the standard name table. Based on the definition of the existing cloud_area_fraction name and the discussion of the proposed names I have written definitions as follows: high_type_cloud_area_fraction: ' High type clouds are: Cirrus, Cirrostratus, Cirrocumulus. X_area_fraction means the fraction of horizontal area occupied by X. Cloud area fraction is also called cloud amount and cloud cover. X_type_cloud_area_fraction is determined on the basis of cloud type and not on the vertical location of the cloud.' medium_type_cloud_area_fraction: 'Middle type clouds are: Altostratus, Altocumulus, Nimbostratus. X_area_fraction means the fraction of horizontal area occupied by X. Cloud area fraction is also called cloud amount and cloud cover. X_type_cloud_area_fraction is determined on the basis of cloud type and not on the vertical location of the cloud.' low_type_cloud_area_fraction: ' Low type clouds are: Stratus, Stratocumulus, Cumulus, Cumulonimbus. X_area_fraction means the fraction of horizontal area occupied by X. Cloud area fraction is also called cloud amount and cloud cover. X_type_cloud_area_fraction is determined on the basis of cloud type and not on the vertical location of the cloud.' These names and definitions will be added at the next update of the standard name table. Best wishes, Alison -- Alison Pamment Tel: +44 1235 778065 NCAS/British Atmospheric Data CentreEmail: alison.pamm...@stfc.ac.uk STFC Rutherford Appleton Laboratory R25, 2.22 Harwell Oxford, Didcot, OX11 0QX, U.K. -Original Message- From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Heiko Klein Sent: 11 June 2012 09:41 To: Cameron-smith, Philip Cc: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] FW: Standard_name for cloud-cover by phenomenon Hi All, after 3 weeks of silence on this subject, I assume there was no-one who answered with 'yes' to Philips questions, and there are no longer objections on using the standardard-names: low_type_cloud_area_fraction medium_type_cloud_area_fraction high_type_cloud_area_fraction Can I hope for these standard-names to appear in the next version of standard-names? Best regards, Heiko On 2012-05-16 19:08, Cameron-smith, Philip wrote: Hi All, I just refreshed my memory of ISCCP, and I should not have been using it as an example in the way that I did (my apologies). Are there any other visual classification schemes in common use other than the current SYNOP one? Is the current SYNOP scheme likely to change significantly? This isn't my
Re: [CF-metadata] [netcdf-java] problem with times in PSD dataset
Hi Cecelia: Thanks for this information. A few questions: * So you are not supporting standard Gregorian calendar even though thats the CF default? * Do modelers need to match historical dates? If so, what calendar do they use? * Is the time library suitable to be released seperate from the ESMF code, eg as standalone C++? John On 12/5/2012 3:01 PM, Cecelia DeLuca wrote: Hi John and all, ESMF has a mature time management library with calendars that are commonly used in climate/weather/related modeling. It supports the following: 360 day, no leap, Gregorian (proleptic), Julian, Julian day, modified Julian day, and custom (including custom calendars that may change the length of days). ESMF, like CESM, doesn't support the standard Gregorian calendar because it doesn't make sense for modeling groups who may need to cross the Julian/Gregorian weirdness line (we've never gotten a request to support standard Gregorian from modelers). ESMF has calendar, time, time interval, clock, and alarm constructs, can run time forward or backward, and prints times and time intervals in ISO8601 format. CESM/CAM, NASA, NOAA, Navy and other codes use it. The most complete interface to the time lib is Fortran, and there are some basic time functions exposed in C (the lib is actually written in C++). However, we could wrap the time functions in Python and include them in ESMP, which is currently a set of ESMF regridding functions wrapped in Python. We could probably do that in the late/winter spring timeframe, with some guidance on what functions were desired and a pass through our prioritization board. Best, -- Cecelia On 12/5/2012 12:25 PM, John Caron wrote: Hi all: Its probably the right thing to do to make gregorian (Mixed Gregorian/Julian calendar) the default calendar for COARDS/CF, for backwards compatibility. However, CDM may leave proleptic_gregorian (ISO8601) as its default. And I would strongly suggest that data writers stop using time since 1-1-1. Ive never seen a dataset where time since 1-1-1 using the mixed gregorian calendar was actually needed. If any one has a real example, Id like to hear about it. If you really need historical accuracy, then put in an ISO8601 formatted string, and an explicit calendar attribute. CDM handles those ok. CF should be upgraded to allow ISO strings also. time since reference date is not good for very large ranges of time. Ill just add that udunits never wanted to be a calendaring library, and shouldnt be used anymore for that. Im relying on joda-time (and its successor threeten) to be the expert in calendering, so i dont have to. I think the netcdf-C library now uses some CDAT (?) code for its calendaring, but Im sure theres other standard libraries that could be used. Anyone have candidate libraries in C or Python for robust calendering In short, we should rely on clear encoding standards (eg ISO8601) with reference software, rather than implementations like udunits that eventually go away. John PS: I think ill cross post to cf, just to throw some gasoline on the fire ;), and maybe some broader viewpoints. On 12/5/2012 10:24 AM, Don Murray (NOAA Affiliate) wrote: Hi Gerry- On 12/5/12 9:42 AM, Gerry Creager - NOAA Affiliate wrote: There are other datasets with reference to 1-1-1. I've seen them most recently in some ocean models. And the ESRL/PSD NCEP reanalysis datasets use it. Don On Wed, Dec 5, 2012 at 10:16 AM, Don Murray (NOAA Affiliate) don.mur...@noaa.gov mailto:don.mur...@noaa.gov wrote: John- I meant to send this to support-netcdf-java, but perhaps others on the list might have the same problem. On 12/4/12 4:51 PM, John Caron wrote: On 12/4/2012 4:09 PM, Don Murray (NOAA Affiliate) wrote: Hi- I was just trying to access the NOAA/ESRL/PSD Outgoing Longwave Radiation (OLR) data using netCDF-Java 4.3 ToolsUI and noticed that the times are wrong. If you open: dods://www.esrl.noaa.gov/psd/__thredds/dodsC/Datasets/__uninterp_OLR/olr.day.mean.nc http://www.esrl.noaa.gov/psd/thredds/dodsC/Datasets/uninterp_OLR/olr.day.mean.nc in the ToolsUI grid viewer, the last time in the file is shown as 2012-12-04 00Z. However, the last time in the file is actually 2012-12-02 00Z. Here is the time variable in that file: double time(time=3989); :units = hours since 1-1-1 00:00:0.0; :long_name = Time; :actual_range = 1.7540448E7, 1.763616E7; // double :delta_t = -00-01 00:00:00; :avg_period = -00-01 00:00:00; :standard_name = time; :axis = T; netCDF-Java 4.2 and ncdump -t -v time (C version) show the correct date/times. hours from 1-1-1 is rather problematic, since you are crossing the
Re: [CF-metadata] [netcdf-java] problem with times in PSD dataset
Hi John and all, Thanks for this information. A few questions: * So you are not supporting standard Gregorian calendar even though thats the CF default? Correct, the climate modelers that we work with don't use it. AFAIK the decision of CESM was to reject the CF default as unreasonable for modeling and use proleptic Gregorian. GFDL might support it, I don't know. We could probably add standard Gregorian as a new calendar if people on the data side needed it. However, we would be happier to join Steve in putting a stake in its heart! * Do modelers need to match historical dates? If so, what calendar do they use? I think the calendar used would depend on what was supported by the model and configuration, as well as the form of the date. If you wanted to represent the date of something like a volcanic eruption you could probably make it work with most of the calendars. * Is the time library suitable to be released seperate from the ESMF code, eg as standalone C++? The time library can be used apart from other ESMF interfaces, and some modeling groups do use it that way. I don't think we'd be willing to extract that part and support a separate build. We did that years ago and it was a pain to maintain. (We could try to isolate the documentation though, so users didn't have to wade through the whole reference manual to find the API.) With ESMP(ython), the scope of the interface is much smaller than ESMF proper and I think Ryan could set time functions up nicely. It might make sense to represent it as a separate python package in that approach. Would python work for you, or would you really prefer C? - Cecelia John On 12/5/2012 3:01 PM, Cecelia DeLuca wrote: Hi John and all, ESMF has a mature time management library with calendars that are commonly used in climate/weather/related modeling. It supports the following: 360 day, no leap, Gregorian (proleptic), Julian, Julian day, modified Julian day, and custom (including custom calendars that may change the length of days). ESMF, like CESM, doesn't support the standard Gregorian calendar because it doesn't make sense for modeling groups who may need to cross the Julian/Gregorian weirdness line (we've never gotten a request to support standard Gregorian from modelers). ESMF has calendar, time, time interval, clock, and alarm constructs, can run time forward or backward, and prints times and time intervals in ISO8601 format. CESM/CAM, NASA, NOAA, Navy and other codes use it. The most complete interface to the time lib is Fortran, and there are some basic time functions exposed in C (the lib is actually written in C++). However, we could wrap the time functions in Python and include them in ESMP, which is currently a set of ESMF regridding functions wrapped in Python. We could probably do that in the late/winter spring timeframe, with some guidance on what functions were desired and a pass through our prioritization board. Best, -- Cecelia On 12/5/2012 12:25 PM, John Caron wrote: Hi all: Its probably the right thing to do to make gregorian (Mixed Gregorian/Julian calendar) the default calendar for COARDS/CF, for backwards compatibility. However, CDM may leave proleptic_gregorian (ISO8601) as its default. And I would strongly suggest that data writers stop using time since 1-1-1. Ive never seen a dataset where time since 1-1-1 using the mixed gregorian calendar was actually needed. If any one has a real example, Id like to hear about it. If you really need historical accuracy, then put in an ISO8601 formatted string, and an explicit calendar attribute. CDM handles those ok. CF should be upgraded to allow ISO strings also. time since reference date is not good for very large ranges of time. Ill just add that udunits never wanted to be a calendaring library, and shouldnt be used anymore for that. Im relying on joda-time (and its successor threeten) to be the expert in calendering, so i dont have to. I think the netcdf-C library now uses some CDAT (?) code for its calendaring, but Im sure theres other standard libraries that could be used. Anyone have candidate libraries in C or Python for robust calendering In short, we should rely on clear encoding standards (eg ISO8601) with reference software, rather than implementations like udunits that eventually go away. John PS: I think ill cross post to cf, just to throw some gasoline on the fire ;), and maybe some broader viewpoints. On 12/5/2012 10:24 AM, Don Murray (NOAA Affiliate) wrote: Hi Gerry- On 12/5/12 9:42 AM, Gerry Creager - NOAA Affiliate wrote: There are other datasets with reference to 1-1-1. I've seen them most recently in some ocean models. And the ESRL/PSD NCEP reanalysis datasets use it. Don On Wed, Dec 5, 2012 at 10:16 AM, Don Murray (NOAA Affiliate) don.mur...@noaa.gov mailto:don.mur...@noaa.gov wrote: John- I meant to send this to support-netcdf-java, but perhaps others on the list might have the same problem. On 12/4/12
[CF-metadata] CF calendars (was: problem with times in PSD dataset)
Hi Steve, Cecelia: I agree we should move to a better default calendar, probably proleptic_gregorian. We are stuck with mixed Gregorian for previous CF versions. I think we just need a proposal that says As of version X, the default calender is proleptic_gregorian. You should explicitly add the calendar attribute for clarity. Udunits is no longer considered to be the reference software for date/time. It would be nice to add advice to the user about calendar tradeoffs and how to do historical date matching for modelers, assuming we have useful things to say. I wonder if allowing ISO formatted strings in place of / in addition to the time since reference date form might be useful for historical time matching? Arguably having calendar reference libraries in Python and Java would be sufficient, possibly Python is preferable even to one in C. John On 12/6/2012 1:45 PM, Cecelia DeLuca wrote: Hi John and all, Thanks for this information. A few questions: * So you are not supporting standard Gregorian calendar even though thats the CF default? Correct, the climate modelers that we work with don't use it. AFAIK the decision of CESM was to reject the CF default as unreasonable for modeling and use proleptic Gregorian. GFDL might support it, I don't know. We could probably add standard Gregorian as a new calendar if people on the data side needed it. However, we would be happier to join Steve in putting a stake in its heart! * Do modelers need to match historical dates? If so, what calendar do they use? I think the calendar used would depend on what was supported by the model and configuration, as well as the form of the date. If you wanted to represent the date of something like a volcanic eruption you could probably make it work with most of the calendars. * Is the time library suitable to be released seperate from the ESMF code, eg as standalone C++? The time library can be used apart from other ESMF interfaces, and some modeling groups do use it that way. I don't think we'd be willing to extract that part and support a separate build. We did that years ago and it was a pain to maintain. (We could try to isolate the documentation though, so users didn't have to wade through the whole reference manual to find the API.) With ESMP(ython), the scope of the interface is much smaller than ESMF proper and I think Ryan could set time functions up nicely. It might make sense to represent it as a separate python package in that approach. Would python work for you, or would you really prefer C? - Cecelia John On 12/5/2012 3:01 PM, Cecelia DeLuca wrote: Hi John and all, ESMF has a mature time management library with calendars that are commonly used in climate/weather/related modeling. It supports the following: 360 day, no leap, Gregorian (proleptic), Julian, Julian day, modified Julian day, and custom (including custom calendars that may change the length of days). ESMF, like CESM, doesn't support the standard Gregorian calendar because it doesn't make sense for modeling groups who may need to cross the Julian/Gregorian weirdness line (we've never gotten a request to support standard Gregorian from modelers). ESMF has calendar, time, time interval, clock, and alarm constructs, can run time forward or backward, and prints times and time intervals in ISO8601 format. CESM/CAM, NASA, NOAA, Navy and other codes use it. The most complete interface to the time lib is Fortran, and there are some basic time functions exposed in C (the lib is actually written in C++). However, we could wrap the time functions in Python and include them in ESMP, which is currently a set of ESMF regridding functions wrapped in Python. We could probably do that in the late/winter spring timeframe, with some guidance on what functions were desired and a pass through our prioritization board. Best, -- Cecelia On 12/5/2012 12:25 PM, John Caron wrote: Hi all: Its probably the right thing to do to make gregorian (Mixed Gregorian/Julian calendar) the default calendar for COARDS/CF, for backwards compatibility. However, CDM may leave proleptic_gregorian (ISO8601) as its default. And I would strongly suggest that data writers stop using time since 1-1-1. Ive never seen a dataset where time since 1-1-1 using the mixed gregorian calendar was actually needed. If any one has a real example, Id like to hear about it. If you really need historical accuracy, then put in an ISO8601 formatted string, and an explicit calendar attribute. CDM handles those ok. CF should be upgraded to allow ISO strings also. time since reference date is not good for very large ranges of time. Ill just add that udunits never wanted to be a calendaring library, and shouldnt be used anymore for that. Im relying on joda-time (and its successor threeten) to be the expert in calendering, so i dont have to. I think the netcdf-C library now uses some CDAT (?) code for its calendaring, but Im sure theres other standard libraries that
Re: [CF-metadata] CF calendars
On 12/6/2012 1:37 PM, John Caron wrote: Hi Steve, Cecelia: I agree we should move to a better default calendar, probably proleptic_gregorian. We are stuck with mixed Gregorian for previous CF versions. I think we just need a proposal that says As of version X, the default calender is proleptic_gregorian. You should explicitly add the calendar attribute for clarity. Udunits is no longer considered to be the reference software for date/time. You've about nailed it here. Perhaps adding that a zero-reference date that lies this side of 1500 AD can ensure that this confusion does not effect your files. It would be nice to add advice to the user about calendar tradeoffs and how to do historical date matching for modelers, assuming we have useful things to say. We could even point them to the Wikipedia discussion of the mess: https://en.wikipedia.org/wiki/Gregorian_calendar I wonder if allowing ISO formatted strings in place of / in addition to the time since reference date form might be useful for historical time matching? I suspect that the historical matching is never going to be a well-posed problem. If we regard the date-time as nothing more than a piece of metadata attached to an XYZ grid, then matching is a well-posed problem of finding the cross walk between different metadata vocabularies. But if we regard time as a continuous coordinate variable and date-time as a way to express that coordinate in ASCII, then matching is a pathological problem, because the blended Gregorian-Julian calendar has an 11 day discontinuity ... and the time of the discontinuity varies depending on what country the event occurred in. Not worth the trouble imho. - Steve Arguably having calendar reference libraries in Python and Java would be sufficient, possibly Python is preferable even to one in C. John On 12/6/2012 1:45 PM, Cecelia DeLuca wrote: Hi John and all, Thanks for this information. A few questions: * So you are not supporting standard Gregorian calendar even though thats the CF default? Correct, the climate modelers that we work with don't use it. AFAIK the decision of CESM was to reject the CF default as unreasonable for modeling and use proleptic Gregorian. GFDL might support it, I don't know. We could probably add standard Gregorian as a new calendar if people on the data side needed it. However, we would be happier to join Steve in putting a stake in its heart! * Do modelers need to match historical dates? If so, what calendar do they use? I think the calendar used would depend on what was supported by the model and configuration, as well as the form of the date. If you wanted to represent the date of something like a volcanic eruption you could probably make it work with most of the calendars. * Is the time library suitable to be released seperate from the ESMF code, eg as standalone C++? The time library can be used apart from other ESMF interfaces, and some modeling groups do use it that way. I don't think we'd be willing to extract that part and support a separate build. We did that years ago and it was a pain to maintain. (We could try to isolate the documentation though, so users didn't have to wade through the whole reference manual to find the API.) With ESMP(ython), the scope of the interface is much smaller than ESMF proper and I think Ryan could set time functions up nicely. It might make sense to represent it as a separate python package in that approach. Would python work for you, or would you really prefer C? - Cecelia John On 12/5/2012 3:01 PM, Cecelia DeLuca wrote: Hi John and all, ESMF has a mature time management library with calendars that are commonly used in climate/weather/related modeling. It supports the following: 360 day, no leap, Gregorian (proleptic), Julian, Julian day, modified Julian day, and custom (including custom calendars that may change the length of days). ESMF, like CESM, doesn't support the standard Gregorian calendar because it doesn't make sense for modeling groups who may need to cross the Julian/Gregorian weirdness line (we've never gotten a request to support standard Gregorian from modelers). ESMF has calendar, time, time interval, clock, and alarm constructs, can run time forward or backward, and prints times and time intervals in ISO8601 format. CESM/CAM, NASA, NOAA, Navy and other codes use it. The most complete interface to the time lib is Fortran, and there are some basic time functions exposed in C (the lib is actually written in C++). However, we could wrap the time functions in Python and include them in ESMP, which is currently a set of ESMF regridding functions wrapped in Python. We could probably do that in the late/winter spring timeframe, with some guidance on what functions were desired and a pass through our prioritization board. Best, -- Cecelia On 12/5/2012 12:25 PM, John Caron wrote: Hi all: Its probably the right thing to do to make
Re: [CF-metadata] [netcdf-java] problem with times in PSD dataset
John There is some meteorological data that is available pre-Gregorian calendar (paleo data, some temperature datasets) and of course there are other scientific fields where data is pre-1500 (e.g. astronomy, archeology) . Given that netCDF files with data dates spanning ~1550 probably already exist and the large number of preexisting files that use the 1-1-1 base (we have over 2000), it doesn't seem reasonable to request that files be changed to accommodate what is essentially a bug; the date values we store are correct. We started using the 1-1-1 base in the mid 1990's (almost 20 years ago) as part of the COARDS (now CF) agreed upon standard. It is reasonable for us to consider future changes but I don't think it reasonable for us to have to change our files because the Java interface is not backwards compatible. Cathy Smith NOAA/ESRL PSD On 12/5/12 12:25 PM, John Caron wrote: Hi all: Its probably the right thing to do to make gregorian (Mixed Gregorian/Julian calendar) the default calendar for COARDS/CF, for backwards compatibility. However, CDM may leave proleptic_gregorian (ISO8601) as its default. And I would strongly suggest that data writers stop using time since 1-1-1. Ive never seen a dataset where time since 1-1-1 using the mixed gregorian calendar was actually needed. If any one has a real example, Id like to hear about it. If you really need historical accuracy, then put in an ISO8601 formatted string, and an explicit calendar attribute. CDM handles those ok. CF should be upgraded to allow ISO strings also. time since reference date is not good for very large ranges of time. Ill just add that udunits never wanted to be a calendaring library, and shouldnt be used anymore for that. Im relying on joda-time (and its successor threeten) to be the expert in calendering, so i dont have to. I think the netcdf-C library now uses some CDAT (?) code for its calendaring, but Im sure theres other standard libraries that could be used. Anyone have candidate libraries in C or Python for robust calendering In short, we should rely on clear encoding standards (eg ISO8601) with reference software, rather than implementations like udunits that eventually go away. John PS: I think ill cross post to cf, just to throw some gasoline on the fire ;), and maybe some broader viewpoints. On 12/5/2012 10:24 AM, Don Murray (NOAA Affiliate) wrote: Hi Gerry- On 12/5/12 9:42 AM, Gerry Creager - NOAA Affiliate wrote: There are other datasets with reference to 1-1-1. I've seen them most recently in some ocean models. And the ESRL/PSD NCEP reanalysis datasets use it. Don On Wed, Dec 5, 2012 at 10:16 AM, Don Murray (NOAA Affiliate) don.mur...@noaa.gov mailto:don.mur...@noaa.gov wrote: John- I meant to send this to support-netcdf-java, but perhaps others on the list might have the same problem. On 12/4/12 4:51 PM, John Caron wrote: On 12/4/2012 4:09 PM, Don Murray (NOAA Affiliate) wrote: Hi- I was just trying to access the NOAA/ESRL/PSD Outgoing Longwave Radiation (OLR) data using netCDF-Java 4.3 ToolsUI and noticed that the times are wrong. If you open: dods://www.esrl.noaa.gov/psd/__thredds/dodsC/Datasets/__uninterp_OLR/olr.day.mean.nc http://www.esrl.noaa.gov/psd/thredds/dodsC/Datasets/uninterp_OLR/olr.day.mean.nc in the ToolsUI grid viewer, the last time in the file is shown as 2012-12-04 00Z. However, the last time in the file is actually 2012-12-02 00Z. Here is the time variable in that file: double time(time=3989); :units = hours since 1-1-1 00:00:0.0; :long_name = Time; :actual_range = 1.7540448E7, 1.763616E7; // double :delta_t = -00-01 00:00:00; :avg_period = -00-01 00:00:00; :standard_name = time; :axis = T; netCDF-Java 4.2 and ncdump -t -v time (C version) show the correct date/times. hours from 1-1-1 is rather problematic, since you are crossing the julian/gregorian weirdness line (i think thats the technical term ;) Im guessing the trouble lies here: Default calendar: for udunits, and therefore for CF, the default calendar is gregorian (Mixed Gregorian/Julian calendar). For CDM, the default calendar is proleptic_gregorian (ISO8601 standard). This only matters for dates before 1582. Joda time supports the GJ calendar (Historically accurate calendar with Julian followed by Gregorian) which seems it would be backward compatible with the CF/udunits. Perhaps that should be the default for backward compatibility. I have to say relying uncritically on a calendar implementation
Re: [CF-metadata] new standard name proposal for total ozone in DU
Hi All, After considerable thought, I do support addition of this std_name, but recommend that we add a comment to the description (as described below). The problem is that atmosphere_mole_content_of_ozone (proposed, units = moles/m2, typically expressed in DU) and equivalent_thickness_at_stp_of_atmosphere_ozone_content (already in CF, units = m, typically expressed in DU) are essentially the same. Although they have nominally different units, the usual unit used in both cases is Dobson Units (DU). 1 DU was originally defined as 10 micrometers of ozone at STP (ie a unit of distance), but can equivalently defined as 446.2... micromoles/m2 (ie, related to 'moles/m2'), see http://en.wikipedia.org/wiki/Dobson_unit. The conversion is trivially done through the ideal gas law. A user putting ozone column data into CF is just as likely to use one std_name as the other, and use DU for the units in either case. It would be appropriate to compare the data directly (with no unit conversion if both are put in as DU). Hence, different datasets may contain the same data using different std_names, which isn't ideal. On the other hand, the official units are different, and we have a related issue where we have separate std_names for quantities in 'moles' and 'mass', which are often trivial to convert between in many cases. If these were the only aspects to consider then I would be against the new std_name. However, there are many more species than ozone, and ozone is the only one that I see expressed as equivalent thickness. This means that we will surely end up wanting atmosphere_mole_content for other species, so it makes sense to have it for ozone too. For me, this tips the balance in favor of accepting the proposed std_name. Unfortunately, I don't think we can mitigate the problems using an alias because the std_names have different official units. Hence, I propose that we simply add a note at the end of the descriptions for atmosphere_mole_content_of_ozone and equivalent_thickness_at_stp_of_atmosphere_ozone_content alerting users to the existence of the other std_name: Note: Ozone columns can be stored in either equivalent_thickness_at_stp_of_atmosphere_ozone_content or atmosphere_mole_content_of_ozone. Best wishes, Philip --- Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab. --- -Original Message- From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of alison.pamm...@stfc.ac.uk Sent: Thursday, December 06, 2012 5:33 AM To: christophe.le...@aeronomie.be Cc: victoria.benn...@stfc.ac.uk; cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] new standard name proposal for total ozone in DU Dear Christophe and Roy, Thank you for the discussion; I think we are agreed! The name will go into the standard name table as follows: atmosphere_mole_content_of_ozone; mol m-2 Definition: ' Content indicates a quantity per unit area. The atmosphere content of a quantity refers to the vertical integral from the surface to the top of the atmosphere. For the content between specified levels in the atmosphere, standard names including content_of_atmosphere_layer are used. The construction atmosphere_mole_content_of_X means the vertically integrated number of moles of X above a unit area. The chemical formula for ozone is O3. atmosphere_mole_content_of_ozone is usually measured in Dobson Units (DU) which are equivalent to 446.2 micromoles m-2.' This name is 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 CentreEmail: alison.pamm...@stfc.ac.uk STFC Rutherford Appleton Laboratory R25, 2.22 Harwell Oxford, Didcot, OX11 0QX, U.K. -Original Message- From: Christophe Lerot [mailto:christophe.le...@aeronomie.be] Sent: 06 December 2012 12:48 To: Pamment, Alison (STFC,RAL,RALSP) Cc: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] new standard name proposal for total ozone in DU Hi Alison and Roy, I think that the solution you proposed is suitable to the O3 community. Having the canonical unit (mol/m-2) for the O3 columns in the vocabulary server is fine as long as it is not a problem to use a different unit (Dobson Unit) in the NetCDF files. The important point is that the variables are expressed in the commonly used units so that the users can understand the file content at a glance. Best regards, Christophe On 5/12/2012 11:30, alison.pamm...@stfc.ac.uk wrote: Dear Roy and Christophe, As Roy says, we usually use SI units for the canonical unit in the standard name table. There are a few exceptions, for example, age_of_sea_ice has
Re: [CF-metadata] [netcdf-java] problem with times in PSD dataset
Hi Cathy: There no question that CF currently defaults to mixed gregorian calendar. The discussion is whether thats the best choice (probably not), and to advise users not to cross the discontinuity (eg store modern dates starting from 1-1-1). Im curious as to how you generate the dates that you store? That is, how do you know that they are correct? John On 12/6/2012 4:34 PM, Cathy Smith (NOAA Affiliate) wrote: John There is some meteorological data that is available pre-Gregorian calendar (paleo data, some temperature datasets) and of course there are other scientific fields where data is pre-1500 (e.g. astronomy, archeology) . Given that netCDF files with data dates spanning ~1550 probably already exist and the large number of preexisting files that use the 1-1-1 base (we have over 2000), it doesn't seem reasonable to request that files be changed to accommodate what is essentially a bug; the date values we store are correct. We started using the 1-1-1 base in the mid 1990's (almost 20 years ago) as part of the COARDS (now CF) agreed upon standard. It is reasonable for us to consider future changes but I don't think it reasonable for us to have to change our files because the Java interface is not backwards compatible. Cathy Smith NOAA/ESRL PSD On 12/5/12 12:25 PM, John Caron wrote: Hi all: Its probably the right thing to do to make gregorian (Mixed Gregorian/Julian calendar) the default calendar for COARDS/CF, for backwards compatibility. However, CDM may leave proleptic_gregorian (ISO8601) as its default. And I would strongly suggest that data writers stop using time since 1-1-1. Ive never seen a dataset where time since 1-1-1 using the mixed gregorian calendar was actually needed. If any one has a real example, Id like to hear about it. If you really need historical accuracy, then put in an ISO8601 formatted string, and an explicit calendar attribute. CDM handles those ok. CF should be upgraded to allow ISO strings also. time since reference date is not good for very large ranges of time. Ill just add that udunits never wanted to be a calendaring library, and shouldnt be used anymore for that. Im relying on joda-time (and its successor threeten) to be the expert in calendering, so i dont have to. I think the netcdf-C library now uses some CDAT (?) code for its calendaring, but Im sure theres other standard libraries that could be used. Anyone have candidate libraries in C or Python for robust calendering In short, we should rely on clear encoding standards (eg ISO8601) with reference software, rather than implementations like udunits that eventually go away. John PS: I think ill cross post to cf, just to throw some gasoline on the fire ;), and maybe some broader viewpoints. On 12/5/2012 10:24 AM, Don Murray (NOAA Affiliate) wrote: Hi Gerry- On 12/5/12 9:42 AM, Gerry Creager - NOAA Affiliate wrote: There are other datasets with reference to 1-1-1. I've seen them most recently in some ocean models. And the ESRL/PSD NCEP reanalysis datasets use it. Don On Wed, Dec 5, 2012 at 10:16 AM, Don Murray (NOAA Affiliate) don.mur...@noaa.gov mailto:don.mur...@noaa.gov wrote: John- I meant to send this to support-netcdf-java, but perhaps others on the list might have the same problem. On 12/4/12 4:51 PM, John Caron wrote: On 12/4/2012 4:09 PM, Don Murray (NOAA Affiliate) wrote: Hi- I was just trying to access the NOAA/ESRL/PSD Outgoing Longwave Radiation (OLR) data using netCDF-Java 4.3 ToolsUI and noticed that the times are wrong. If you open: dods://www.esrl.noaa.gov/psd/__thredds/dodsC/Datasets/__uninterp_OLR/olr.day.mean.nc http://www.esrl.noaa.gov/psd/thredds/dodsC/Datasets/uninterp_OLR/olr.day.mean.nc in the ToolsUI grid viewer, the last time in the file is shown as 2012-12-04 00Z. However, the last time in the file is actually 2012-12-02 00Z. Here is the time variable in that file: double time(time=3989); :units = hours since 1-1-1 00:00:0.0; :long_name = Time; :actual_range = 1.7540448E7, 1.763616E7; // double :delta_t = -00-01 00:00:00; :avg_period = -00-01 00:00:00; :standard_name = time; :axis = T; netCDF-Java 4.2 and ncdump -t -v time (C version) show the correct date/times. hours from 1-1-1 is rather problematic, since you are crossing the julian/gregorian weirdness line (i think thats the technical term ;) Im guessing the trouble lies here: Default calendar: for udunits, and therefore for CF, the default calendar is gregorian (Mixed Gregorian/Julian calendar). For CDM, the default calendar is proleptic_gregorian (ISO8601 standard).
Re: [CF-metadata] [netcdf-java] problem with times in PSD dataset
On 12/6/2012 4:09 PM, John Caron wrote: Hi Cathy: There no question that CF currently defaults to mixed gregorian calendar. The discussion is whether thats the best choice (probably not), and to advise users not to cross the discontinuity (eg store modern dates starting from 1-1-1). Im curious as to how you generate the dates that you store? That is, how do you know that they are correct? Hi Cathy, A question to add to John's: * If a user made a time series plot of paleo data across the Julian-Gregorian discontinuity, what expectations would he/she have about how the time axis was labelled? Do you know of software that will correctly label the time axis across a mixed Julian-Gregorian time series? - Steve John On 12/6/2012 4:34 PM, Cathy Smith (NOAA Affiliate) wrote: John There is some meteorological data that is available pre-Gregorian calendar (paleo data, some temperature datasets) and of course there are other scientific fields where data is pre-1500 (e.g. astronomy, archeology) . Given that netCDF files with data dates spanning ~1550 probably already exist and the large number of preexisting files that use the 1-1-1 base (we have over 2000), it doesn't seem reasonable to request that files be changed to accommodate what is essentially a bug; the date values we store are correct. We started using the 1-1-1 base in the mid 1990's (almost 20 years ago) as part of the COARDS (now CF) agreed upon standard. It is reasonable for us to consider future changes but I don't think it reasonable for us to have to change our files because the Java interface is not backwards compatible. Cathy Smith NOAA/ESRL PSD On 12/5/12 12:25 PM, John Caron wrote: Hi all: Its probably the right thing to do to make gregorian (Mixed Gregorian/Julian calendar) the default calendar for COARDS/CF, for backwards compatibility. However, CDM may leave proleptic_gregorian (ISO8601) as its default. And I would strongly suggest that data writers stop using time since 1-1-1. Ive never seen a dataset where time since 1-1-1 using the mixed gregorian calendar was actually needed. If any one has a real example, Id like to hear about it. If you really need historical accuracy, then put in an ISO8601 formatted string, and an explicit calendar attribute. CDM handles those ok. CF should be upgraded to allow ISO strings also. time since reference date is not good for very large ranges of time. Ill just add that udunits never wanted to be a calendaring library, and shouldnt be used anymore for that. Im relying on joda-time (and its successor threeten) to be the expert in calendering, so i dont have to. I think the netcdf-C library now uses some CDAT (?) code for its calendaring, but Im sure theres other standard libraries that could be used. Anyone have candidate libraries in C or Python for robust calendering In short, we should rely on clear encoding standards (eg ISO8601) with reference software, rather than implementations like udunits that eventually go away. John PS: I think ill cross post to cf, just to throw some gasoline on the fire ;), and maybe some broader viewpoints. On 12/5/2012 10:24 AM, Don Murray (NOAA Affiliate) wrote: Hi Gerry- On 12/5/12 9:42 AM, Gerry Creager - NOAA Affiliate wrote: There are other datasets with reference to 1-1-1. I've seen them most recently in some ocean models. And the ESRL/PSD NCEP reanalysis datasets use it. Don On Wed, Dec 5, 2012 at 10:16 AM, Don Murray (NOAA Affiliate) don.mur...@noaa.gov mailto:don.mur...@noaa.gov wrote: John- I meant to send this to support-netcdf-java, but perhaps others on the list might have the same problem. On 12/4/12 4:51 PM, John Caron wrote: On 12/4/2012 4:09 PM, Don Murray (NOAA Affiliate) wrote: Hi- I was just trying to access the NOAA/ESRL/PSD Outgoing Longwave Radiation (OLR) data using netCDF-Java 4.3 ToolsUI and noticed that the times are wrong. If you open: dods://www.esrl.noaa.gov/psd/__thredds/dodsC/Datasets/__uninterp_OLR/olr.day.mean.nc http://www.esrl.noaa.gov/psd/thredds/dodsC/Datasets/uninterp_OLR/olr.day.mean.nc in the ToolsUI grid viewer, the last time in the file is shown as 2012-12-04 00Z. However, the last time in the file is actually 2012-12-02 00Z. Here is the time variable in that file: double time(time=3989); :units = hours since 1-1-1 00:00:0.0; :long_name = Time; :actual_range = 1.7540448E7, 1.763616E7; // double :delta_t = -00-01 00:00:00; :avg_period = -00-01 00:00:00; :standard_name = time; :axis = T; netCDF-Java 4.2 and ncdump -t -v time (C version) show the correct date/times. hours from 1-1-1
Re: [CF-metadata] CF calendars (was: problem with times in PSD dataset)
All, I agree that the current calendar definitions and usage have a lot of problems. Following are some proposals that are geared towards both accuracy and backward compatibility. 1. Please, NO default calendar. Starting with the next CF version, the calendar attribute should be required on all time coordinate variables. 2. Define a new and unique name for the mixed Julian/Gregorian calendar. My favorite would be julian-gregorian. I could tolerate mixed julian-gregorian. 3. Recommend that mixed Julian/Gregorian never be used, except (a) in genuine historical data sets that properly need to span the crossover; and (b) to facilitate backward compatibility in existing data sets. 4. Redefine gregorian to mean ONLY the proper Gregorian calendar starting on the crossover date 1582 October 15. Add the formal constraint on this calendar, that any usage with dates earlier than the crossover is prohibited. Note that many existing data sets are automatically compatible with this constraint, with no changes needed. 5. Recommend gregorian, NOT proleptic_gregorian, as the CF preferred calendar for dates associated with the modern era. 6. Stop using standard as a calendar name. Please be explicit. --Dave On Thu, Dec 6, 2012 at 2:37 PM, John Caron ca...@unidata.ucar.edu wrote: Hi Steve, Cecelia: I agree we should move to a better default calendar, probably proleptic_gregorian. We are stuck with mixed Gregorian for previous CF versions. I think we just need a proposal that says As of version X, the default calender is proleptic_gregorian. You should explicitly add the calendar attribute for clarity. Udunits is no longer considered to be the reference software for date/time. It would be nice to add advice to the user about calendar tradeoffs and how to do historical date matching for modelers, assuming we have useful things to say. I wonder if allowing ISO formatted strings in place of / in addition to the time since reference date form might be useful for historical time matching? Arguably having calendar reference libraries in Python and Java would be sufficient, possibly Python is preferable even to one in C. John On 12/6/2012 1:45 PM, Cecelia DeLuca wrote: Hi John and all, Thanks for this information. A few questions: * So you are not supporting standard Gregorian calendar even though thats the CF default? Correct, the climate modelers that we work with don't use it. AFAIK the decision of CESM was to reject the CF default as unreasonable for modeling and use proleptic Gregorian. GFDL might support it, I don't know. We could probably add standard Gregorian as a new calendar if people on the data side needed it. However, we would be happier to join Steve in putting a stake in its heart! * Do modelers need to match historical dates? If so, what calendar do they use? I think the calendar used would depend on what was supported by the model and configuration, as well as the form of the date. If you wanted to represent the date of something like a volcanic eruption you could probably make it work with most of the calendars. * Is the time library suitable to be released seperate from the ESMF code, eg as standalone C++? The time library can be used apart from other ESMF interfaces, and some modeling groups do use it that way. I don't think we'd be willing to extract that part and support a separate build. We did that years ago and it was a pain to maintain. (We could try to isolate the documentation though, so users didn't have to wade through the whole reference manual to find the API.) With ESMP(ython), the scope of the interface is much smaller than ESMF proper and I think Ryan could set time functions up nicely. It might make sense to represent it as a separate python package in that approach. Would python work for you, or would you really prefer C? - Cecelia John On 12/5/2012 3:01 PM, Cecelia DeLuca wrote: Hi John and all, ESMF has a mature time management library with calendars that are commonly used in climate/weather/related modeling. It supports the following: 360 day, no leap, Gregorian (proleptic), Julian, Julian day, modified Julian day, and custom (including custom calendars that may change the length of days). ESMF, like CESM, doesn't support the standard Gregorian calendar because it doesn't make sense for modeling groups who may need to cross the Julian/Gregorian weirdness line (we've never gotten a request to support standard Gregorian from modelers). ESMF has calendar, time, time interval, clock, and alarm constructs, can run time forward or backward, and prints times and time intervals in ISO8601 format. CESM/CAM, NASA, NOAA, Navy and other codes use it. The most complete interface to the time lib is Fortran, and there are some basic time functions exposed in C (the lib is actually written in C++). However, we could wrap the time functions in Python and include them in
Re: [CF-metadata] new standard name proposal for total ozone in DU
Dear all, I would also like to support this proposal. And I thank Philip for his careful thinking. If these were the only aspects to consider then I would be against the new std_name. However, there are many more species than ozone, and ozone is the only one that I see expressed as equivalent thickness. This means that we will surely end up wanting atmosphere_mole_content for other species, so it makes sense to have it for ozone too. For me, this tips the balance in favor of accepting the proposed std_name. Wouldn't this even call for recommending the use of atmosphere_mole_content as preferred option? Since both quantities are essentially the same and both are reported in DU, it will be merely a naming thing in practice. The advantage being that it will be easier for outsiders to understand that an atmosphere_mole_content of ozone is the same concept as an atmosphere_mole_content of some other species, whereas this gets lost if the default for ozone is equivalent_thickness_at_stp_of_atmosphere_ozone_content while all other compounds use atmosphere_mole_content. Should we even go as far as to deprecate the use of equivalent_thickness_at_stp_of_atmosphere_ozone_content? Philip also raises a good point with respect to alias names: has it been stated clearly that they must refer to exactly the same quantity? I believe they should, because if we allow trivial unit conversions to count as aliases, then even wavelength and frequency could be considered of aliases, which surely no one would want. Best regards, Martin Date: Thu, 6 Dec 2012 23:41:16 + From: Cameron-smith, Philip cameronsmi...@llnl.gov To: alison.pamm...@stfc.ac.uk alison.pamm...@stfc.ac.uk, christophe.le...@aeronomie.be christophe.le...@aeronomie.be Cc: victoria.benn...@stfc.ac.uk victoria.benn...@stfc.ac.uk, cf-metadata@cgd.ucar.edu cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] new standard name proposal for total ozone in DU Message-ID: 298f51abd432da4288ce6b8c469a2afc338...@prdexmbx-04.the-lab.llnl.gov Content-Type: text/plain; charset=us-ascii Hi All, After considerable thought, I do support addition of this std_name, but recommend that we add a comment to the description (as described below). The problem is that atmosphere_mole_content_of_ozone (proposed, units = moles/m2, typically expressed in DU) and equivalent_thickness_at_stp_of_atmosphere_ozone_content (already in CF, units = m, typically expressed in DU) are essentially the same. Although they have nominally different units, the usual unit used in both cases is Dobson Units (DU). 1 DU was originally defined as 10 micrometers of ozone at STP (ie a unit of distance), but can equivalently defined as 446.2... micromoles/m2 (ie, related to 'moles/m2'), see http://en.wikipedia.org/wiki/Dobson_unit. The conversion is trivially done through the ideal gas law. A user putting ozone column data into CF is just as likely to use one std_name as the other, and use DU for the units in either case. It would be appropriate to compare the data directly (with no unit conversion if both are put in as DU). Hence, different datasets may contain the same data using different std_names, which isn't ideal. On the other hand, the official units are different, and we have a related issue where we have separate std_names for quantities in 'moles' and 'mass', which are often trivial to convert between in many cases. If these were the only aspects to consider then I would be against the new std_name. However, there are many more species than ozone, and ozone is the only one that I see expressed as equivalent thickness. This means that we will surely end up wanting atmosphere_mole_content for other species, so it makes sense to have it for ozone too. For me, this tips the balance in favor of accepting the proposed std_name. Unfortunately, I don't think we can mitigate the problems using an alias because the std_names have different official units. Hence, I propose that we simply add a note at the end of the descriptions for atmosphere_mole_content_of_ozone and equivalent_thickness_at_stp_of_atmosphere_ozone_content alerting users to the existence of the other std_name: Note: Ozone columns can be stored in either equivalent_thickness_at_stp_of_atmosphere_ozone_content or atmosphere_mole_content_of_ozone. Best wishes, Philip --- Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab. --- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
