John,
I think the standard names and basic template are all the same. The
only difference is that
the structure we're using for TIGGE has 4 variable dimensions vs 5,
where the 5th allows for multiple forecast initialization times.
On Mar 16, 2010, at 3:43 PM, John Caron wrote:
> 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
>
> _______________________________________________
> 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 - 17:16:26 GMT
