Hi Doug:
Looks to be the same as Paco's. Do you know what was modified?
On 3/16/2010 1:46 PM, Doug Schuster wrote:
> NCAR uses a modified version of Paco's file structure for TIGGE output.
> All ensemble members found in the file require the same "single" model
> initialization time, the same forecast timesteps, and
> identical grids types.
>
> A sample file can be found at:
>
> http://dss.ucar.edu/download/tigge/ncep_20100223000000_tp_lev_255_id_528.1.5deg.nc
>
>
> Here's a snippet from the file header metadata -Doug:
>
> dimensions:
> longitude = 240 ;
> latitude = 121 ;
> string4 = 4 ;
> string2 = 2 ;
> time = 4 ;
> realization = 21 ;
> variables:
> float longitude(longitude) ;
> longitude:data_type = "float" ;
> longitude:units = "degrees_east" ;
> longitude:axis = "X" ;
> longitude:standard_name = "longitude" ;
> longitude:valid_min = 0.f ;
> longitude:valid_max = 358.5f ;
> float latitude(latitude) ;
> latitude:data_type = "float" ;
> latitude:units = "degrees_north" ;
> latitude:axis = "Y" ;
> latitude:standard_name = "latitude" ;
> latitude:valid_min = -90.f ;
> latitude:valid_max = 90.f ;
> int time(time) ;
> time:data_type = "int" ;
> time:units = "hours since 1950-01-01 00:00:00" ;
> time:standard_name = "time" ;
> time:long_name = "Forecast Valid Time" ;
> int realization(realization) ;
> realization:data_type = "int" ;
> realization:units = "1" ;
> realization:standard_name = "realization" ;
> realization:long_name = "Number of the simulation in the
> ensemble" ;
> char forecast_type(realization, string2) ;
> forecast_type:data_type = "char" ;
> forecast_type:long_name = "Forecast type" ;
> char institution(realization, string4) ;
> institution:data_type = "char" ;
> institution:standard_name = "institution" ;
> institution:long_name = "Institution responsible for the
> forecast system" ;
> char source(realization, string4) ;
> source:data_type = "char" ;
> source:standard_name = "source" ;
> source:long_name = "Method of production of the data" ;
> char experiment_id(realization, string4) ;
> experiment_id:data_type = "char" ;
> experiment_id:standard_name = "experiment_id" ;
> experiment_id:long_name = "Experiment identifier" ;
> int perturbation_method(realization) ;
> perturbation_method:data_type = "int" ;
> perturbation_method:long_name = "Perturbation method, GRIB-2
> Code table 4.6" ;
> float tp(time, realization, latitude, longitude) ;
> tp:data_type = "float" ;
> tp:units = "kg m-2 s-1" ;
> tp:standard_name = "precipitation_amount" ;
> tp:level_name = "Ground or water surface " ;
> tp:level_units = "unknown" ;
> tp:level_value = 0.f ;
> tp:coordinates = "institution forecast_type source
> experiment_id perturbation_method" ;
> tp:_FillValue = 9.96921e+36f ;
>
> // global attributes:
> :Model_Initialization_Date_and_Time_UTC = "2010-2-23 0 UTC" ;
> :Conventions = "CF-1.0" ;
> :Institution = "NCAR" ;
> :Generator = "grib2_to_netcdf" ;
> :Created = "Wed Mar 03 04:37:58 2010" ;
> :Title = "TIGGE" ;
> :References = "For TIGGE, check http://tigge.ucar.edu" ;
>
> On Mar 16, 2010, at 1:31 PM, V. Balaji wrote:
>
>> Jonathan Gregory writes:
>>
>>> Dear John
>>>
>>>> Im not sure if we ever converged on how to write ensemble files.
>>> No, we didn't. If I remember correctly, we couldn't agree on the
>>> relationship
>>> between attributes and coordinates, and that was a sticking-point. I
>>> thought
>>> that we ought to allow multivalued auxiliary coord variables for
>>> ensemble
>>> axes, corresponding to attributes that might be used to describe a
>>> single
>>> model. I would give these standard_names to identify them. Paco
>>> started the
>>> discussion, and in the end he made his own decisions for what to do
>>> for the
>>> ENSEMBLES project (because CF had not concluded), so he might
>>> comment on it.
>>
>> http://ensembles.ecmwf.int/thredds/ensembles/stream2/seasonal/atmospheric/catalog.html
>>
>>
>> has examples of how Paco has it set up.
>> (esp see the "mother of all aggregations" :-).
>>
>> It requires the ensemble to share the same space and time
>> discretization.
>>
>>>
>>>> Particularly, how does software recognize the ensemble dimension?
>>> We didn't agree. But at the end of the discussion, Steve also
>>> suggested that
>>> it could be identified by an axis attribute, just as you have. I
>>> like that
>>> idea too. But it could also be given a standard name, like other
>>> coordinate
>>> variables e.g. ensemble_member_identifier. I suppose the values of this
>>> coord var might be either numeric or strings, though it your example
>>> it is
>>> integer. I haven't looked at the trac ticket to see if we discussed
>>> these
>>> points before.
>>>
>>>> Perhaps we should add :axis = "Ensemble" to the model coordinate
>>>> variable?
>>> I'd suggest lower case, like most CF keywords. The other axis
>>> attributes are
>>> all single letters (X Y Z T) but I don't think it would be a problem
>>> to use
>>> a word.
>>>
>>> Best wishes
>>>
>>> Jonathan
>>> _______________________________________________
>>> CF-metadata mailing list
>>> CF-metadata at cgd.ucar.edu
>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>>
>>
>> --
>>
>> V. Balaji Office: +1-609-452-6516
>> Head, Modeling Systems Group, GFDL Home: +1-212-253-6662
>> Princeton University Email: v.balaji at noaa.gov
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Tue Mar 16 2010 - 15:43:00 GMT
