From T.Hume at bom.gov.au Wed Jan 7 16:46:10 2009 From: T.Hume at bom.gov.au (Timothy Hume) Date: Thu, 8 Jan 2009 10:46:10 +1100 Subject: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] Message-ID: Hi, I am writing NetCDF files which hold surface fields (2m temperature etc) from multiple NWP model runs (all the runs from the same model for the last month or so). The files are for operational use, so I want them to strictly follow the CF conventions. I am running into a couple of problems, where the conventions don't seem to be ideally suited for storing more than a single model run. Here is what I do: I have four dimensions and associated coordinate variables: basetime: The base time for the model run (units: seconds since 1970-01-01 00:00:00.0 +0:00) forecast: The forecast lead time, relative to the basetime (units: hours) latitude longitude There is no need for a vertical dimension, because I am using surface fields. Never-the-less I make use of a scalar vertical coordinate variable as described in Section 5.7 of the CF-1.3 metadata conventions document. The use of two dimensions to store the time information (basetime and forecast) seems to be a natural way to store multiple NWP model runs, and is the standard way used in the very old NUWG conventions. As far as I can tell, what I am doing is supported by the CF conventions, provided the time axis is taken to be the basetime dimension. This is because Section 4.4 of the conventions specifies the units of the time coordinate must include a reference time. Obviously the units of the forecast coordinate cannot include a reference time, because the reference time varies, and is determined by the value of the basetime coordinate. The difficulty I am encountering is that some applications which read NetCDF/CF files (such as the Unidata IDV and Joe Sirott's very nice web based NetCDF data viewer) seem to choke on my data. I suspect (but am not 100% certain in the case of the IDV) that the reason is because of the way I handle the time information in my files. To illustrate in more detail what my files look like, I am attaching the CDL from an example file. The CDL is non-CF compliant, because I have specified the "T" axis (via the axis variable attribute) to be the forecast coordinate, and the forecast coordinate has invalid units (no reference time). I am planning on switching the "T" axis to the base time coordinate, which as far as I can determine should make the file CF compliant. My question is: is there a better (or more standard) way of storing multiple NWP model runs in a single file than what I am doing? Cheers, Tim Hume Centre for Australian Weather and Climate Research Australian Bureau of Meteorology Melbourne Australia --- Example CDL follows --- netcdf gasp_1p0deg_ocf_t2m_rtdb_opn { dimensions: forecast = 69 ; basetime = UNLIMITED ; // (100 currently) latitude = 96 ; longitude = 121 ; bounds = 2 ; variables: double forecast(forecast) ; forecast:long_name = "Time of model forecast, relative to the basetime" ; forecast:units = "hours" ; forecast:standard_name = "forecast_period" ; forecast:axis = "T" ; forecast:bounds = "forecast_bounds" ; double forecast_bounds(forecast, bounds) ; forecast_bounds:long_name = "forecast interval" ; forecast_bounds:units = "hours" ; int basetime(basetime) ; basetime:long_name = "Model basetime" ; basetime:units = "seconds since 1970-01-01 00:00:00.0 +0:00" ; basetime:calendar = "gregorian" ; basetime:standard_name = "forecast_reference_time" ; double latitude(latitude) ; latitude:long_name = "latitude" ; latitude:units = "degrees_north" ; latitude:bounds = "latitude_bounds" ; latitude:valid_min = -90. ; latitude:valid_max = 90. ; latitude:standard_name = "latitude" ; latitude:axis = "Y" ; double latitude_bounds(latitude, bounds) ; latitude_bounds:long_name = "grid cell latitude boundaries" ; latitude_bounds:units = "degrees_north" ; latitude_bounds:valid_min = -90. ; latitude_bounds:valid_max = 90. ; double longitude(longitude) ; longitude:long_name = "longitude" ; longitude:units = "degrees_east" ; longitude:bounds = "longitude_bounds" ; longitude:valid_min = -360. ; longitude:valid_max = 360. ; longitude:standard_name = "longitude" ; longitude:axis = "X" ; double longitude_bounds(longitude, bounds) ; longitude_bounds:long_name = "grid cell longitude boundaries" ; longitude_bounds:units = "degrees_east" ; longitude_bounds:valid_min = -360. ; longitude_bounds:valid_max = 360. ; float temperature_2m(basetime, forecast, latitude, longitude) ; temperature_2m:long_name = "Air temperature 2m above the surface" ; temperature_2m:units = "K" ; temperature_2m:_FillValue = 9.96921e+36f ; temperature_2m:missing_value = 9.96921e+36f ; temperature_2m:valid_min = 180.f ; temperature_2m:valid_max = 330.f ; temperature_2m:standard_name = "air_temperature" ; temperature_2m:cell_methods = "lat: lon: mean (area weighted)" ; temperature_2m:coordinates = "level" ; double level ; level:long_name = "Height above the surface" ; level:units = "m" ; level:positive = "up" ; level:standard_name = "height" ; level:axis = "Z" ; // global attributes: :Conventions = "CF-1.3" ; :history = "File created by the Gridded OCF data ingest system" ; :institution = "Australian Bureau of Meteorology" ; :source = "model" ; :title = "GASP forecasts of temperature_2m; resolution: 1.0 degree; source: rtdb" ; :topography = "MSAS" ; } From taylor13 at llnl.gov Wed Jan 7 17:03:07 2009 From: taylor13 at llnl.gov (Karl Taylor) Date: Wed, 07 Jan 2009 16:03:07 -0800 Subject: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: <496542BB.9000804@llnl.gov> Hi Tim, Other than the axis attribute for time, I didn't see any issues. You might run the CF compliance checker on the file (http://cf-pcmdi.llnl.gov/conformance), but it might not run if the other utilities stumbled. Maybe someone else has some ideas. cheers, Karl Timothy Hume wrote: > Hi, > > I am writing NetCDF files which hold surface fields (2m temperature etc) from multiple NWP model runs (all the runs from the same model for the last month or so). The files are for operational use, so I want them to strictly follow the CF conventions. I am running into a couple of problems, where the conventions don't seem to be ideally suited for storing more than a single model run. > > Here is what I do: > > I have four dimensions and associated coordinate variables: > > basetime: The base time for the model run (units: seconds since 1970-01-01 00:00:00.0 +0:00) > forecast: The forecast lead time, relative to the basetime (units: hours) > latitude > longitude > > There is no need for a vertical dimension, because I am using surface fields. Never-the-less I make use of a scalar vertical coordinate variable as described in Section 5.7 of the CF-1.3 metadata conventions document. > > The use of two dimensions to store the time information (basetime and forecast) seems to be a natural way to store multiple NWP model runs, and is the standard way used in the very old NUWG conventions. As far as I can tell, what I am doing is supported by the CF conventions, provided the time axis is taken to be the basetime dimension. This is because Section 4.4 of the conventions specifies the units of the time coordinate must include a reference time. Obviously the units of the forecast coordinate cannot include a reference time, because the reference time varies, and is determined by the value of the basetime coordinate. > > The difficulty I am encountering is that some applications which read NetCDF/CF files (such as the Unidata IDV and Joe Sirott's very nice web based NetCDF data viewer) seem to choke on my data. I suspect (but am not 100% certain in the case of the IDV) that the reason is because of the way I handle the time information in my files. > > To illustrate in more detail what my files look like, I am attaching the CDL from an example file. The CDL is non-CF compliant, because I have specified the "T" axis (via the axis variable attribute) to be the forecast coordinate, and the forecast coordinate has invalid units (no reference time). I am planning on switching the "T" axis to the base time coordinate, which as far as I can determine should make the file CF compliant. > > My question is: is there a better (or more standard) way of storing multiple NWP model runs in a single file than what I am doing? > > Cheers, > > Tim Hume > Centre for Australian Weather and Climate Research > Australian Bureau of Meteorology > Melbourne > Australia > > --- Example CDL follows --- > > netcdf gasp_1p0deg_ocf_t2m_rtdb_opn { > dimensions: > forecast = 69 ; > basetime = UNLIMITED ; // (100 currently) > latitude = 96 ; > longitude = 121 ; > bounds = 2 ; > variables: > double forecast(forecast) ; > forecast:long_name = "Time of model forecast, relative to the basetime" ; > forecast:units = "hours" ; > forecast:standard_name = "forecast_period" ; > forecast:axis = "T" ; > forecast:bounds = "forecast_bounds" ; > double forecast_bounds(forecast, bounds) ; > forecast_bounds:long_name = "forecast interval" ; > forecast_bounds:units = "hours" ; > int basetime(basetime) ; > basetime:long_name = "Model basetime" ; > basetime:units = "seconds since 1970-01-01 00:00:00.0 +0:00" ; > basetime:calendar = "gregorian" ; > basetime:standard_name = "forecast_reference_time" ; > double latitude(latitude) ; > latitude:long_name = "latitude" ; > latitude:units = "degrees_north" ; > latitude:bounds = "latitude_bounds" ; > latitude:valid_min = -90. ; > latitude:valid_max = 90. ; > latitude:standard_name = "latitude" ; > latitude:axis = "Y" ; > double latitude_bounds(latitude, bounds) ; > latitude_bounds:long_name = "grid cell latitude boundaries" ; > latitude_bounds:units = "degrees_north" ; > latitude_bounds:valid_min = -90. ; > latitude_bounds:valid_max = 90. ; > double longitude(longitude) ; > longitude:long_name = "longitude" ; > longitude:units = "degrees_east" ; > longitude:bounds = "longitude_bounds" ; > longitude:valid_min = -360. ; > longitude:valid_max = 360. ; > longitude:standard_name = "longitude" ; > longitude:axis = "X" ; > double longitude_bounds(longitude, bounds) ; > longitude_bounds:long_name = "grid cell longitude boundaries" ; > longitude_bounds:units = "degrees_east" ; > longitude_bounds:valid_min = -360. ; > longitude_bounds:valid_max = 360. ; > float temperature_2m(basetime, forecast, latitude, longitude) ; > temperature_2m:long_name = "Air temperature 2m above the surface" ; > temperature_2m:units = "K" ; > temperature_2m:_FillValue = 9.96921e+36f ; > temperature_2m:missing_value = 9.96921e+36f ; > temperature_2m:valid_min = 180.f ; > temperature_2m:valid_max = 330.f ; > temperature_2m:standard_name = "air_temperature" ; > temperature_2m:cell_methods = "lat: lon: mean (area weighted)" ; > temperature_2m:coordinates = "level" ; > double level ; > level:long_name = "Height above the surface" ; > level:units = "m" ; > level:positive = "up" ; > level:standard_name = "height" ; > level:axis = "Z" ; > > // global attributes: > :Conventions = "CF-1.3" ; > :history = "File created by the Gridded OCF data ingest system" ; > :institution = "Australian Bureau of Meteorology" ; > :source = "model" ; > :title = "GASP forecasts of temperature_2m; resolution: 1.0 degree; source: rtdb" ; > :topography = "MSAS" ; > } > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http:// mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > From T.Hume at bom.gov.au Wed Jan 7 17:19:33 2009 From: T.Hume at bom.gov.au (Timothy Hume) Date: Thu, 8 Jan 2009 11:19:33 +1100 Subject: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] In-Reply-To: <496542BB.9000804@llnl.gov> Message-ID: Hi Karl, I have just checked one of my files, and get two errors: The first error is: ------------------ Checking variable: forecast ------------------ ERROR (4.4): Invalid units and/or reference time This is the error I am aware of. My file should become compliant if I switch the "T" axis to basetime. The second error is: ------------------ Checking variable: level ------------------ ERROR (4): Axis attribute is not allowed for auxillary coordinate variables. I was unaware that the axis attribute should not be used for scalar coordinate variables (as describe in Section 5.7). Is this intended? In any case, I don't think this small error should cause the NetCDF viewers I tried (IDV and Joe Sirott's web application) to not work. Cheers, Tim. -----Original Message----- From: Karl Taylor [mailto:taylor13 at llnl.gov] Sent: Thursday, 8 January 2009 11:03 To: Timothy Hume Cc: cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] Hi Tim, Other than the axis attribute for time, I didn't see any issues. You might run the CF compliance checker on the file (http://cf-pcmdi.llnl.gov/conformance), but it might not run if the other utilities stumbled. Maybe someone else has some ideas. cheers, Karl Timothy Hume wrote: > Hi, > > I am writing NetCDF files which hold surface fields (2m temperature etc) from multiple NWP model runs (all the runs from the same model for the last month or so). The files are for operational use, so I want them to strictly follow the CF conventions. I am running into a couple of problems, where the conventions don't seem to be ideally suited for storing more than a single model run. > > Here is what I do: > > I have four dimensions and associated coordinate variables: > > basetime: The base time for the model run (units: seconds since 1970-01-01 00:00:00.0 +0:00) > forecast: The forecast lead time, relative to the basetime (units: hours) > latitude > longitude > > There is no need for a vertical dimension, because I am using surface fields. Never-the-less I make use of a scalar vertical coordinate variable as described in Section 5.7 of the CF-1.3 metadata conventions document. > > The use of two dimensions to store the time information (basetime and forecast) seems to be a natural way to store multiple NWP model runs, and is the standard way used in the very old NUWG conventions. As far as I can tell, what I am doing is supported by the CF conventions, provided the time axis is taken to be the basetime dimension. This is because Section 4.4 of the conventions specifies the units of the time coordinate must include a reference time. Obviously the units of the forecast coordinate cannot include a reference time, because the reference time varies, and is determined by the value of the basetime coordinate. > > The difficulty I am encountering is that some applications which read NetCDF/CF files (such as the Unidata IDV and Joe Sirott's very nice web based NetCDF data viewer) seem to choke on my data. I suspect (but am not 100% certain in the case of the IDV) that the reason is because of the way I handle the time information in my files. > > To illustrate in more detail what my files look like, I am attaching the CDL from an example file. The CDL is non-CF compliant, because I have specified the "T" axis (via the axis variable attribute) to be the forecast coordinate, and the forecast coordinate has invalid units (no reference time). I am planning on switching the "T" axis to the base time coordinate, which as far as I can determine should make the file CF compliant. > > My question is: is there a better (or more standard) way of storing multiple NWP model runs in a single file than what I am doing? > > Cheers, > > Tim Hume > Centre for Australian Weather and Climate Research > Australian Bureau of Meteorology > Melbourne > Australia > > --- Example CDL follows --- > > netcdf gasp_1p0deg_ocf_t2m_rtdb_opn { > dimensions: > forecast = 69 ; > basetime = UNLIMITED ; // (100 currently) > latitude = 96 ; > longitude = 121 ; > bounds = 2 ; > variables: > double forecast(forecast) ; > forecast:long_name = "Time of model forecast, relative to the basetime" ; > forecast:units = "hours" ; > forecast:standard_name = "forecast_period" ; > forecast:axis = "T" ; > forecast:bounds = "forecast_bounds" ; > double forecast_bounds(forecast, bounds) ; > forecast_bounds:long_name = "forecast interval" ; > forecast_bounds:units = "hours" ; > int basetime(basetime) ; > basetime:long_name = "Model basetime" ; > basetime:units = "seconds since 1970-01-01 00:00:00.0 +0:00" ; > basetime:calendar = "gregorian" ; > basetime:standard_name = "forecast_reference_time" ; > double latitude(latitude) ; > latitude:long_name = "latitude" ; > latitude:units = "degrees_north" ; > latitude:bounds = "latitude_bounds" ; > latitude:valid_min = -90. ; > latitude:valid_max = 90. ; > latitude:standard_name = "latitude" ; > latitude:axis = "Y" ; > double latitude_bounds(latitude, bounds) ; > latitude_bounds:long_name = "grid cell latitude boundaries" ; > latitude_bounds:units = "degrees_north" ; > latitude_bounds:valid_min = -90. ; > latitude_bounds:valid_max = 90. ; > double longitude(longitude) ; > longitude:long_name = "longitude" ; > longitude:units = "degrees_east" ; > longitude:bounds = "longitude_bounds" ; > longitude:valid_min = -360. ; > longitude:valid_max = 360. ; > longitude:standard_name = "longitude" ; > longitude:axis = "X" ; > double longitude_bounds(longitude, bounds) ; > longitude_bounds:long_name = "grid cell longitude boundaries" ; > longitude_bounds:units = "degrees_east" ; > longitude_bounds:valid_min = -360. ; > longitude_bounds:valid_max = 360. ; > float temperature_2m(basetime, forecast, latitude, longitude) ; > temperature_2m:long_name = "Air temperature 2m above the surface" ; > temperature_2m:units = "K" ; > temperature_2m:_FillValue = 9.96921e+36f ; > temperature_2m:missing_value = 9.96921e+36f ; > temperature_2m:valid_min = 180.f ; > temperature_2m:valid_max = 330.f ; > temperature_2m:standard_name = "air_temperature" ; > temperature_2m:cell_methods = "lat: lon: mean (area weighted)" ; > temperature_2m:coordinates = "level" ; > double level ; > level:long_name = "Height above the surface" ; > level:units = "m" ; > level:positive = "up" ; > level:standard_name = "height" ; > level:axis = "Z" ; > > // global attributes: > :Conventions = "CF-1.3" ; > :history = "File created by the Gridded OCF data ingest system" ; > :institution = "Australian Bureau of Meteorology" ; > :source = "model" ; > :title = "GASP forecasts of temperature_2m; resolution: 1.0 degree; source: rtdb" ; > :topography = "MSAS" ; > } > _______________________________________________ > 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 Jan 7 18:07:22 2009 From: taylor13 at llnl.gov (Karl Taylor) Date: Wed, 07 Jan 2009 17:07:22 -0800 Subject: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: <496551CA.4050802@llnl.gov> Hi Tim, Section 4.4 (just before section 4.1) states "The methods of identifying coordinate types described in this section apply both to coordinate variables and to auxiliary coordinate variables named by the coordinates attribute." Since the axis attribute is one of the methods used to identify a vertical coordinate, it would seem to be allowed for the level in your file. On the other hand, in the 4th paragraph of section 5.7, it says that "The axis attribute is not allowed for auxiliary coordinate variables". This seems to contradict the earlier statement. We need to revise the document to be internally consistent. Does anyone recall why we would want to prohibit the use of the axis attribute for auxiliary coordinate variables? cheers, Karl Timothy Hume wrote: > Hi Karl, > > I have just checked one of my files, and get two errors: > > The first error is: > > ------------------ > Checking variable: forecast > ------------------ > ERROR (4.4): Invalid units and/or reference time > > This is the error I am aware of. My file should become compliant if I switch the "T" axis to basetime. > > > The second error is: > > ------------------ > Checking variable: level > ------------------ > ERROR (4): Axis attribute is not allowed for auxillary coordinate variables. > > I was unaware that the axis attribute should not be used for scalar coordinate variables (as describe in Section 5.7). Is this intended? In any case, I don't think this small error should cause the NetCDF viewers I tried (IDV and Joe Sirott's web application) to not work. > > Cheers, > > Tim. > > -----Original Message----- > From: Karl Taylor [mailto:taylor13 at llnl.gov] > Sent: Thursday, 8 January 2009 11:03 > To: Timothy Hume > Cc: cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] > > Hi Tim, > > Other than the axis attribute for time, I didn't see any issues. You > might run the CF compliance checker on the file > (http:// cf-pcmdi.llnl.gov/conformance), but it might not run if the > other utilities stumbled. Maybe someone else has some ideas. > > cheers, > Karl > > > Timothy Hume wrote: >> Hi, >> >> I am writing NetCDF files which hold surface fields (2m temperature etc) from multiple NWP model runs (all the runs from the same model for the last month or so). The files are for operational use, so I want them to strictly follow the CF conventions. I am running into a couple of problems, where the conventions don't seem to be ideally suited for storing more than a single model run. >> >> Here is what I do: >> >> I have four dimensions and associated coordinate variables: >> >> basetime: The base time for the model run (units: seconds since 1970-01-01 00:00:00.0 +0:00) >> forecast: The forecast lead time, relative to the basetime (units: hours) >> latitude >> longitude >> >> There is no need for a vertical dimension, because I am using surface fields. Never-the-less I make use of a scalar vertical coordinate variable as described in Section 5.7 of the CF-1.3 metadata conventions document. >> >> The use of two dimensions to store the time information (basetime and forecast) seems to be a natural way to store multiple NWP model runs, and is the standard way used in the very old NUWG conventions. As far as I can tell, what I am doing is supported by the CF conventions, provided the time axis is taken to be the basetime dimension. This is because Section 4.4 of the conventions specifies the units of the time coordinate must include a reference time. Obviously the units of the forecast coordinate cannot include a reference time, because the reference time varies, and is determined by the value of the basetime coordinate. >> >> The difficulty I am encountering is that some applications which read NetCDF/CF files (such as the Unidata IDV and Joe Sirott's very nice web based NetCDF data viewer) seem to choke on my data. I suspect (but am not 100% certain in the case of the IDV) that the reason is because of the way I handle the time information in my files. >> >> To illustrate in more detail what my files look like, I am attaching the CDL from an example file. The CDL is non-CF compliant, because I have specified the "T" axis (via the axis variable attribute) to be the forecast coordinate, and the forecast coordinate has invalid units (no reference time). I am planning on switching the "T" axis to the base time coordinate, which as far as I can determine should make the file CF compliant. >> >> My question is: is there a better (or more standard) way of storing multiple NWP model runs in a single file than what I am doing? >> >> Cheers, >> >> Tim Hume >> Centre for Australian Weather and Climate Research >> Australian Bureau of Meteorology >> Melbourne >> Australia >> >> --- Example CDL follows --- >> >> netcdf gasp_1p0deg_ocf_t2m_rtdb_opn { >> dimensions: >> forecast = 69 ; >> basetime = UNLIMITED ; // (100 currently) >> latitude = 96 ; >> longitude = 121 ; >> bounds = 2 ; >> variables: >> double forecast(forecast) ; >> forecast:long_name = "Time of model forecast, relative to the basetime" ; >> forecast:units = "hours" ; >> forecast:standard_name = "forecast_period" ; >> forecast:axis = "T" ; >> forecast:bounds = "forecast_bounds" ; >> double forecast_bounds(forecast, bounds) ; >> forecast_bounds:long_name = "forecast interval" ; >> forecast_bounds:units = "hours" ; >> int basetime(basetime) ; >> basetime:long_name = "Model basetime" ; >> basetime:units = "seconds since 1970-01-01 00:00:00.0 +0:00" ; >> basetime:calendar = "gregorian" ; >> basetime:standard_name = "forecast_reference_time" ; >> double latitude(latitude) ; >> latitude:long_name = "latitude" ; >> latitude:units = "degrees_north" ; >> latitude:bounds = "latitude_bounds" ; >> latitude:valid_min = -90. ; >> latitude:valid_max = 90. ; >> latitude:standard_name = "latitude" ; >> latitude:axis = "Y" ; >> double latitude_bounds(latitude, bounds) ; >> latitude_bounds:long_name = "grid cell latitude boundaries" ; >> latitude_bounds:units = "degrees_north" ; >> latitude_bounds:valid_min = -90. ; >> latitude_bounds:valid_max = 90. ; >> double longitude(longitude) ; >> longitude:long_name = "longitude" ; >> longitude:units = "degrees_east" ; >> longitude:bounds = "longitude_bounds" ; >> longitude:valid_min = -360. ; >> longitude:valid_max = 360. ; >> longitude:standard_name = "longitude" ; >> longitude:axis = "X" ; >> double longitude_bounds(longitude, bounds) ; >> longitude_bounds:long_name = "grid cell longitude boundaries" ; >> longitude_bounds:units = "degrees_east" ; >> longitude_bounds:valid_min = -360. ; >> longitude_bounds:valid_max = 360. ; >> float temperature_2m(basetime, forecast, latitude, longitude) ; >> temperature_2m:long_name = "Air temperature 2m above the surface" ; >> temperature_2m:units = "K" ; >> temperature_2m:_FillValue = 9.96921e+36f ; >> temperature_2m:missing_value = 9.96921e+36f ; >> temperature_2m:valid_min = 180.f ; >> temperature_2m:valid_max = 330.f ; >> temperature_2m:standard_name = "air_temperature" ; >> temperature_2m:cell_methods = "lat: lon: mean (area weighted)" ; >> temperature_2m:coordinates = "level" ; >> double level ; >> level:long_name = "Height above the surface" ; >> level:units = "m" ; >> level:positive = "up" ; >> level:standard_name = "height" ; >> level:axis = "Z" ; >> >> // global attributes: >> :Conventions = "CF-1.3" ; >> :history = "File created by the Gridded OCF data ingest system" ; >> :institution = "Australian Bureau of Meteorology" ; >> :source = "model" ; >> :title = "GASP forecasts of temperature_2m; resolution: 1.0 degree; source: rtdb" ; >> :topography = "MSAS" ; >> } >> _______________________________________________ >> 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 Wed Jan 7 18:56:13 2009 From: caron at unidata.ucar.edu (John Caron) Date: Wed, 07 Jan 2009 18:56:13 -0700 Subject: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] In-Reply-To: <496551CA.4050802@llnl.gov> References: <496551CA.4050802@llnl.gov> Message-ID: <49655D3D.1010300@unidata.ucar.edu> Hi Karl, Tim: I think the original wording doesnt fully anticipate multiple datetime coordinates: Section 4.4: " A time coordinate is identifiable from its units string alone. The Udunits routines utScan() and utIsTime() can be used to make this determination. Optionally, the time coordinate may be indicated additionally by providing the standard_name attribute with an appropriate value, and/or the axis attribute with the value T. " In Tim's example, his "forecast/valid time" is actually an offset from the base time, in units of time, not a udunit datetime. This allows it to be a 1D coordinate variable. But in the general case, if the forecast time spacing depends on the basetime, it must be 2D. We see this a lot in NCEP model output. In general, when storing multiple forecast model runs in the same file there are two options: 1. A 1D "basetime/runtime" coordinate variable identified by standard name "forecast_reference_time" which holds udunit datetimes, and a 2D "forecast/valid time" auxiliary coordinate variable with standard name "time" which also holds udunit datetimes. It must be dimensioned by the runtime and the time dimensions. Data variables will need to use the "coordinates" attribute to reference the time auxiliary coordinate, as usual. 2. A 1D "basetime/runtime" coordinate variable identified by standard name "forecast_reference_time" which holds udunit dates, and a 1D or 2D "forecast offset time" auxiliary coordinate variable identified by standard name "forecast_period" which holds a udunit time unit (eg hours), which is added to the basetime to get the forecast datetime. If 1D, it will be dimensioned by time, if 2d it will be dimensioned by runtime and time, and must be referenced by the "coordinates" attribute As an aside, the utIsTime() function is ambiguous as to whether we have a time unit or a datetime unit (which udunits calls "having an offset"). I think we need to carefully distinguish time and datetime, and specify where each is allowed. If this seems reasonable, I can write up a proposal. Karl Taylor wrote: > Hi Tim, > > Section 4.4 (just before section 4.1) states "The methods of identifying > coordinate types described in this section apply both to coordinate > variables and to auxiliary coordinate variables named by the coordinates > attribute." Since the axis attribute is one of the methods used to > identify a vertical coordinate, it would seem to be allowed for the > level in your file. > > On the other hand, in the 4th paragraph of section 5.7, it says that > "The axis attribute is not allowed for auxiliary coordinate variables". > This seems to contradict the earlier statement. > > We need to revise the document to be internally consistent. Does anyone > recall why we would want to prohibit the use of the axis attribute for > auxiliary coordinate variables? > > cheers, > Karl > > Timothy Hume wrote: >> Hi Karl, >> >> I have just checked one of my files, and get two errors: >> >> The first error is: >> >> ------------------ >> Checking variable: forecast >> ------------------ >> ERROR (4.4): Invalid units and/or reference time >> >> This is the error I am aware of. My file should become compliant if I >> switch the "T" axis to basetime. >> >> >> The second error is: >> >> ------------------ >> Checking variable: level >> ------------------ >> ERROR (4): Axis attribute is not allowed for auxillary coordinate >> variables. >> >> I was unaware that the axis attribute should not be used for scalar >> coordinate variables (as describe in Section 5.7). Is this intended? >> In any case, I don't think this small error should cause the NetCDF >> viewers I tried (IDV and Joe Sirott's web application) to not work. >> >> Cheers, >> >> Tim. >> >> -----Original Message----- >> From: Karl Taylor [mailto:taylor13 at llnl.gov] Sent: Thursday, 8 January >> 2009 11:03 >> To: Timothy Hume >> Cc: cf-metadata at cgd.ucar.edu >> Subject: Re: [CF-metadata] Storing multiple NWP model runs in a NetCDF >> - CF file [SEC=UNCLASSIFIED] >> >> Hi Tim, >> >> Other than the axis attribute for time, I didn't see any issues. You >> might run the CF compliance checker on the file (http:// >> cf-pcmdi.llnl.gov/conformance), but it might not run if the other >> utilities stumbled. Maybe someone else has some ideas. >> >> cheers, >> Karl >> >> >> Timothy Hume wrote: >>> Hi, >>> >>> I am writing NetCDF files which hold surface fields (2m temperature >>> etc) from multiple NWP model runs (all the runs from the same model >>> for the last month or so). The files are for operational use, so I >>> want them to strictly follow the CF conventions. I am running into a >>> couple of problems, where the conventions don't seem to be ideally >>> suited for storing more than a single model run. >>> >>> Here is what I do: >>> >>> I have four dimensions and associated coordinate variables: >>> >>> basetime: The base time for the model run (units: seconds since >>> 1970-01-01 00:00:00.0 +0:00) >>> forecast: The forecast lead time, relative to the basetime (units: >>> hours) >>> latitude >>> longitude >>> >>> There is no need for a vertical dimension, because I am using surface >>> fields. Never-the-less I make use of a scalar vertical coordinate >>> variable as described in Section 5.7 of the CF-1.3 metadata >>> conventions document. >>> >>> The use of two dimensions to store the time information (basetime and >>> forecast) seems to be a natural way to store multiple NWP model runs, >>> and is the standard way used in the very old NUWG conventions. As far >>> as I can tell, what I am doing is supported by the CF conventions, >>> provided the time axis is taken to be the basetime dimension. This is >>> because Section 4.4 of the conventions specifies the units of the >>> time coordinate must include a reference time. Obviously the units of >>> the forecast coordinate cannot include a reference time, because the >>> reference time varies, and is determined by the value of the basetime >>> coordinate. >>> >>> The difficulty I am encountering is that some applications which read >>> NetCDF/CF files (such as the Unidata IDV and Joe Sirott's very nice >>> web based NetCDF data viewer) seem to choke on my data. I suspect >>> (but am not 100% certain in the case of the IDV) that the reason is >>> because of the way I handle the time information in my files. >>> >>> To illustrate in more detail what my files look like, I am attaching >>> the CDL from an example file. The CDL is non-CF compliant, because I >>> have specified the "T" axis (via the axis variable attribute) to be >>> the forecast coordinate, and the forecast coordinate has invalid >>> units (no reference time). I am planning on switching the "T" axis to >>> the base time coordinate, which as far as I can determine should make >>> the file CF compliant. >>> >>> My question is: is there a better (or more standard) way of storing >>> multiple NWP model runs in a single file than what I am doing? >>> Cheers, >>> >>> Tim Hume >>> Centre for Australian Weather and Climate Research >>> Australian Bureau of Meteorology >>> Melbourne >>> Australia >>> >>> --- Example CDL follows --- >>> >>> netcdf gasp_1p0deg_ocf_t2m_rtdb_opn { >>> dimensions: >>> forecast = 69 ; >>> basetime = UNLIMITED ; // (100 currently) >>> latitude = 96 ; >>> longitude = 121 ; >>> bounds = 2 ; >>> variables: >>> double forecast(forecast) ; >>> forecast:long_name = "Time of model forecast, relative to the >>> basetime" ; >>> forecast:units = "hours" ; >>> forecast:standard_name = "forecast_period" ; >>> forecast:axis = "T" ; >>> forecast:bounds = "forecast_bounds" ; >>> double forecast_bounds(forecast, bounds) ; >>> forecast_bounds:long_name = "forecast interval" ; >>> forecast_bounds:units = "hours" ; >>> int basetime(basetime) ; >>> basetime:long_name = "Model basetime" ; >>> basetime:units = "seconds since 1970-01-01 00:00:00.0 +0:00" ; >>> basetime:calendar = "gregorian" ; >>> basetime:standard_name = "forecast_reference_time" ; >>> double latitude(latitude) ; >>> latitude:long_name = "latitude" ; >>> latitude:units = "degrees_north" ; >>> latitude:bounds = "latitude_bounds" ; >>> latitude:valid_min = -90. ; >>> latitude:valid_max = 90. ; >>> latitude:standard_name = "latitude" ; >>> latitude:axis = "Y" ; >>> double latitude_bounds(latitude, bounds) ; >>> latitude_bounds:long_name = "grid cell latitude boundaries" ; >>> latitude_bounds:units = "degrees_north" ; >>> latitude_bounds:valid_min = -90. ; >>> latitude_bounds:valid_max = 90. ; >>> double longitude(longitude) ; >>> longitude:long_name = "longitude" ; >>> longitude:units = "degrees_east" ; >>> longitude:bounds = "longitude_bounds" ; >>> longitude:valid_min = -360. ; >>> longitude:valid_max = 360. ; >>> longitude:standard_name = "longitude" ; >>> longitude:axis = "X" ; >>> double longitude_bounds(longitude, bounds) ; >>> longitude_bounds:long_name = "grid cell longitude boundaries" ; >>> longitude_bounds:units = "degrees_east" ; >>> longitude_bounds:valid_min = -360. ; >>> longitude_bounds:valid_max = 360. ; >>> float temperature_2m(basetime, forecast, latitude, longitude) ; >>> temperature_2m:long_name = "Air temperature 2m above the >>> surface" ; >>> temperature_2m:units = "K" ; >>> temperature_2m:_FillValue = 9.96921e+36f ; >>> temperature_2m:missing_value = 9.96921e+36f ; >>> temperature_2m:valid_min = 180.f ; >>> temperature_2m:valid_max = 330.f ; >>> temperature_2m:standard_name = "air_temperature" ; >>> temperature_2m:cell_methods = "lat: lon: mean (area weighted)" ; >>> temperature_2m:coordinates = "level" ; >>> double level ; >>> level:long_name = "Height above the surface" ; >>> level:units = "m" ; >>> level:positive = "up" ; >>> level:standard_name = "height" ; >>> level:axis = "Z" ; >>> >>> // global attributes: >>> :Conventions = "CF-1.3" ; >>> :history = "File created by the Gridded OCF data ingest >>> system" ; >>> :institution = "Australian Bureau of Meteorology" ; >>> :source = "model" ; >>> :title = "GASP forecasts of temperature_2m; resolution: 1.0 >>> degree; source: rtdb" ; >>> :topography = "MSAS" ; >>> } >>> _______________________________________________ >>> 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 T.Hume at bom.gov.au Wed Jan 7 19:03:12 2009 From: T.Hume at bom.gov.au (Timothy Hume) Date: Thu, 8 Jan 2009 13:03:12 +1100 Subject: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] In-Reply-To: <496551CA.4050802@llnl.gov> Message-ID: Hi Karl, Thanks for the help. I have remedied the situation by simply deleting the optional axis attribute from the scalar coordinate variable called "level". In my files, level isn't really an axis (in the sense it does not have a corresponding dimension); perhaps this is the reason for the prohibition? I have also made some progress with the IDV viewer being able to display the data (which now pass all the tests in the CF-1.3 compliance checker). The latest version of IDV (24 December) will open the files (an earlier version didn't), but it still doesn't understand the method of identifying times which I use, and only appears capable of displaying a single base time. For the time being I am using ncview, which works perfectly on the files, but using IDV would be nice, because it has some pretty nice extra features. Thanks, Tim Hume Centre for Australian Weather and Climate Research Australian Bureau of Meteorology Melbourne Australia -----Original Message----- From: Karl Taylor [mailto:taylor13 at llnl.gov] Sent: Thursday, 8 January 2009 12:07 To: Timothy Hume Cc: cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] Hi Tim, Section 4.4 (just before section 4.1) states "The methods of identifying coordinate types described in this section apply both to coordinate variables and to auxiliary coordinate variables named by the coordinates attribute." Since the axis attribute is one of the methods used to identify a vertical coordinate, it would seem to be allowed for the level in your file. On the other hand, in the 4th paragraph of section 5.7, it says that "The axis attribute is not allowed for auxiliary coordinate variables". This seems to contradict the earlier statement. We need to revise the document to be internally consistent. Does anyone recall why we would want to prohibit the use of the axis attribute for auxiliary coordinate variables? cheers, Karl Timothy Hume wrote: > Hi Karl, > > I have just checked one of my files, and get two errors: > > The first error is: > > ------------------ > Checking variable: forecast > ------------------ > ERROR (4.4): Invalid units and/or reference time > > This is the error I am aware of. My file should become compliant if I switch the "T" axis to basetime. > > > The second error is: > > ------------------ > Checking variable: level > ------------------ > ERROR (4): Axis attribute is not allowed for auxillary coordinate variables. > > I was unaware that the axis attribute should not be used for scalar coordinate variables (as describe in Section 5.7). Is this intended? In any case, I don't think this small error should cause the NetCDF viewers I tried (IDV and Joe Sirott's web application) to not work. > > Cheers, > > Tim. > > -----Original Message----- > From: Karl Taylor [mailto:taylor13 at llnl.gov] > Sent: Thursday, 8 January 2009 11:03 > To: Timothy Hume > Cc: cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] > > Hi Tim, > > Other than the axis attribute for time, I didn't see any issues. You > might run the CF compliance checker on the file > (http:// cf-pcmdi.llnl.gov/conformance), but it might not run if the > other utilities stumbled. Maybe someone else has some ideas. > > cheers, > Karl > > > Timothy Hume wrote: >> Hi, >> >> I am writing NetCDF files which hold surface fields (2m temperature etc) from multiple NWP model runs (all the runs from the same model for the last month or so). The files are for operational use, so I want them to strictly follow the CF conventions. I am running into a couple of problems, where the conventions don't seem to be ideally suited for storing more than a single model run. >> >> Here is what I do: >> >> I have four dimensions and associated coordinate variables: >> >> basetime: The base time for the model run (units: seconds since 1970-01-01 00:00:00.0 +0:00) >> forecast: The forecast lead time, relative to the basetime (units: hours) >> latitude >> longitude >> >> There is no need for a vertical dimension, because I am using surface fields. Never-the-less I make use of a scalar vertical coordinate variable as described in Section 5.7 of the CF-1.3 metadata conventions document. >> >> The use of two dimensions to store the time information (basetime and forecast) seems to be a natural way to store multiple NWP model runs, and is the standard way used in the very old NUWG conventions. As far as I can tell, what I am doing is supported by the CF conventions, provided the time axis is taken to be the basetime dimension. This is because Section 4.4 of the conventions specifies the units of the time coordinate must include a reference time. Obviously the units of the forecast coordinate cannot include a reference time, because the reference time varies, and is determined by the value of the basetime coordinate. >> >> The difficulty I am encountering is that some applications which read NetCDF/CF files (such as the Unidata IDV and Joe Sirott's very nice web based NetCDF data viewer) seem to choke on my data. I suspect (but am not 100% certain in the case of the IDV) that the reason is because of the way I handle the time information in my files. >> >> To illustrate in more detail what my files look like, I am attaching the CDL from an example file. The CDL is non-CF compliant, because I have specified the "T" axis (via the axis variable attribute) to be the forecast coordinate, and the forecast coordinate has invalid units (no reference time). I am planning on switching the "T" axis to the base time coordinate, which as far as I can determine should make the file CF compliant. >> >> My question is: is there a better (or more standard) way of storing multiple NWP model runs in a single file than what I am doing? >> >> Cheers, >> >> Tim Hume >> Centre for Australian Weather and Climate Research >> Australian Bureau of Meteorology >> Melbourne >> Australia >> >> --- Example CDL follows --- >> >> netcdf gasp_1p0deg_ocf_t2m_rtdb_opn { >> dimensions: >> forecast = 69 ; >> basetime = UNLIMITED ; // (100 currently) >> latitude = 96 ; >> longitude = 121 ; >> bounds = 2 ; >> variables: >> double forecast(forecast) ; >> forecast:long_name = "Time of model forecast, relative to the basetime" ; >> forecast:units = "hours" ; >> forecast:standard_name = "forecast_period" ; >> forecast:axis = "T" ; >> forecast:bounds = "forecast_bounds" ; >> double forecast_bounds(forecast, bounds) ; >> forecast_bounds:long_name = "forecast interval" ; >> forecast_bounds:units = "hours" ; >> int basetime(basetime) ; >> basetime:long_name = "Model basetime" ; >> basetime:units = "seconds since 1970-01-01 00:00:00.0 +0:00" ; >> basetime:calendar = "gregorian" ; >> basetime:standard_name = "forecast_reference_time" ; >> double latitude(latitude) ; >> latitude:long_name = "latitude" ; >> latitude:units = "degrees_north" ; >> latitude:bounds = "latitude_bounds" ; >> latitude:valid_min = -90. ; >> latitude:valid_max = 90. ; >> latitude:standard_name = "latitude" ; >> latitude:axis = "Y" ; >> double latitude_bounds(latitude, bounds) ; >> latitude_bounds:long_name = "grid cell latitude boundaries" ; >> latitude_bounds:units = "degrees_north" ; >> latitude_bounds:valid_min = -90. ; >> latitude_bounds:valid_max = 90. ; >> double longitude(longitude) ; >> longitude:long_name = "longitude" ; >> longitude:units = "degrees_east" ; >> longitude:bounds = "longitude_bounds" ; >> longitude:valid_min = -360. ; >> longitude:valid_max = 360. ; >> longitude:standard_name = "longitude" ; >> longitude:axis = "X" ; >> double longitude_bounds(longitude, bounds) ; >> longitude_bounds:long_name = "grid cell longitude boundaries" ; >> longitude_bounds:units = "degrees_east" ; >> longitude_bounds:valid_min = -360. ; >> longitude_bounds:valid_max = 360. ; >> float temperature_2m(basetime, forecast, latitude, longitude) ; >> temperature_2m:long_name = "Air temperature 2m above the surface" ; >> temperature_2m:units = "K" ; >> temperature_2m:_FillValue = 9.96921e+36f ; >> temperature_2m:missing_value = 9.96921e+36f ; >> temperature_2m:valid_min = 180.f ; >> temperature_2m:valid_max = 330.f ; >> temperature_2m:standard_name = "air_temperature" ; >> temperature_2m:cell_methods = "lat: lon: mean (area weighted)" ; >> temperature_2m:coordinates = "level" ; >> double level ; >> level:long_name = "Height above the surface" ; >> level:units = "m" ; >> level:positive = "up" ; >> level:standard_name = "height" ; >> level:axis = "Z" ; >> >> // global attributes: >> :Conventions = "CF-1.3" ; >> :history = "File created by the Gridded OCF data ingest system" ; >> :institution = "Australian Bureau of Meteorology" ; >> :source = "model" ; >> :title = "GASP forecasts of temperature_2m; resolution: 1.0 degree; source: rtdb" ; >> :topography = "MSAS" ; >> } >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata at cgd.ucar.edu >> http:// mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> > > > From T.Hume at bom.gov.au Wed Jan 7 19:19:28 2009 From: T.Hume at bom.gov.au (Timothy Hume) Date: Thu, 8 Jan 2009 13:19:28 +1100 Subject: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] In-Reply-To: <49655D3D.1010300@unidata.ucar.edu> Message-ID: Hi John, This seems a reasonable proposal to me. Often when storing NWP forecasts option (2) will suffice. Most centres will always include the same forecast lead times each time new NWP model data are disseminated (for example some centres will send out +6, +12, +18, +24, +36, +42, +48, +60 and +72 hour forecasts for two model runs per day, ever day). Data users will then often want to extract particular forecast lead times (e.g. +48 hours). Option (2) makes this a trivial task. On the other hand option (1) is also useful, even when the time offsets are fixed. For example, one can construct an auxilliary coordinate variable called valid_time which is two dimensional. This aids in the cases when the user wants to extract all forecasts which are valid at a particular time. In fact, using both options (1) and (2) often yields the most useful files. Tim. -----Original Message----- From: John Caron [mailto:caron at unidata.ucar.edu] Sent: Thursday, 8 January 2009 12:56 To: Karl Taylor Cc: Timothy Hume; cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] Hi Karl, Tim: I think the original wording doesnt fully anticipate multiple datetime coordinates: Section 4.4: " A time coordinate is identifiable from its units string alone. The Udunits routines utScan() and utIsTime() can be used to make this determination. Optionally, the time coordinate may be indicated additionally by providing the standard_name attribute with an appropriate value, and/or the axis attribute with the value T. " In Tim's example, his "forecast/valid time" is actually an offset from the base time, in units of time, not a udunit datetime. This allows it to be a 1D coordinate variable. But in the general case, if the forecast time spacing depends on the basetime, it must be 2D. We see this a lot in NCEP model output. In general, when storing multiple forecast model runs in the same file there are two options: 1. A 1D "basetime/runtime" coordinate variable identified by standard name "forecast_reference_time" which holds udunit datetimes, and a 2D "forecast/valid time" auxiliary coordinate variable with standard name "time" which also holds udunit datetimes. It must be dimensioned by the runtime and the time dimensions. Data variables will need to use the "coordinates" attribute to reference the time auxiliary coordinate, as usual. 2. A 1D "basetime/runtime" coordinate variable identified by standard name "forecast_reference_time" which holds udunit dates, and a 1D or 2D "forecast offset time" auxiliary coordinate variable identified by standard name "forecast_period" which holds a udunit time unit (eg hours), which is added to the basetime to get the forecast datetime. If 1D, it will be dimensioned by time, if 2d it will be dimensioned by runtime and time, and must be referenced by the "coordinates" attribute As an aside, the utIsTime() function is ambiguous as to whether we have a time unit or a datetime unit (which udunits calls "having an offset"). I think we need to carefully distinguish time and datetime, and specify where each is allowed. If this seems reasonable, I can write up a proposal. Karl Taylor wrote: > Hi Tim, > > Section 4.4 (just before section 4.1) states "The methods of identifying > coordinate types described in this section apply both to coordinate > variables and to auxiliary coordinate variables named by the coordinates > attribute." Since the axis attribute is one of the methods used to > identify a vertical coordinate, it would seem to be allowed for the > level in your file. > > On the other hand, in the 4th paragraph of section 5.7, it says that > "The axis attribute is not allowed for auxiliary coordinate variables". > This seems to contradict the earlier statement. > > We need to revise the document to be internally consistent. Does anyone > recall why we would want to prohibit the use of the axis attribute for > auxiliary coordinate variables? > > cheers, > Karl > > Timothy Hume wrote: >> Hi Karl, >> >> I have just checked one of my files, and get two errors: >> >> The first error is: >> >> ------------------ >> Checking variable: forecast >> ------------------ >> ERROR (4.4): Invalid units and/or reference time >> >> This is the error I am aware of. My file should become compliant if I >> switch the "T" axis to basetime. >> >> >> The second error is: >> >> ------------------ >> Checking variable: level >> ------------------ >> ERROR (4): Axis attribute is not allowed for auxillary coordinate >> variables. >> >> I was unaware that the axis attribute should not be used for scalar >> coordinate variables (as describe in Section 5.7). Is this intended? >> In any case, I don't think this small error should cause the NetCDF >> viewers I tried (IDV and Joe Sirott's web application) to not work. >> >> Cheers, >> >> Tim. >> >> -----Original Message----- >> From: Karl Taylor [mailto:taylor13 at llnl.gov] Sent: Thursday, 8 January >> 2009 11:03 >> To: Timothy Hume >> Cc: cf-metadata at cgd.ucar.edu >> Subject: Re: [CF-metadata] Storing multiple NWP model runs in a NetCDF >> - CF file [SEC=UNCLASSIFIED] >> >> Hi Tim, >> >> Other than the axis attribute for time, I didn't see any issues. You >> might run the CF compliance checker on the file (http:// >> cf-pcmdi.llnl.gov/conformance), but it might not run if the other >> utilities stumbled. Maybe someone else has some ideas. >> >> cheers, >> Karl >> >> >> Timothy Hume wrote: >>> Hi, >>> >>> I am writing NetCDF files which hold surface fields (2m temperature >>> etc) from multiple NWP model runs (all the runs from the same model >>> for the last month or so). The files are for operational use, so I >>> want them to strictly follow the CF conventions. I am running into a >>> couple of problems, where the conventions don't seem to be ideally >>> suited for storing more than a single model run. >>> >>> Here is what I do: >>> >>> I have four dimensions and associated coordinate variables: >>> >>> basetime: The base time for the model run (units: seconds since >>> 1970-01-01 00:00:00.0 +0:00) >>> forecast: The forecast lead time, relative to the basetime (units: >>> hours) >>> latitude >>> longitude >>> >>> There is no need for a vertical dimension, because I am using surface >>> fields. Never-the-less I make use of a scalar vertical coordinate >>> variable as described in Section 5.7 of the CF-1.3 metadata >>> conventions document. >>> >>> The use of two dimensions to store the time information (basetime and >>> forecast) seems to be a natural way to store multiple NWP model runs, >>> and is the standard way used in the very old NUWG conventions. As far >>> as I can tell, what I am doing is supported by the CF conventions, >>> provided the time axis is taken to be the basetime dimension. This is >>> because Section 4.4 of the conventions specifies the units of the >>> time coordinate must include a reference time. Obviously the units of >>> the forecast coordinate cannot include a reference time, because the >>> reference time varies, and is determined by the value of the basetime >>> coordinate. >>> >>> The difficulty I am encountering is that some applications which read >>> NetCDF/CF files (such as the Unidata IDV and Joe Sirott's very nice >>> web based NetCDF data viewer) seem to choke on my data. I suspect >>> (but am not 100% certain in the case of the IDV) that the reason is >>> because of the way I handle the time information in my files. >>> >>> To illustrate in more detail what my files look like, I am attaching >>> the CDL from an example file. The CDL is non-CF compliant, because I >>> have specified the "T" axis (via the axis variable attribute) to be >>> the forecast coordinate, and the forecast coordinate has invalid >>> units (no reference time). I am planning on switching the "T" axis to >>> the base time coordinate, which as far as I can determine should make >>> the file CF compliant. >>> >>> My question is: is there a better (or more standard) way of storing >>> multiple NWP model runs in a single file than what I am doing? >>> Cheers, >>> >>> Tim Hume >>> Centre for Australian Weather and Climate Research >>> Australian Bureau of Meteorology >>> Melbourne >>> Australia >>> >>> --- Example CDL follows --- >>> >>> netcdf gasp_1p0deg_ocf_t2m_rtdb_opn { >>> dimensions: >>> forecast = 69 ; >>> basetime = UNLIMITED ; // (100 currently) >>> latitude = 96 ; >>> longitude = 121 ; >>> bounds = 2 ; >>> variables: >>> double forecast(forecast) ; >>> forecast:long_name = "Time of model forecast, relative to the >>> basetime" ; >>> forecast:units = "hours" ; >>> forecast:standard_name = "forecast_period" ; >>> forecast:axis = "T" ; >>> forecast:bounds = "forecast_bounds" ; >>> double forecast_bounds(forecast, bounds) ; >>> forecast_bounds:long_name = "forecast interval" ; >>> forecast_bounds:units = "hours" ; >>> int basetime(basetime) ; >>> basetime:long_name = "Model basetime" ; >>> basetime:units = "seconds since 1970-01-01 00:00:00.0 +0:00" ; >>> basetime:calendar = "gregorian" ; >>> basetime:standard_name = "forecast_reference_time" ; >>> double latitude(latitude) ; >>> latitude:long_name = "latitude" ; >>> latitude:units = "degrees_north" ; >>> latitude:bounds = "latitude_bounds" ; >>> latitude:valid_min = -90. ; >>> latitude:valid_max = 90. ; >>> latitude:standard_name = "latitude" ; >>> latitude:axis = "Y" ; >>> double latitude_bounds(latitude, bounds) ; >>> latitude_bounds:long_name = "grid cell latitude boundaries" ; >>> latitude_bounds:units = "degrees_north" ; >>> latitude_bounds:valid_min = -90. ; >>> latitude_bounds:valid_max = 90. ; >>> double longitude(longitude) ; >>> longitude:long_name = "longitude" ; >>> longitude:units = "degrees_east" ; >>> longitude:bounds = "longitude_bounds" ; >>> longitude:valid_min = -360. ; >>> longitude:valid_max = 360. ; >>> longitude:standard_name = "longitude" ; >>> longitude:axis = "X" ; >>> double longitude_bounds(longitude, bounds) ; >>> longitude_bounds:long_name = "grid cell longitude boundaries" ; >>> longitude_bounds:units = "degrees_east" ; >>> longitude_bounds:valid_min = -360. ; >>> longitude_bounds:valid_max = 360. ; >>> float temperature_2m(basetime, forecast, latitude, longitude) ; >>> temperature_2m:long_name = "Air temperature 2m above the >>> surface" ; >>> temperature_2m:units = "K" ; >>> temperature_2m:_FillValue = 9.96921e+36f ; >>> temperature_2m:missing_value = 9.96921e+36f ; >>> temperature_2m:valid_min = 180.f ; >>> temperature_2m:valid_max = 330.f ; >>> temperature_2m:standard_name = "air_temperature" ; >>> temperature_2m:cell_methods = "lat: lon: mean (area weighted)" ; >>> temperature_2m:coordinates = "level" ; >>> double level ; >>> level:long_name = "Height above the surface" ; >>> level:units = "m" ; >>> level:positive = "up" ; >>> level:standard_name = "height" ; >>> level:axis = "Z" ; >>> >>> // global attributes: >>> :Conventions = "CF-1.3" ; >>> :history = "File created by the Gridded OCF data ingest >>> system" ; >>> :institution = "Australian Bureau of Meteorology" ; >>> :source = "model" ; >>> :title = "GASP forecasts of temperature_2m; resolution: 1.0 >>> degree; source: rtdb" ; >>> :topography = "MSAS" ; >>> } >>> _______________________________________________ >>> 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 Jan 8 01:50:50 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Thu, 8 Jan 2009 08:50:50 +0000 Subject: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] Message-ID: <20090108085050.GB24620@met.reading.ac.uk> Dear all I think we excluded the axis attribute from auxiliary coords because it is intended for the 1D coord variables. However we didn't allow for the special case of a scalar coord variable, which is really equivalent to a size-1 1D coord variable. I agree with Karl that scalar coord variables should be allowed to have the axis attribute. There is a summary of previous discussions of 2D time coordinates at http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2006/001008.html - itself now 2.5 years ago! It would be good to state some more explicit recommendations in the standard. How does that summary compare with what John and Tim have in mind now? Best wishes Jonathan From schuster at ucar.edu Thu Jan 8 06:40:55 2009 From: schuster at ucar.edu (Douglas Schuster) Date: Thu, 8 Jan 2009 06:40:55 -0700 Subject: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: <6355F73B-DC99-4FF7-98F2-4A1AC950D8DD@ucar.edu> Hi Tim, John, NCAR has been using a structure similar to option 2 for TIGGE based NetCDF files that is not technically CF compliant, but was reviewed by colleagues at ECMWF, UK MetOffice, and BADC (Dec 10, 2007, ECMWF workshop) and deemed acceptable. The structure is designed to handle multiple ensemble forecast systems, and multiple init times with varying forecast periods. i.e. int reftime(reftime) ; reftime:data_type = "int" ; reftime:units = "hours since 1950-01-01 00:00:00" ; reftime:standard_name = "forecast_reference_time" ; reftime:long_name = "Time of model initialization" ; int leadtime(reftime) ; leadtime:data_type = "int" ; leadtime:units = "hours" ; leadtime:standard_name = "forecast_period" ; leadtime:long_name = "Hours since forecast_reference_time" ; The structure was based on the proposal by Francisco J. Doblas-Reyes for the "Ensembles" project. A thread related to this proposal can be found at: http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2007/001470.html A sample file is available for download at: http://dss.ucar.edu/download/doug/data.nc The metadata "CDL" dump of the file can be accessed at: http://dss.ucar.edu/download/doug/data.dump Doug On Jan 7, 2009, at 7:19 PM, Timothy Hume wrote: > Hi John, > > This seems a reasonable proposal to me. Often when storing NWP > forecasts option (2) will suffice. Most centres will always include > the same forecast lead times each time new NWP model data are > disseminated (for example some centres will send out +6, +12, +18, > +24, +36, +42, +48, +60 and +72 hour forecasts for two model runs > per day, ever day). Data users will then often want to extract > particular forecast lead times (e.g. +48 hours). Option (2) makes > this a trivial task. > > On the other hand option (1) is also useful, even when the time > offsets are fixed. For example, one can construct an auxilliary > coordinate variable called valid_time which is two dimensional. This > aids in the cases when the user wants to extract all forecasts which > are valid at a particular time. In fact, using both options (1) and > (2) often yields the most useful files. > > Tim. > > > -----Original Message----- > From: John Caron [mailto:caron at unidata.ucar.edu] > Sent: Thursday, 8 January 2009 12:56 > To: Karl Taylor > Cc: Timothy Hume; cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] Storing multiple NWP model runs in a > NetCDF - CF file [SEC=UNCLASSIFIED] > > Hi Karl, Tim: > > I think the original wording doesnt fully anticipate multiple > datetime coordinates: > > Section 4.4: > " A time coordinate is identifiable from its units string alone. The > Udunits routines utScan() and utIsTime() can be used to make this > determination. Optionally, the time coordinate may be indicated > additionally by providing the standard_name attribute with an > appropriate value, and/or the axis attribute with the value T. " > > In Tim's example, his "forecast/valid time" is actually an offset > from the base time, in units of time, not a udunit datetime. This > allows it to be a 1D coordinate variable. But in the general case, > if the forecast time spacing depends on the basetime, it must be 2D. > We see this a lot in NCEP model output. > > In general, when storing multiple forecast model runs in the same > file there are two options: > > 1. A 1D "basetime/runtime" coordinate variable identified by > standard name "forecast_reference_time" which holds udunit > datetimes, and a 2D "forecast/valid time" auxiliary coordinate > variable with standard name "time" which also holds udunit > datetimes. It must be dimensioned by the runtime and the time > dimensions. Data variables will need to use the "coordinates" > attribute to reference the time auxiliary coordinate, as usual. > > 2. A 1D "basetime/runtime" coordinate variable identified by > standard name "forecast_reference_time" which holds udunit dates, > and a 1D or 2D "forecast offset time" auxiliary coordinate variable > identified by standard name "forecast_period" which holds a udunit > time unit (eg hours), which is added to the basetime to get the > forecast datetime. If 1D, it will be dimensioned by time, if 2d it > will be dimensioned by runtime and time, and must be referenced by > the "coordinates" attribute > > As an aside, the utIsTime() function is ambiguous as to whether we > have a time unit or a datetime unit (which udunits calls "having an > offset"). I think we need to carefully distinguish time and > datetime, and specify where each is allowed. > > If this seems reasonable, I can write up a proposal. > > > Karl Taylor wrote: >> Hi Tim, >> >> Section 4.4 (just before section 4.1) states "The methods of >> identifying >> coordinate types described in this section apply both to coordinate >> variables and to auxiliary coordinate variables named by the >> coordinates >> attribute." Since the axis attribute is one of the methods used to >> identify a vertical coordinate, it would seem to be allowed for the >> level in your file. >> >> On the other hand, in the 4th paragraph of section 5.7, it says that >> "The axis attribute is not allowed for auxiliary coordinate >> variables". >> This seems to contradict the earlier statement. >> >> We need to revise the document to be internally consistent. Does >> anyone >> recall why we would want to prohibit the use of the axis attribute >> for >> auxiliary coordinate variables? >> >> cheers, >> Karl >> >> Timothy Hume wrote: >>> Hi Karl, >>> >>> I have just checked one of my files, and get two errors: >>> >>> The first error is: >>> >>> ------------------ >>> Checking variable: forecast >>> ------------------ >>> ERROR (4.4): Invalid units and/or reference time >>> >>> This is the error I am aware of. My file should become compliant >>> if I >>> switch the "T" axis to basetime. >>> >>> >>> The second error is: >>> >>> ------------------ >>> Checking variable: level >>> ------------------ >>> ERROR (4): Axis attribute is not allowed for auxillary coordinate >>> variables. >>> >>> I was unaware that the axis attribute should not be used for scalar >>> coordinate variables (as describe in Section 5.7). Is this intended? >>> In any case, I don't think this small error should cause the NetCDF >>> viewers I tried (IDV and Joe Sirott's web application) to not work. >>> >>> Cheers, >>> >>> Tim. >>> >>> -----Original Message----- >>> From: Karl Taylor [mailto:taylor13 at llnl.gov] Sent: Thursday, 8 >>> January >>> 2009 11:03 >>> To: Timothy Hume >>> Cc: cf-metadata at cgd.ucar.edu >>> Subject: Re: [CF-metadata] Storing multiple NWP model runs in a >>> NetCDF >>> - CF file [SEC=UNCLASSIFIED] >>> >>> Hi Tim, >>> >>> Other than the axis attribute for time, I didn't see any issues. >>> You >>> might run the CF compliance checker on the file (http:// >>> cf-pcmdi.llnl.gov/conformance), but it might not run if the other >>> utilities stumbled. Maybe someone else has some ideas. >>> >>> cheers, >>> Karl >>> >>> >>> Timothy Hume wrote: >>>> Hi, >>>> >>>> I am writing NetCDF files which hold surface fields (2m temperature >>>> etc) from multiple NWP model runs (all the runs from the same model >>>> for the last month or so). The files are for operational use, so I >>>> want them to strictly follow the CF conventions. I am running >>>> into a >>>> couple of problems, where the conventions don't seem to be ideally >>>> suited for storing more than a single model run. >>>> >>>> Here is what I do: >>>> >>>> I have four dimensions and associated coordinate variables: >>>> >>>> basetime: The base time for the model run (units: seconds since >>>> 1970-01-01 00:00:00.0 +0:00) >>>> forecast: The forecast lead time, relative to the basetime >>>> (units: >>>> hours) >>>> latitude >>>> longitude >>>> >>>> There is no need for a vertical dimension, because I am using >>>> surface >>>> fields. Never-the-less I make use of a scalar vertical coordinate >>>> variable as described in Section 5.7 of the CF-1.3 metadata >>>> conventions document. >>>> >>>> The use of two dimensions to store the time information (basetime >>>> and >>>> forecast) seems to be a natural way to store multiple NWP model >>>> runs, >>>> and is the standard way used in the very old NUWG conventions. As >>>> far >>>> as I can tell, what I am doing is supported by the CF conventions, >>>> provided the time axis is taken to be the basetime dimension. >>>> This is >>>> because Section 4.4 of the conventions specifies the units of the >>>> time coordinate must include a reference time. Obviously the >>>> units of >>>> the forecast coordinate cannot include a reference time, because >>>> the >>>> reference time varies, and is determined by the value of the >>>> basetime >>>> coordinate. >>>> >>>> The difficulty I am encountering is that some applications which >>>> read >>>> NetCDF/CF files (such as the Unidata IDV and Joe Sirott's very nice >>>> web based NetCDF data viewer) seem to choke on my data. I suspect >>>> (but am not 100% certain in the case of the IDV) that the reason is >>>> because of the way I handle the time information in my files. >>>> >>>> To illustrate in more detail what my files look like, I am >>>> attaching >>>> the CDL from an example file. The CDL is non-CF compliant, >>>> because I >>>> have specified the "T" axis (via the axis variable attribute) to be >>>> the forecast coordinate, and the forecast coordinate has invalid >>>> units (no reference time). I am planning on switching the "T" >>>> axis to >>>> the base time coordinate, which as far as I can determine should >>>> make >>>> the file CF compliant. >>>> >>>> My question is: is there a better (or more standard) way of storing >>>> multiple NWP model runs in a single file than what I am doing? >>>> Cheers, >>>> >>>> Tim Hume >>>> Centre for Australian Weather and Climate Research >>>> Australian Bureau of Meteorology >>>> Melbourne >>>> Australia >>>> >>>> --- Example CDL follows --- >>>> >>>> netcdf gasp_1p0deg_ocf_t2m_rtdb_opn { >>>> dimensions: >>>> forecast = 69 ; >>>> basetime = UNLIMITED ; // (100 currently) >>>> latitude = 96 ; >>>> longitude = 121 ; >>>> bounds = 2 ; >>>> variables: >>>> double forecast(forecast) ; >>>> forecast:long_name = "Time of model forecast, relative to >>>> the >>>> basetime" ; >>>> forecast:units = "hours" ; >>>> forecast:standard_name = "forecast_period" ; >>>> forecast:axis = "T" ; >>>> forecast:bounds = "forecast_bounds" ; >>>> double forecast_bounds(forecast, bounds) ; >>>> forecast_bounds:long_name = "forecast interval" ; >>>> forecast_bounds:units = "hours" ; >>>> int basetime(basetime) ; >>>> basetime:long_name = "Model basetime" ; >>>> basetime:units = "seconds since 1970-01-01 00:00:00.0 >>>> +0:00" ; >>>> basetime:calendar = "gregorian" ; >>>> basetime:standard_name = "forecast_reference_time" ; >>>> double latitude(latitude) ; >>>> latitude:long_name = "latitude" ; >>>> latitude:units = "degrees_north" ; >>>> latitude:bounds = "latitude_bounds" ; >>>> latitude:valid_min = -90. ; >>>> latitude:valid_max = 90. ; >>>> latitude:standard_name = "latitude" ; >>>> latitude:axis = "Y" ; >>>> double latitude_bounds(latitude, bounds) ; >>>> latitude_bounds:long_name = "grid cell latitude >>>> boundaries" ; >>>> latitude_bounds:units = "degrees_north" ; >>>> latitude_bounds:valid_min = -90. ; >>>> latitude_bounds:valid_max = 90. ; >>>> double longitude(longitude) ; >>>> longitude:long_name = "longitude" ; >>>> longitude:units = "degrees_east" ; >>>> longitude:bounds = "longitude_bounds" ; >>>> longitude:valid_min = -360. ; >>>> longitude:valid_max = 360. ; >>>> longitude:standard_name = "longitude" ; >>>> longitude:axis = "X" ; >>>> double longitude_bounds(longitude, bounds) ; >>>> longitude_bounds:long_name = "grid cell longitude >>>> boundaries" ; >>>> longitude_bounds:units = "degrees_east" ; >>>> longitude_bounds:valid_min = -360. ; >>>> longitude_bounds:valid_max = 360. ; >>>> float temperature_2m(basetime, forecast, latitude, longitude) ; >>>> temperature_2m:long_name = "Air temperature 2m above the >>>> surface" ; >>>> temperature_2m:units = "K" ; >>>> temperature_2m:_FillValue = 9.96921e+36f ; >>>> temperature_2m:missing_value = 9.96921e+36f ; >>>> temperature_2m:valid_min = 180.f ; >>>> temperature_2m:valid_max = 330.f ; >>>> temperature_2m:standard_name = "air_temperature" ; >>>> temperature_2m:cell_methods = "lat: lon: mean (area >>>> weighted)" ; >>>> temperature_2m:coordinates = "level" ; >>>> double level ; >>>> level:long_name = "Height above the surface" ; >>>> level:units = "m" ; >>>> level:positive = "up" ; >>>> level:standard_name = "height" ; >>>> level:axis = "Z" ; >>>> >>>> // global attributes: >>>> :Conventions = "CF-1.3" ; >>>> :history = "File created by the Gridded OCF data ingest >>>> system" ; >>>> :institution = "Australian Bureau of Meteorology" ; >>>> :source = "model" ; >>>> :title = "GASP forecasts of temperature_2m; resolution: 1.0 >>>> degree; source: rtdb" ; >>>> :topography = "MSAS" ; >>>> } >>>> _______________________________________________ >>>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From T.Hume at bom.gov.au Thu Jan 8 15:53:51 2009 From: T.Hume at bom.gov.au (Timothy Hume) Date: Fri, 9 Jan 2009 09:53:51 +1100 Subject: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CFfile [SEC=UNCLASSIFIED] In-Reply-To: <20090108085050.GB24620@met.reading.ac.uk> Message-ID: Hi Jonathan, I think that your case (iv) is what I am dealing with. For NWP applications I think cases (i) and (iv) will be most common. Case (i) applies to a single NWP run with multiple lead times, case (iv) applies to multiple NWP runs, each run having multiple (but fixed) lead times. As it happens, my files (equivalent to your case (iv)?) now pass the CF 1.3 compliance checker with no errors, provided the "T" axis is assigned to the basetime (equivalent to analysis or reference time) coordinate. I think for developers it is also convenient to have examples (e.g. CDLs) illustrating how each case would be implemented in practise ... multiple analysis times, validity times and lead times can quickly get confusing. Tim -----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, 8 January 2009 19:51 To: cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CFfile [SEC=UNCLASSIFIED] Dear all I think we excluded the axis attribute from auxiliary coords because it is intended for the 1D coord variables. However we didn't allow for the special case of a scalar coord variable, which is really equivalent to a size-1 1D coord variable. I agree with Karl that scalar coord variables should be allowed to have the axis attribute. There is a summary of previous discussions of 2D time coordinates at http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2006/001008.html - itself now 2.5 years ago! It would be good to state some more explicit recommendations in the standard. How does that summary compare with what John and Tim have in mind now? Best wishes Jonathan _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From T.Hume at bom.gov.au Thu Jan 8 16:09:34 2009 From: T.Hume at bom.gov.au (Timothy Hume) Date: Fri, 9 Jan 2009 10:09:34 +1100 Subject: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CFfile [SEC=UNCLASSIFIED] In-Reply-To: <6355F73B-DC99-4FF7-98F2-4A1AC950D8DD@ucar.edu> Message-ID: Hi Doug, How do you handle requests for "all the data from a particular model run", or "all the 24 hour forecasts from all runs"? I notice that your reftime and leadtime variables have repeated values, which can make it more difficult to do such commonly requested extractions. This is why I chose to use two dimensions. For example, if someone requests all the 24->72 hour forecasts from all the model runs between 00Z 1 January 2009 and 00Z 5 January 2009 I use the NetCDF operator "ncks" like this: ncks -d basetime,"2009-01-01 00:00:00".,"2009-01-05 00:00:00". -d forecast,24.,72. bigfile.nc subset.nc Is there an easy way to do such extractions using your format? Cheers, Tim. ________________________________ From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Douglas Schuster Sent: Friday, 9 January 2009 00:41 To: Timothy Hume Cc: John Caron; cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CFfile [SEC=UNCLASSIFIED] Hi Tim, John, NCAR has been using a structure similar to option 2 for TIGGE based NetCDF files that is not technically CF compliant, but was reviewed by colleagues at ECMWF, UK MetOffice, and BADC (Dec 10, 2007, ECMWF workshop) and deemed acceptable. The structure is designed to handle multiple ensemble forecast systems, and multiple init times with varying forecast periods. i.e. int reftime(reftime) ; reftime:data_type = "int" ; reftime:units = "hours since 1950-01-01 00:00:00" ; reftime:standard_name = "forecast_reference_time" ; reftime:long_name = "Time of model initialization" ; int leadtime(reftime) ; leadtime:data_type = "int" ; leadtime:units = "hours" ; leadtime:standard_name = "forecast_period" ; leadtime:long_name = "Hours since forecast_reference_time" ; The structure was based on the proposal by Francisco J. Doblas-Reyes for the "Ensembles" project. A thread related to this proposal can be found at: http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2007/001470.html A sample file is available for download at: http://dss.ucar.edu/download/doug/data.nc The metadata "CDL" dump of the file can be accessed at: http://dss.ucar.edu/download/doug/data.dump Doug On Jan 7, 2009, at 7:19 PM, Timothy Hume wrote: Hi John, This seems a reasonable proposal to me. Often when storing NWP forecasts option (2) will suffice. Most centres will always include the same forecast lead times each time new NWP model data are disseminated (for example some centres will send out +6, +12, +18, +24, +36, +42, +48, +60 and +72 hour forecasts for two model runs per day, ever day). Data users will then often want to extract particular forecast lead times (e.g. +48 hours). Option (2) makes this a trivial task. On the other hand option (1) is also useful, even when the time offsets are fixed. For example, one can construct an auxilliary coordinate variable called valid_time which is two dimensional. This aids in the cases when the user wants to extract all forecasts which are valid at a particular time. In fact, using both options (1) and (2) often yields the most useful files. Tim. -----Original Message----- From: John Caron [mailto:caron at unidata.ucar.edu] Sent: Thursday, 8 January 2009 12:56 To: Karl Taylor Cc: Timothy Hume; cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] Hi Karl, Tim: I think the original wording doesnt fully anticipate multiple datetime coordinates: Section 4.4: " A time coordinate is identifiable from its units string alone. The Udunits routines utScan() and utIsTime() can be used to make this determination. Optionally, the time coordinate may be indicated additionally by providing the standard_name attribute with an appropriate value, and/or the axis attribute with the value T. " In Tim's example, his "forecast/valid time" is actually an offset from the base time, in units of time, not a udunit datetime. This allows it to be a 1D coordinate variable. But in the general case, if the forecast time spacing depends on the basetime, it must be 2D. We see this a lot in NCEP model output. In general, when storing multiple forecast model runs in the same file there are two options: 1. A 1D "basetime/runtime" coordinate variable identified by standard name "forecast_reference_time" which holds udunit datetimes, and a 2D "forecast/valid time" auxiliary coordinate variable with standard name "time" which also holds udunit datetimes. It must be dimensioned by the runtime and the time dimensions. Data variables will need to use the "coordinates" attribute to reference the time auxiliary coordinate, as usual. 2. A 1D "basetime/runtime" coordinate variable identified by standard name "forecast_reference_time" which holds udunit dates, and a 1D or 2D "forecast offset time" auxiliary coordinate variable identified by standard name "forecast_period" which holds a udunit time unit (eg hours), which is added to the basetime to get the forecast datetime. If 1D, it will be dimensioned by time, if 2d it will be dimensioned by runtime and time, and must be referenced by the "coordinates" attribute As an aside, the utIsTime() function is ambiguous as to whether we have a time unit or a datetime unit (which udunits calls "having an offset"). I think we need to carefully distinguish time and datetime, and specify where each is allowed. If this seems reasonable, I can write up a proposal. Karl Taylor wrote: Hi Tim, Section 4.4 (just before section 4.1) states "The methods of identifying coordinate types described in this section apply both to coordinate variables and to auxiliary coordinate variables named by the coordinates attribute." Since the axis attribute is one of the methods used to identify a vertical coordinate, it would seem to be allowed for the level in your file. On the other hand, in the 4th paragraph of section 5.7, it says that "The axis attribute is not allowed for auxiliary coordinate variables". This seems to contradict the earlier statement. We need to revise the document to be internally consistent. Does anyone recall why we would want to prohibit the use of the axis attribute for auxiliary coordinate variables? cheers, Karl Timothy Hume wrote: Hi Karl, I have just checked one of my files, and get two errors: The first error is: ------------------ Checking variable: forecast ------------------ ERROR (4.4): Invalid units and/or reference time This is the error I am aware of. My file should become compliant if I switch the "T" axis to basetime. The second error is: ------------------ Checking variable: level ------------------ ERROR (4): Axis attribute is not allowed for auxillary coordinate variables. I was unaware that the axis attribute should not be used for scalar coordinate variables (as describe in Section 5.7). Is this intended? In any case, I don't think this small error should cause the NetCDF viewers I tried (IDV and Joe Sirott's web application) to not work. Cheers, Tim. -----Original Message----- From: Karl Taylor [mailto:taylor13 at llnl.gov] Sent: Thursday, 8 January 2009 11:03 To: Timothy Hume Cc: cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] Hi Tim, Other than the axis attribute for time, I didn't see any issues. You might run the CF compliance checker on the file (http:// cf-pcmdi.llnl.gov/conformance), but it might not run if the other utilities stumbled. Maybe someone else has some ideas. cheers, Karl Timothy Hume wrote: Hi, I am writing NetCDF files which hold surface fields (2m temperature etc) from multiple NWP model runs (all the runs from the same model for the last month or so). The files are for operational use, so I want them to strictly follow the CF conventions. I am running into a couple of problems, where the conventions don't seem to be ideally suited for storing more than a single model run. Here is what I do: I have four dimensions and associated coordinate variables: basetime: The base time for the model run (units: seconds since 1970-01-01 00:00:00.0 +0:00) forecast: The forecast lead time, relative to the basetime (units: hours) latitude longitude There is no need for a vertical dimension, because I am using surface fields. Never-the-less I make use of a scalar vertical coordinate variable as described in Section 5.7 of the CF-1.3 metadata conventions document. The use of two dimensions to store the time information (basetime and forecast) seems to be a natural way to store multiple NWP model runs, and is the standard way used in the very old NUWG conventions. As far as I can tell, what I am doing is supported by the CF conventions, provided the time axis is taken to be the basetime dimension. This is because Section 4.4 of the conventions specifies the units of the time coordinate must include a reference time. Obviously the units of the forecast coordinate cannot include a reference time, because the reference time varies, and is determined by the value of the basetime coordinate. The difficulty I am encountering is that some applications which read NetCDF/CF files (such as the Unidata IDV and Joe Sirott's very nice web based NetCDF data viewer) seem to choke on my data. I suspect (but am not 100% certain in the case of the IDV) that the reason is because of the way I handle the time information in my files. To illustrate in more detail what my files look like, I am attaching the CDL from an example file. The CDL is non-CF compliant, because I have specified the "T" axis (via the axis variable attribute) to be the forecast coordinate, and the forecast coordinate has invalid units (no reference time). I am planning on switching the "T" axis to the base time coordinate, which as far as I can determine should make the file CF compliant. My question is: is there a better (or more standard) way of storing multiple NWP model runs in a single file than what I am doing? Cheers, Tim Hume Centre for Australian Weather and Climate Research Australian Bureau of Meteorology Melbourne Australia --- Example CDL follows --- netcdf gasp_1p0deg_ocf_t2m_rtdb_opn { dimensions: forecast = 69 ; basetime = UNLIMITED ; // (100 currently) latitude = 96 ; longitude = 121 ; bounds = 2 ; variables: double forecast(forecast) ; forecast:long_name = "Time of model forecast, relative to the basetime" ; forecast:units = "hours" ; forecast:standard_name = "forecast_period" ; forecast:axis = "T" ; forecast:bounds = "forecast_bounds" ; double forecast_bounds(forecast, bounds) ; forecast_bounds:long_name = "forecast interval" ; forecast_bounds:units = "hours" ; int basetime(basetime) ; basetime:long_name = "Model basetime" ; basetime:units = "seconds since 1970-01-01 00:00:00.0 +0:00" ; basetime:calendar = "gregorian" ; basetime:standard_name = "forecast_reference_time" ; double latitude(latitude) ; latitude:long_name = "latitude" ; latitude:units = "degrees_north" ; latitude:bounds = "latitude_bounds" ; latitude:valid_min = -90. ; latitude:valid_max = 90. ; latitude:standard_name = "latitude" ; latitude:axis = "Y" ; double latitude_bounds(latitude, bounds) ; latitude_bounds:long_name = "grid cell latitude boundaries" ; latitude_bounds:units = "degrees_north" ; latitude_bounds:valid_min = -90. ; latitude_bounds:valid_max = 90. ; double longitude(longitude) ; longitude:long_name = "longitude" ; longitude:units = "degrees_east" ; longitude:bounds = "longitude_bounds" ; longitude:valid_min = -360. ; longitude:valid_max = 360. ; longitude:standard_name = "longitude" ; longitude:axis = "X" ; double longitude_bounds(longitude, bounds) ; longitude_bounds:long_name = "grid cell longitude boundaries" ; longitude_bounds:units = "degrees_east" ; longitude_bounds:valid_min = -360. ; longitude_bounds:valid_max = 360. ; float temperature_2m(basetime, forecast, latitude, longitude) ; temperature_2m:long_name = "Air temperature 2m above the surface" ; temperature_2m:units = "K" ; temperature_2m:_FillValue = 9.96921e+36f ; temperature_2m:missing_value = 9.96921e+36f ; temperature_2m:valid_min = 180.f ; temperature_2m:valid_max = 330.f ; temperature_2m:standard_name = "air_temperature" ; temperature_2m:cell_methods = "lat: lon: mean (area weighted)" ; temperature_2m:coordinates = "level" ; double level ; level:long_name = "Height above the surface" ; level:units = "m" ; level:positive = "up" ; level:standard_name = "height" ; level:axis = "Z" ; // global attributes: :Conventions = "CF-1.3" ; :history = "File created by the Gridded OCF data ingest system" ; :institution = "Australian Bureau of Meteorology" ; :source = "model" ; :title = "GASP forecasts of temperature_2m; resolution: 1.0 degree; source: rtdb" ; :topography = "MSAS" ; } _______________________________________________ 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 Fri Jan 9 01:34:41 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 9 Jan 2009 08:34:41 +0000 Subject: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CFfile [SEC=UNCLASSIFIED] Message-ID: <20090109083441.GC29793@met.reading.ac.uk> Dear Tim So for the case of multiple analysis and forecast times, where all combinations exist, you have two multivalued time dimensions, one for forecast reference time (= base time, analysis time, initialisation time) and one for forecast period (lead time). The former has units of "UNITS since TIME" and the latter is a plain time-unit. Is that right? In http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2006/001008.html we proposed instead to deal with this 2D case by introducing an index dimension and collapsing it into 1D, with the forecast reference time and the forecast period being 1D auxiliary coord vars. That obscures the 2D structure, which is a loss. The reason for proposing it was that it reduced the number of different structures that would have to be used. The 2D structure can only be used if all 2D combinations exist. In http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2007/001470.html, the method that Doug uses, 2D is also collapsed into 1D, but instead of introducing a plain index dimension, the 1D coordinate is validity time (forecast reference time + forecast period). That is a better idea, I think, because it's a useful coordinate variable rather than just an index. Again forecast reference time and forecast period are 1D auxiliary coord vars. I agree that the CF standard should have examples for each of the recommended structures. That would need a proposal on trac and maybe John was offering to make one. What do you think about using Doug's/Paco's collapse of 2D into 1D? To get all the 24-h forecasts, for instance, you'd have to search the 1D auxiliary coord var of forecast period and use it to select particular indices of the time dimension. That is a bit more awkward, but the structure has an advantage in generality. Best wishes Jonathan From alison.pamment at stfc.ac.uk Fri Jan 9 06:56:37 2009 From: alison.pamment at stfc.ac.uk (Pamment, JA (Alison)) Date: Fri, 9 Jan 2009 13:56:37 -0000 Subject: [CF-metadata] new named fields for ocean Message-ID: Dear Stephen, Please see below for my responses to all the standard names you proposed in your document http://www.clivar.org/organization/wgomd/wgomd_publications.php. I think you will see that for the most part I am happy to accept the names as proposed, but I have made a few suggestions for slight modifications to some of the names. I am aware that you want to finalise the names for CMIP5 soon and I hope these responses will assist you in doing so. For the purpose of commenting on individual names I have labelled your proposals as X.Y where X is your table number and Y is the number of the entry in the table. Where a name in one of your tables is already in the CF standard name table I have (except in one or two cases) not included a comment. Table 1. 1.1 equation of state - This would need underscores instead of spaces, thus: equation_of_state. 1.2 seawater freezing temp - As in 1.1, underscores need to be added. 'seawater' is divided into two words in existing standard names, also 'temp' should be expanded to say 'temperature'. I think that the name sea_water_freezing_temperature sounds as though one might expect to find actual temperature values in the varaiable and I wonder if it might be better to call it sea_water_freezing_temperature_formula. What do others think? Presumably both of these quantities are described by formulae which will differ between models. Your table says that the actual formulae will consist of Fortran code. Is the idea that these 'data' will be placed in a character variable something like the following? dimensions: nlines = 1 ; // no. of lines of FORTRAN code supplied maxlen = 80 ; // max string length used to supply FORTRAN code variables: char swft(nlines,maxlen) ; swft:standard_name = "sea_water_freezing_temperature_formula" ; swft:canonical_units = "1" ; data: swft = "TF = -0.0575*S + 0.001710523*SQRT(S**3) - 0.0002154996*S**2 - 0.00753*p" ; If this is what you intend, then I think the canonical_units in the standard name table should be '1', i.e. dimensionless and the definition of the standard name would explain that the contents are strings. This is our usual practice for string valued variables. 1.3 reference_sea_water_density_for_boussinesq_approximation - OK. 1.5 grid specification (lengths, areas) with units of m and m2. I assume here that you are thinking of names such as grid_length and grid_area? We already have a name cell_area with units of m2, defined as the horizontal area of a gridcell, which sounds like it is probably the quantity you need. Currently we don't have standard names for other grid metrics, but area and volume can be recorded in the cell_measures attribute (see Section 7.2 of the CF Conventions). Regarding grid_length, I think this is something that would usually be calculated from the cell boundaries given in a bounds variable. See also my comments on proposal 2.11 cell_thickness. 1.6 region. Although your table indicates that this quantity is new to CMIP5, we do already have a CF standard name of "region". It is a CF recommendation that, where possible, variables having this standard name take their values from the standardized list of region names at http://www.cfconventions.org/documents/cf-standard-names/standardized-re gion-names. Table 2. 2.1 sea_water_mass; kg - OK. 2.2 sea_water_pressure_at_sea_floor; Pa - The name is fine. I note that we already have the name sea_water_pressure in the standard name table and that this quantity has a canonical_unit of dbar. Clearly the units can be converted, but I think that we should aim for consistent canonical_units for these two names. Does it make more sense to use dbar or Pa? 2.3 sea_water_pressure_at_sea_water_surface; Pa. I appreciate that this is a different quantity to surface_air_pressure and therefore we need a new name. However, do we need to say sea_water_surface or would it suffice to say surface_sea_water_pressure? ('Surface' is defined in standard names to mean the lower boundary of the atmosphere which therefore would also be the upper boundary of the ocean). 2.4 sea_water_volume; m3 - OK. 2.6 square_of_sea_surface_height_above_geoid; m2. OK. 2.8 global_average_steric_sea_level_change; m. OK. We already have the names global_average_sea_level_change and global_average_thermosteric_sea_level_change and this new proposal is consistent. Am I correct in thinking that steric sea level change is the sum of thermosteric and halosteric contributions to changes in sea water density? 2.10 cell_mass_per_area; kg m-2. Does this mean the mass per unit area of the sea water contained within each grid cell? If so, I suggest the name should be mass_of_sea_water_per_unit_area which would be similar to the existing name atmosphere_mass_of_air_per_unit_area. 2.11 cell_thickness; m. See also my comments on proposal 1.5 "grid specification". Cell_thickness would usually be calculated from the bounds on the vertical coordinate variable. Names such as cell_length and cell_thickness have been discussed on the mailing list in the past and have received equivocal support. See, for example, the conversation we had in 2006 on cell_metrics in http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2006/001068.html and following messages. I note that both Ian Culverwell and Jonathan seem to support the idea of introducing cell_thickness as a new quantity in the cell_measure attribute. I too think that would be a sensible approach rather than introducing it as a new standard name. This will require a proposal for a small modification to the CF conventions which needs to be opened as a new ticket on the CF trac system. I will submit a proposal to the trac system to take this forward as there is clearly a demand for somewhere convenient to access this type of grid metric information. 2.13 sea_surface_temperature; K. This quantity is already in the standard name table. For information, I would like to point out that we have recently introduced the following standard names for related quantities: sea_surface_skin_temperature, sea_surface_subskin_temperature, sea_surface_foundation_temperature. I am drawing attention to the existence of these names in case they are relevant to the CMIP5 work. 2.14 square_of_sea_surface_temperature; K2. OK. 2.17 sea_water_age_since_surface_contact; year. The name sounds fine. I think the canonical_units in the standard name table should probably be seconds, rather than years because of the way UDunits defines a year. For more information on this please see Section 4.4 of the CF Conventions. 2.18 moles_of_cfc11_per_unit_mass_in_sea_water; mol kg-1. I would slightly re-order this name to read moles_per_unit_mass_of_cfc11_in_sea_water so that its syntax is more consistent with existing mole_fraction and mole_concentration standard names. I think moles_per_unit_mass with units of mol kg-1 is fine. 'mole_fraction' implies units of mol mol-1 (i.e. dimensionless) and 'mole_concentration' means the units are mol m-3 so we clearly need a new description for your units. 2.19 ocean_barotropic_mass_streamfunction; kg s-1. OK. 2.21 square_of_ocean_mixed_layer_thickness_defined_by_sigma_t; m2. OK. 2.22 ocean_mixed_layer_thickness_defined_by_mixing_scheme; m. I would understand this to mean the depth of the mixed layer as calculated by a model's own mixing scheme - is that correct? I think the name is OK. Table 3. 3.3 upward_ocean_mass_transport; kg s-1. OK. We already have a number of ocean salt and heat transport names in the table. I assume the mass referred to in this name is that of the sea water including salt. Correct? 3.4 square_of_upward_ocean_mass_transport; kg2 s-2. OK. 3.5 ocean_mass_x_transport; kg s-1 and 3.6 ocean_mass_y_transport; kg s-1. These are consistent with the existing x and y velocity names. OK. 3.7 ocean_meridional_overturning_mass_streamfunction; kg s-1. The name is OK. The description of the existing standard name ocean_meridional_overturning_streamfunction says "The ocean meridional overturning streamfunction should not include not include "bolus" or Gent-McWilliams velocity." Presumably the mass streamfunction is defined in an analogous way? 3.8 ocean_y_overturning_mass_streamfunction; kg s-1. OK. Presumably this also excludes bolus and Gent-McWilliams contributions? 3.9 ocean_meridional_overturning_mass_streamfunction_due_to_bolus_advection; kg s-1. OK. 3.10 ocean_y_overturning_mass_streamfunction_due_to_bolus_advection; kg s-1. OK. 3.14 ocean_heat_x_transport; W and 3.15 ocean_heat_y_transport; W. Both OK. 3.16 ocean_heat_x_transport_due_to_bolus_advection; W and 3.18 ocean_heat_y_transport_due_to_bolus_advection; W. Both OK. 3.17 ocean_heat_x_transport_due_to_diffusion; W and 3.19 ocean_heat_y_transport_due_to_diffusion; W. Both OK. Table 4. As I mentioned earlier, CF does have a defined set of standardized region names whose use is described in Section 6.1 of the conventions document. The region names are not, however, standard names in their own right and do not appear in the standard name table. Similarly, your region names would not need to become CF standard names. I note that you have defined the extent of your named areas and it may be possible to add them to the standardized list at a later date. Table 5. The majority of names in table 5 are already in the standard name table. Only two are new proposals. 5.5 water_flux_into_sea_water_from_icebergs; kg m-2 s-1. OK. 5.6 water_flux_into_sea_water_due_to_sea_ice_thermodynamics; kg m-2 s-1. We have recently introduced the standard name water_flux_out_of_sea_water_due_to_sea_ice_thermodynamics which has the opposite sign convention to your name. However, I see no problem in also introducing your name as its meaning is clear and we do already have a similar pair of names: water_flux_into_sea_water and water_flux_out_of_sea_water. OK. Table 6. 6.1 virtual_salt_flux_into_sea_water_due_to_rainfall; kg m-2 s-1. OK. 6.2 virtual_salt_flux_into_sea_water_due_to_evaporation; kg m-2 s-1. OK. 6.3 virtual_salt_flux_into_sea_water_due_to_rivers; kg m-2 s-1. I suggest that we amend this name slightly to read virtual_salt_flux_into_sea_water_from_rivers because in standard names we reserve the phrase 'due to' to refer to a physical process as in the previous two names, for example. 'from_rivers' is also more consistent with the water flux names. 6.4 virtual_salt_flux_into_sea_water_due_to_sea_ice_thermodynamics; kg m-2 s-1. OK. 6.6 virtual_salt_flux_correction; kg m-2 s-1. OK. 6.8 salt_flux_from_rivers_into_sea_water; kg m-2 s-1. I suggest that this name should be re-ordered to read salt_flux_into_sea_water_from_rivers for consistency with the water flux names. Table 7. 7.1 upward_geothermal_heat_flux_at_sea_floor; W m-2. OK 7.2 rainfall_temperature_flux_expressed_as_heat_flux; W m-2. 7.3 evaporation_temperature_flux_expressed_as_heat_flux; W m-2. 7.4 temperature_flux_into_sea_water_from_runoff_expressed_as_heat_flux; W m-2. I have thought hard about these three names because initially I wasn't very keen on the use of 'temperature flux' but having studied the definitions in section 4.5.3 of your document I can see what you mean and I can't think of an obvious improvement. To make the three names more consistent with one another and with existing names I would suggest a slight rewording as follows: 7.2 temperature_flux_due_to_rainfall_expressed_as_heat_flux_into_sea_water; W m-2; 7.3 temperature_flux_due_to_evaporation_expressed_as_heat_flux_out_of_sea_wa ter; W m-2; 7.4 temperature_flux_due_to_runoff_expressed_as_heat_flux_into_sea_water; W m-2. These are a bit longer than the original proposals but they all now follow the same pattern and it is clear in which direction the flux is positive. 7.5 heat_flux_into_sea_water_due_to_sea_ice_thermodynamics; W m-2. OK. 7.6 heat_flux_into_sea_water_due_to_icebergs; W m-2. Is this quantity analogous to 7.5, i.e. would it be better to say heat_flux_into_sea_water_due_to_iceberg_thermodynamics? 7.11 downwelling_shortwave_flux_in_sea_water; W m-2. OK. Table 8. Please note that the canonical units for the quantities listed in table 8 would appear in the standard name table as Pascals, which is exactly equivalent to N m-2. 8.3 surface_downward_x_stress_correction; Pa and 8.4 surface_downward_y_stress_correction; Pa. Both OK. Table 9. 9.3 ocean_vertical_tracer_diffusivity_due_to_background; m2 s-1. OK. >From your document I understand 'due_to_background' to mean a static imposed field which may be either a constant value over the globe or spatially varying, depending on the model used. Is that the correct interpretation? 9.4 ocean_vertical_tracer_diffusivity_due_to_tides; m2 s-1. OK. 9.5 tendency_of_ocean_potential_energy_content; W m-2. OK. 9.6 tendency_of_ocean_potential_energy_content_due_to_tides; W m-2. OK. I am aware that distinctions can be made between a number of different ocean tides and indeed we have recently introduced standard names for sea surface heights due to various tidal components. Please could you supply a sentence or two that can be included in the definitions of 'due_to_tides' names so that it is clear which processes are included/excluded. 9.7 tendency_of_ocean_potential_energy_content_due_to_background; W m-2. OK. 9.9 ocean_vertical_momentum_diffusivity_due_to_background; m2 s-1. OK. 9.10 ocean_vertical_momentum_diffusivity_due_to_tides; m2 s-1. OK. 9.11 ocean_vertical_momentum_diffusivity_due_to_form_drag; m2 s-1. OK. 9.12 ocean_kinetic_energy_dissipation_per_unit_area_due_to_vertical_friction; W m-2. OK. Table 10. While I will not pretend to have a detailed understanding of ocean diffusivity parametrization schemes I can see that all these names are composed on a common pattern and using standard and well defined terms. I note that there was some discussion of whether to use 'laplacian' in the lateral diffusivities and that it was concluded that the term is acceptable in these names. Therefore I am happy to accept all the names in table 10 as proposed. 10.1 ocean_tracer_bolus_laplacian_diffusivity; m2 s-1. 10.2 ocean_tracer_bolus_biharmonic_diffusivity; m4 s-1. 10.3 ocean_tracer_epineutral_laplacian_diffusivity; m2 s-1. 10.4 ocean_tracer_epineutral_biharmonic_diffusivity; m4 s-1. 10.5 ocean_tracer_xy_laplacian_diffusivity; m2 s-1. 10.6 ocean_tracer_xy_biharmonic_diffusivity; m4 s-1. 10.7 tendency_of_ocean_eddy_kinetic_energy_content_due_to_bolus_transport; W m-2. 10.8 ocean_momentum_xy_laplacian_diffusivity; m2 s-1. 10.9 ocean_ momentum_xy_biharmonic_diffusivity; m4 s-1. 10.10 ocean_kinetic_energy_dissipation_per_unit_area_due_to_xy_friction; W m-2. Best wishes, Alison ==> Please note new email address: alison.pamment at stfc.ac.uk <== ------ J 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 schuster at ucar.edu Thu Jan 8 20:52:14 2009 From: schuster at ucar.edu (Doug Schuster) Date: Thu, 8 Jan 2009 20:52:14 -0700 Subject: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CFfile [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: <5D06E2FC-E1F2-471C-80CB-1D9F729AEDCC@ucar.edu> Tim, I'm not sure if there is an easy way to do such extractions using our format. The TIGGE file structure is designed to handle possible output from a GRIB2 to NetCDF converter. This leads to the potential for 5 dimensions (reftime,ensemble_member,level,lat,lon). With this structure, we wanted to limit time to one direct coordinate variable while allowing for the potential of multiple initialization times with varying forecast periods (similar to Jonathan's case V). The example I provided shows repeating forecast periods, but the structure allows for multiple init times and varying forecast periods. i.e. Reftime(1) = 20071012,12z; Leadtime(1)=24 Reftime(2) = 20071013, 00z; Leadtime(2)=12 Reftime(3) = 20071013, 00z; Leadtime(3)= 18 In your case where you are always building files from parameters based on single levels, from one forecast system and simulation type, and where forecast lead times are constant across all inits, it makes sense to use the 2 dimensional time solution. Cheers, Doug On Jan 8, 2009, at 4:09 PM, Timothy Hume wrote: > Hi Doug, > > How do you handle requests for "all the data from a particular model > run", or "all the 24 hour forecasts from all runs"? I notice that > your reftime and leadtime variables have repeated values, which can > make it more difficult to do such commonly requested extractions. > This is why I chose to use two dimensions. For example, if someone > requests all the 24->72 hour forecasts from all the model runs > between 00Z 1 January 2009 and 00Z 5 January 2009 I use the NetCDF > operator "ncks" like this: > > ncks -d basetime,"2009-01-01 00:00:00".,"2009-01-05 00:00:00". -d > forecast,24.,72. bigfile.nc subset.nc > > Is there an easy way to do such extractions using your format? > > Cheers, > > Tim. > > ________________________________ > > From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu > ] On Behalf Of Douglas Schuster > Sent: Friday, 9 January 2009 00:41 > To: Timothy Hume > Cc: John Caron; cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] Storing multiple NWP model runs in a > NetCDF - CFfile [SEC=UNCLASSIFIED] > > > Hi Tim, John, > > NCAR has been using a structure similar to option 2 for TIGGE based > NetCDF files that is not > technically CF compliant, but was reviewed by colleagues at ECMWF, > UK MetOffice, and BADC > (Dec 10, 2007, ECMWF workshop) and deemed acceptable. The structure > is designed to handle multiple > ensemble forecast systems, and multiple init times with varying > forecast periods. > > > i.e. > > int reftime(reftime) ; > reftime:data_type = "int" ; > reftime:units = "hours since 1950-01-01 00:00:00" ; > reftime:standard_name = "forecast_reference_time" ; > reftime:long_name = "Time of model initialization" ; > int leadtime(reftime) ; > leadtime:data_type = "int" ; > leadtime:units = "hours" ; > leadtime:standard_name = "forecast_period" ; > leadtime:long_name = "Hours since > forecast_reference_time" ; > > The structure was based on > the proposal by Francisco J. Doblas-Reyes for the "Ensembles" > project. A thread related to this proposal > can be found at: > > > http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2007/001470.html > > A sample file is available for download at: > > http://dss.ucar.edu/download/doug/data.nc > > The metadata "CDL" dump of the file can be accessed at: > > http://dss.ucar.edu/download/doug/data.dump > > Doug > > > On Jan 7, 2009, at 7:19 PM, Timothy Hume wrote: > > > Hi John, > > This seems a reasonable proposal to me. Often when storing NWP > forecasts option (2) will suffice. Most centres will always include > the same forecast lead times each time new NWP model data are > disseminated (for example some centres will send out +6, +12, +18, > +24, +36, +42, +48, +60 and +72 hour forecasts for two model runs > per day, ever day). Data users will then often want to extract > particular forecast lead times (e.g. +48 hours). Option (2) makes > this a trivial task. > > On the other hand option (1) is also useful, even when the time > offsets are fixed. For example, one can construct an auxilliary > coordinate variable called valid_time which is two dimensional. This > aids in the cases when the user wants to extract all forecasts which > are valid at a particular time. In fact, using both options (1) and > (2) often yields the most useful files. > > Tim. > > > -----Original Message----- > From: John Caron [mailto:caron at unidata.ucar.edu] > Sent: Thursday, 8 January 2009 12:56 > To: Karl Taylor > Cc: Timothy Hume; cf-metadata at cgd.ucar.edu > Subject: Re: [CF-metadata] Storing multiple NWP model runs in a > NetCDF - CF file [SEC=UNCLASSIFIED] > > Hi Karl, Tim: > > I think the original wording doesnt fully anticipate multiple > datetime coordinates: > > Section 4.4: > " A time coordinate is identifiable from its units string alone. > The Udunits routines utScan() and utIsTime() can be used to make > this determination. Optionally, the time coordinate may be indicated > additionally by providing the standard_name attribute with an > appropriate value, and/or the axis attribute with the value T. " > > In Tim's example, his "forecast/valid time" is actually an offset > from the base time, in units of time, not a udunit datetime. This > allows it to be a 1D coordinate variable. But in the general case, > if the forecast time spacing depends on the basetime, it must be 2D. > We see this a lot in NCEP model output. > > In general, when storing multiple forecast model runs in the same > file there are two options: > > 1. A 1D "basetime/runtime" coordinate variable identified by > standard name "forecast_reference_time" which holds udunit > datetimes, and a 2D "forecast/valid time" auxiliary coordinate > variable with standard name "time" which also holds udunit > datetimes. It must be dimensioned by the runtime and the time > dimensions. Data variables will need to use the "coordinates" > attribute to reference the time auxiliary coordinate, as usual. > > 2. A 1D "basetime/runtime" coordinate variable identified by > standard name "forecast_reference_time" which holds udunit dates, > and a 1D or 2D "forecast offset time" auxiliary coordinate variable > identified by standard name "forecast_period" which holds a udunit > time unit (eg hours), which is added to the basetime to get the > forecast datetime. If 1D, it will be dimensioned by time, if 2d it > will be dimensioned by runtime and time, and must be referenced by > the "coordinates" attribute > > As an aside, the utIsTime() function is ambiguous as to whether we > have a time unit or a datetime unit (which udunits calls "having an > offset"). I think we need to carefully distinguish time and > datetime, and specify where each is allowed. > > If this seems reasonable, I can write up a proposal. > > > Karl Taylor wrote: > > > Hi Tim, > > > > Section 4.4 (just before section 4.1) states "The methods of > identifying > > > coordinate types described in this section apply both to coordinate > > > variables and to auxiliary coordinate variables named by the > coordinates > > > attribute." Since the axis attribute is one of the methods used to > > > identify a vertical coordinate, it would seem to be allowed for the > > > level in your file. > > > > On the other hand, in the 4th paragraph of section 5.7, it says that > > > "The axis attribute is not allowed for auxiliary coordinate > variables". > > > This seems to contradict the earlier statement. > > > > We need to revise the document to be internally consistent. Does > anyone > > > recall why we would want to prohibit the use of the axis attribute > for > > > auxiliary coordinate variables? > > > > cheers, > > > Karl > > > > Timothy Hume wrote: > > > Hi Karl, > > > > I have just checked one of my files, and get two errors: > > > > The first error is: > > > > ------------------ > > > Checking variable: forecast > > > ------------------ > > > ERROR (4.4): Invalid units and/or reference time > > > > This is the error I am aware of. My file should become compliant > if I > > > switch the "T" axis to basetime. > > > > > The second error is: > > > > ------------------ > > > Checking variable: level > > > ------------------ > > > ERROR (4): Axis attribute is not allowed for auxillary coordinate > > > variables. > > > > I was unaware that the axis attribute should not be used for scalar > > > coordinate variables (as describe in Section 5.7). Is this > intended? > > > In any case, I don't think this small error should cause the NetCDF > > > viewers I tried (IDV and Joe Sirott's web application) to not work. > > > > Cheers, > > > > Tim. > > > > -----Original Message----- > > > From: Karl Taylor [mailto:taylor13 at llnl.gov] Sent: Thursday, 8 > January > > > 2009 11:03 > > > To: Timothy Hume > > > Cc: cf-metadata at cgd.ucar.edu > > > Subject: Re: [CF-metadata] Storing multiple NWP model runs in a > NetCDF > > > - CF file [SEC=UNCLASSIFIED] > > > > Hi Tim, > > > > Other than the axis attribute for time, I didn't see any issues. > You > > > might run the CF compliance checker on the file (http:// > > > cf-pcmdi.llnl.gov/conformance), but it might not run if the other > > > utilities stumbled. Maybe someone else has some ideas. > > > > cheers, > > > Karl > > > > > Timothy Hume wrote: > > > Hi, > > > > I am writing NetCDF files which hold surface fields (2m > temperature > > > etc) from multiple NWP model runs (all the runs from the same > model > > > for the last month or so). The files are for operational use, so I > > > want them to strictly follow the CF conventions. I am running > into a > > > couple of problems, where the conventions don't seem to be ideally > > > suited for storing more than a single model run. > > > > Here is what I do: > > > > I have four dimensions and associated coordinate variables: > > > > basetime: The base time for the model run (units: seconds since > > > 1970-01-01 00:00:00.0 +0:00) > > > forecast: The forecast lead time, relative to the basetime > (units: > > > hours) > > > latitude > > > longitude > > > > There is no need for a vertical dimension, because I am using > surface > > > fields. Never-the-less I make use of a scalar vertical coordinate > > > variable as described in Section 5.7 of the CF-1.3 metadata > > > conventions document. > > > > The use of two dimensions to store the time information > (basetime and > > > forecast) seems to be a natural way to store multiple NWP model > runs, > > > and is the standard way used in the very old NUWG conventions. > As far > > > as I can tell, what I am doing is supported by the CF conventions, > > > provided the time axis is taken to be the basetime dimension. > This is > > > because Section 4.4 of the conventions specifies the units of the > > > time coordinate must include a reference time. Obviously the > units of > > > the forecast coordinate cannot include a reference time, because > the > > > reference time varies, and is determined by the value of the > basetime > > > coordinate. > > > > The difficulty I am encountering is that some applications which > read > > > NetCDF/CF files (such as the Unidata IDV and Joe Sirott's very > nice > > > web based NetCDF data viewer) seem to choke on my data. I suspect > > > (but am not 100% certain in the case of the IDV) that the reason > is > > > because of the way I handle the time information in my files. > > > > To illustrate in more detail what my files look like, I am > attaching > > > the CDL from an example file. The CDL is non-CF compliant, > because I > > > have specified the "T" axis (via the axis variable attribute) to > be > > > the forecast coordinate, and the forecast coordinate has invalid > > > units (no reference time). I am planning on switching the "T" > axis to > > > the base time coordinate, which as far as I can determine should > make > > > the file CF compliant. > > > > My question is: is there a better (or more standard) way of > storing > > > multiple NWP model runs in a single file than what I am doing? > > > Cheers, > > > > Tim Hume > > > Centre for Australian Weather and Climate Research > > > Australian Bureau of Meteorology > > > Melbourne > > > Australia > > > > --- Example CDL follows --- > > > > netcdf gasp_1p0deg_ocf_t2m_rtdb_opn { > > > dimensions: > > > forecast = 69 ; > > > basetime = UNLIMITED ; // (100 currently) > > > latitude = 96 ; > > > longitude = 121 ; > > > bounds = 2 ; > > > variables: > > > double forecast(forecast) ; > > > forecast:long_name = "Time of model forecast, relative to > the > > > basetime" ; > > > forecast:units = "hours" ; > > > forecast:standard_name = "forecast_period" ; > > > forecast:axis = "T" ; > > > forecast:bounds = "forecast_bounds" ; > > > double forecast_bounds(forecast, bounds) ; > > > forecast_bounds:long_name = "forecast interval" ; > > > forecast_bounds:units = "hours" ; > > > int basetime(basetime) ; > > > basetime:long_name = "Model basetime" ; > > > basetime:units = "seconds since 1970-01-01 00:00:00.0 > +0:00" ; > > > basetime:calendar = "gregorian" ; > > > basetime:standard_name = "forecast_reference_time" ; > > > double latitude(latitude) ; > > > latitude:long_name = "latitude" ; > > > latitude:units = "degrees_north" ; > > > latitude:bounds = "latitude_bounds" ; > > > latitude:valid_min = -90. ; > > > latitude:valid_max = 90. ; > > > latitude:standard_name = "latitude" ; > > > latitude:axis = "Y" ; > > > double latitude_bounds(latitude, bounds) ; > > > latitude_bounds:long_name = "grid cell latitude > boundaries" ; > > > latitude_bounds:units = "degrees_north" ; > > > latitude_bounds:valid_min = -90. ; > > > latitude_bounds:valid_max = 90. ; > > > double longitude(longitude) ; > > > longitude:long_name = "longitude" ; > > > longitude:units = "degrees_east" ; > > > longitude:bounds = "longitude_bounds" ; > > > longitude:valid_min = -360. ; > > > longitude:valid_max = 360. ; > > > longitude:standard_name = "longitude" ; > > > longitude:axis = "X" ; > > > double longitude_bounds(longitude, bounds) ; > > > longitude_bounds:long_name = "grid cell longitude > boundaries" ; > > > longitude_bounds:units = "degrees_east" ; > > > longitude_bounds:valid_min = -360. ; > > > longitude_bounds:valid_max = 360. ; > > > float temperature_2m(basetime, forecast, latitude, longitude) ; > > > temperature_2m:long_name = "Air temperature 2m above the > > > surface" ; > > > temperature_2m:units = "K" ; > > > temperature_2m:_FillValue = 9.96921e+36f ; > > > temperature_2m:missing_value = 9.96921e+36f ; > > > temperature_2m:valid_min = 180.f ; > > > temperature_2m:valid_max = 330.f ; > > > temperature_2m:standard_name = "air_temperature" ; > > > temperature_2m:cell_methods = "lat: lon: mean (area > weighted)" ; > > > temperature_2m:coordinates = "level" ; > > > double level ; > > > level:long_name = "Height above the surface" ; > > > level:units = "m" ; > > > level:positive = "up" ; > > > level:standard_name = "height" ; > > > level:axis = "Z" ; > > > > // global attributes: > > > :Conventions = "CF-1.3" ; > > > :history = "File created by the Gridded OCF data ingest > > > system" ; > > > :institution = "Australian Bureau of Meteorology" ; > > > :source = "model" ; > > > :title = "GASP forecasts of temperature_2m; resolution: 1.0 > > > degree; source: rtdb" ; > > > :topography = "MSAS" ; > > > } > > > _______________________________________________ > > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ngalbraith at whoi.edu Fri Jan 9 11:08:13 2009 From: ngalbraith at whoi.edu (Nan Galbraith) Date: Fri, 09 Jan 2009 13:08:13 -0500 Subject: [CF-metadata] Standardized region names In-Reply-To: <48AC57F7.60600@llnl.gov> References: <2bb6ee950808181005x4de270cbja3100cb4337f0d2b@mail.gmail.com> <1240F43731C2EB4F8CC9BF70D233B5110B8CE5@SRV-XCHANGE-2K3.pc.cls.fr> <48AC57F7.60600@llnl.gov> Message-ID: <4967928D.2050601@whoi.edu> Reviving an old topic, the CF region names list is now out of date; there are 7 or 8 names on the GCMD list that have not been added to the CF document. They are: Bay Of Bengal Bay Of Fundy Davis Straight Georges Bank Grand Banks Gulf Of Maine Gulf Of St Lawrence And I'm not sure if you'd want to include it, but they list "South China And Eastern Archipelagic Seas" too. Should the CF list be updated in the next rev? I think GCMD is planning to come out with an update (any day now) anyway, but thought I'd mention this while I happen to be looking at it. > The list of regions can be found here: > http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standardized-region-names > Thanks -Nan -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* From Stephen.Griffies at noaa.gov Fri Jan 9 12:27:09 2009 From: Stephen.Griffies at noaa.gov (Stephen Griffies) Date: Fri, 09 Jan 2009 14:27:09 -0500 Subject: [CF-metadata] new named fields for ocean In-Reply-To: References: Message-ID: <4967A50D.6070602@noaa.gov> Alison, Many thanks for your detailed and useful comments. I have commented only on those names where you provided comments. In short, I have absorbed nearly all of your suggestions. Perhaps the only unresolved issue concerns how CF should standardize 1/ Fortran routines (should it do so?) 2/ grid specifications (before standard names, we need a standard suite of grid fields sufficient to specify those grids used today for climate modelling) I believe these issues are nontrivial and will need to be discussed on a separate email stream. Best, Stephen Pamment, JA (Alison) wrote: > Dear Stephen, > > Please see below for my responses to all the standard names you proposed > in your document > http://www.clivar.org/organization/wgomd/wgomd_publications.php. I > think you will see that for the most part I am happy to accept the names > as proposed, but I have made a few suggestions for slight modifications > to some of the names. I am aware that you want to finalise the names > for CMIP5 soon and I hope these responses will assist you in doing so. > > For the purpose of commenting on individual names I have labelled your > proposals as X.Y where X is your table number and Y is the number of the > entry in the table. Where a name in one of your tables is already in > the CF standard name table I have (except in one or two cases) not > included a comment. > > Table 1. > 1.1 equation of state - This would need underscores instead of spaces, > thus: equation_of_state. > Given your comment to 1.2, I suggest: sea_water_equation_of_state > 1.2 seawater freezing temp - As in 1.1, underscores need to be added. > 'seawater' is divided into two words in existing standard names, also > 'temp' should be expanded to say 'temperature'. I think that the name > sea_water_freezing_temperature sounds as though one might expect to find > actual temperature values in the varaiable and I wonder if it might be > better to call it sea_water_freezing_temperature_formula. What do > others think? > More consistent with 1.1, I suggest: sea_water_freezing_temperature_equation > Presumably both of these quantities are described by formulae which will > differ between models. Your table says that the actual formulae will > consist of Fortran code. Is the idea that these 'data' will be placed > in a character variable something like the following? > > dimensions: > nlines = 1 ; // no. of lines of FORTRAN code supplied > maxlen = 80 ; // max string length used to supply FORTRAN code > variables: > char swft(nlines,maxlen) ; > swft:standard_name = "sea_water_freezing_temperature_formula" ; > swft:canonical_units = "1" ; > data: > swft = "TF = -0.0575*S + 0.001710523*SQRT(S**3) - 0.0002154996*S**2 - > 0.00753*p" ; > > If this is what you intend, then I think the canonical_units in the > standard name table should be '1', i.e. dimensionless and the definition > of the standard name would explain that the contents are strings. This > is our usual practice for string valued variables. > My desire is to have the CMIP5 participants archive their equation of state and seawater freezing equation. Do you think we need to make these Fortran codes into a CF standard name? Perhaps we can just consider this issues as part of the CMIP5 request outside of CF. > 1.5 grid specification (lengths, areas) with units of m and m2. > I assume here that you are thinking of names such as grid_length and > grid_area? We already have a name cell_area with units of m2, defined > as the horizontal area of a gridcell, which sounds like it is probably > the quantity you need. Currently we don't have standard names for other > grid metrics, but area and volume can be recorded in the cell_measures > attribute (see Section 7.2 of the CF Conventions). Regarding > grid_length, I think this is something that would usually be calculated > from the cell boundaries given in a bounds variable. See also my > comments on proposal 2.11 cell_thickness. > > The discussion of a standard grid file is beyond this present document, and beyond my expertise. I defer to others for finalizing a community sanctioned grid specification file (with sufficient information to specify an arbitrary curvilinear grid), and then to have standard names for each of the grid fields. My understanding is that the present suite of fields in CF are not sufficient for all the grids presently in use by global climate models (e.g., tripolar, cubed sphere, icosahedral). What we need for CMIP5 is this grid information, in total, including information for arbitrary curvilinear grids. How that information is archived needs to be resolved. There are folks in the community cognizant of this issue, and hopefully they will reach a conclusion soon, at which point they can iterate with CF for standardizing the names. > 1.6 region. > Although your table indicates that this quantity is new to CMIP5, we do > already have a CF standard name of "region". It is a CF recommendation > that, where possible, variables having this standard name take their > values from the standardized list of region names at > http://www.cfconventions.org/documents/cf-standard-names/standardized-re > gion-names. > I believe the region names are taken from this list. > Table 2 > > 2.2 sea_water_pressure_at_sea_floor; Pa - The name is fine. I note that > we already have the name sea_water_pressure in the standard name table > and that this quantity has a canonical_unit of dbar. Clearly the units > can be converted, but I think that we should aim for consistent > canonical_units for these two names. Does it make more sense to use > dbar or Pa? > As you note, dbar is indeed better, so I will change the recommended units from Pa to dbar. > 2.3 sea_water_pressure_at_sea_water_surface; Pa. I appreciate that this > is a different quantity to surface_air_pressure and therefore we need a > new name. However, do we need to say sea_water_surface or would it > suffice to say surface_sea_water_pressure? ('Surface' is defined in > standard names to mean the lower boundary of the atmosphere which > therefore would also be the upper boundary of the ocean). > > surface_sea_water_pressure sounds fine to me. > 2.8 global_average_steric_sea_level_change; m. OK. We already have the > names global_average_sea_level_change and > global_average_thermosteric_sea_level_change and this new proposal is > consistent. Am I correct in thinking that steric sea level change is > the sum of thermosteric and halosteric contributions to changes in sea > water density? > Correct, though halosteric is not so important, so generally it is ignored. > 2.10 cell_mass_per_area; kg m-2. Does this mean the mass per unit area > of the sea water contained within each grid cell? If so, I suggest the > name should be mass_of_sea_water_per_unit_area which would be similar to > the existing name atmosphere_mass_of_air_per_unit_area. > > I agree. > 2.11 cell_thickness; m. See also my comments on proposal 1.5 "grid > specification". Cell_thickness would usually be calculated from the > bounds on the vertical coordinate variable. Names such as cell_length > and cell_thickness have been discussed on the mailing list in the past > and have received equivocal support. See, for example, the conversation > we had in 2006 on cell_metrics in > http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2006/001068.html and > following messages. I note that both Ian Culverwell and Jonathan seem > to support the idea of introducing cell_thickness as a new quantity in > the cell_measure attribute. I too think that would be a sensible > approach rather than introducing it as a new standard name. This will > require a proposal for a small modification to the CF conventions which > needs to be opened as a new ticket on the CF trac system. I will submit > a proposal to the trac system to take this forward as there is clearly a > demand for somewhere convenient to access this type of grid metric > information. > > I caution against considering thickness in the same manner as horizontal area. Thickness is generally a time dependent field that must be computed using a prognostic equation, whereas horizontal area in most models is static (except those few models with dynamical grids). > 2.13 sea_surface_temperature; K. This quantity is already in the > standard name table. For information, I would like to point out that we > have recently introduced the following standard names for related > quantities: sea_surface_skin_temperature, > sea_surface_subskin_temperature, sea_surface_foundation_temperature. I > am drawing attention to the existence of these names in case they are > relevant to the CMIP5 work. > > Thanks for the pointer. sea_surface_temperature is sufficient for CMIP5. > 2.17 sea_water_age_since_surface_contact; year. The name sounds fine. > I think the canonical_units in the standard name table should probably > be seconds, rather than years because of the way UDunits defines a year. > For more information on this please see Section 4.4 of the CF > Conventions. > > The nearly universal unit for age in oceanography is years. Can we make an exception here? > 2.18 moles_of_cfc11_per_unit_mass_in_sea_water; mol kg-1. I would > slightly re-order this name to read > moles_per_unit_mass_of_cfc11_in_sea_water so that its syntax is more > consistent with existing mole_fraction and mole_concentration standard > names. I think moles_per_unit_mass with units of mol kg-1 is fine. > 'mole_fraction' implies units of mol mol-1 (i.e. dimensionless) and > 'mole_concentration' means the units are mol m-3 so we clearly need a > new description for your units. > > Sounds good. > 2.22 ocean_mixed_layer_thickness_defined_by_mixing_scheme; m. I would > understand this to mean the depth of the mixed layer as calculated by a > model's own mixing scheme - is that correct? I think the name is OK. > > Correct. > Table 3. > 3.3 upward_ocean_mass_transport; kg s-1. OK. We already have a number > of ocean salt and heat transport names in the table. I assume the mass > referred to in this name is that of the sea water including salt. > Correct? > Correct. I will clarify this point in the report. > 3.7 ocean_meridional_overturning_mass_streamfunction; kg s-1. The name > is OK. The description of the existing standard name > ocean_meridional_overturning_streamfunction says "The ocean meridional > overturning streamfunction should not include not include "bolus" or > Gent-McWilliams velocity." Presumably the mass streamfunction is > defined in an analogous way? > In fact, as detailed in the report, the field ocean_meridional_overturning_mass_streamfunction should include ALL physical processes, resolved or parameterized, that impact mass/volume transport. This specification deviates from the ocean_meridional_overturning_streamfunction specification. This specification is in response to the physically relevant transport being that arising from all processes. > 3.8 ocean_y_overturning_mass_streamfunction; kg s-1. OK. Presumably > this also excludes bolus and Gent-McWilliams contributions? > > In fact, this includes bolus, and any other parameterized processes impacting the overturning. > > Table 4. > As I mentioned earlier, CF does have a defined set of standardized > region names whose use is described in Section 6.1 of the conventions > document. The region names are not, however, standard names in their > own right and do not appear in the standard name table. Similarly, your > region names would not need to become CF standard names. I note that > you have defined the extent of your named areas and it may be possible > to add them to the standardized list at a later date. > Sounds reasonable. > Table 5. > The majority of names in table 5 are already in the standard name table. > Only two are new proposals. > > OK. > 6.3 virtual_salt_flux_into_sea_water_due_to_rivers; kg m-2 s-1. I > suggest that we amend this name slightly to read > virtual_salt_flux_into_sea_water_from_rivers because in standard names > we reserve the phrase 'due to' to refer to a physical process as in the > previous two names, for example. 'from_rivers' is also more consistent > with the water flux names. > OK. > > 6.8 salt_flux_from_rivers_into_sea_water; kg m-2 s-1. I suggest that > this name should be re-ordered to read > salt_flux_into_sea_water_from_rivers for consistency with the water flux > names. > OK > Table 7 > > 7.2 rainfall_temperature_flux_expressed_as_heat_flux; W m-2. > 7.3 evaporation_temperature_flux_expressed_as_heat_flux; W m-2. > 7.4 temperature_flux_into_sea_water_from_runoff_expressed_as_heat_flux; > W m-2. > I have thought hard about these three names because initially I wasn't > very keen on the use of 'temperature flux' but having studied the > definitions in section 4.5.3 of your document I can see what you mean > and I can't think of an obvious improvement. To make the three names > more consistent with one another and with existing names I would suggest > a slight rewording as follows: > 7.2 > temperature_flux_due_to_rainfall_expressed_as_heat_flux_into_sea_water; > W m-2; > 7.3 > temperature_flux_due_to_evaporation_expressed_as_heat_flux_out_of_sea_wa > ter; W m-2; > 7.4 > temperature_flux_due_to_runoff_expressed_as_heat_flux_into_sea_water; W > m-2. > These are a bit longer than the original proposals but they all now > follow the same pattern and it is clear in which direction the flux is > positive. > OK. Thanks for the careful thought. > 7.6 heat_flux_into_sea_water_due_to_icebergs; W m-2. Is this quantity > analogous to 7.5, i.e. would it be better to say > heat_flux_into_sea_water_due_to_iceberg_thermodynamics? > > Agree with your altered name heat_flux_into_sea_water_due_to_iceberg_thermodynamics > Table 8. > Please note that the canonical units for the quantities listed in table > 8 would appear in the standard name table as Pascals, which is exactly > equivalent to N m-2. > > Indeed. I will make this note in the table caption. > Table 9. > 9.3 ocean_vertical_tracer_diffusivity_due_to_background; m2 s-1. OK. > >From your document I understand 'due_to_background' to mean a static > imposed field which may be either a constant value over the globe or > spatially varying, depending on the model used. Is that the correct > interpretation? > > Yes, correct. > 9.6 tendency_of_ocean_potential_energy_content_due_to_tides; W m-2. OK. > I am aware that distinctions can be made between a number of different > ocean tides and indeed we have recently introduced standard names for > sea surface heights due to various tidal components. Please could you > supply a sentence or two that can be included in the definitions of > 'due_to_tides' names so that it is clear which processes are > included/excluded. > Will do. In short, "due to tides" is a catch-all for "due to astronomical gravity changes which manifests as tides". We do not distinguish tidal components for these parameterizations. > > Best wishes, > Alison > > ==> Please note new email address: alison.pamment at stfc.ac.uk <== > > ------ > J 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. > > -- Stephen M. Griffies phone: +1-609-452-6672 Geophysical Fluid Dynamics Laboratory FAX: +1-609-987-5063 Princeton Forrestal Campus Rte. 1 email: stephen.griffies at noaa.gov 201 Forrestal Road http://www.gfdl.noaa.gov/~smg Princeton, NJ 08542-0308 USA From Steven.C.Hankin at noaa.gov Fri Jan 9 15:11:44 2009 From: Steven.C.Hankin at noaa.gov (Steve Hankin) Date: Fri, 09 Jan 2009 14:11:44 -0800 Subject: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] In-Reply-To: <496551CA.4050802@llnl.gov> References: <496551CA.4050802@llnl.gov> Message-ID: <4967CBA0.8050406@noaa.gov> Hi Tim (and Karl), I'd like to suggest another way to approach this that might bridge the divide between what's written in the CF standard and what applications can handle in practice. While the CF standard in principle supports the concept of two time axes (basetime, forecast time), many applications do not. A nice way to address the dual-axis nature of a forecast collection, while remaining far more compatible with existing software, is to handle the extra time axis through the Unidata "Forecast Model Run Collection Aggregation" capabilities: http://www.unidata.ucar.edu/software/netcdf/ncml/v2.2/FmrcAggregation.html If you scroll down the page you'll see a color diagram that explains the approach: the collection of outputs, which is 5-dimensional/dual-time (or 4D if the Z axis is degenerate), can be navigated as a choice of conventional single-time-axis datasets, that are compatible with conventional OPeNDAP-enabled software. An added advantage of this approach is that there is no need to re-write the output data from your model. The aggregation capabilities of the server take care of extracting all of the correct slices from the data on-the-fly (and usually with very satisfactory performance). - Steve ==================================== Karl Taylor wrote: > Hi Tim, > > Section 4.4 (just before section 4.1) states "The methods of > identifying coordinate types described in this section apply both to > coordinate variables and to auxiliary coordinate variables named by > the coordinates attribute." Since the axis attribute is one of the > methods used to identify a vertical coordinate, it would seem to be > allowed for the level in your file. > > On the other hand, in the 4th paragraph of section 5.7, it says that > "The axis attribute is not allowed for auxiliary coordinate > variables". This seems to contradict the earlier statement. > > We need to revise the document to be internally consistent. Does > anyone recall why we would want to prohibit the use of the axis > attribute for auxiliary coordinate variables? > > cheers, > Karl > > Timothy Hume wrote: >> Hi Karl, >> >> I have just checked one of my files, and get two errors: >> >> The first error is: >> >> ------------------ >> Checking variable: forecast >> ------------------ >> ERROR (4.4): Invalid units and/or reference time >> >> This is the error I am aware of. My file should become compliant if I >> switch the "T" axis to basetime. >> >> >> The second error is: >> >> ------------------ >> Checking variable: level >> ------------------ >> ERROR (4): Axis attribute is not allowed for auxillary coordinate >> variables. >> >> I was unaware that the axis attribute should not be used for scalar >> coordinate variables (as describe in Section 5.7). Is this intended? >> In any case, I don't think this small error should cause the NetCDF >> viewers I tried (IDV and Joe Sirott's web application) to not work. >> >> Cheers, >> >> Tim. >> >> -----Original Message----- >> From: Karl Taylor [mailto:taylor13 at llnl.gov] Sent: Thursday, 8 >> January 2009 11:03 >> To: Timothy Hume >> Cc: cf-metadata at cgd.ucar.edu >> Subject: Re: [CF-metadata] Storing multiple NWP model runs in a >> NetCDF - CF file [SEC=UNCLASSIFIED] >> >> Hi Tim, >> >> Other than the axis attribute for time, I didn't see any issues. You >> might run the CF compliance checker on the file (http:// >> cf-pcmdi.llnl.gov/conformance), but it might not run if the other >> utilities stumbled. Maybe someone else has some ideas. >> >> cheers, >> Karl >> >> >> Timothy Hume wrote: >>> Hi, >>> >>> I am writing NetCDF files which hold surface fields (2m temperature >>> etc) from multiple NWP model runs (all the runs from the same model >>> for the last month or so). The files are for operational use, so I >>> want them to strictly follow the CF conventions. I am running into a >>> couple of problems, where the conventions don't seem to be ideally >>> suited for storing more than a single model run. >>> >>> Here is what I do: >>> >>> I have four dimensions and associated coordinate variables: >>> >>> basetime: The base time for the model run (units: seconds since >>> 1970-01-01 00:00:00.0 +0:00) >>> forecast: The forecast lead time, relative to the basetime >>> (units: hours) >>> latitude >>> longitude >>> >>> There is no need for a vertical dimension, because I am using >>> surface fields. Never-the-less I make use of a scalar vertical >>> coordinate variable as described in Section 5.7 of the CF-1.3 >>> metadata conventions document. >>> >>> The use of two dimensions to store the time information (basetime >>> and forecast) seems to be a natural way to store multiple NWP model >>> runs, and is the standard way used in the very old NUWG conventions. >>> As far as I can tell, what I am doing is supported by the CF >>> conventions, provided the time axis is taken to be the basetime >>> dimension. This is because Section 4.4 of the conventions specifies >>> the units of the time coordinate must include a reference time. >>> Obviously the units of the forecast coordinate cannot include a >>> reference time, because the reference time varies, and is determined >>> by the value of the basetime coordinate. >>> >>> The difficulty I am encountering is that some applications which >>> read NetCDF/CF files (such as the Unidata IDV and Joe Sirott's very >>> nice web based NetCDF data viewer) seem to choke on my data. I >>> suspect (but am not 100% certain in the case of the IDV) that the >>> reason is because of the way I handle the time information in my files. >>> >>> To illustrate in more detail what my files look like, I am attaching >>> the CDL from an example file. The CDL is non-CF compliant, because I >>> have specified the "T" axis (via the axis variable attribute) to be >>> the forecast coordinate, and the forecast coordinate has invalid >>> units (no reference time). I am planning on switching the "T" axis >>> to the base time coordinate, which as far as I can determine should >>> make the file CF compliant. >>> >>> My question is: is there a better (or more standard) way of storing >>> multiple NWP model runs in a single file than what I am doing? >>> Cheers, >>> >>> Tim Hume >>> Centre for Australian Weather and Climate Research >>> Australian Bureau of Meteorology >>> Melbourne >>> Australia >>> >>> --- Example CDL follows --- >>> >>> netcdf gasp_1p0deg_ocf_t2m_rtdb_opn { >>> dimensions: >>> forecast = 69 ; >>> basetime = UNLIMITED ; // (100 currently) >>> latitude = 96 ; >>> longitude = 121 ; >>> bounds = 2 ; >>> variables: >>> double forecast(forecast) ; >>> forecast:long_name = "Time of model forecast, relative to >>> the basetime" ; >>> forecast:units = "hours" ; >>> forecast:standard_name = "forecast_period" ; >>> forecast:axis = "T" ; >>> forecast:bounds = "forecast_bounds" ; >>> double forecast_bounds(forecast, bounds) ; >>> forecast_bounds:long_name = "forecast interval" ; >>> forecast_bounds:units = "hours" ; >>> int basetime(basetime) ; >>> basetime:long_name = "Model basetime" ; >>> basetime:units = "seconds since 1970-01-01 00:00:00.0 +0:00" ; >>> basetime:calendar = "gregorian" ; >>> basetime:standard_name = "forecast_reference_time" ; >>> double latitude(latitude) ; >>> latitude:long_name = "latitude" ; >>> latitude:units = "degrees_north" ; >>> latitude:bounds = "latitude_bounds" ; >>> latitude:valid_min = -90. ; >>> latitude:valid_max = 90. ; >>> latitude:standard_name = "latitude" ; >>> latitude:axis = "Y" ; >>> double latitude_bounds(latitude, bounds) ; >>> latitude_bounds:long_name = "grid cell latitude boundaries" ; >>> latitude_bounds:units = "degrees_north" ; >>> latitude_bounds:valid_min = -90. ; >>> latitude_bounds:valid_max = 90. ; >>> double longitude(longitude) ; >>> longitude:long_name = "longitude" ; >>> longitude:units = "degrees_east" ; >>> longitude:bounds = "longitude_bounds" ; >>> longitude:valid_min = -360. ; >>> longitude:valid_max = 360. ; >>> longitude:standard_name = "longitude" ; >>> longitude:axis = "X" ; >>> double longitude_bounds(longitude, bounds) ; >>> longitude_bounds:long_name = "grid cell longitude boundaries" ; >>> longitude_bounds:units = "degrees_east" ; >>> longitude_bounds:valid_min = -360. ; >>> longitude_bounds:valid_max = 360. ; >>> float temperature_2m(basetime, forecast, latitude, longitude) ; >>> temperature_2m:long_name = "Air temperature 2m above the >>> surface" ; >>> temperature_2m:units = "K" ; >>> temperature_2m:_FillValue = 9.96921e+36f ; >>> temperature_2m:missing_value = 9.96921e+36f ; >>> temperature_2m:valid_min = 180.f ; >>> temperature_2m:valid_max = 330.f ; >>> temperature_2m:standard_name = "air_temperature" ; >>> temperature_2m:cell_methods = "lat: lon: mean (area >>> weighted)" ; >>> temperature_2m:coordinates = "level" ; >>> double level ; >>> level:long_name = "Height above the surface" ; >>> level:units = "m" ; >>> level:positive = "up" ; >>> level:standard_name = "height" ; >>> level:axis = "Z" ; >>> >>> // global attributes: >>> :Conventions = "CF-1.3" ; >>> :history = "File created by the Gridded OCF data ingest >>> system" ; >>> :institution = "Australian Bureau of Meteorology" ; >>> :source = "model" ; >>> :title = "GASP forecasts of temperature_2m; resolution: 1.0 >>> degree; source: rtdb" ; >>> :topography = "MSAS" ; >>> } >>> _______________________________________________ >>> 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 -- 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 From caron at unidata.ucar.edu Fri Jan 9 17:40:14 2009 From: caron at unidata.ucar.edu (John Caron) Date: Fri, 09 Jan 2009 17:40:14 -0700 Subject: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CF file [SEC=UNCLASSIFIED] In-Reply-To: <4967CBA0.8050406@noaa.gov> References: <496551CA.4050802@llnl.gov> <4967CBA0.8050406@noaa.gov> Message-ID: <4967EE6E.6020304@unidata.ucar.edu> As Steve says, the "FMRC Aggregation" helps to bridge between a complex 2-time dimension collection, and applications that can only deal with one time dimension. A pretty poster is here: http://www.unidata.ucar.edu/staff/caron/presentations/FmrcPoster.pdf Still, we need to decide how to encode the 2-time dimension case into a single file, when that is needed. Steve Hankin wrote: > Hi Tim (and Karl), > > I'd like to suggest another way to approach this that might bridge the > divide between what's written in the CF standard and what applications > can handle in practice. While the CF standard in principle supports the > concept of two time axes (basetime, forecast time), many applications do > not. A nice way to address the dual-axis nature of a forecast > collection, while remaining far more compatible with existing software, > is to handle the extra time axis through the Unidata "Forecast Model Run > Collection Aggregation" capabilities: > http://www.unidata.ucar.edu/software/netcdf/ncml/v2.2/FmrcAggregation.html > > If you scroll down the page you'll see a color diagram that explains the > approach: the collection of outputs, which is 5-dimensional/dual-time > (or 4D if the Z axis is degenerate), can be navigated as a choice of > conventional single-time-axis datasets, that are compatible with > conventional OPeNDAP-enabled software. > An added advantage of this approach is that there is no need to re-write > the output data from your model. The aggregation capabilities of the > server take care of extracting all of the correct slices from the data > on-the-fly (and usually with very satisfactory performance). > > - Steve > > ==================================== > > Karl Taylor wrote: >> Hi Tim, >> >> Section 4.4 (just before section 4.1) states "The methods of >> identifying coordinate types described in this section apply both to >> coordinate variables and to auxiliary coordinate variables named by >> the coordinates attribute." Since the axis attribute is one of the >> methods used to identify a vertical coordinate, it would seem to be >> allowed for the level in your file. >> >> On the other hand, in the 4th paragraph of section 5.7, it says that >> "The axis attribute is not allowed for auxiliary coordinate >> variables". This seems to contradict the earlier statement. >> >> We need to revise the document to be internally consistent. Does >> anyone recall why we would want to prohibit the use of the axis >> attribute for auxiliary coordinate variables? >> >> cheers, >> Karl >> >> Timothy Hume wrote: >>> Hi Karl, >>> >>> I have just checked one of my files, and get two errors: >>> >>> The first error is: >>> >>> ------------------ >>> Checking variable: forecast >>> ------------------ >>> ERROR (4.4): Invalid units and/or reference time >>> >>> This is the error I am aware of. My file should become compliant if I >>> switch the "T" axis to basetime. >>> >>> >>> The second error is: >>> >>> ------------------ >>> Checking variable: level >>> ------------------ >>> ERROR (4): Axis attribute is not allowed for auxillary coordinate >>> variables. >>> >>> I was unaware that the axis attribute should not be used for scalar >>> coordinate variables (as describe in Section 5.7). Is this intended? >>> In any case, I don't think this small error should cause the NetCDF >>> viewers I tried (IDV and Joe Sirott's web application) to not work. >>> >>> Cheers, >>> >>> Tim. >>> >>> -----Original Message----- >>> From: Karl Taylor [mailto:taylor13 at llnl.gov] Sent: Thursday, 8 >>> January 2009 11:03 >>> To: Timothy Hume >>> Cc: cf-metadata at cgd.ucar.edu >>> Subject: Re: [CF-metadata] Storing multiple NWP model runs in a >>> NetCDF - CF file [SEC=UNCLASSIFIED] >>> >>> Hi Tim, >>> >>> Other than the axis attribute for time, I didn't see any issues. You >>> might run the CF compliance checker on the file (http:// >>> cf-pcmdi.llnl.gov/conformance), but it might not run if the other >>> utilities stumbled. Maybe someone else has some ideas. >>> >>> cheers, >>> Karl >>> >>> >>> Timothy Hume wrote: >>>> Hi, >>>> >>>> I am writing NetCDF files which hold surface fields (2m temperature >>>> etc) from multiple NWP model runs (all the runs from the same model >>>> for the last month or so). The files are for operational use, so I >>>> want them to strictly follow the CF conventions. I am running into a >>>> couple of problems, where the conventions don't seem to be ideally >>>> suited for storing more than a single model run. >>>> >>>> Here is what I do: >>>> >>>> I have four dimensions and associated coordinate variables: >>>> >>>> basetime: The base time for the model run (units: seconds since >>>> 1970-01-01 00:00:00.0 +0:00) >>>> forecast: The forecast lead time, relative to the basetime >>>> (units: hours) >>>> latitude >>>> longitude >>>> >>>> There is no need for a vertical dimension, because I am using >>>> surface fields. Never-the-less I make use of a scalar vertical >>>> coordinate variable as described in Section 5.7 of the CF-1.3 >>>> metadata conventions document. >>>> >>>> The use of two dimensions to store the time information (basetime >>>> and forecast) seems to be a natural way to store multiple NWP model >>>> runs, and is the standard way used in the very old NUWG conventions. >>>> As far as I can tell, what I am doing is supported by the CF >>>> conventions, provided the time axis is taken to be the basetime >>>> dimension. This is because Section 4.4 of the conventions specifies >>>> the units of the time coordinate must include a reference time. >>>> Obviously the units of the forecast coordinate cannot include a >>>> reference time, because the reference time varies, and is determined >>>> by the value of the basetime coordinate. >>>> >>>> The difficulty I am encountering is that some applications which >>>> read NetCDF/CF files (such as the Unidata IDV and Joe Sirott's very >>>> nice web based NetCDF data viewer) seem to choke on my data. I >>>> suspect (but am not 100% certain in the case of the IDV) that the >>>> reason is because of the way I handle the time information in my files. >>>> >>>> To illustrate in more detail what my files look like, I am attaching >>>> the CDL from an example file. The CDL is non-CF compliant, because I >>>> have specified the "T" axis (via the axis variable attribute) to be >>>> the forecast coordinate, and the forecast coordinate has invalid >>>> units (no reference time). I am planning on switching the "T" axis >>>> to the base time coordinate, which as far as I can determine should >>>> make the file CF compliant. >>>> >>>> My question is: is there a better (or more standard) way of storing >>>> multiple NWP model runs in a single file than what I am doing? >>>> Cheers, >>>> >>>> Tim Hume >>>> Centre for Australian Weather and Climate Research >>>> Australian Bureau of Meteorology >>>> Melbourne >>>> Australia >>>> >>>> --- Example CDL follows --- >>>> >>>> netcdf gasp_1p0deg_ocf_t2m_rtdb_opn { >>>> dimensions: >>>> forecast = 69 ; >>>> basetime = UNLIMITED ; // (100 currently) >>>> latitude = 96 ; >>>> longitude = 121 ; >>>> bounds = 2 ; >>>> variables: >>>> double forecast(forecast) ; >>>> forecast:long_name = "Time of model forecast, relative to >>>> the basetime" ; >>>> forecast:units = "hours" ; >>>> forecast:standard_name = "forecast_period" ; >>>> forecast:axis = "T" ; >>>> forecast:bounds = "forecast_bounds" ; >>>> double forecast_bounds(forecast, bounds) ; >>>> forecast_bounds:long_name = "forecast interval" ; >>>> forecast_bounds:units = "hours" ; >>>> int basetime(basetime) ; >>>> basetime:long_name = "Model basetime" ; >>>> basetime:units = "seconds since 1970-01-01 00:00:00.0 +0:00" ; >>>> basetime:calendar = "gregorian" ; >>>> basetime:standard_name = "forecast_reference_time" ; >>>> double latitude(latitude) ; >>>> latitude:long_name = "latitude" ; >>>> latitude:units = "degrees_north" ; >>>> latitude:bounds = "latitude_bounds" ; >>>> latitude:valid_min = -90. ; >>>> latitude:valid_max = 90. ; >>>> latitude:standard_name = "latitude" ; >>>> latitude:axis = "Y" ; >>>> double latitude_bounds(latitude, bounds) ; >>>> latitude_bounds:long_name = "grid cell latitude boundaries" ; >>>> latitude_bounds:units = "degrees_north" ; >>>> latitude_bounds:valid_min = -90. ; >>>> latitude_bounds:valid_max = 90. ; >>>> double longitude(longitude) ; >>>> longitude:long_name = "longitude" ; >>>> longitude:units = "degrees_east" ; >>>> longitude:bounds = "longitude_bounds" ; >>>> longitude:valid_min = -360. ; >>>> longitude:valid_max = 360. ; >>>> longitude:standard_name = "longitude" ; >>>> longitude:axis = "X" ; >>>> double longitude_bounds(longitude, bounds) ; >>>> longitude_bounds:long_name = "grid cell longitude boundaries" ; >>>> longitude_bounds:units = "degrees_east" ; >>>> longitude_bounds:valid_min = -360. ; >>>> longitude_bounds:valid_max = 360. ; >>>> float temperature_2m(basetime, forecast, latitude, longitude) ; >>>> temperature_2m:long_name = "Air temperature 2m above the >>>> surface" ; >>>> temperature_2m:units = "K" ; >>>> temperature_2m:_FillValue = 9.96921e+36f ; >>>> temperature_2m:missing_value = 9.96921e+36f ; >>>> temperature_2m:valid_min = 180.f ; >>>> temperature_2m:valid_max = 330.f ; >>>> temperature_2m:standard_name = "air_temperature" ; >>>> temperature_2m:cell_methods = "lat: lon: mean (area >>>> weighted)" ; >>>> temperature_2m:coordinates = "level" ; >>>> double level ; >>>> level:long_name = "Height above the surface" ; >>>> level:units = "m" ; >>>> level:positive = "up" ; >>>> level:standard_name = "height" ; >>>> level:axis = "Z" ; >>>> >>>> // global attributes: >>>> :Conventions = "CF-1.3" ; >>>> :history = "File created by the Gridded OCF data ingest >>>> system" ; >>>> :institution = "Australian Bureau of Meteorology" ; >>>> :source = "model" ; >>>> :title = "GASP forecasts of temperature_2m; resolution: 1.0 >>>> degree; source: rtdb" ; >>>> :topography = "MSAS" ; >>>> } >>>> _______________________________________________ >>>> 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 Fri Jan 9 18:21:48 2009 From: caron at unidata.ucar.edu (John Caron) Date: Fri, 09 Jan 2009 18:21:48 -0700 Subject: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CFfile [SEC=UNCLASSIFIED] In-Reply-To: <20090109083441.GC29793@met.reading.ac.uk> References: <20090109083441.GC29793@met.reading.ac.uk> Message-ID: <4967F82C.9020704@unidata.ucar.edu> Hi Jonathan, Tim, Doug, et al: Jonathan Gregory wrote: > Dear Tim > > So for the case of multiple analysis and forecast times, where all combinations > exist, you have two multivalued time dimensions, one for forecast reference > time (= base time, analysis time, initialisation time) and one for forecast > period (lead time). The former has units of "UNITS since TIME" and the latter > is a plain time-unit. Is that right? thats what i understand also > > In http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2006/001008.html we > proposed instead to deal with this 2D case by introducing an index dimension > and collapsing it into 1D, with the forecast reference time and the forecast > period being 1D auxiliary coord vars. That obscures the 2D structure, which is > a loss. The reason for proposing it was that it reduced the number of different > structures that would have to be used. The 2D structure can only be used if > all 2D combinations exist. the index dimension method makes a compact file, but id say that its hard to figure out without documentation. > > In http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2007/001470.html, the > method that Doug uses, 2D is also collapsed into 1D, but instead of introducing > a plain index dimension, the 1D coordinate is validity time (forecast reference > time + forecast period). That is a better idea, I think, because it's a useful > coordinate variable rather than just an index. Again forecast reference time > and forecast period are 1D auxiliary coord vars. this is good because its got only 1D coordinates, which are meaningful. the downside is that the coordinate values may not be unique, so its not really a coordinate variable. this can mess with some software that assumes one can uniquely name things with the coordinate values. > > I agree that the CF standard should have examples for each of the recommended > structures. That would need a proposal on trac and maybe John was offering to > make one. yes, if theres general agreement on how to proceed. > > What do you think about using Doug's/Paco's collapse of 2D into 1D? To get all > the 24-h forecasts, for instance, you'd have to search the 1D auxiliary coord > var of forecast period and use it to select particular indices of the time > dimension. That is a bit more awkward, but the structure has an advantage in > generality. looks like the main defect is that again, the coordinate values may not be unique. im not that concerned with the search problem. one must read in the coordinate values and figure out what they correspond to. ----------------------------- the main elements of any solution are the 3 types of time coordinates, with standard names: forecast_reference_time forecast_period time such that forecast_reference_time + forecast_period = time. there are 3 main difficulties to answer: 1. in the general case, forecast_period may be 2D (not common though), and time is often 2D. is this allowable as auxiliary coordinates? 2. there may be missing cases, akin to ragged arrays. possible solutions are an "index dimension" (section 8.2), or to use missing values, or ?. (I notice that existing examples I have seen find a way to avoid this) 3. solutions that try to stick with only 1D variables will, in general, have repeated coordinate values, making them technically not coordinate variables. will we allow this? > > Best wishes > > Jonathan > _______________________________________________ > 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 Jan 9 18:23:58 2009 From: taylor13 at llnl.gov (Karl Taylor) Date: Fri, 09 Jan 2009 17:23:58 -0800 Subject: [CF-metadata] new named fields for ocean In-Reply-To: <4967A50D.6070602@noaa.gov> References: <4967A50D.6070602@noaa.gov> Message-ID: <4967F8AE.2030309@llnl.gov> Dear Alison and Stephen, Thanks to both of you for good progress on this. I have added further remarks to Stephen's email. I hope Jonathan and others will also review the issues raised. I apologize for responding here not only to the issue of "standard_names" but also as to what should be saved for CMIP5, but this is of immediate concern too. Best regards, Karl Stephen Griffies wrote: > Alison, > > > Many thanks for your detailed and useful comments. I have commented > only on those names where you provided comments. In short, I have > absorbed nearly all of your suggestions. Perhaps the only unresolved > issue concerns how CF should standardize > > > 1/ Fortran routines (should it do so?) > > > 2/ grid specifications (before standard names, we need a standard suite > of grid fields sufficient to specify those grids used today for climate > modelling) > > > I believe these issues are nontrivial and will need to be discussed on a > separate email stream. I agree. These are not variables (i.e., a physical quantities) and therefore do not require standard_names CF does not control the vocabulary for metadata that is not currently part of the convention. There are efforts underway (e.g. METAFOR) that are attempting to standardize the way experiments and models are described (documented) with metadata, but for now you would be free to do what you want in recording the code information. > > Best, > Stephen > > > > Pamment, JA (Alison) wrote: >> Dear Stephen, >> > >> >> Table 1. >> 1.1 equation of state - This would need underscores instead of spaces, >> thus: equation_of_state. >> > > Given your comment to 1.2, I suggest: sea_water_equation_of_state No. No standard name is needed for non-physical quantities. > > > > My desire is to have the CMIP5 participants archive their equation of > state and seawater freezing equation. Do you think we need to make > these Fortran codes into a CF standard name? Perhaps we can just > consider this issues as part of the CMIP5 request outside of CF. Yes, I think this is the way to go. > > >> 1.5 grid specification (lengths, areas) with units of m and m2. >> I assume here that you are thinking of names such as grid_length and >> grid_area? We already have a name cell_area with units of m2, defined >> as the horizontal area of a gridcell, which sounds like it is probably >> the quantity you need. Currently we don't have standard names for other >> grid metrics, but area and volume can be recorded in the cell_measures >> attribute (see Section 7.2 of the CF Conventions). Regarding >> grid_length, I think this is something that would usually be calculated >> from the cell boundaries given in a bounds variable. See also my >> comments on proposal 2.11 cell_thickness. >> >> > > The discussion of a standard grid file is beyond this present document, > and beyond my expertise. I defer to others for finalizing a community > sanctioned grid specification file (with sufficient information to > specify an arbitrary curvilinear grid), and then to have standard names > for each of the grid fields. My understanding is that the present suite > of fields in CF are not sufficient for all the grids presently in use by > global climate models (e.g., tripolar, cubed sphere, icosahedral). > What we need for CMIP5 is this grid information, in total, including > information for arbitrary curvilinear grids. How that information is > archived needs to be resolved. There are folks in the community > cognizant of this issue, and hopefully they will reach a conclusion > soon, at which point they can iterate with CF for standardizing the names. I agree this is outside of what can be done at this time. I hope, however, that for any grid, the data could be stored in a structured way (either 1-d, 2-d, or 3-d array of numbers) and an approximate longitude and latitude could be associated with each of these. If this is the case (and I trust it is), then CF says how to store it along with the longitudes and latitudes. > >> 2.3 sea_water_pressure_at_sea_water_surface; Pa. I appreciate that this >> is a different quantity to surface_air_pressure and therefore we need a >> new name. However, do we need to say sea_water_surface or would it >> suffice to say surface_sea_water_pressure? ('Surface' is defined in >> standard names to mean the lower boundary of the atmosphere which >> therefore would also be the upper boundary of the ocean). >> >> > > surface_sea_water_pressure sounds fine to me. I think this is incorrect because when sea ice is present we want the pressure at the interface between sea ice and the ocean, not the atmos. and ocean. I suggest: pressure_at_the_top_of_the_sea or pressure_at_the_sea_water_surface but perhaps there are better words. > >> 2.11 cell_thickness; m. See also my comments on proposal 1.5 "grid >> specification". Cell_thickness would usually be calculated from the >> bounds on the vertical coordinate variable. Names such as cell_length >> and cell_thickness have been discussed on the mailing list in the past >> and have received equivocal support. See, for example, the conversation >> we had in 2006 on cell_metrics in >> http:// mailman.cgd.ucar.edu/pipermail/cf-metadata/2006/001068.html and >> following messages. I note that both Ian Culverwell and Jonathan seem >> to support the idea of introducing cell_thickness as a new quantity in >> the cell_measure attribute. I too think that would be a sensible >> approach rather than introducing it as a new standard name. This will >> require a proposal for a small modification to the CF conventions which >> needs to be opened as a new ticket on the CF trac system. I will submit >> a proposal to the trac system to take this forward as there is clearly a >> demand for somewhere convenient to access this type of grid metric >> information. >> > > I caution against considering thickness in the same manner as horizontal > area. Thickness is generally a time dependent field that must be > computed using a prognostic equation, whereas horizontal area in most > models is static (except those few models with dynamical grids). More analogous is the "pressure thickness" of a sigma (or hybrid sigma pressure) vertical coordinate system for the atmosphere. Here the thickness can be calculated with well-know formulas, given the surface pressure and the vertical coordinate information. The surface pressure is, of course, a function of time. In the ocean models, would you have to save a full 3-d ocean field every time-step to calculate the thickness? We will have to prioritize among the following fields to save: grid cell horizontal area grid cell volume grid cell mass grid cell thickness grid cell mass per unit area grid cell density We shouldn't store information that can be obtained by simple multiplication or division from other quantities stored. What is the minimum set recommended? [I apologize if this is already addressed in the document, which I have at this point just begun to study.] > > >> 2.17 sea_water_age_since_surface_contact; year. The name sounds fine. >> I think the canonical_units in the standard name table should probably >> be seconds, rather than years because of the way UDunits defines a year. >> For more information on this please see Section 4.4 of the CF >> Conventions. >> > The nearly universal unit for age in oceanography is years. Can we make > an exception here? The units in the standard_name table should be generic and consistent (in this case "s"). For CMIP5 we can ask for any unit you like, and although "year" is not a true unit since it varies from one year to the next, I think in this case it might be o.k. (the approximation should be good within a small fraction of a percent). What do others think? > >> 2.22 ocean_mixed_layer_thickness_defined_by_mixing_scheme; m. I would >> understand this to mean the depth of the mixed layer as calculated by a >> model's own mixing scheme - is that correct? I think the name is OK. > > Correct. I don't see what "defined_by_mixing_scheme" adds. This does not make the definition any more precise than simply ocean_mixed_layer_thickness. Are there already other types of ocean_mixed_layer_thicknesses defined? > > >> 3.7 ocean_meridional_overturning_mass_streamfunction; kg s-1. The name >> is OK. The description of the existing standard name >> ocean_meridional_overturning_streamfunction says "The ocean meridional >> overturning streamfunction should not include not include "bolus" or >> Gent-McWilliams velocity." Presumably the mass streamfunction is >> defined in an analogous way? >> > > In fact, as detailed in the report, the field > ocean_meridional_overturning_mass_streamfunction should include ALL > physical processes, resolved or parameterized, that impact mass/volume > transport. This specification deviates from the > ocean_meridional_overturning_streamfunction specification. This > specification is in response to the physically relevant transport being > that arising from all processes. > >> 3.8 ocean_y_overturning_mass_streamfunction; kg s-1. OK. Presumably >> this also excludes bolus and Gent-McWilliams contributions? >> > In fact, this includes bolus, and any other parameterized processes > impacting the overturning. I'm not particularly happy with y_overturning. Are there any better ideas? > > > >> Table 7 >> >> 7.2 rainfall_temperature_flux_expressed_as_heat_flux; W m-2. >> 7.3 evaporation_temperature_flux_expressed_as_heat_flux; W m-2. >> 7.4 temperature_flux_into_sea_water_from_runoff_expressed_as_heat_flux; >> W m-2. >> I have thought hard about these three names because initially I wasn't >> very keen on the use of 'temperature flux' but having studied the >> definitions in section 4.5.3 of your document I can see what you mean >> and I can't think of an obvious improvement. To make the three names >> more consistent with one another and with existing names I would suggest >> a slight rewording as follows: >> 7.2 >> temperature_flux_due_to_rainfall_expressed_as_heat_flux_into_sea_water; >> W m-2; >> 7.3 >> temperature_flux_due_to_evaporation_expressed_as_heat_flux_out_of_sea_wa >> ter; W m-2; >> 7.4 >> temperature_flux_due_to_runoff_expressed_as_heat_flux_into_sea_water; W >> m-2. >> These are a bit longer than the original proposals but they all now >> follow the same pattern and it is clear in which direction the flux is >> positive. >> > > OK. Thanks for the careful thought. I do not like "temperature flux" expressed as heat flux. There must be some terms used in engineering and physics that are better for this. Ablation of material surfaces remove energy both by removing mass with a certain amount of internal energy and by energy required to change the phase. Is anyone familiar with the terminology? Also, are you sure you want only "rainfall", rather than "precipitation" , which includes water falling out of the atmosphere in the solid state (e.g., snow). Perhaps you need to "snowfall" besides "rainfall" (because the snow likely melts when it hits the ocean with the resultant latent heat transfer), but I didn't see mention of "snow" on the list. From graybeal at mbari.org Sat Jan 10 12:51:28 2009 From: graybeal at mbari.org (John Graybeal) Date: Sat, 10 Jan 2009 11:51:28 -0800 Subject: [CF-metadata] new named fields for ocean In-Reply-To: <4967F8AE.2030309@llnl.gov> References: <4967A50D.6070602@noaa.gov> <4967F8AE.2030309@llnl.gov> Message-ID: <20D76D45-EB57-4BBE-BC2D-6A575135B162@mbari.org> I encourage CF to evaluate the creation of standard names on the basis of what is useful and compatible with the standard names vocabulary, rather than what is _required_ by the current standard. If CF does not expressly exclude the creation of names of non-physical quantities, then wouldn't it be a good thing to allow more complete description of the contents of a data set, including its metadata if necessary? I am not knowledgeable enough to be know if this name is appropriate in this particular context, so this is a more general question of philosophy. So perhaps the topic should move to the TRAC discussions, if my argument isn't rejected out of hand. John On Jan 9, 2009, at 5:23 PM, Karl Taylor wrote: >> Given your comment to 1.2, I suggest: sea_water_equation_of_state > > No. No standard name is needed for non-physical quantities. > John -------------- John Graybeal -- 831-775-1956 Monterey Bay Aquarium Research Institute Marine Metadata Interoperability Project: http://marinemetadata.org From T.Hume at bom.gov.au Sun Jan 11 15:39:00 2009 From: T.Hume at bom.gov.au (Timothy Hume) Date: Mon, 12 Jan 2009 09:39:00 +1100 Subject: [CF-metadata] Storing multiple NWP model runs in a NetCDF - CFfile [SEC=UNCLASSIFIED] In-Reply-To: <4967F82C.9020704@unidata.ucar.edu> Message-ID: Hi, It strikes me that the issue of more than one time coordinate is just a special case of a more general issue. There is a spatial analogy. Normally it makes sense to store NWP or climate model data on two spatial dimensions (e.g. latitude and longitude). This is because most model output has all the combinations of latitudes and longitudes. However, when it comes to storing data from a network of weather stations (for example), it makes sense to collapse the two spatial dimensions into a single "station" dimension, and have latitude and longitude as auxilliary coordinate variables. If the two spatial dimensions were not collapsed, one would end up with very large files mostly full of missing values. Therefore, maybe the solution to the two time coordinate problem is to have a standard method for collapsing two or more dimensions into a single dimension. Then users could apply the collapsing method to any combination of dimensions they choose. Normally it would only be desirable to collapse multiple time dimensions to a single dimension, or latitude and longitude to a single "station" dimension. However, someone might come up with a data set where it made sense to collapse latitude and time into a single dimension (I can't even imagine why one would want to do this, but you never know ...) Maybe the collapsing method could work like this: 1) Start with two (or more)dimensions and coordinate variables which need to be collapsed dimensions: dim1 = n1; dim2 = n2; variables: double dim1(dim1); double dim2(dim2); double data(dim1, dim2); 2) Create a new dimension d3 which has auxiliary coordinate variables called dim1 and dim2: dimensions: dim3 = n1*n2; variables: double dim1(dim3); double dim2(dim3); double data(dim3); 3) There could be an optional recommendation concerning the order in which the dimensions were collapsed. For example, if dim1(dim1) had values of 1, 2 and 3 and dim2(dim2) had values of 4, 5 and 6; then once collapsed: dim1(dim3) = 1, 1, 1, 2, 2, 2, 3, 3, 3 dim2(dim3) = 4, 5, 6, 4, 5, 6, 4, 5, 6 A recommendation such as this would potentially make mapping of data to arrays in programming languages easier. Returning to the original issue of multiple time coordinates. There are some good practical reasons for my application to use two separate dimensions (forecast_reference_time and forecast_period) rather than collapsing them into a single dimension: 1) For NWP applications, it is quite common to have all the combinations of forecast_reference_time and forecast_period. Therefore using two dimensions won't waste space with missing values. For some model data I store (e.g. some JMA data), the model runs at 12Z have more forecast_periods available than the model runs at 00Z. In these cases, collapsing the time coordinates into a single dimension would save disc space at the expense of making the files more difficult to use. I prefer to take the disc space penalty and keep the two dimensions (and fill all the long range forecasts from the 00Z run with missing values). 2) Keeping two separate dimensions makes it trivial to perform some common operations on subsets of the data. For example, I can use the NetCDF operators to easily compute the average bias (with respect to analyses) of 48 hour forecasts during the last thirty days. 3) Keeping forecast_period as a separate dimension, and utilising the CF cell methods (on the forecast_period dimension) provides a nice way to store accumulations (a.g. accumulated precipitation). Most models include accumulations since the analysis or reference time, but some reset accumulation totals every 24 hours. Either way, the use of a separate forecast_period and the CF cell methods can deal with these data. All that is necessary is to set the forecast_period_bounds variable to the start and end times of the accumulations. I have a feeling that storing accumulations would be more difficult if I collapsed the time coordinates onto a single dimension (but I may be wrong). Cheers, Tim Hume Centre for Australian Weather and Climate Research Australian Bureau of Meteorology Melbourne Australia > ----------------------------- > > the main elements of any solution are the 3 types of time > coordinates, with standard names: > > forecast_reference_time > forecast_period > time > > such that forecast_reference_time + forecast_period = time. > > there are 3 main difficulties to answer: > > 1. in the general case, forecast_period may be 2D (not > common though), and time is often 2D. is this allowable as > auxiliary coordinates? > > 2. there may be missing cases, akin to ragged arrays. > possible solutions are an "index dimension" (section 8.2), or > to use missing values, or ?. (I notice that existing examples > I have seen find a way to avoid this) > > 3. solutions that try to stick with only 1D variables will, > in general, have repeated coordinate values, making them > technically not coordinate variables. will we allow this? From j.m.gregory at reading.ac.uk Mon Jan 12 06:49:13 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Mon, 12 Jan 2009 13:49:13 +0000 Subject: [CF-metadata] new named fields for ocean Message-ID: <20090112134913.GA15221@met.reading.ac.uk> Dear all I agree with others that the equation of state and freezing temperature can be left for the moment, until it is decided *how* this information will be collected for CMIP5. It would be a departure to give such things standard names, but it could be considered. I agree also that we need ways to describe more grid-information for CMIP5 (I assume this will come in Balaji's proposal). But even without adding it to cell_measures, we could introduce the standard_name of cell_thickness. An analysis program could find the variable by using the standard name and the grid information. The cell_measures is a pointer which would make it easier to find. Given Karl's remark "when sea ice is present we want the pressure at the interface between sea ice and the ocean, not the atmosphere and ocean" perhaps we should stick with sea_water_pressure_at_sea_water_surface as originally proposed. I think that may be why we chose it i.e. it is not surface pressure. I think year is acceptable, if inaccurate, for the age of sea water. It depends on analysis programs treating it properly. Perhaps the CMIP5 doc can say exactly how this quantity is to be evaluated and interpreted in years. The document intends to use the existing name of region, but some of the possible values for a region variable are proposals for addition to the list of standard region names. Cheers Jonathan From Stephen.Griffies at noaa.gov Mon Jan 12 07:23:43 2009 From: Stephen.Griffies at noaa.gov (Stephen Griffies) Date: Mon, 12 Jan 2009 09:23:43 -0500 Subject: [CF-metadata] new named fields for ocean In-Reply-To: <4967F8AE.2030309@llnl.gov> References: <4967A50D.6070602@noaa.gov> <4967F8AE.2030309@llnl.gov> Message-ID: <496B526F.8080001@noaa.gov> Karl, Here are some modifications in response to your email. 1/ As Jonathan says in his email, the desire is to have a measure of the total pressure applied to the liquid ocean surface, including sea ice and atmosphere loading. If "surface" is interpreted as the liquid ocean surface, then the name surface_sea_water_pressure is fine. But to be extra clear, your suggestion pressure_at_the_sea_water_surface is appealing. Likewise, I suggest changing sea_water_pressure_at_sea_floor to just the simpler pressure_at_sea_floor, since the desired pressure includes that from seawater as well as the media above the liquid ocean. In summary, I recommend the following two field names that are sufficient to bound the ocean pressure field: pressure_at_the_sea_water_surface pressure_at_sea_floor 2/ There is presently no minimum set of grid variables discussed in the report. The resolution of what is a minimal set goes beyond this email list. But in the process of thinking about this set, it is important to remember that the vertical thickness and mass per unit area are in general time dependent three dimensional fields. 3/ For age, I concur with Jonathan, and recommend age to be in years, and will discuss this point in the report more clearly. 4/ There are multiple mixed layers already defined in CF. Mixed layer as defined by a density criteria (e.g., as in Levitus) is distinct from the depth that turbulent mixing occurs. There are physical reasons to request BOTH. We detail why in the ocean report. 5/ temperature flux question: > > I do not like "temperature flux" expressed as heat flux. There must > be some terms used in engineering and physics that are better for > this. Ablation of material surfaces remove energy both by removing > mass with a certain amount of internal energy and by energy required > to change the phase. Is anyone familiar with the terminology? > I too find this name unappealing. I suggest the following alternatives: temperature_flux_due_to_rainfall_expressed_as_heat_flux_into_sea_water --> heat_flux_into_sea_water_due_to_rainfall_mass_flux temperature_flux_due_to_evaporation_expressed_as_heat_flux_out_of_sea_water --> heat_flux_out_of_sea_water_due_to_evaporative_mass_flux temperature_flux_due_to_runoff_expressed_as_heat_flux_into_sea_water --> heat_flux_into_sea_water_due_to_runoff_mass_flux These new names are A/ shorter, B/ more directly what is intended physically; i.e., a heat flux due to a mass flux. 6/ snowfall question: > Also, are you sure you want only "rainfall", rather than > "precipitation" , which includes water falling out of the atmosphere > in the solid state (e.g., snow). Perhaps you need to "snowfall" > besides "rainfall" (because the snow likely melts when it hits the > ocean with the resultant latent heat transfer), but I didn't see > mention of "snow" on the list. > Good point. We do request snowfall as a mass flux. But since we are measuring heat flux from mass transfer, relative to 0C, then snow falling at 0C will not contribute any heat transfer due to mass transfer. But as you say, it will cause heat transfer from latent heat of fusion. This latent heat term was missing in our original report. For this latent heat, I suggest the name heat_flux_into_sea_water_due_to_snow_thermodynamics analogous to the other fields of this sort from icebergs and seaice. Best, Stephen -- Stephen M. Griffies phone: +1-609-452-6672 Geophysical Fluid Dynamics Laboratory FAX: +1-609-987-5063 Princeton Forrestal Campus Rte. 1 email: stephen.griffies at noaa.gov 201 Forrestal Road http://www.gfdl.noaa.gov/~smg Princeton, NJ 08542-0308 USA From rkl at bodc.ac.uk Mon Jan 12 07:51:09 2009 From: rkl at bodc.ac.uk (Roy Lowry) Date: Mon, 12 Jan 2009 14:51:09 +0000 Subject: [CF-metadata] Standardized region names Message-ID: Dear All, FYI there are a couple of activities in this area. SeaVoX has a draft ontology (see attached PDF) of water body names based largely (but NOT exclusively) on terms agreed by the IHO that will be supported by WFS-served coverage polygons. It is planned to use nodes in this ontology as hooks for local extensions. Some work has been proposed in the UK to develop extensions for the North Sea, Irish Sea, English Channel, Bristol Channel and "Inner Seas off the west coast of Scotland". Work is underway at NGDC in Boulder to ehnhance the geometries and maintenance infrastructure of the IHB Undersea Feature Names with a view to their publication through WFS. These may we worthy of consultation in any revision of the names for use in CF. Cheers, Roy. >>> Nan Galbraith 1/9/2009 6:08 pm >>> Reviving an old topic, the CF region names list is now out of date; there are 7 or 8 names on the GCMD list that have not been added to the CF document. They are: Bay Of Bengal Bay Of Fundy Davis Straight Georges Bank Grand Banks Gulf Of Maine Gulf Of St Lawrence And I'm not sure if you'd want to include it, but they list "South China And Eastern Archipelagic Seas" too. Should the CF list be updated in the next rev? I think GCMD is planning to come out with an update (any day now) anyway, but thought I'd mention this while I happen to be looking at it. > The list of regions can be found here: > http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standardized-region-names > 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 rkl at bodc.ac.uk Mon Jan 12 08:11:54 2009 From: rkl at bodc.ac.uk (Roy Lowry) Date: Mon, 12 Jan 2009 15:11:54 +0000 Subject: [CF-metadata] Attachment Message-ID: Dear All, Attachment from my previous e-mail cause size issues so I've posted it on FTP for anyone who is interested in directory ftp.pol.ac.uk/pub/bodc/ndg Cheers, Roy. -- 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 Jan 12 11:31:34 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Mon, 12 Jan 2009 18:31:34 +0000 Subject: [CF-metadata] new named fields for ocean Message-ID: <20090112183134.GA17165@met.reading.ac.uk> Dear Steve I would prefer keeping the sea_water in sea_water_pressure: > sea_water_pressure_at_the_sea_water_surface > sea_water_pressure_at_sea_floor It might seem redundant in this context but it corresponds to the standard name of sea_water_pressure, analogous to air_pressure. That means the pressure that exists in the medium of sea water. It doesn't imply that it is caused only by overlying sea water. > I too find this name unappealing. I suggest the following alternatives: > > temperature_flux_due_to_rainfall_expressed_as_heat_flux_into_sea_water > --> heat_flux_into_sea_water_due_to_rainfall_mass_flux > > temperature_flux_due_to_evaporation_expressed_as_heat_flux_out_of_sea_water > --> heat_flux_out_of_sea_water_due_to_evaporative_mass_flux > > temperature_flux_due_to_runoff_expressed_as_heat_flux_into_sea_water --> > heat_flux_into_sea_water_due_to_runoff_mass_flux > > These new names are A/ shorter, B/ more directly what is intended > physically; i.e., a heat flux due to a mass flux. When we had the earlier discussion, I proposed temperature flux because I think that temperature multiplied by mass flux is a quantity that people have to be careful with because of its arbitrary zero. In that respect it is not like a genuine heat flux. You can't tell what heat is being added unless you know the temperature and the mass of the water it's being added to. I thought "temperature flux" would draw attention to the way it was evaluated. To be more explicit, it is product_of_rainfall_temperature_and_rainfall_flux_expressed_as_heat_flux Without expressed_as_heat_flux it would be in K kg m-2 s-1 rather than W m-2. Maybe it's OK to omit _into_sea_water since rainfall flux is generally assumed to be at the surface, and this quantity exists equally over land. We would use cell_methods to restrict it to the sea part of the gridbox. The definition should also state what the zero of temperature is. Why do we want these quantities? Would be clearer and easier to ask for the rainfall_temperature and the temperature_of_water_flux_into_sea_water_from_rivers? I'm sorry that I hadn't thought about the evaporation before. I'm not sure what this means: isn't the evaporating water necessarily at surface temperature? The heat carried away is just the latent heat. Best wishes Jonathan From andrew.woolf at stfc.ac.uk Sat Jan 10 09:57:14 2009 From: andrew.woolf at stfc.ac.uk (Woolf, A (Andrew)) Date: Sat, 10 Jan 2009 16:57:14 -0000 Subject: [CF-metadata] EGU session ESSI9: "Data and Metadata Models & Mark-up Languages" Message-ID: (With apologies for any cross-posting, and please pass on to interested colleagues...) The deadline is now very close for submissions to the European Geosciences Union General Assembly 2009, to be held in Vienna 19-24 April. Please consider submitting an abstract to session ESSI9 "Data and Metadata Models & Mark-up Languages". Submissions are invited on topics including (but not limited to) the following: * Data and Metadata schemas for the Geosciences * Mark-up languages * Conceptual models for scientific data types * ISO coverages and features as different views onto data * Multi-dimensional data modeling * Observations and measurements models and schemas * Harmonization of data and metadata models for Geospatial Information and Earth and Space Sciences * Integrating binary formats with conceptual schemas and mark-up languages * Multilingualism * Data and metadata granularity * Discovery, evaluation and use metadata * Exposing data models through web-based services Please submit abstracts by this Tuesday 13 January 2009: http://meetingorganizer.copernicus.org/EGU2009/session/410 Many thanks, Andrew Woolf ----------------------------------------------------- Dr Andrew Woolf (andrew.woolf at stfc.ac.uk) Environmental e-Science and Spatial Informatics STFC e-Science Centre Rutherford Appleton Lab Chilton, Didcot, Oxon., OX11 0QX, UK Ph: +44 (0)1235 778027 http://www.e-science.stfc.ac.uk/organisation/staff/andrew_woolf -- Scanned by iCritical. -------------- next part -------------- An HTML attachment was scrubbed... URL: From taylor13 at llnl.gov Mon Jan 12 12:41:47 2009 From: taylor13 at llnl.gov (Karl Taylor) Date: Mon, 12 Jan 2009 11:41:47 -0800 Subject: [CF-metadata] new named fields for ocean In-Reply-To: <20090112183134.GA17165@met.reading.ac.uk> References: <20090112183134.GA17165@met.reading.ac.uk> Message-ID: <496B9CFB.5080507@llnl.gov> Dear Steve and Jonathan, [I'm not sure Steve was copied on your email Jonathan, so I have attached it in full below.] Concerning Jonathan's last point in his email below, I too wondered whether it wouldn't be more straight forward simply to save the temperature of the precipitation arriving at the surface. I also was surprised that the evaporating water might be at a different temperature than the surface it is leaving. If this is the case, I don't really see why the heat flux is given by the formula you specified. As I understand it evaporation is the residual difference between the H2O molecules leaving the liquid surface and the H2O vapor molecules entering the surface. Shouldn't the "energy flux" you are interested in here depend on these upward and downward fluxes of water mass explicitly in this case and not simply on the evaporation rate? One more general comment: even if precipitation and evaporating water molecules are both assumed to be at the same temperature as the surface water, the ocean energy can be changed through the mechanism you are attempting to account for (which is in addition to the latent heat flux). I'm concerned, however, that the atmosphere (in current models) won't "feel" the energy transfer implied by this additional flux. Suppose, for example, that evaporation occurs preferentially over warm regions of the ocean, and precipitation over cool regions. Then besides the latent heat transfer from ocean to atmosphere (which is accounted for by atmos. models and normally assumed to be independent of temperature), you will find the ocean loses additional energy (because the water molecules leaving the ocean through evaporation are warmer than the rain entering it). This implies that water molecules give up heat to the atmosphere (beyond the latent heat released), but I'm not sure our current models account for this. Do you know if this is one of the reasons that most coupled AOGCMs fail to conserve energy exactly? Or does the atmosphere model actually indirectly account for this gain of energy in some way (by use of virtual temperature?). Best regards, Karl Dear Steve I would prefer keeping the sea_water in sea_water_pressure: > > sea_water_pressure_at_the_sea_water_surface > > sea_water_pressure_at_sea_floor It might seem redundant in this context but it corresponds to the standard name of sea_water_pressure, analogous to air_pressure. That means the pressure that exists in the medium of sea water. It doesn't imply that it is caused only by overlying sea water. > > I too find this name unappealing. I suggest the following alternatives: > > > > temperature_flux_due_to_rainfall_expressed_as_heat_flux_into_sea_water > > --> heat_flux_into_sea_water_due_to_rainfall_mass_flux > > > > temperature_flux_due_to_evaporation_expressed_as_heat_flux_out_of_sea_water > > --> heat_flux_out_of_sea_water_due_to_evaporative_mass_flux > > > > temperature_flux_due_to_runoff_expressed_as_heat_flux_into_sea_water --> > > heat_flux_into_sea_water_due_to_runoff_mass_flux > > > > These new names are A/ shorter, B/ more directly what is intended > > physically; i.e., a heat flux due to a mass flux. When we had the earlier discussion, I proposed temperature flux because I think that temperature multiplied by mass flux is a quantity that people have to be careful with because of its arbitrary zero. In that respect it is not like a genuine heat flux. You can't tell what heat is being added unless you know the temperature and the mass of the water it's being added to. I thought "temperature flux" would draw attention to the way it was evaluated. To be more explicit, it is product_of_rainfall_temperature_and_rainfall_flux_expressed_as_heat_flux Without expressed_as_heat_flux it would be in K kg m-2 s-1 rather than W m-2. Maybe it's OK to omit _into_sea_water since rainfall flux is generally assumed to be at the surface, and this quantity exists equally over land. We would use cell_methods to restrict it to the sea part of the gridbox. The definition should also state what the zero of temperature is. Why do we want these quantities? Would be clearer and easier to ask for the rainfall_temperature and the temperature_of_water_flux_into_sea_water_from_rivers? I'm sorry that I hadn't thought about the evaporation before. I'm not sure what this means: isn't the evaporating water necessarily at surface temperature? The heat carried away is just the latent heat. Best wishes Jonathan _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http:// mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From Stephen.Griffies at noaa.gov Mon Jan 12 14:33:05 2009 From: Stephen.Griffies at noaa.gov (Stephen Griffies) Date: Mon, 12 Jan 2009 16:33:05 -0500 Subject: [CF-metadata] new named fields for ocean In-Reply-To: <20090112183134.GA17165@met.reading.ac.uk> References: <20090112183134.GA17165@met.reading.ac.uk> Message-ID: <496BB711.1070006@noaa.gov> Jonathan, I am happy to take your suggestions for the names. I have taken further discussion on the physics of these requested terms off-line. Best, Stephen > I would prefer keeping the sea_water in sea_water_pressure: >> sea_water_pressure_at_the_sea_water_surface >> sea_water_pressure_at_sea_floor Fine >> temperature_flux_due_to_rainfall_expressed_as_heat_flux_into_sea_water >> temperature_flux_due_to_evaporation_expressed_as_heat_flux_out_of_sea_water >> temperature_flux_due_to_runoff_expressed_as_heat_flux_into_sea_water Fine From Stephen.Griffies at noaa.gov Tue Jan 13 07:42:06 2009 From: Stephen.Griffies at noaa.gov (Stephen Griffies) Date: Tue, 13 Jan 2009 09:42:06 -0500 Subject: [CF-metadata] new named fields for ocean In-Reply-To: <496BB68C.2040401@noaa.gov> References: <20090112183134.GA17165@met.reading.ac.uk> <496B9CFB.5080507@llnl.gov> <496BB68C.2040401@noaa.gov> Message-ID: <496CA83E.8080106@noaa.gov> Hi, This email discusses the issue of why there are extra heat fluxes in ocean models with an open water budget, relative to ocean models that artificially close their water budget (i.e., ocean models employing a virtual tracer flux). I originally thought it best to have this discussion off-line, but some contacted me asking to continue online... Stephen Stephen Griffies wrote: > Karl and Jonathan, > > 1/ Regarding pressures: Jonathan, I am fine keeping the original names. > I will report back to the list with this point. > > 2/ Regarding the temperature fluxes: Jonathan, I am again happy > returning to the names that we originally came up with. More generally, > here are some comments... > > The issue of heat fluxes associated with the transfer of mass or volume > across the ocean boundary is a relatively new issue for CMIP. Indeed, > from my understanding, GFDL was perhaps amongst only one or two other > coupled models in AR4 that considered material transport across the > ocean surface associated with E-P+R. Delworth etal (2006) discussed the > point in its heat budget discussion. The remaining coupled models have a > closed water budget for the ocean (i.e., use virtual tracer fluxes). We > are not interested in retaining virtual tracer fluxes, and so had to > consider the implications of opening up the ocean to mass transport with > the atmosphere and land. Doing so adds this extra heat transfer term. We > wish to have a means for CMIP5 to record this term. It is clearly > written in the WGOMD report that virtual flux models will record zero > for this heat. > > To reiterate what we have already said: the transport of material > substance (water) across the seawater boundary has an associated > transfer of tracer mass. Correspondingly, there is a transfer of > tracer, including heat, since the water carries a nonzero temperature > and nonzero tracer concentration. For many cases, the water is fresh, > so it only carries a heat. But some river models are being considered > that carry tracer concentration. If we remove water (e.g., through > evaporation), then we remove heat. The heat transfer associated with > phase changes is in ADDITION to the heat associated with mass transport. > > Most modelers consider rain falling into the ocean to enter at the SST, > as well as the water evaporating to be at the SST. But how one > specifies the tracer concentration or temperature of the water > transferred across the boundary is not relevant to the discussion. All > I wish to have is the total amount of heat transferred to/from the ocean > with the water mass, referenced to 0C. > > As Karl noted, atmospheric models generally do not carry a temperature > for the moisture. But this present limitation of the atmospheric models > should not force us to shut down the ocean's water cycle. That decision > would lead us back to virtual tracer fluxes, which are not desirable > from an oceanographic perspective. Atmospheric modelers inform me that > the non-conservation associated with not carrying temperature of their > moisture is small, so I should quit bothering them with this issue... > > > Steve > From m.schultz at fz-juelich.de Wed Jan 14 04:01:47 2009 From: m.schultz at fz-juelich.de (Schultz, Martin) Date: Wed, 14 Jan 2009 12:01:47 +0100 Subject: [CF-metadata] new standard names for atmospheric dynamics Message-ID: <2E9C45494F78A3498A77616E7C2DBB4C01B3B087@icg217.icg-ii-w2k.kfa-juelich.de> Dear all, I just checked the standard_name table on http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/11/standard-name-table and couldn't find anything suitable for the following variables which we produce in ECHAM. As I am trying to add standard names to the model output, I am wondering if these could be defined relatively easily. My apologies if they were discussed already - I haven't checked the email archive carfully. longname = 'air mass in grid box' proposed standard_name: air_mass units: kg longname = 'volume of grid box' proposed standard_name: grid_box_volume units: m3 longname = 'height of grid box' proposed standard_name: grid_box_height units: m longname = 'upper tropopause level index' proposed standard_name: upper_tropopause_level_index units: index longname = 'lower tropopause level index'note: this is a diagnostic using the WMO criterion. proposed standard_name: lower_tropopause_level_index units: index Note: The tropopause is not always unequivocally defined in this way, this is why we defined an upper and lower level index. The tropopause height is already defined as "tropopause_altitude", but in units of m. longname='precipitation formation rate' proposed standard_name: precipitation_formation_flux units: kg m-2 s-1 or: tendency_of_precipitation_flux_due_to_formation longname='precipitation evaporation rate' proposed standard_name: precipitation_evaporation_flux units: kg m-2 s-1 or: tendency_of_precipitation_flux_due_to_evaporation longname='fraction of gridbox occupied by updrafts' seems to be defined already as convective_cloud_area_fraction_in_atmosphere_layer (OK) 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 J?lich GmbH 52425 J?lich Sitz der Gesellschaft: J?lich Eingetragen im Handelsregister des Amtsgerichts D?ren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in B?rbel Brumme-Bothe Gesch?ftsf?hrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- ------------------------------------------------------------------- From j.m.gregory at reading.ac.uk Wed Jan 14 04:37:44 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Wed, 14 Jan 2009 11:37:44 +0000 Subject: [CF-metadata] new standard names for atmospheric dynamics Message-ID: <20090114113744.GB2056@met.reading.ac.uk> Dear Martin > longname = 'air mass in grid box' > proposed standard_name: air_mass units: kg This could be just air_mass (or would mass_of_air be better, since "air mass" is a meteorological term). The fact that's in a gridbox is implied by its being a gridded quantity, and the cell_methods can indicate it's the sum in the box - an extensive quantity. There is a stdname sea_ice_mass following this idea. > longname = 'volume of grid box' > proposed standard_name: grid_box_volume units: m3 cell_volume has been discussed before. > > longname = 'height of grid box' > proposed standard_name: grid_box_height units: m cell_thickness is currently under consideration for ocean and would apply equally to atmos. > longname = 'upper tropopause level index' > proposed standard_name: upper_tropopause_level_index units: index > longname = 'lower tropopause level index'note: this is a diagnostic using the WMO criterion. proposed standard_name: lower_tropopause_level_index units: index > Note: The tropopause is not always unequivocally defined in this way, this is why we defined an upper and lower level index. The tropopause height is already defined as "tropopause_altitude", but in units of m. Could you formulate these as model_level_number_at_X? There are already several standard names of that form. > longname='precipitation formation rate' > proposed standard_name: precipitation_formation_flux units: kg m-2 s-1 > or: tendency_of_precipitation_flux_due_to_formation > > longname='precipitation evaporation rate' > proposed standard_name: precipitation_evaporation_flux units: kg m-2 s-1 > or: tendency_of_precipitation_flux_due_to_evaporation It doesn't seem quite right for it to be a tendency of precipitation flux. Since the precip flux is already kg m-2 s-1, a tendency would be kg m-2 s-2. Perhaps it is a tendency of the mass of precipitation, or the mass content or concentration of precipitation, or maybe a vertical divergence of the flux? Best wishes Jonathan From taylor13 at llnl.gov Wed Jan 14 18:57:10 2009 From: taylor13 at llnl.gov (Karl Taylor) Date: Wed, 14 Jan 2009 17:57:10 -0800 Subject: [CF-metadata] new named fields for ocean In-Reply-To: References: Message-ID: <496E97F6.1060505@llnl.gov> Dear Alison and Stephen, A few comments on the ocean standard names: > > 2.10 cell_mass_per_area; kg m-2. Does this mean the mass per unit area > of the sea water contained within each grid cell? If so, I suggest the > name should be mass_of_sea_water_per_unit_area which would be similar to > the existing name atmosphere_mass_of_air_per_unit_area. We distinguish currently between atmosphere_mass_per_unit_area and atmosphere_mass_of_air_per_unit_area (which only accounts for the gaseous constituents, not, for example, precipitation). For the oceans I think Stephen wants to save the total mass, i.e., seawater_mass_per_unit_area. > > > 7.5 heat_flux_into_sea_water_due_to_sea_ice_thermodynamics; W m-2. OK. In CMIP3 we collected upward_sea_ice_basal_heat_flux, which is a CF standard name, which we described in CMIP3 as "Compute the average rate that heat flows up at the base of the sea ice (i.e., Watts) divided by the average area of the grid cell covered by sea ice. This quantity multiplied both by the average area covered by sea ice and by the length of the month should yield the total energy flowing into the ice from below. Report as 0.0 in regions free of sea ice." Is that the same thing except for a factor that is the fraction of the ocean covered by seaice? > 9.12 > ocean_kinetic_energy_dissipation_per_unit_area_due_to_vertical_friction; > W m-2. OK. I don't find this particularly enlightening. What distinguishes "vertical friction" for other friction? best regards, Karl From Stephen.Griffies at noaa.gov Thu Jan 15 14:40:56 2009 From: Stephen.Griffies at noaa.gov (Stephen Griffies) Date: Thu, 15 Jan 2009 16:40:56 -0500 Subject: [CF-metadata] new named fields for ocean In-Reply-To: <496E97F6.1060505@llnl.gov> References: <496E97F6.1060505@llnl.gov> Message-ID: <496FAD68.2090102@noaa.gov> Karl, I include here responses for two of your three questions. The sea ice flux question awaits input from ice folks here, to see how the new request compares to CMIP3. Best, Stephen Karl Taylor wrote: > Dear Alison and Stephen, > > A few comments on the ocean standard names: > >> >> 2.10 cell_mass_per_area; kg m-2. Does this mean the mass per unit area >> of the sea water contained within each grid cell? If so, I suggest the >> name should be mass_of_sea_water_per_unit_area which would be similar to >> the existing name atmosphere_mass_of_air_per_unit_area. > > We distinguish currently between atmosphere_mass_per_unit_area and > atmosphere_mass_of_air_per_unit_area (which only accounts for the > gaseous constituents, not, for example, precipitation). For the > oceans I think Stephen wants to save the total mass, i.e., > seawater_mass_per_unit_area. >> For non-Boussinesq models, I wish to have the mass of seawater in a grid cell, per horizontal area of the cell. This mass includes all dissolved tracers, as well as liquid water, hence the name "seawater mass". I do not have a strong feeling for whether "mass_of_sea_water_per_unit_area" is preferable to "seawater_mass_per_unit_area", as they both seem to refer to the same thing. In my updated report, it reads "mass_of_sea_water_per_unit_area". Please advise if you wish this name to change. >> 9.12 >> ocean_kinetic_energy_dissipation_per_unit_area_due_to_vertical_friction; >> W m-2. OK. > > I don't find this particularly enlightening. What distinguishes > "vertical friction" for other friction? > Ocean models generally use lateral friction with a huge viscosity set according to the needs of numerical stability constraints. In contrast, vertical friction uses a much smaller viscosity that is more aligned with physical closures (though far from being derived from first principles). In studying the kinetic energy budget in ocean simulations, it is very useful to know how much energy is dissipated from horizontal friction, and how much is separately dissipated from vertical friction. It is for this reason that we request saving energy dissipation from vertical friction separate from horizontal friction. We ask for both terms. There are endnotes that detail the precise nature of what is requested. Best, Stephen > best regards, > Karl -- Stephen M. Griffies phone: +1-609-452-6672 Geophysical Fluid Dynamics Laboratory FAX: +1-609-987-5063 Princeton Forrestal Campus Rte. 1 email: stephen.griffies at noaa.gov 201 Forrestal Road http://www.gfdl.noaa.gov/~smg Princeton, NJ 08542-0308 USA From brian.hand at grizmail.umt.edu Fri Jan 16 11:33:15 2009 From: brian.hand at grizmail.umt.edu (Hand, Brian) Date: Fri, 16 Jan 2009 11:33:15 -0700 Subject: [CF-metadata] Question about cf conventions-dimensionless coordinates Message-ID: <3C864C6F35A7594AA1FDC0CC9CC19BCFFBFC09@MUMMAILVS3.gs.umt.edu> I'm trying to find out some general information about cf 1.3/1.4. For the standard_name land_ice_sigma_coordinate, I wanted to know if there is a formula definition? I've run it through the compliance checker to tell me that there is no formula for the formula_terms specified. I guess I'm a little bit unclear on the dimensionless coordinates in general. It says only the ones under Appendix D? have formula definitions? Are some user defined? Thanks, Brian. From j.m.gregory at reading.ac.uk Sat Jan 17 09:10:29 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Sat, 17 Jan 2009 16:10:29 +0000 Subject: [CF-metadata] Question about cf conventions-dimensionless coordinates Message-ID: <20090117161029.GB15641@met.reading.ac.uk> Dear Brian You are quite right. This is an omission; we do need a formula for the working out the altitude coord from the land-ice sigma coord. Is it correct that sigma is 0 at the bed and 1 and the surface? If so I reckon the formula is surface_altitude(n,k,j,i) = bedrock_altitude(n,j,i) + land_ice_thickness(n,j,i)*land_ice_sigma_coordinate(k) where i,j are horizontal gridpoint indices, k level, n time. I'd propose formula terms of bedrock_altitude, land_ice_thickness and land_ice_sigma_coordinate. These are all standard names. In most of the formulae we have used abbreviations to identify the terms, but why not spell them out? Best wishes Jonathan From r.s.hatcher at reading.ac.uk Mon Jan 19 02:30:08 2009 From: r.s.hatcher at reading.ac.uk (Rosalyn Hatcher) Date: Mon, 19 Jan 2009 09:30:08 +0000 Subject: [CF-metadata] CF Checker 1.4 Message-ID: <49744820.5000909@reading.ac.uk> Dear All, I have updated the CF checker at http://puma.nerc.ac.uk/cgi-bin/cf-checker.pl to implement checks for CF-1.4 as detailed in Trac Ticket #43 (One of the cell_methods recommendations has yet to be implemented as it's a bit more complex, but I hope to get around to that soon.) I have tested the changes on a very limited set of netcdf files that I've cobbled together from examples in the CF Document. If anyone has any CF-1.4 compliant netcdf files I would be grateful if you could send me a few. If you find any problems please let me know. Assuming all is well I'll arrange for the version on the BADC site to be upgraded next week. Regards, Ros. -- ------------------------------------------------------------------------ Rosalyn Hatcher NCAS Computational Modelling Services Dept. of Meteorology, University of Reading, Earley Gate, Reading. RG6 6BB Email: r.s.hatcher at reading.ac.uk Tel: +44 (0) 118 378 6016 From m.schultz at fz-juelich.de Mon Jan 19 03:20:46 2009 From: m.schultz at fz-juelich.de (Schultz, Martin) Date: Mon, 19 Jan 2009 11:20:46 +0100 Subject: [CF-metadata] new standard names for atmospheric dynamics In-Reply-To: References: Message-ID: <2E9C45494F78A3498A77616E7C2DBB4C01C16D26@icg217.icg-ii-w2k.kfa-juelich.de> Dear Jonathan, > 1) proposed standard_name: air_mass units: kg so you agree with "air_mass". Great! I don't think that the common meteorological definition of air mass would be in conflict with this, since we somehow assume that one grid box contains an "air mass" with characteristic properties. Only potential problem is with astronomy ;-) Wikipedia lists: "In astronomy, airmass is the optical path length through Earth's atmosphere for light from a celestial source." > 2) proposed standard_name: grid_box_volume units: m3 cell_volume is fine with me. It would be great if one could perform a fulltext search on the archive. Haven't found this option, and this makes it a bit hard to find that previous discussion. Or is there another way except downloading the archive, unzipping it and perform a "grep..."? > 3) proposed standard_name: grid_box_height units: m cell_thickness suits me just as well. > 4) proposed standard_name: upper_tropopause_level_index units: index model_level_number_at_tropopause is OK. The philosophical distinction between the "upper" and "lower" tropopause could be done in the cell_methods field if needed? > 5) proposed standard_name: precipitation_formation_flux units: kg m-2 s-1 > or: tendency_of_precipitation_flux_due_to_formation > > proposed standard_name: precipitation_evaporation_flux units: kg m-2 s-1 > or: tendency_of_precipitation_flux_due_to_evaporation > > It doesn't seem quite right for it to be a tendency of precipitation flux. > Since the precip flux is already kg m-2 s-1, a tendency would be kg m-2 s-2. > Perhaps it is a tendency of the mass of precipitation, or the mass content or > concentration of precipitation, or maybe a vertical divergence of the flux? This is difficult. In principle, "tendency_of_precipitation_mass" (or something like it) would be right. BUT the beauty of these variables is that they distinguish between formation and loss. OK - I just found the "due_to_production" concept again. So, perhaps we can agree on tendency_of_precipitation_mass_due_to_formation and tendency_of_precipitation_mass_due_to_evaporation But then: have we already agreed on the sign for the latter? Did we have a similar discussion for chemical processes already? There would be potentially a lot of terms like tendency_of_ozone_due_to_chemical_production or tendency_of_ozone_due_to_chemical_loss with a similar problem. I checked on Christiane's wiki site but couldn't find anything on this. BTW: where are we with respect to all the new chemical names that were proposed? It would be great if we could soon see them somehow embedded in the standard_name table as preparations for the next IPCC runs are ongoing and we should be prepared for that. My recommendation would be the following: Add the "concept names" as given on Christiane's wiki into the standard_name table using "X" as surrogate for the chemical species. If a note appears at the top of the table saying that "X" is a placeholder and must be replaced by a meaningful chemical name, then everyone should be able to understand this. Then, add a new "compound" table (potentially a link onto such a table on Christiane's site would do?), where accepted entries for "X" would be listed. This still leaves the problem that not all processes are valid for all "X", but I would judge this as a far minor problem than the existing problem that we don't have these names defined or that the table would pretty much explode if we spell out all chemical standard names explicitly. Normally, we shouldn't expect to ever receive any model output with process-species pairs that are nonsense, as the models should only generate meaningful variables in the first place. 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. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- ------------------------------------------------------------------- From j.d.blower at reading.ac.uk Mon Jan 19 03:36:15 2009 From: j.d.blower at reading.ac.uk (Jon Blower) Date: Mon, 19 Jan 2009 10:36:15 +0000 Subject: [CF-metadata] Fwd: CF Checker 1.4 In-Reply-To: <2bb6ee950901190235u3eb6561apaeafc38ae639d882@mail.gmail.com> References: <49744820.5000909@reading.ac.uk> <2bb6ee950901190235u3eb6561apaeafc38ae639d882@mail.gmail.com> Message-ID: <2bb6ee950901190236v16074cabj6954fb873501748b@mail.gmail.com> Dear Rosalyn, Thanks very much for this update. I was wondering if it might be helpful to clarify on this page the aspects of CF that the checker cannot (or does not) check? For example, if a data provider does not set the _FillValue correctly, this cannot be checked automatically because the checker would have no way of knowing in advance which cells should be marked in this way. Such a data file would be parsed incorrectly by tools. (This is a real example by the way - people often send me data files that have been checked using the checker but still have problems - presumably because the checker can, generally speaking, only check syntax, not semantics.) Best wishes, Jon P.S. In the case of _FillValue I guess you could apply a non-exact method: if "a lot" of cells in a file have exactly the same value then there's a fair chance this is supposed to be a _FillValue - perhaps this information could be used to raise a warning to the user, even if it's not enough to spot an error with certainty? 2009/1/19 Rosalyn Hatcher : > Dear All, > > I have updated the CF checker at > http://puma.nerc.ac.uk/cgi-bin/cf-checker.pl to implement checks for CF-1.4 > as detailed in Trac Ticket #43 (One of the cell_methods recommendations has > yet to be implemented as it's a bit more complex, but I hope to get around > to that soon.) > > I have tested the changes on a very limited set of netcdf files that I've > cobbled together from examples in the CF Document. If anyone has any CF-1.4 > compliant netcdf files I would be grateful if you could send me a few. > > If you find any problems please let me know. Assuming all is well I'll > arrange for the version on the BADC site to be upgraded next week. > > Regards, > Ros. > > -- > ------------------------------------------------------------------------ > Rosalyn Hatcher > NCAS Computational Modelling Services > Dept. of Meteorology, University of Reading, Earley Gate, Reading. RG6 6BB > Email: r.s.hatcher at reading.ac.uk Tel: +44 (0) 118 378 6016 > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -- 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 j.m.gregory at reading.ac.uk Tue Jan 20 02:10:56 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 20 Jan 2009 09:10:56 +0000 Subject: [CF-metadata] new standard names for atmospheric dynamics Message-ID: <20090120091056.GA28001@met.reading.ac.uk> Dear Martin > > 1) proposed standard_name: air_mass units: kg > Actually I am concerned about this: > I don't think that the common > meteorological definition of air mass would be in conflict with this I do think it could be confusing, and that mass_of_air would be better to avoid this confusion. > It would be great if one could perform a > fulltext search on the archive. When I want to do this, I view the "downloadable version" in the browser e.g. http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2009.txt and search it with text-search (find in this page). > > 4) proposed standard_name: upper_tropopause_level_index units: > index > > model_level_number_at_tropopause is OK. The philosophical distinction > between the "upper" and "lower" tropopause could be done in the > cell_methods field if needed? I don't think so, as that is more intended for statistical variation within a cell. What is the distinction? If there are two kinds of tropopause, it would be best to give then distinct "surface" names for the at_SURFACE phrase. > tendency_of_precipitation_mass_due_to_formation > and > tendency_of_precipitation_mass_due_to_evaporation I would suggest that "condensation" might be a more obvious opposite to "evaporation". I wonder why you want these to be kg s-1 and not kg m-2 s-1? Most existing names are per m2 e.g. tendency_of_atmosphere_mass_per_unit_area. If also it is going to be a function of a vertical coordinate as well, maybe kg m-3 would be preferable i.e. a mass_concentration. Then it would be intensive in all special dimensions. I think we should try to avoid a potential confusion about whether precipitation specifically means something arriving at the surface (as it does in almost all existing names) or something in the body of the atmosphere. We could say tendency_of_atmosphere_mass_of_precipitation_due_to_X to get round this. If they were kg m-2 s-1 they would be tendency_of_atmosphere_mass_content_of_precipitation_due_to_X which is a construction we have used for many chemical species. tendency is a signed quantity; it's just a derivative wrt time. Hence it is positive for condensation and negative for evaporation. I agree that it would be helpful to clarify that in the guidelines. I expect that Alison will summarise the status of the chemical names. My impression of the debate was that the preference was for including all names explicitly for the moment in the table, to ensure they are all sensible, but I'll wait for Alison's conclusion. Yes, there are many names to be agreed for AR5 runs. Best wishes Jonathan From atb299 at noc.soton.ac.uk Tue Jan 20 04:48:21 2009 From: atb299 at noc.soton.ac.uk (Blaker A.T.) Date: Tue, 20 Jan 2009 11:48:21 +0000 Subject: [CF-metadata] Some new standard names for ocean model fields In-Reply-To: <20090120091056.GA28001@met.reading.ac.uk> Message-ID: <351EEAB3365AFF4BAE56D8DB1926C7AF6301A9012A@UOS-CL-EX7-L1.soton.ac.uk> Dear all, I would like to propose some new standard names for ocean fields:- "barotropic_sea_water_x_velocity" ; (m s-1) "barotropic_sea_water_y_velocity" ; (m s-1) (same quantities as barotropic_eastward_sea_water_velocity and barotropic_northward_sea_water_velocity, but for use on a non-standard grid) "ocean_heat_x_transport" ; (w) "ocean_heat_y_transport" ; (w) "ocean_salt_x_transport" ; (1e-3 kg s-1) "ocean_salt_y_transport" ; (1e-3 kg s-1) (again, same as the existing northward/eastward names, but for non-standard grid) "mass_x_transport_of_sea_water_due_to_advection" ; (kg s-1) "mass_y_transport_of_sea_water_due_to_advection" ; (kg s-1) "mass_x_transport_of_sea_water_due_to_advection_and_bolus_advection" ; (kg s-1) "mass_y_transport_of_sea_water_due_to_advection_and_bolus_advection" ; (kg s-1) (mass transports on a non-standard grid) "tendency_of_sea_water_temperature" ; (K s-1) "tendency_of_sea_water_salinity" ; (1e-3 s-1) (the total tendencies of t and s) "ocean_montgomery_potential" ; (m2 s-2) (the ocean Montgomery potential) "water_flux_into_sea_water_from_rivers_and_surface_water_flux" ; (kg m-2 s-1) (P-E+runoff, does not include water flux to/from sea_ice ) I welcome any comments on these proposed names. Adam Blaker Climate Modeller National Oceanography Centre, Southampton From brian.hand at grizmail.umt.edu Tue Jan 20 20:08:57 2009 From: brian.hand at grizmail.umt.edu (Hand, Brian) Date: Tue, 20 Jan 2009 20:08:57 -0700 Subject: [CF-metadata] cf-conventions-dimensionless coordinates Message-ID: <3C864C6F35A7594AA1FDC0CC9CC19BCFFBFC0E@MUMMAILVS3.gs.umt.edu> Thanks Jonathan for the response. I just wanted to get more clarification about standard_names in general. Johnathan mentioned this was an omission, meaning a unique formula is associated with certain standard_names that represent dimensionless coordinates. I ask because I wasn't sure if it was possible to define a formula or those were set by the use of the standard name and really the only wiggle room you have is in the variables you choose for the formula terms? The equation proposed looks good, though I think for our model at least we define 0 as the surface and 1 as the bed, but could be mistaken. Thanks, Brian. From j.m.gregory at reading.ac.uk Wed Jan 21 04:27:22 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Wed, 21 Jan 2009 11:27:22 +0000 Subject: [CF-metadata] Fwd: cf-conventions-dimensionless coordinates Message-ID: <20090121112722.GC4744@met.reading.ac.uk> Dear Brian Maybe it is generally the case that sigma=0 is the surface and sigma=1 is the bed in ice-sheet models. In some cases there could be more than one formula for a given dimensionless vertical coordinate, as there are different ways of using it. The various formulae could have different selections of terms. Best wishes Jonathan From rkl at bodc.ac.uk Wed Jan 21 05:29:22 2009 From: rkl at bodc.ac.uk (Roy Lowry) Date: Wed, 21 Jan 2009 12:29:22 +0000 Subject: [CF-metadata] Some new standard names for ocean model fields Message-ID: Hi Adam, 'water_flux_into_sea_water_from_rivers_and_surface_water_flux' seems a bit of a mouthfull. Could we express the same meaning as 'total_water_flux_into_sea_water' where total is defined as 'water from all inputs'? Cheers, Roy. >>> "Blaker A.T." 1/20/2009 11:48 am >>> Dear all, I would like to propose some new standard names for ocean fields:- "barotropic_sea_water_x_velocity" ; (m s-1) "barotropic_sea_water_y_velocity" ; (m s-1) (same quantities as barotropic_eastward_sea_water_velocity and barotropic_northward_sea_water_velocity, but for use on a non-standard grid) "ocean_heat_x_transport" ; (w) "ocean_heat_y_transport" ; (w) "ocean_salt_x_transport" ; (1e-3 kg s-1) "ocean_salt_y_transport" ; (1e-3 kg s-1) (again, same as the existing northward/eastward names, but for non-standard grid) "mass_x_transport_of_sea_water_due_to_advection" ; (kg s-1) "mass_y_transport_of_sea_water_due_to_advection" ; (kg s-1) "mass_x_transport_of_sea_water_due_to_advection_and_bolus_advection" ; (kg s-1) "mass_y_transport_of_sea_water_due_to_advection_and_bolus_advection" ; (kg s-1) (mass transports on a non-standard grid) "tendency_of_sea_water_temperature" ; (K s-1) "tendency_of_sea_water_salinity" ; (1e-3 s-1) (the total tendencies of t and s) "ocean_montgomery_potential" ; (m2 s-2) (the ocean Montgomery potential) "water_flux_into_sea_water_from_rivers_and_surface_water_flux" ; (kg m-2 s-1) (P-E+runoff, does not include water flux to/from sea_ice ) I welcome any comments on these proposed names. Adam Blaker Climate Modeller National Oceanography Centre, Southampton _______________________________________________ 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 atb299 at noc.soton.ac.uk Wed Jan 21 06:25:12 2009 From: atb299 at noc.soton.ac.uk (Blaker A.T.) Date: Wed, 21 Jan 2009 13:25:12 +0000 Subject: [CF-metadata] Some new standard names for ocean model fields In-Reply-To: Message-ID: <351EEAB3365AFF4BAE56D8DB1926C7AF6301CBF688@UOS-CL-EX7-L1.soton.ac.uk> Hi Roy, There already exists a standard name 'water_flux_into_sea_water' which is effectively water from all inputs. My proposed name only includes the P-E and the runoff from rivers. It does not include the effects of sea ice or any flux corrections. I think in this case, and comparing with other similar existing names relating to water fluxes, it is better to be explicit about what is included and what is not included. Cheers, Adam > -----Original Message----- > From: Roy Lowry [mailto:rkl at bodc.ac.uk] > Sent: 21 January 2009 12:29 > To: cf-metadata at cgd.ucar.edu; Blaker A.T. > Subject: Re: [CF-metadata] Some new standard names for ocean model fields > > Hi Adam, > > 'water_flux_into_sea_water_from_rivers_and_surface_water_flux' seems a bit > of a mouthfull. Could we express the same meaning as > 'total_water_flux_into_sea_water' where total is defined as 'water from > all inputs'? > > Cheers, Roy. > > >>> "Blaker A.T." 1/20/2009 11:48 am >>> > Dear all, > > I would like to propose some new standard names for ocean fields:- > > > "barotropic_sea_water_x_velocity" ; (m s-1) > "barotropic_sea_water_y_velocity" ; (m s-1) > (same quantities as barotropic_eastward_sea_water_velocity and > barotropic_northward_sea_water_velocity, but for use on a non-standard > grid) > > > "ocean_heat_x_transport" ; (w) > "ocean_heat_y_transport" ; (w) > "ocean_salt_x_transport" ; (1e-3 kg s-1) > "ocean_salt_y_transport" ; (1e-3 kg s-1) > (again, same as the existing northward/eastward names, but for non- > standard grid) > > > "mass_x_transport_of_sea_water_due_to_advection" ; (kg s-1) > "mass_y_transport_of_sea_water_due_to_advection" ; (kg s-1) > "mass_x_transport_of_sea_water_due_to_advection_and_bolus_advection" ; (kg > s-1) > "mass_y_transport_of_sea_water_due_to_advection_and_bolus_advection" ; (kg > s-1) > (mass transports on a non-standard grid) > > > "tendency_of_sea_water_temperature" ; (K s-1) > "tendency_of_sea_water_salinity" ; (1e-3 s-1) > (the total tendencies of t and s) > > > "ocean_montgomery_potential" ; (m2 s-2) > (the ocean Montgomery potential) > > > "water_flux_into_sea_water_from_rivers_and_surface_water_flux" ; (kg m-2 > s-1) > (P-E+runoff, does not include water flux to/from sea_ice ) > > > > I welcome any comments on these proposed names. > > > Adam Blaker > > Climate Modeller > National Oceanography Centre, Southampton > > > _______________________________________________ > 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 Wed Jan 21 07:05:43 2009 From: rkl at bodc.ac.uk (Roy Lowry) Date: Wed, 21 Jan 2009 14:05:43 +0000 Subject: [CF-metadata] Some new standard names for ocean model fields Message-ID: Apologies, I'd misread your explanation as the term including flux from sea ice. Cheers, Roy. >>> "Blaker A.T." 1/21/2009 1:25 pm >>> Hi Roy, There already exists a standard name 'water_flux_into_sea_water' which is effectively water from all inputs. My proposed name only includes the P-E and the runoff from rivers. It does not include the effects of sea ice or any flux corrections. I think in this case, and comparing with other similar existing names relating to water fluxes, it is better to be explicit about what is included and what is not included. Cheers, Adam > -----Original Message----- > From: Roy Lowry [mailto:rkl at bodc.ac.uk] > Sent: 21 January 2009 12:29 > To: cf-metadata at cgd.ucar.edu; Blaker A.T. > Subject: Re: [CF-metadata] Some new standard names for ocean model fields > > Hi Adam, > > 'water_flux_into_sea_water_from_rivers_and_surface_water_flux' seems a bit > of a mouthfull. Could we express the same meaning as > 'total_water_flux_into_sea_water' where total is defined as 'water from > all inputs'? > > Cheers, Roy. > > >>> "Blaker A.T." 1/20/2009 11:48 am >>> > Dear all, > > I would like to propose some new standard names for ocean fields:- > > > "barotropic_sea_water_x_velocity" ; (m s-1) > "barotropic_sea_water_y_velocity" ; (m s-1) > (same quantities as barotropic_eastward_sea_water_velocity and > barotropic_northward_sea_water_velocity, but for use on a non-standard > grid) > > > "ocean_heat_x_transport" ; (w) > "ocean_heat_y_transport" ; (w) > "ocean_salt_x_transport" ; (1e-3 kg s-1) > "ocean_salt_y_transport" ; (1e-3 kg s-1) > (again, same as the existing northward/eastward names, but for non- > standard grid) > > > "mass_x_transport_of_sea_water_due_to_advection" ; (kg s-1) > "mass_y_transport_of_sea_water_due_to_advection" ; (kg s-1) > "mass_x_transport_of_sea_water_due_to_advection_and_bolus_advection" ; (kg > s-1) > "mass_y_transport_of_sea_water_due_to_advection_and_bolus_advection" ; (kg > s-1) > (mass transports on a non-standard grid) > > > "tendency_of_sea_water_temperature" ; (K s-1) > "tendency_of_sea_water_salinity" ; (1e-3 s-1) > (the total tendencies of t and s) > > > "ocean_montgomery_potential" ; (m2 s-2) > (the ocean Montgomery potential) > > > "water_flux_into_sea_water_from_rivers_and_surface_water_flux" ; (kg m-2 > s-1) > (P-E+runoff, does not include water flux to/from sea_ice ) > > > > I welcome any comments on these proposed names. > > > Adam Blaker > > Climate Modeller > National Oceanography Centre, Southampton > > > _______________________________________________ > 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 Wed Jan 21 07:53:30 2009 From: ngalbraith at whoi.edu (Nan Galbraith) Date: Wed, 21 Jan 2009 09:53:30 -0500 Subject: [CF-metadata] new named fields for ocean (algorithms) In-Reply-To: <4967A50D.6070602@noaa.gov> References: <4967A50D.6070602@noaa.gov> Message-ID: <497736EA.5090708@whoi.edu> > My desire is to have the CMIP5 participants archive their equation of > state and seawater freezing equation. Do you think we need to make > these Fortran codes into a CF standard name? Perhaps we can just > consider this issues as part of the CMIP5 request outside of CF. Just another suggestion on this part of the thread; we store algorithms as attributes, which has much less overhead than creating variables. They can be globals or attributes of the variables to which they're applied. There's nothing to prevent the development and use of a set of standard terms to identify common algorithms - but as far as I know this list doesn't exist - yet. Cheers - Nan -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* From Siobhan.O'farrell at csiro.au Thu Jan 22 00:51:45 2009 From: Siobhan.O'farrell at csiro.au (Siobhan.O'farrell at csiro.au) Date: Thu, 22 Jan 2009 18:51:45 +1100 Subject: [CF-metadata] New Cryospheric variables Message-ID: Dear all, In November/December I circulated a list of cryospheric variables for suggested collection by the CMIP 5 models through the cryospheric community for comment. An updated version of the document with revisions following input from the community is available at http://cherax.hpsc.csiro.au/users/ofa001/Cryosphere.doc (you might need to paste and cut it into browser) Jonathan Gregory pointed out the need to have new variables agreed on by this cf-metadata discussion list and I have highlighted in the document in red, new variable names which follow the CF standard name conventions. I started this process before Christmas, but due to the longer SH summer break have only just completed it. Many of the variables have been selected so that the cryospheric community can better understand thermodynamic and dynamic budgets of sea ice and additional variables have been added to categorise snow cover and permafrost regions. Some of the variables particularly in relation to the ice sheets are unlikely to be available in many models for CMIP5 timeframe but have been included for the period when the climate community Earth system models do include ice sheet/permafrost models. The new suggested names for sea ice thermodynamic variables are Sea_ice_albedo, Sea_ice_thickness_in_sea_ice_categories, Sea_ice_area_fraction_in_sea_ice_categories, Sea_ice_salinity, Surface_temperature_in_sea_ice, Temperature_at_sea_ice_snow_interface, Sea_ice_age, Sea_ice_growth_due_to_frazil_ice, Sea_ice_growth_due_to_congelation_ice, Sea_ice_growth_due_to_lateral_accretion, Sea_ice_growth_due_to_snow_ice_formation, Sea_ice_melt_amount_at_ice_surface, Sea_ice_melt_amount_at_ice_base, Sea_ice_melt_amount_at_lateral_sides, Sea_ice_total_heat_content, Downward_shortwave_flux_at_sea_ice_surface, Shortwave_flux_absorbed_in_sea_ice, Downward_longwave_flux_at_sea_ice_surface, Upward_longwave_flux_at_sea_ice_surface, Sensible_heat_flux_at_sea_ice_surface, Latent_heat_flux_at_sea_ice_surface, Downward_sea_ice_freshwater_flux. For sea ice dynamic variables Eastward_sea_ice_transport, Northward_sea_ice_transport, Sea_ice_volume_transport_at_Fram_strait, Downward_eastward_atmospheric_stress_at_sea_ice_surface, Downward_northward_atmospheric_stress_at_sea_ice_surface, Downward_northward_oceanic_stress_at_sea_ice_base, Downward_eastward_oceanic_stress_at_sea_ice_base, Eastward_internal_stress_at_sea_ice_base, Northward_internal_stress_in_sea_ice, Eastward_coriolis_stress_in_sea_ice, Northward_coriolis_stress_in_sea_ice, Eastward_sea_surface_tilt_stress_in_sea_ice, Northward_sea_surface_tilt_stress_in_sea_ice, Sea_ice_strain_rate_due_to_divergence, Sea_ice_strain_rate_due_to_shear, Sea_ice_ridging_rate. For land surface variables Snow_density, Snow_age, Snow_thermal_energy_content, Liquid_water_content_in_snow_layer, Permafrost_layer_thickness, Liquid_water_content_in_permafrost_layer, Active_layer_thickness, Liquid_water_content_in_active_layer, Temperature_profile_in_active_layer, Temperature_profile_in_permafrost_layer. For Ice sheets and shelves Land_ice_basal_stress, Land_ice_geothermal_heat_flux, Surface_ice_melt_amount, Superimposed_ice_formation_in_ice_sheet, Runoff_flux_due_to_ice_sheet_melt, Land_ice_melt_rate_at_ice_shelf_base, Marine_ice_accretion_rate_at_ice_shelf_base, Ocean_temperature_in_ice_shelf_cavity, Ocean_salinity_in_ice_shelf_cavity, Ocean_temperature_at_ice_shelf_cavity_front, Ocean_salinity_at_ice_shelf_cavity_front, Surface_orography_at_ice_sheet_surface. Best regards Siobhan O'Farrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl at met.no Mon Jan 26 10:03:35 2009 From: thomasl at met.no (Thomas Lavergne) Date: Mon, 26 Jan 2009 17:03:35 +0000 Subject: [CF-metadata] X and Y projection coordinate (center vs corner) Message-ID: <497DECE7.2080303@met.no> Hi, I apologize if this was discussed already but I did not find it explicitly in the archive nor in the standard document. I have datasets mapped in a polar stereographic projection. My file structure is thus something like: dimensions: xc = 119 ; yc = 177 ; variables: int Polar_Stereographic_Grid ; Polar_Stereographic_Grid:grid_mapping_name = "polar_stereographic" ; Polar_Stereographic_Grid:straight_vertical_longitude_from_pole = -45.f ; Polar_Stereographic_Grid:latitude_of_projection_origin = 90.f ; Polar_Stereographic_Grid:standard_parallel = 70.f ; Polar_Stereographic_Grid:false_easting = 0.f ; Polar_Stereographic_Grid:false_northing = 0.f ; Polar_Stereographic_Grid:earth_shape = "elliptical" ; Polar_Stereographic_Grid:proj4_string = "+proj=stere +a=6378273 +b=6356889.44891 +lat_0=90 +lat_ts=70 +lon_0=-45" ; double xc(xc) ; xc:axis = "X" ; xc:units = "km" ; xc:long_name = "x coordinate of projection (eastings)" ; xc:standard_name = "projection_x_coordinate" ; xc:grid_spacing = "62.50 km" ; double yc(yc) ; yc:axis = "Y" ; yc:units = "km" ; yc:long_name = "y coordinate of projection (northings)" ; yc:standard_name = "projection_y_coordinate" ; yc:grid_spacing = "62.50 km" ; float lon(yc, xc) ; lon:long_name = "longitude coordinate" ; lon:standard_name = "longitude" ; lon:units = "degrees_east" ; lon:_FillValue = -9999.f ; lon:grid_mapping = "Polar_Stereographic_Grid" ; lon:coordinates = "yc xc" ; float lat(yc, xc) ; lat:long_name = "latitude coordinate" ; lat:standard_name = "latitude" ; lat:units = "degrees_north" ; lat:_FillValue = -9999.f ; lat:grid_mapping = "Polar_Stereographic_Grid" ; lat:coordinates = "yc xc" ; And my xc and yc 1D datasets are filled with the grid coordinates corresponding to the values in lat and lon dataset. My issue is that I try to feed such a file into an application. The latter seems to unilaterally translate the values in xc and yc as the coordinates of one of the _corners_ of each cell while I originally entered the coordinates of the _center_ of each grid cell. All my isolines result shifted by half a cell size in both X and Y directions. I know I should maybe use the lat and lon boundaries (http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#cell-boundaries) but I do not think it will help my visualization software in handling my file. Is it written anywhere in CF what the content of the projection_x&y_coordinate should be (center vs corner)? Are there standardized ways to tell the application reading my file that I am giving it the center of the grid cell? Thank you if you can help me clarify this. Do not hesitate to point me to archived discussions if they exist... Cheers, Thomas From ogura at moon.biglobe.ne.jp Mon Jan 26 09:23:18 2009 From: ogura at moon.biglobe.ne.jp (Tomoo Ogura) Date: Tue, 27 Jan 2009 01:23:18 +0900 Subject: [CF-metadata] Some new standard names for cloud feedback study Message-ID: <978E6AF1DAD84EF49F5859AD4221B75B@nies.go.jp> Dear all, I would like to propose some new standard names relevant to cloud feedback. They represent the tendency terms for cloud condensed water content in GCMs. We hope to use these terms to better understand the model cloud responses to greenhouse gas increase in the Cloud Feedback Model Intercomparison Project (CFMIP) as part of CMIP5. I would like to start by proposing a few examples first. If the examples look all right, I hope to add other terms to make the list more comprehensive. The total number of the terms amounts to 33. The units are in 1/s. [1] Cloud liquid water budget tendency_of_stratiform_cloud_liquid_water_content_due_to_condensation_and_evaporation tendency_of_stratiform_cloud_liquid_water_content_due_to_melting_from_cloud_ice [2] Cloud ice budget tendency_of_stratiform_cloud_ice_content_due_to_homogeneous_nucleation tendency_of_stratiform_cloud_ice_content_due_to_melting_to_cloud_liquid [3] Cloud condensed water budget (this category is added because cloud liquid water budget or cloud ice budget may not be available in some GCMs.) tendency_of_stratiform_cloud_condensed_water_content_due_to_condensation_and_evaporation tendency_of_stratiform_cloud_condensed_water_content_due_to_autoconversion_to_rain The standard names proposed above follow the format; tendency_of_{A}_due_to_{B}_from_{C}_to_{D}. {A} is the name of cloud water variable such as stratiform_cloud_liquid_ water_content or stratiform_cloud_ice_content. {B} is a process such as condensation or melting . {C} and {D} are water categories (optional). They are added if the process {B} has multiple meanings such as 'melting of cloud ice', which may mean conversion of cloud ice to either rain or cloud liquid water. I thank you in advance for all your comments. Best regards, 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 Tue Jan 27 01:09:12 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 27 Jan 2009 08:09:12 +0000 Subject: [CF-metadata] Some new standard names for cloud feedback study Message-ID: <20090127080912.GA14684@met.reading.ac.uk> Dear Tomoo As you and I have already discussed, I think this approach and these names are fine. The units of a quantity with name tendency_of_X are 1/s * the units of the quantity X. In the names you have so far proposed, X has units kg m-2 e.g. cloud liquid water content, so the new quantities are in kg m-2 s-1. Best wishes Jonathan From j.m.gregory at reading.ac.uk Tue Jan 27 01:34:44 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 27 Jan 2009 08:34:44 +0000 Subject: [CF-metadata] X and Y projection coordinate (center vs corner) Message-ID: <20090127083444.GA14878@met.reading.ac.uk> Dear Thomas I think it may not be explicitly written down in the CF standard, but it is certainly assumed that the coordinates you give (xc yc) are the gridpoints. For an intensive quantity, the default interpretation of the data is that it exists at particular points, which are those specified by the coordinates. Your application is making a surprising assumption in taking the coordinates to lie at the corner of the cell. As you say, CF provides bounds in order to describe cells, because that's not what coordinates are intended for. Cheers Jonathan From thomasl at met.no Tue Jan 27 03:00:25 2009 From: thomasl at met.no (Thomas Lavergne) Date: Tue, 27 Jan 2009 10:00:25 +0000 Subject: [CF-metadata] X and Y projection coordinate (center vs corner) In-Reply-To: <20090127083444.GA14878@met.reading.ac.uk> References: <20090127083444.GA14878@met.reading.ac.uk> Message-ID: <497EDB39.3010900@met.no> Dear Jonathan, We should not be overly surprised by the choice made by some applications. Software were designed and developed before CF conventions (or even netCDF) came in place and, in the slow process of adapting to new standards, need to keep backward compatibility with previous ways of doing things. The (silent) standard for my application was to consider "corners" and was not yet adapted to use the "center". Anyway, and although I agree with you that CF "provides bounds to describe cells", we could acknowledge that, in very particular (but not rare) occasions, a spatially intensive grid coordinate system can be interpreted as representative of a cell (e.g. for plotting purposes). I do not think we can expect from historical applications, some handling several other formats, that they start digging out "cells" information because they happen to load a CF-compliant netCDF file. Cells are great for us to specify what goes into a pixel (an average, a maximum, etc...) but are an overkill when it only comes to locating the pixel before plotting the field, don't you think? If we agree on this, one could imagine having a special paragraph in the CF document for the case of a "regularly spaced grid whose all cells are equally sized rectangles that cover totally (and only) the area left between the neighboring cells". If I am not mistaken, then the projection_x&y_coordinates are sufficient and their 'grid_spacing' attribute defines the cell dimensions. The only degree of freedom left is to decide/specify what the values in the projection_x&y_coordinates 1D datasets stand for (center vs border). Two solutions here : 1) CF demands that they hold the center of the grid cell; 2) we come up with a syntax that allows us to code that we are giving the 'center', the 'lower' or the 'upper' value of the grid cell. Then we could be free to give, in one file, the 'center' on the X and Y coordinates but the 'lower' limit in the Z coordinate. Why not grid_reference (or grid_location...) : double xc(xc) ; xc:axis = "X" ; xc:units = "km" ; xc:long_name = "x coordinate of projection (eastings)" ; xc:standard_name = "projection_x_coordinate" ; xc:grid_spacing = "62.50 km" ; xc:grid_location = "center" I am almost certain that you do not like this, Jonathan ;-), as it mixes between two distinct concepts : coordinates vs cells, intensive vs extensive. But maybe it is worth having the discussion? I repeat that 'cell' is a great concept but might be an overkill for some usage. Furthermore, CF is used by many models, some with C-grid, some with A-grid, some with mixed of those two... Do they all use cells or do most of them silently use the 'intensive' coordinates system as a proxy for their cells? And if the case, how bad is that (in the CF sense)? I have no strong feeling about this, but I do not see how I can contact the team of developers of my favorite visualization software and tell them that they should decode the "cell" information before plotting my data field. And, so far, I have no way of telling them "read the CF document : it is written that you should use the values as 'center' coordinates". Cheers, Thomas Jonathan Gregory wrote: > Dear Thomas > > I think it may not be explicitly written down in the CF standard, but it is > certainly assumed that the coordinates you give (xc yc) are the gridpoints. > For an intensive quantity, the default interpretation of the data is that > it exists at particular points, which are those specified by the coordinates. > Your application is making a surprising assumption in taking the coordinates > to lie at the corner of the cell. As you say, CF provides bounds in order to > describe cells, because that's not what coordinates are intended for. > > 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 27 05:55:51 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 27 Jan 2009 12:55:51 +0000 Subject: [CF-metadata] X and Y projection coordinate (center vs corner) Message-ID: <20090127125551.GA17853@met.reading.ac.uk> Dear Thomas I agree with you that for many purposes cells are not required (e.g. you don't need them for doing contour plots). I also agree that in practice (again, such as making contour plots) you assume the data applies at points, even when it is extensive in space. In a sense, it is somewhat undefined for model data whether it is point or cell; in a model, space is quantised so the distinction is blurred. You are right, I am not enthusiastic about making a formal relation between the vertices and the gridpoints! However, I would not be against including a statement in the convention that the gridpoint should typically be positioned within the cell, rather than on the boundaries, if there is no good reason otherwise. Maybe we do say something like that, but I can't remember where. I agree that we should have a debate. Others' views are welcome. Best wishes Jonathan From caron at unidata.ucar.edu Tue Jan 27 10:45:04 2009 From: caron at unidata.ucar.edu (John Caron) Date: Tue, 27 Jan 2009 10:45:04 -0700 Subject: [CF-metadata] X and Y projection coordinate (center vs corner) In-Reply-To: <497EDB39.3010900@met.no> References: <20090127083444.GA14878@met.reading.ac.uk> <497EDB39.3010900@met.no> Message-ID: <497F4820.7080806@unidata.ucar.edu> My own thinking goes along these lines: A grid is a discrete sampling of a continuous function. The coordinates give a location in space/time, say {x(x), y(y), z(z), time(time)}, and the value of that function at that point is data(time,z,y,x). >From that POV, its likely to be "wrong" that an application would interpret the coordinate as one of the edges of a cell, because that would make it "off-by-half-point" for contouring or visualization. I agree with Jonathan to add such a wording for future clarity. IMO, you could contact the application developer and say: if you see a CF file, please interpret coordinates as center-of-cell where that matters. Coordinate bounds allow edges to be explicit, and you could ask the application developer to look for those. When not specified, I put the edges halfway between the coordinates. Balaji's gridspec is a solution for describing other sampling topologies, but alas, we have not yet integrated it into the spec, nor does the netcdf-java library implement it yet. Regards, John Thomas Lavergne wrote: > Dear Jonathan, > > We should not be overly surprised by the choice made by some > applications. Software were designed and developed before CF conventions > (or even netCDF) came in place and, in the slow process of adapting to > new standards, need to keep backward compatibility with previous ways of > doing things. The (silent) standard for my application was to consider > "corners" and was not yet adapted to use the "center". > > Anyway, and although I agree with you that CF "provides bounds to > describe cells", we could acknowledge that, in very particular (but not > rare) occasions, a spatially intensive grid coordinate system can be > interpreted as representative of a cell (e.g. for plotting purposes). I > do not think we can expect from historical applications, some handling > several other formats, that they start digging out "cells" information > because they happen to load a CF-compliant netCDF file. Cells are great > for us to specify what goes into a pixel (an average, a maximum, etc...) > but are an overkill when it only comes to locating the pixel before > plotting the field, don't you think? > > If we agree on this, one could imagine having a special paragraph in the > CF document for the case of a "regularly spaced grid whose all cells are > equally sized rectangles that cover totally (and only) the area left > between the neighboring cells". If I am not mistaken, then the > projection_x&y_coordinates are sufficient and their 'grid_spacing' > attribute defines the cell dimensions. The only degree of freedom left > is to decide/specify what the values in the projection_x&y_coordinates > 1D datasets stand for (center vs border). Two solutions here : > > 1) CF demands that they hold the center of the grid cell; > > 2) we come up with a syntax that allows us to code that we are giving > the 'center', the 'lower' or the 'upper' value of the grid cell. Then we > could be free to give, in one file, the 'center' on the X and Y > coordinates but the 'lower' limit in the Z coordinate. Why not > grid_reference (or grid_location...) : > double xc(xc) ; > xc:axis = "X" ; > xc:units = "km" ; > xc:long_name = "x coordinate of projection (eastings)" ; > xc:standard_name = "projection_x_coordinate" ; > xc:grid_spacing = "62.50 km" ; > xc:grid_location = "center" > > I am almost certain that you do not like this, Jonathan ;-), as it mixes > between two distinct concepts : coordinates vs cells, intensive vs > extensive. But maybe it is worth having the discussion? I repeat that > 'cell' is a great concept but might be an overkill for some usage. > > Furthermore, CF is used by many models, some with C-grid, some with > A-grid, some with mixed of those two... Do they all use cells or do most > of them silently use the 'intensive' coordinates system as a proxy for > their cells? And if the case, how bad is that (in the CF sense)? > > I have no strong feeling about this, but I do not see how I can contact > the team of developers of my favorite visualization software and tell > them that they should decode the "cell" information before plotting my > data field. And, so far, I have no way of telling them "read the CF > document : it is written that you should use the values as 'center' > coordinates". > > Cheers, > Thomas > > Jonathan Gregory wrote: >> Dear Thomas >> >> I think it may not be explicitly written down in the CF standard, but >> it is >> certainly assumed that the coordinates you give (xc yc) are the >> gridpoints. >> For an intensive quantity, the default interpretation of the data is that >> it exists at particular points, which are those specified by the >> coordinates. >> Your application is making a surprising assumption in taking the >> coordinates >> to lie at the corner of the cell. As you say, CF provides bounds in >> order to >> describe cells, because that's not what coordinates are intended for. >> >> Cheers >> >> 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 From fhage at ucar.edu Tue Jan 27 11:13:29 2009 From: fhage at ucar.edu (Frank Hage) Date: Tue, 27 Jan 2009 18:13:29 +0000 Subject: [CF-metadata] X and Y projection coordinate (center vs corner) In-Reply-To: <497F4820.7080806@unidata.ucar.edu> References: <20090127083444.GA14878@met.reading.ac.uk> <497EDB39.3010900@met.no> <497F4820.7080806@unidata.ucar.edu> Message-ID: <20090127181329.GB6454@tempest.rap.ucar.edu> As an author of a popular weather data display I believe the standard should describe the center point's of the data. Both Wind barbs or vectors and contour rendering must use the true locations of the values, not the edges of a virtual cell. In my software only earth conformal images are treated as if they have a true extent, all other data are considered to be valid only at the dimensionless point in space. The users choice of rendering determines whether the points fill the cells or are represented by some other graphical means. -- Frank Hage fhage at ucar.edu National Center for Atmospheric Research From j.m.gregory at reading.ac.uk Tue Jan 27 11:33:18 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Tue, 27 Jan 2009 18:33:18 +0000 Subject: [CF-metadata] X and Y projection coordinate (center vs corner) Message-ID: <20090127183318.GA19736@met.reading.ac.uk> Dear all In view of our general agreement, I have just proposed to add some text to the CF standard in ticket 44. I've proposed this as a defect, because it doesn't change the standard, just clarifies it. Please have a look. If anyone objects, it can't be accepted as a defect, but if you think it's OK but that the wording should be improved, that's fine - please make suggestions in the ticket. Cheers Jonathan From taylor13 at llnl.gov Tue Jan 27 11:46:03 2009 From: taylor13 at llnl.gov (Karl Taylor) Date: Tue, 27 Jan 2009 10:46:03 -0800 Subject: [CF-metadata] X and Y projection coordinate (center vs corner) In-Reply-To: <20090127183318.GA19736@met.reading.ac.uk> References: <20090127183318.GA19736@met.reading.ac.uk> Message-ID: <497F566B.9070705@llnl.gov> Dear all, I support the additional text suggested by Jonathan. The proposed wording seems clear to me, but perhaps others can find a way to improve it. cheers, Karl Jonathan Gregory wrote: > Dear all > > In view of our general agreement, I have just proposed to add some text to > the CF standard in ticket 44. I've proposed this as a defect, because it > doesn't change the standard, just clarifies it. Please have a look. If anyone > objects, it can't be accepted as a defect, but if you think it's OK but that > the wording should be improved, that's fine - please make suggestions in the > ticket. > > Cheers > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http:// mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > From ogura at nies.go.jp Tue Jan 27 19:32:17 2009 From: ogura at nies.go.jp (Tomoo Ogura) Date: Wed, 28 Jan 2009 11:32:17 +0900 Subject: [CF-metadata] Some new standard names for cloud feedback study Message-ID: <92B344DE41174E3E99BA305C726B74E1@nies.go.jp> Dear Jonathan, Thanks for your comment. A complete list of the proposed standard names is at the end of this email. > The units of a quantity with name tendency_of_X are 1/s * the units of > the quantity X. In the names you have so far proposed, X has units kg m-2 > e.g. cloud liquid water content, so the new quantities are in kg m-2 s-1. I see. Actually my idea is that X is the mass of cloud liquid water per unit mass of air with the units of kg/kg - I hope this is all right. In this case I assume that tendency_of_X has units of kg/kg/s or 1/s. Best wishes, Tomoo ----- standard name list start ----- [1] Cloud liquid water budget tendency_of_stratiform_cloud_liquid_water_content_due_to_condensation_and_evaporation tendency_of_stratiform_cloud_liquid_water_content_due_to_homogeneous_nucleation tendency_of_stratiform_cloud_liquid_water_content_due_to_heterogeneous_nucleation tendency_of_stratiform_cloud_liquid_water_content_due_to_riming tendency_of_stratiform_cloud_liquid_water_content_due_to_accretion_to_rain tendency_of_stratiform_cloud_liquid_water_content_due_to_accretion_to_snow tendency_of_stratiform_cloud_liquid_water_content_due_to_melting_from_cloud_ice tendency_of_stratiform_cloud_liquid_water_content_due_to_autoconversion tendency_of_stratiform_cloud_liquid_water_content_due_to_advection tendency_of_stratiform_cloud_liquid_water_content_due_to_condensation_and_evaporation_from_longwave_heating tendency_of_stratiform_cloud_liquid_water_content_due_to_condensation_and_evaporation_from_shortwave_heating tendency_of_stratiform_cloud_liquid_water_content_due_to_condensation_and_evaporation_from_boundary_layer_mixing tendency_of_stratiform_cloud_liquid_water_content_due_to_condensation_and_evaporation_from_convection tendency_of_stratiform_cloud_liquid_water_content_due_to_condensation_and_evaporation_from_turbulence tendency_of_stratiform_cloud_liquid_water_content_due_to_condensation_and_evaporation_from_pressure_change [2] Cloud ice budget tendency_of_stratiform_cloud_ice_content_due_to_homogeneous_nucleation tendency_of_stratiform_cloud_ice_content_due_to_heterogeneous_nucleation_from_cloud_liquid tendency_of_stratiform_cloud_ice_content_due_to_heterogeneous_nucleation_from_water_vapor tendency_of_stratiform_cloud_ice_content_due_to_riming_from_cloud_liquid tendency_of_stratiform_cloud_ice_content_due_to_riming_from_rain tendency_of_stratiform_cloud_ice_content_due_to_deposition_and_sublimation tendency_of_stratiform_cloud_ice_content_due_to_aggregation tendency_of_stratiform_cloud_ice_content_due_to_accretion_to_snow tendency_of_stratiform_cloud_ice_content_due_to_evaporation_of_melting_ice tendency_of_stratiform_cloud_ice_content_due_to_melting_to_rain tendency_of_stratiform_cloud_ice_content_due_to_melting_to_cloud_liquid tendency_of_stratiform_cloud_ice_content_due_to_icefall tendency_of_stratiform_cloud_ice_content_due_to_advection [3] Cloud condensed water budget tendency_of_stratiform_cloud_condensed_water_content_due_to_condensation_and_evaporation tendency_of_stratiform_cloud_condensed_water_content_due_to_autoconversion_to_rain tendency_of_stratiform_cloud_condensed_water_content_due_to_autoconversion_to_snow tendency_of_stratiform_cloud_condensed_water_content_due_to_icefall tendency_of_stratiform_cloud_condensed_water_content_due_to_advection ----- standard name list end ----- --- 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 Wed Jan 28 01:11:16 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Wed, 28 Jan 2009 08:11:16 +0000 Subject: [CF-metadata] Some new standard names for cloud feedback study Message-ID: <20090128081116.GA21595@met.reading.ac.uk> Dear Tomoo > I see. Actually my idea is that X is the mass of cloud liquid water > per unit mass of air with the units of kg/kg - I hope this is all right. > In this case I assume that tendency_of_X has units of kg/kg/s or 1/s. Yes, it would be OK to have such quantities. However, existing CF names of cloud_liquid|condensed_water_content are in kg m-2; we use "content" to mean something per m2. If you want kg kg-1, then the phrase to use is mass_fraction_of_cloud_liquid|condensed_water_in_air mass_fraction_of_cloud_ice_water_in_air There are some tendency names for these quantities already as well in the standard name table. If that's what CFMIP would prefer, you could change your proposal to use these phrases instead. Best wishes Jonathan From thomasl at met.no Wed Jan 28 03:54:16 2009 From: thomasl at met.no (Thomas Lavergne) Date: Wed, 28 Jan 2009 10:54:16 +0000 Subject: [CF-metadata] X and Y projection coordinate (center vs corner) In-Reply-To: <20090127183318.GA19736@met.reading.ac.uk> References: <20090127183318.GA19736@met.reading.ac.uk> Message-ID: <49803958.8050701@met.no> Dear all, Mea culpa. Due to a mistake in my own software, I was the one writing 'shifted' X and Y values in my netCDF files. Although they were never explicitly named, the software development team deserves my apologies :-/. It took me some time to investigate and make sure that it was my mistake, which is why I did not contribute to the discussion yesterday. This being said, I find that the text in ticket 44 clarifies things by giving a definition for what should be the values of the X and Y datasets and acknowledging that applications can make use of them as center points. Although a software bug originated this discussion, I am in favor of including the text in ticket 44. Jonathan, I would understand if you prefer a "statu quo" (cancel ticket 44) as, until proved otherwise, no software application was misled by the current version of the CF document. Sorry for the extra work as well as extra volume on the list, Thomas Jonathan Gregory wrote: > Dear all > > In view of our general agreement, I have just proposed to add some text to > the CF standard in ticket 44. I've proposed this as a defect, because it > doesn't change the standard, just clarifies it. Please have a look. If anyone > objects, it can't be accepted as a defect, but if you think it's OK but that > the wording should be improved, that's fine - please make suggestions in the > ticket. > > 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 Wed Jan 28 04:16:11 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Wed, 28 Jan 2009 11:16:11 +0000 Subject: [CF-metadata] X and Y projection coordinate (center vs corner) Message-ID: <20090128111611.GA24973@met.reading.ac.uk> Dear Thomas It was a useful point to raise, and I think it's a benefit to make this clarification in the standard. Best wishes Jonathan From Young-In.Won-1 at nasa.gov Thu Jan 29 11:52:06 2009 From: Young-In.Won-1 at nasa.gov (Won, Young-In (GSFC-610.2)[RSIS]) Date: Thu, 29 Jan 2009 12:52:06 -0600 Subject: [CF-metadata] Emissivity not found in the current standard name table In-Reply-To: <978E6AF1DAD84EF49F5859AD4221B75B@nies.go.jp> References: <978E6AF1DAD84EF49F5859AD4221B75B@nies.go.jp> Message-ID: <2B88375CB06CAA4A8861A3C48389D9256E553C@NDMSEVS37B.ndc.nasa.gov> Hello, I am working on AIRS (Atmospheric Infrared Sounders) data in NASA Goddard Space Flight Center (Goddard Earth Science Data Information Data Center). The default format of our data is HDF-EOS, but we also provide converting service into NetCDF. We are trying to make the converted file CF compliant. One of primary attributes for CF compliant variables is standard name and there are several parameters (from AIRS instrument) that cannot be matched with the current standard name list. For example, I cannot find parameter related to "Emissivity", which is fraction of the amount of thermal radiation that a blackbody would (or ratio of energy radiated by a particular material to energy radiated by a black body at the same temperature. AIRS provides two types of surface Emissivity; one in IR region and the other in Microwave region. My first trial naming these two emissivity would be something like, - surface_ir_emissivity (or surface_longwave_emissivity) - surface_microwave_emissivity, following the convention for other parameter name. I would appreciate for discussion/comments on these parameters for inclusion in the table. Thanks, Young-In ---------------------------------------------------- Young-In Won, Ph.D. NASA Goddard Space Flight Center Mail stop: 610.2 Greenbelt, MD 20771 (301) 614 6749 (O) (301) 614 5268 (F) young-in.won at nasa.gov From ogura at nies.go.jp Thu Jan 29 19:09:21 2009 From: ogura at nies.go.jp (Tomoo Ogura) Date: Fri, 30 Jan 2009 11:09:21 +0900 Subject: [CF-metadata] Some new standard names for cloud feedback study Message-ID: <59F5E61D401B472EB10F714B8DC9E765@nies.go.jp> Dear Jonathan Thanks for the clarification. I'd like to change my proposal from (a) cloud_liquid_water_content, to (b) mass_fraction_of_cloud_liquid _water_in_air. Following is a list of the updated standard names; [1] Cloud liquid water budget tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_condensation_and_evaporation tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_homogeneous_nucleation tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_heterogeneous_nucleation tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_riming tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_accretion_to_rain tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_accretion_to_snow tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_melting_from_cloud_ice tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_autoconversion tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_advection tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_condensation_and_evaporation_from_longwave_heating tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_condensation_and_evaporation_from_shortwave_heating tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_condensation_and_evaporation_from_boundary_layer_mixing tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_condensation_and_evaporation_from_convection tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_condensation_and_evaporation_from_turbulence tendency_of_mass_fraction_of_stratiform_cloud_liquid_water_in_air_due_to_condensation_and_evaporation_from_pressure_change [2] Cloud ice budget tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_homogeneous_nucleation 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_heterogeneous_nucleation_from_water_vapor tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_riming_from_cloud_liquid tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_riming_from_rain tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_deposition_and_sublimation tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_aggregation tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_accretion_to_snow tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_evaporation_of_melting_ice tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_melting_to_rain 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_icefall tendency_of_mass_fraction_of_stratiform_cloud_ice_in_air_due_to_advection [3] Cloud condensed water budget tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due_to_condensation_and_evaporation tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due_to_autoconversion_to_rain tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due_to_autoconversion_to_snow tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due_to_icefall tendency_of_mass_fraction_of_stratiform_cloud_condensed_water_in_air_due_to_advection Best wishes, Tomoo From j.m.gregory at reading.ac.uk Fri Jan 30 01:27:32 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 30 Jan 2009 08:27:32 +0000 Subject: [CF-metadata] Some new standard names for cloud feedback study Message-ID: <20090130082732.GA10370@met.reading.ac.uk> Dear Tomoo I think those are all fine. Their canonical unit would be s-1, as you intended. Thanks. Cheers Jonathan From j.m.gregory at reading.ac.uk Fri Jan 30 01:53:23 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 30 Jan 2009 08:53:23 +0000 Subject: [CF-metadata] Emissivity not found in the current standard name table Message-ID: <20090130085323.GA11370@met.reading.ac.uk> Dear Young-In Yes, by analogy with surface_albedo, I think surface_emissivity would be fine. > - surface_ir_emissivity (or surface_longwave_emissivity) It should be longwave, for consistence with other names. > - surface_microwave_emissivity, I think microwave would be OK; it would need a definition. You could also have plain surface_emissivity and provide a (perhaps scalar) coordinate variable of radiation_wavelength with bounds to specify the range to which it applies precisely. Cheers Jonathan From c.khroulev at gmail.com Mon Feb 2 12:53:49 2009 From: c.khroulev at gmail.com (Constantine Khroulev) Date: Mon, 2 Feb 2009 10:53:49 -0900 Subject: [CF-metadata] time dimension and calendar for an ice-sheet model output Message-ID: <20BC7FBE-6F07-4B8C-95C6-1BE1E4EBE420@gmail.com> Hello, I am updating PISM to CF-1.4, and I have a question about the reference date and calendar. In our context 1) time in the output file denotes "seconds (or years) relative to present", i.e. it for paleoclimate runs it is negative (and is used to extract appropriate temperature and sea-level offsets from ice-core data, for example) and for runs "into the future" it is positive. 2) a year is always 3.15569e+07 seconds. I might be wrong, but it seems that 1) suggests that any particular "real" reference date will be... well... unfitting, and 2) suggests that standard calendars are not applicable here either. It is appropriate to use the units string of "years since 1-1-1 0:0:0" or similar, following Example 4.6? Should I use calendar="none", or should I define a custom calendar? What would you recommend? Thank you! -- Constantine Khroulev PISM (www.pism-docs.org) Developer/Maintainer University of Alaska Fairbanks From Young-In.Won-1 at nasa.gov Mon Feb 2 14:01:29 2009 From: Young-In.Won-1 at nasa.gov (Won, Young-In (GSFC-610.2)[RSIS]) Date: Mon, 2 Feb 2009 15:01:29 -0600 Subject: [CF-metadata] Emissivity not found in the current standard nametable In-Reply-To: <20090130085323.GA11370@met.reading.ac.uk> References: <20090130085323.GA11370@met.reading.ac.uk> Message-ID: <2B88375CB06CAA4A8861A3C48389D9256E598A@NDMSEVS37B.ndc.nasa.gov> Dear Jonathan, The Surface microwave emissivity is for 1 x1 degree gridded data at three different wavelengths (23.8, 50.3 and 89.0 GHz). So, I suppose it can be written as (in CDL form, assuming the variable name "EmisMW" and its dimension "MWEmisLvls"), dimensions: lat = 180 ; lon = 360 ; MWEmisLvls =3 ; variables: float MWEmisLvls(MWEmisLvls) MWEmisLvls:standard_name="radiation_wavelength"; cannot find radiation_frequency, but should be O.K. MWEmisLvls:units="GHz"; float EmisMW(MWEmisLvls, lat, lon) ; EmisMW: _FillValue=-9999.f; EmisMW: long_name="Microwave spectral emissivity"; EmisMW: standard_name="surface_microwave_emissivity"; data: MWEmisLvls = 23.8, 50.3, 89.0; (I skippped lat, lon as those are straitforward) Young-In -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory Sent: Friday, January 30, 2009 3:53 AM To: cf-metadata at cgd.ucar.edu Subject: [CF-metadata] Emissivity not found in the current standard nametable Dear Young-In Yes, by analogy with surface_albedo, I think surface_emissivity would be fine. > - surface_ir_emissivity (or surface_longwave_emissivity) It should be longwave, for consistence with other names. > - surface_microwave_emissivity, I think microwave would be OK; it would need a definition. You could also have plain surface_emissivity and provide a (perhaps scalar) coordinate variable of radiation_wavelength with bounds to specify the range to which it applies precisely. Cheers Jonathan _______________________________________________ CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata From Young-In.Won-1 at nasa.gov Mon Feb 2 17:21:05 2009 From: Young-In.Won-1 at nasa.gov (Won, Young-In (GSFC-610.2)[RSIS]) Date: Mon, 2 Feb 2009 18:21:05 -0600 Subject: [CF-metadata] Emissivity not found in the current standard nametable References: <20090130085323.GA11370@met.reading.ac.uk> Message-ID: <2B88375CB06CAA4A8861A3C48389D9256E59FB@NDMSEVS37B.ndc.nasa.gov> Dear All, I would like to propose two (three for the dimension) new standard names as follows. 1. name: surface_longwave_emissivity canonical unit: 1 ( unitless number between 0 and 1) definition: The ratio of energy radiated by the Earth's surface to energy radiated by a black body at the same temperature in longwave region. 2. surface_mircrowave_emissivity canonical unit: 1 ( unitless number between 0 and 1) definition: The ratio of energy radiated by the Earth's surface to energy radiated by a black body at the same temperature in microwave frequency region. 3. name: radiation_frequency (alias: electromagnetic_frequency) canonical unit: hertz; definition: The radiation frequency can refer to any electromagnetic frequency, such as light, heat radiation and radio waves (copied and modified from "radiation_wavelength". I need "radiaton_frequency" because the emissivity in our data set is given at specific frequency). Thanks, Young-In ---------------------------------------------------- Young-In Won, Ph.D. NASA Goddard Space Flight Center Mail stop: 610.2 Greenbelt, MD 20771 (301) 614 6749 (O) (301) 614 5268 (F) young-in.won at nasa.gov -----Original Message----- From: Won, Young-In (GSFC-610.2)[RSIS] Sent: Monday, February 02, 2009 4:01 PM To: 'Jonathan Gregory'; cf-metadata at cgd.ucar.edu Subject: RE: [CF-metadata] Emissivity not found in the current standard nametable Dear Jonathan, The Surface microwave emissivity is for 1 x1 degree gridded data at three different wavelengths (23.8, 50.3 and 89.0 GHz). So, I suppose it can be written as (in CDL form, assuming the variable name "EmisMW" and its dimension "MWEmisLvls"), dimensions: lat = 180 ; lon = 360 ; MWEmisLvls =3 ; variables: float MWEmisLvls(MWEmisLvls) MWEmisLvls:standard_name="radiation_wavelength"; cannot find radiation_frequency, but should be O.K. MWEmisLvls:units="GHz"; float EmisMW(MWEmisLvls, lat, lon) ; EmisMW: _FillValue=-9999.f; EmisMW: long_name="Microwave spectral emissivity"; EmisMW: standard_name="surface_microwave_emissivity"; data: MWEmisLvls = 23.8, 50.3, 89.0; (I skippped lat, lon as those are straitforward) Young-In -----Original Message----- From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory Sent: Friday, January 30, 2009 3:53 AM To: cf-metadata at cgd.ucar.edu Subject: [CF-metadata] Emissivity not found in the current standard nametable Dear Young-In Yes, by analogy with surface_albedo, I think surface_emissivity would be fine. > - surface_ir_emissivity (or surface_longwave_emissivity) It should be longwave, for consistence with other names. > - surface_microwave_emissivity, I think microwave would be OK; it would need a definition. You could also have plain surface_emissivity and provide a (perhaps scalar) coordinate variable of radiation_wavelength with bounds to specify the range to which it applies precisely. 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 Thu Feb 5 15:11:11 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Thu, 5 Feb 2009 22:11:11 +0000 Subject: [CF-metadata] time dimension and calendar for an ice-sheet model output Message-ID: <20090205221111.GA26420@met.reading.ac.uk> Dear Constantine > 1) time in the output file denotes "seconds (or years) relative to > present", i.e. it for paleoclimate runs it is negative (and is used to > extract appropriate temperature and sea-level offsets from ice-core > data, for example) and for runs "into the future" it is positive. > 2) a year is always 3.15569e+07 seconds. > > I might be wrong, but it seems that 1) suggests that any particular > "real" reference date will be... well... unfitting, and 2) suggests > that standard calendars are not applicable here either. You're right, you couldn't specify a time-unit relative to a moving reference time. But if you are using "relative to present" you can't really be precise about what "present" means, can you? The precise meaning of "relative to present" changes as seconds pass! I imagine you mean "approximately present" in the same sense as years BP. That is quite vague, so it seems to me you could just pick a reference date, define it as "present", but recognise it as an arbitrary choice. If you are talking about -21000 years relative to present, it doesn't much matter if it's today, last Tuesday, or 1984 that you choose. It might be simplest if you always used the same date, so that the absolute values of your time coordinates always had the same meaning in your files. Alternatively, it might be more convenient if you used positive time coords relative to an appropriate reference date, such as "seconds since -21000-1-1". Unfortunately udunits won't process that correctly. Your year length is exactly what udunits means by a year, so you can use the unit of years safely. Does your model have a seasonal cycle? If not, a calendar of "none" would be appropriate. If it does, CF has useful facilities for describing climatological means. You can also specify your own custom-made paleocalendar. But for these facilities to make sense you would have to change your year to a whole number of days, possibly with leap years. Cheers Jonathan From Siobhan.O'farrell at csiro.au Fri Feb 6 00:06:57 2009 From: Siobhan.O'farrell at csiro.au (Siobhan.O'farrell at csiro.au) Date: Fri, 6 Feb 2009 18:06:57 +1100 Subject: [CF-metadata] FW: New Cryospheric variables Message-ID: Dear all I sent this message to the list a couple of weeks back, with the exception of one person it didn't get much response, he pointed out difficulty opening the file, after some investigation using Australian colleagues and talking to local IT I discovered that the correct URL is http://www.hpsc.csiro.au/users/ofa001/Cryosphere.doc My apologies for the confusion. Regards Siobhan ________________________________ From: O'Farrell, Siobhan (CMAR, Aspendale) Sent: Thursday, 22 January 2009 6:52 PM To: 'cf-metadata at cgd.ucar.edu' Subject: New Cryospheric variables Dear all, In November/December I circulated a list of cryospheric variables for suggested collection by the CMIP 5 models through the cryospheric community for comment. An updated version of the document with revisions following input from the community is available at http://cherax.hpsc.csiro.au/users/ofa001/Cryosphere.doc (you might need to paste and cut it into browser) Jonathan Gregory pointed out the need to have new variables agreed on by this cf-metadata discussion list and I have highlighted in the document in red, new variable names which follow the CF standard name conventions. I started this process before Christmas, but due to the longer SH summer break have only just completed it. Many of the variables have been selected so that the cryospheric community can better understand thermodynamic and dynamic budgets of sea ice and additional variables have been added to categorise snow cover and permafrost regions. Some of the variables particularly in relation to the ice sheets are unlikely to be available in many models for CMIP5 timeframe but have been included for the period when the climate community Earth system models do include ice sheet/permafrost models. The new suggested names for sea ice thermodynamic variables are Sea_ice_albedo, Sea_ice_thickness_in_sea_ice_categories, Sea_ice_area_fraction_in_sea_ice_categories, Sea_ice_salinity, Surface_temperature_in_sea_ice, Temperature_at_sea_ice_snow_interface, Sea_ice_age, Sea_ice_growth_due_to_frazil_ice, Sea_ice_growth_due_to_congelation_ice, Sea_ice_growth_due_to_lateral_accretion, Sea_ice_growth_due_to_snow_ice_formation, Sea_ice_melt_amount_at_ice_surface, Sea_ice_melt_amount_at_ice_base, Sea_ice_melt_amount_at_lateral_sides, Sea_ice_total_heat_content, Downward_shortwave_flux_at_sea_ice_surface, Shortwave_flux_absorbed_in_sea_ice, Downward_longwave_flux_at_sea_ice_surface, Upward_longwave_flux_at_sea_ice_surface, Sensible_heat_flux_at_sea_ice_surface, Latent_heat_flux_at_sea_ice_surface, Downward_sea_ice_freshwater_flux. For sea ice dynamic variables Eastward_sea_ice_transport, Northward_sea_ice_transport, Sea_ice_volume_transport_at_Fram_strait, Downward_eastward_atmospheric_stress_at_sea_ice_surface, Downward_northward_atmospheric_stress_at_sea_ice_surface, Downward_northward_oceanic_stress_at_sea_ice_base, Downward_eastward_oceanic_stress_at_sea_ice_base, Eastward_internal_stress_at_sea_ice_base, Northward_internal_stress_in_sea_ice, Eastward_coriolis_stress_in_sea_ice, Northward_coriolis_stress_in_sea_ice, Eastward_sea_surface_tilt_stress_in_sea_ice, Northward_sea_surface_tilt_stress_in_sea_ice, Sea_ice_strain_rate_due_to_divergence, Sea_ice_strain_rate_due_to_shear, Sea_ice_ridging_rate. For land surface variables Snow_density, Snow_age, Snow_thermal_energy_content, Liquid_water_content_in_snow_layer, Permafrost_layer_thickness, Liquid_water_content_in_permafrost_layer, Active_layer_thickness, Liquid_water_content_in_active_layer, Temperature_profile_in_active_layer, Temperature_profile_in_permafrost_layer. For Ice sheets and shelves Land_ice_basal_stress, Land_ice_geothermal_heat_flux, Surface_ice_melt_amount, Superimposed_ice_formation_in_ice_sheet, Runoff_flux_due_to_ice_sheet_melt, Land_ice_melt_rate_at_ice_shelf_base, Marine_ice_accretion_rate_at_ice_shelf_base, Ocean_temperature_in_ice_shelf_cavity, Ocean_salinity_in_ice_shelf_cavity, Ocean_temperature_at_ice_shelf_cavity_front, Ocean_salinity_at_ice_shelf_cavity_front, Surface_orography_at_ice_sheet_surface. Best regards Siobhan O'Farrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From c.khroulev at gmail.com Fri Feb 6 11:33:24 2009 From: c.khroulev at gmail.com (Constantine Khroulev) Date: Fri, 6 Feb 2009 09:33:24 -0900 Subject: [CF-metadata] A typo in cf-conventions.pdf? Message-ID: <293B926E-CE36-4F81-81D0-BF92759CF06F@gmail.com> Hello, The overview (section 1.3) in cf-conventions.pdf from http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/ states that "We recommend that the NUG defined attribute Conventions be given the string value "CF-1.2" "CF-1.3" to identify datasets that conform to these conventions." ("CF-1.2" is crossed out in the sentence above.) I.e. my question is: shouldn't that say "CF-1.4" instead of "CF-1.3"? Should we use "CF-1.3" or "CF-1.4" in our datasets following these conventions? Thank you! -- Constantine Khroulev PISM (www.pism-docs.org) Developer/Maintainer University of Alaska Fairbanks From j.m.gregory at reading.ac.uk Fri Feb 6 11:43:46 2009 From: j.m.gregory at reading.ac.uk (Jonathan Gregory) Date: Fri, 6 Feb 2009 18:43:46 +0000 Subject: [CF-metadata] A typo in cf-conventions.pdf? Message-ID: <20090206184346.GA3785@met.reading.ac.uk> Dear Constantine It should say CF-1.4, of course. Well spotted. I will submit a request for it to be changed. We must remember to keep this sentence up to date! Cheers Jonathan From ngalbraith at whoi.edu Mon Feb 9 07:40:59 2009 From: ngalbraith at whoi.edu (Nan Galbraith) Date: Mon, 09 Feb 2009 09:40:59 -0500 Subject: [CF-metadata] how to use time zones? Message-ID: <4990407B.4040909@whoi.edu> We use UTC for everything, but someone on another mailing list recently raised the issue of time zones, so I wondered how CF handles them. There's an example in the CF manual using local time: seconds since 1992-10-8 15:15:42.5 -6:00 indicates seconds since October 8th, 1992 at 3 hours, 15 minutes and 42.5 seconds in the afternoon in the time zone which is six hours to the west of Coordinated Universal Time (i.e. Mountain Daylight Time). which implies the way time zones should be expressed, but I couldn't find an actual 'rule' anywhere. I don't have a copy of ISO 8601 but found this*: Regarding Time Zones, it is common for those East of Greenwich to be treated as Positive, and for those to the West (i.e. the Americas) to be treated as Negative. This is also defined towards the end of the ISO 8601 standard. Should something similar be spelled out in the CF manual, or is the example clear enough? Thanks - Nan *(What Is ISO 8601? Ian Galpin, 1997-Feb-04, mit.edu) -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* From bruce.wright at metoffice.gov.uk Tue Feb 10 01:04:01 2009 From: bruce.wright at metoffice.gov.uk (Wright, Bruce) Date: Tue, 10 Feb 2009 08:04:01 -0000 Subject: [CF-metadata] how to use time zones? In-Reply-To: <4990407B.4040909@whoi.edu> References: <4990407B.4040909@whoi.edu> Message-ID: <8AC4893FB411FA4AA8CFECD9C8913B6601F3E66D@EXXMAIL01.desktop.frd.metoffice.com> Hi Nan, I don't know how CF handles time zones, but I thought it might be worth pointing out that the Wikipedia page on ISO 8601 is quite useful. The relevant section: http://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators offers the following ways of representing times in zones other than UTC: