[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20021002: 20021002: convert ccm netcdf file to gempak



Wuyin,

The dcreanal & dcreanal2 programs will assume that the COARDS convention
grids are CED. The NetCDF files I looked at didn't define a projection, but 
rather just gave the lats and lons of all the grid points, so I
computed the delta-lat and delta-lon for the CED grid from them. The
global grids I looked at were either CED or a gaussian grid.

Yes, it is true that the dcreanal decoder recognizes the parameter
through the GRIB_id and GRIB_name attributes in the reanalysis. In
absence of these, the decoder just skips the parameter, which is
why you don't see any output.

The file header you sent looks very close to that which dcreanal2 can
handle. I did leave an example of the data I was given in
$NAWIPS/unidata/ldmbridge/dcreanal2/datau.cdf.

It looks like the only thing missing in your header is the lack of 
the GRIB parameter identifier for lookup in the ncarncep1.tbl file.

The U wind component attributes in the file I mentioned above have:
u:grib_name = "UGRD" ;
u:gribparam = 33 ;

My program looks for either "GRIB_name" or "grib_name", and
"GRIB_id" or "gribparam". The U wind component parameter ID=33 is
matched in the ncarncep1.tbl file for the GEMPAK conventional name
of UREL.

In your header you sent, there wasn't a GRIB id:
        float uwnd(time, level, lat, lon) ;
                uwnd:long_name = "Monthly Longterm Mean of U-Wind" ;
                uwnd:actual_range = -24.25311f, 49.69793f ;
                uwnd:units = "m/s" ;
                uwnd:add_offset = 0.f ;
                uwnd:scale_factor = 1.f ;
                uwnd:missing_value = -9.96921e+36f ;
                uwnd:precision = 0s ;
                uwnd:least_significant_digit = 0s ;
                uwnd:var_desc = "u-wind\n", "U" ;
                uwnd:dataset = "CDC Derived NCEP Reanalysis Products\n", "AC" ;
                uwnd:level_desc = "Multiple levels\n", "F" ;
                uwnd:statistic = "Long Term Mean\n", "C" ;
                uwnd:parent_stat = "Other\n",


If necessary, I could rewrite the program to use the "var_desc" name of "U",
but you would loose some functionality in GEMPAK by not using conventional
names. For example, GEMPAK knows to combine the UREL and VREL components
when you use the "OBS" or "WND" name in a grid function. If your grids were
named U and V, you would have to compose the vector first before use
in a funvtion.

The dcreanal2 decoder looks for "level", "time", "lat" and "lon",
and does have the GRIB_id and GRIB_name in your level parameter,
so the vertical coordinate id will be found in the vcrdgrib1.tbl.
The time and lat/lon also look like what I wrote thr program to
handle.

       float level(level) ;
                level:units = "millibar" ;
                level:long_name = "Level" ;
                level:positive = "down" ;
                level:GRIB_id = 100s ;
                level:GRIB_name = "hPa" ;
                level:actual_range = 1000.f, 10.f ;
        float lat(lat) ;
                lat:units = "degrees_north" ;
                lat:actual_range = 90.f, -90.f ;
                lat:long_name = "Latitude" ;
        float lon(lon) ;
                lon:units = "degrees_east" ;
                lon:long_name = "Longitude" ;
                lon:actual_range = 0.f, 357.5f ;
        double time(time) ;
                time:units = "hours since 1-1-1 00:00:0.0" ;
                time:long_name = "Time" ;
                time:actual_range = 0., 8016. ;
                time:delta_t = "0000-01-00 00:00:00" ;
                time:avg_period = "0029-00-00 00:00:00" ;
                time:prev_avg_period = "0000-00-00 06:00:00" ;
                time:ltm_range = 17242392., 17495880. ;

Steve Chiswell
Unidata User Support




>From: Wuyin Lin <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200210021822.g92IM5119927

>  This message is in MIME format.  The first part should be readable text,
>  while the remaining parts are likely unreadable without MIME-aware tools.
>  Send mail to address@hidden for more info.
>
>--0-1037082531-1033583071=:7370
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>Hi Steve,
>
>   I find a long term mean u-wind from ncep-reanalysis.
>The header of the netcdf file is attached. Is that true
>the variable and vertical coordinate have to be recognized
>by the decoder thru attributes "GRID_id, GRIB_name"? If so,
>I will be close to get the solution. Should the projection
>method be defined somehow in netcdf file? If no definition at all,
>will it be considered CED by default?
>
>  I applied dcreanal to the netcdf file mentioned above.
>It did nothing except printing the following. Looks like
>I am still missing something. Could you take a look of the attach
>header file?
>
>#>dcreanal uwnd.mon.ltm.nc uwnd.gem
> Changing center table to cntrgrib1.tbl
> Changing vertical coord table to vcrdgrib1.tbl
> Changing WMO parameter table to ncarncep1.tbl
> Changing center parameter table to ncarncep1.tbl
>
> thanks a lot.
>
>Wuyin
>
>On Wed, 2 Oct 2002, Unidata Support wrote:
>
>> 
>> Wuyin,
>> 
>> If you are creating grib messages, then you do have to
>> create the necessary parameter tables for the model center
>> for the grib decoders to correctly identify the parameters.
>> Typically, you would define the projection in the GDS block
>> which is the convention by which the decoder will determine
>> the grid projection for the GEMPAK file.
>> 
>> As for the netcdf file, writing a decoder for a specific CDL is
>> possible, which is what I did for the NCAP/NCEP reanalysis NetCDF files
>> with the dcreanal and dcreanal2 decoders. These netcdf files
>> used the COARDS convention. If yoru files are similar,
>> then the dcreanal decoder would be a good strarting point.
>> 
>> It is not generally possible to write a single NetCDF decoder 
>> for all possible NetCDF grid files since the flexibility in the 
>> CDL convention used prohibits a generic solution.
>> 
>> One typical problem you may confront is that GEMPAK requires
>> even spacing between grid rows, while some climate model output uses
>> a gaussian grid where the grid row spacing varies with latitude.
>> You would have to interpolate to evenly spaced grid rows in that case
>> in order to use the data within GEMPAK.
>> 
>> Steve Chiswell
>> 
>> 
>> >From: Wuyin Lin <address@hidden>
>> >Organization: UCAR/Unidata
>> >Keywords: 200210021446.g92Ekp105849
>> 
>> >Dear GEMPAK support team,
>> >
>> >   I would like to display ccm output using gempak.
>> >The ccm output are in netcdf format. I do find some
>> >old messages on the unidata archive discussing 
>> >the conversion from netcdf to gempak. (e.g.,
>> >http://www.unidata.ucar.edu/projects/coohl/mhonarc/MailArchives/gempak/msg0
> 068
>> > 9.html)
>> >but still clueless how to apply it.
>> >
>> >   Indirectly, I attempted to use dcgrib/dcgrib2. 
>> >First, a sample netcdf file is converted to GRIB using
>> >gradsnc/lats4d. But there is not much documentation
>> >for lats4d and the generated GRIB file can't be
>> >recogized by the decoders dcgrib/dcgrib2 for various
>> >reason (e.g, projection, grib compression table, etc.)
>> >causing the creation of gempak to fail.
>> >
>> >   Advices on how to proceed with this conversion and
>> >guidelines for any existing resources are greatly appreciated.
>> >
>> >   thank you very much,
>> >
>> >Wuyin Lin
>> >address@hidden
>> >
>> >
>> >From address@hidden Tue Oct  1 14:14:33 2002
>> >Received: from atmsci.msrc.sunysb.edu (atmsci.msrc.sunysb.edu [129.49.64.50
> ])
>> >    by unidata.ucar.edu (UCAR/Unidata) with ESMTP id g91KEX122348
>> >    for <address@hidden>; Tue, 1 Oct 2002 14:14:33 -0600 (
>> > MDT)
>> >Organization: UCAR/Unidata
>> >Keywords: 200210012014.g91KEX122348
>> >Received: from localhost (wlin@localhost)
>> >    by atmsci.msrc.sunysb.edu (8.9.3/8.9.3) with SMTP id QAA04801
>> >    for <address@hidden>; Tue, 1 Oct 2002 16:16:58 -0400 (
>> > EDT)
>> >Date: Tue, 1 Oct 2002 16:16:57 -0400 (EDT)
> >From: Wuyin Lin <address@hidden>
>> >To: address@hidden
>> >Subject: convert ccm netcdf tape to gempak
>> >Message-ID: <address@hidden
> u>
>> >MIME-Version: 1.0
>> >Content-Type: TEXT/PLAIN; charset=US-ASCII
>> >
>> >Dear GEMPAK support team,
>> >
>> >   I would like to display ccm output using gempak.
>> >The ccm output are in netcdf format. I do find some
>> >old messages on the unidata archive discussing 
>> >the conversion from netcdf to gempak. (e.g.,
>> >http://www.unidata.ucar.edu/projects/coohl/mhonarc/MailArchives/gempak/msg0
> 068
>> > 9.html)
>> >but still clueless how to apply it.
>> >
>> >   Indirectly, I attempted to use dcgrib/dcgrib2. 
>> >First, a sample netcdf file is converted to GRIB using
>> >gradsnc/lats4d. But there is not much documentation
>> >for lats4d and the generated GRIB file can't be
>> >recogized by the decoders dcgrib/dcgrib2 for various
>> >reason (e.g, projection, grib compression table, etc.)
>> >causing the creation of gempak to fail.
>> >
>> >   Advices on how to proceed with this conversion and
>> >guidelines for any existing resources are greatly appreciated.
>> >
>> >   thank you very much,
>> >
>> >Wuyin Lin
>> >address@hidden
>> >
>> 
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8643                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service                        http://www.unidata.ucar.edu/     
>> ****************************************************************************
>> 
>
>--0-1037082531-1033583071=:7370
>Content-Type: TEXT/PLAIN; charset=US-ASCII; name="header.txt"
>Content-Transfer-Encoding: BASE64
>Content-ID: <address@hidden>
>Content-Description: A-netcdf-header
>
>bmV0Y2RmIHV3bmQubW9uLmx0bSB7DQpkaW1lbnNpb25zOg0KCWxvbiA9IDE0
>NCA7DQoJbGF0ID0gNzMgOw0KCWxldmVsID0gMTcgOw0KCXRpbWUgPSBVTkxJ
>TUlURUQgOyAvLyAoMTIgY3VycmVudGx5KQ0KdmFyaWFibGVzOg0KCWZsb2F0
>IGxldmVsKGxldmVsKSA7DQoJCWxldmVsOnVuaXRzID0gIm1pbGxpYmFyIiA7
>DQoJCWxldmVsOmxvbmdfbmFtZSA9ICJMZXZlbCIgOw0KCQlsZXZlbDpwb3Np
>dGl2ZSA9ICJkb3duIiA7DQoJCWxldmVsOkdSSUJfaWQgPSAxMDBzIDsNCgkJ
>bGV2ZWw6R1JJQl9uYW1lID0gImhQYSIgOw0KCQlsZXZlbDphY3R1YWxfcmFu
>Z2UgPSAxMDAwLmYsIDEwLmYgOw0KCWZsb2F0IGxhdChsYXQpIDsNCgkJbGF0
>OnVuaXRzID0gImRlZ3JlZXNfbm9ydGgiIDsNCgkJbGF0OmFjdHVhbF9yYW5n
>ZSA9IDkwLmYsIC05MC5mIDsNCgkJbGF0OmxvbmdfbmFtZSA9ICJMYXRpdHVk
>ZSIgOw0KCWZsb2F0IGxvbihsb24pIDsNCgkJbG9uOnVuaXRzID0gImRlZ3Jl
>ZXNfZWFzdCIgOw0KCQlsb246bG9uZ19uYW1lID0gIkxvbmdpdHVkZSIgOw0K
>CQlsb246YWN0dWFsX3JhbmdlID0gMC5mLCAzNTcuNWYgOw0KCWRvdWJsZSB0
>aW1lKHRpbWUpIDsNCgkJdGltZTp1bml0cyA9ICJob3VycyBzaW5jZSAxLTEt
>MSAwMDowMDowLjAiIDsNCgkJdGltZTpsb25nX25hbWUgPSAiVGltZSIgOw0K
>CQl0aW1lOmFjdHVhbF9yYW5nZSA9IDAuLCA4MDE2LiA7DQoJCXRpbWU6ZGVs
>dGFfdCA9ICIwMDAwLTAxLTAwIDAwOjAwOjAwIiA7DQoJCXRpbWU6YXZnX3Bl
>cmlvZCA9ICIwMDI5LTAwLTAwIDAwOjAwOjAwIiA7DQoJCXRpbWU6cHJldl9h
>dmdfcGVyaW9kID0gIjAwMDAtMDAtMDAgMDY6MDA6MDAiIDsNCgkJdGltZTps
>dG1fcmFuZ2UgPSAxNzI0MjM5Mi4sIDE3NDk1ODgwLiA7DQoJZmxvYXQgdXdu
>ZCh0aW1lLCBsZXZlbCwgbGF0LCBsb24pIDsNCgkJdXduZDpsb25nX25hbWUg
>PSAiTW9udGhseSBMb25ndGVybSBNZWFuIG9mIFUtV2luZCIgOw0KCQl1d25k
>OmFjdHVhbF9yYW5nZSA9IC0yNC4yNTMxMWYsIDQ5LjY5NzkzZiA7DQoJCXV3
>bmQ6dW5pdHMgPSAibS9zIiA7DQoJCXV3bmQ6YWRkX29mZnNldCA9IDAuZiA7
>DQoJCXV3bmQ6c2NhbGVfZmFjdG9yID0gMS5mIDsNCgkJdXduZDptaXNzaW5n
>X3ZhbHVlID0gLTkuOTY5MjFlKzM2ZiA7DQoJCXV3bmQ6cHJlY2lzaW9uID0g
>MHMgOw0KCQl1d25kOmxlYXN0X3NpZ25pZmljYW50X2RpZ2l0ID0gMHMgOw0K
>CQl1d25kOnZhcl9kZXNjID0gInUtd2luZFxuIiwNCiAgICAiVSIgOw0KCQl1
>d25kOmRhdGFzZXQgPSAiQ0RDIERlcml2ZWQgTkNFUCBSZWFuYWx5c2lzIFBy
>b2R1Y3RzXG4iLA0KICAgICJBQyIgOw0KCQl1d25kOmxldmVsX2Rlc2MgPSAi
>TXVsdGlwbGUgbGV2ZWxzXG4iLA0KICAgICJGIiA7DQoJCXV3bmQ6c3RhdGlz
>dGljID0gIkxvbmcgVGVybSBNZWFuXG4iLA0KICAgICJDIiA7DQoJCXV3bmQ6
>cGFyZW50X3N0YXQgPSAiT3RoZXJcbiIsDQogICAgIi0iIDsNCg0KLy8gZ2xv
>YmFsIGF0dHJpYnV0ZXM6DQoJCTp0aXRsZSA9ICJtb250aGx5IGxvbmd0ZXJt
>IG1lYW4gdSB3aW5kIGZyb20gdGhlIE5DRVAgUmVhbmFseXNpcyIgOw0KCQk6
>aGlzdG9yeSA9ICJDcmVhdGVkIGF0IHRoZSBOT0FBLUNJUkVTIENsaW1hdGUg
>RGlhZ25vc3RpY3MgQ2VudGVyKENEQykgdXNpbmcgL2hvbWUvY2FzL0FUTEFT
>L2NhbGMubW9ubWVhbi5mcm9teXIuZiIgOw0KCQk6ZGVzY3JpcHRpb24gPSAi
>RGF0YSBmcm9tIE5DRVAgaW5pdGlhbGl6ZWQgcmVhbmFseXNpcyAoNHgvZGF5
>KS4gIFRoZXNlIGFyZSBpbnRlcnBvbGF0ZWQgdG8gcHJlc3N1cmUgc3VyZmFj
>ZXMgZnJvbSBtb2RlbCAoc2lnbWEpIHN1cmZhY2VzIiA7DQoJCTpwbGF0Zm9y
>bSA9ICJNb2RlbCIgOw0KCQk6Q29udmVudGlvbnMgPSAiQ09BUkRTIiA7DQo=
>--0-1037082531-1033583071=:7370--
>
>From address@hidden Wed Oct  2 11:50:08 2002
>Received: from atmsci.msrc.sunysb.edu (atmsci.msrc.sunysb.edu [129.49.64.50])
>       by unidata.ucar.edu (UCAR/Unidata) with ESMTP id g92Ho7118234;
>       Wed, 2 Oct 2002 11:50:08 -0600 (MDT)
>Organization: UCAR/Unidata
>Keywords: 200210021750.g92Ho7118234
>Received: from localhost (wlin@localhost)
>       by atmsci.msrc.sunysb.edu (8.9.3/8.9.3) with SMTP id NAA14853;
>       Wed, 2 Oct 2002 13:52:29 -0400 (EDT)
>Date: Wed, 2 Oct 2002 13:52:29 -0400 (EDT)
>From: Wuyin Lin <address@hidden>
>To: Unidata Support <address@hidden>
>cc: address@hidden
>Subject: Re: 20021002: convert ccm netcdf file to gempak 
>In-Reply-To: <address@hidden>
>Message-ID: <address@hidden>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>Steve,
>
>  Thank you very much for the info. dcreanal[2] should be
>the exact one I am looking for. Basically I will re-generate the
>netcdf file from scratch (including grid spacing and
>attributes definition) to follow the COADS convention precisely
>for all necessary definitions. 
>
>Could you show me a simple example what are the necessary parts for a
>netcdf variable (including naming and associated attributes) in order
>to be recognized by the decoder? Such as how a variable is defined
>to match an id on the table of 'ncarncep1.tbl', how a projection
>(if needed ) is defined in netcdf to be recognized by dcreanal?
>How the vertical cooridnate id on 'vcrdgrib1.tbl' to be associated
>with an attribute on the netcdf file? If you know where to download
>a standard netcdf product of ncep re-analysis, (the one kind you wrote
>dcreanal to decode), it should be equally helpful for me as I can 
>study the file header for reference.
>
> thanks again.
>
>Wuyin
>On Wed, 2 Oct 2002, Unidata Support wrote:
>
>> 
>> Wuyin,
>> 
>> If you are creating grib messages, then you do have to
>> create the necessary parameter tables for the model center
>> for the grib decoders to correctly identify the parameters.
>> Typically, you would define the projection in the GDS block
>> which is the convention by which the decoder will determine
>> the grid projection for the GEMPAK file.
>> 
>> As for the netcdf file, writing a decoder for a specific CDL is
>> possible, which is what I did for the NCAP/NCEP reanalysis NetCDF files
>> with the dcreanal and dcreanal2 decoders. These netcdf files
>> used the COARDS convention. If yoru files are similar,
>> then the dcreanal decoder would be a good strarting point.
>> 
>> It is not generally possible to write a single NetCDF decoder 
>> for all possible NetCDF grid files since the flexibility in the 
>> CDL convention used prohibits a generic solution.
>> 
>> One typical problem you may confront is that GEMPAK requires
>> even spacing between grid rows, while some climate model output uses
>> a gaussian grid where the grid row spacing varies with latitude.
>> You would have to interpolate to evenly spaced grid rows in that case
>> in order to use the data within GEMPAK.
>> 
>> Steve Chiswell
>> 
>> 
>> >From: Wuyin Lin <address@hidden>
>> >Organization: UCAR/Unidata
>> >Keywords: 200210021446.g92Ekp105849
>> 
>> >Dear GEMPAK support team,
>> >
>> >   I would like to display ccm output using gempak.
>> >The ccm output are in netcdf format. I do find some
>> >old messages on the unidata archive discussing 
>> >the conversion from netcdf to gempak. (e.g.,
>> >http://www.unidata.ucar.edu/projects/coohl/mhonarc/MailArchives/gempak/msg0
> 068
>> > 9.html)
>> >but still clueless how to apply it.
>> >
>> >   Indirectly, I attempted to use dcgrib/dcgrib2. 
>> >First, a sample netcdf file is converted to GRIB using
>> >gradsnc/lats4d. But there is not much documentation
>> >for lats4d and the generated GRIB file can't be
>> >recogized by the decoders dcgrib/dcgrib2 for various
>> >reason (e.g, projection, grib compression table, etc.)
>> >causing the creation of gempak to fail.
>> >
>> >   Advices on how to proceed with this conversion and
>> >guidelines for any existing resources are greatly appreciated.
>> >
>> >   thank you very much,
>> >
>> >Wuyin Lin
>> >address@hidden
>> >
>> >
>> >From address@hidden Tue Oct  1 14:14:33 2002
>> >Received: from atmsci.msrc.sunysb.edu (atmsci.msrc.sunysb.edu [129.49.64.50
> ])
>> >    by unidata.ucar.edu (UCAR/Unidata) with ESMTP id g91KEX122348
>> >    for <address@hidden>; Tue, 1 Oct 2002 14:14:33 -0600 (
>> > MDT)
>> >Organization: UCAR/Unidata
>> >Keywords: 200210012014.g91KEX122348
>> >Received: from localhost (wlin@localhost)
>> >    by atmsci.msrc.sunysb.edu (8.9.3/8.9.3) with SMTP id QAA04801
>> >    for <address@hidden>; Tue, 1 Oct 2002 16:16:58 -0400 (
>> > EDT)
>> >Date: Tue, 1 Oct 2002 16:16:57 -0400 (EDT)
>> >From: Wuyin Lin <address@hidden>
>> >To: address@hidden
>> >Subject: convert ccm netcdf tape to gempak
>> >Message-ID: <address@hidden
> u>
>> >MIME-Version: 1.0
>> >Content-Type: TEXT/PLAIN; charset=US-ASCII
>> >
>> >Dear GEMPAK support team,
>> >
>> >   I would like to display ccm output using gempak.
>> >The ccm output are in netcdf format. I do find some
>> >old messages on the unidata archive discussing 
>> >the conversion from netcdf to gempak. (e.g.,
>> >http://www.unidata.ucar.edu/projects/coohl/mhonarc/MailArchives/gempak/msg0
> 068
>> > 9.html)
>> >but still clueless how to apply it.
>> >
>> >   Indirectly, I attempted to use dcgrib/dcgrib2. 
>> >First, a sample netcdf file is converted to GRIB using
>> >gradsnc/lats4d. But there is not much documentation
>> >for lats4d and the generated GRIB file can't be
>> >recogized by the decoders dcgrib/dcgrib2 for various
>> >reason (e.g, projection, grib compression table, etc.)
>> >causing the creation of gempak to fail.
>> >
>> >   Advices on how to proceed with this conversion and
>> >guidelines for any existing resources are greatly appreciated.
>> >
>> >   thank you very much,
>> >
>> >Wuyin Lin
>> >address@hidden
>> >
>> 
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8643                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service                        http://www.unidata.ucar.edu/     
>> ****************************************************************************
>> 
>