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
Received on Fri Jan 09 2009 - 15:11:44 GMT
