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
>
Received on Fri Jan 09 2009 - 17:40:14 GMT
