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
[email protected]
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: [email protected]
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Reply via email to