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

[GEMPAK #JXL-995488]: GEMPAK - Using NSSL NetCDF radar in GEMPAK



John,

If you are trying to decode GRIB2 parameters as below, you will have
to create a local center table for the model center that NSSL is using.
The junk in the table name is due to the number that is being used 
not being defined in wmocenter.tbl. Using verbose 4 in dcgrib2, I find
that the modelling center is 161. I created a wmocenter entry of NSSL for
that center, and then created a g2varsnssl0.tbl for the correct parameter 
category and discipling set: 0 15 192 0. I also had to create a vertical 
coordinate edition 0 table. I still get an error in decoding which exists
in both nagrib2 as well as dcgrib2 which I'll investigate further, but something
is apparently not right.


The files that NSSL is sending via LDM here are the qpesums grids and
are able to be displayed as images in any GEMPAK program, but the format of 
these netcdf files is different than what you have. Yours has pixel array values
of a lat/lon image. The header of one of the files I have
looks like:
netcdf 20060724-2040 {
dimensions:
        Lat = 1501 ;
        Lon = 2001 ;
variables:
        short cref(Lat, Lon) ;
                cref:Units = "dBZ" ;
                cref:TypeName = "cref" ;
                cref:MissingData = -999.f ;
                cref:Scale = 10.f ;
                cref:attributes = "" ;
        short hgt_cref(Lat, Lon) ;
                hgt_cref:Units = "kmMSL" ;
                hgt_cref:TypeName = "hgt_cref" ;
                hgt_cref:MissingData = -1.f ;
                hgt_cref:Scale = 1000.f ;
                hgt_cref:attributes = "" ;
        short etp18(Lat, Lon) ;
                etp18:Units = "kmMSL" ;
                etp18:TypeName = "etp18" ;
                etp18:MissingData = -1.f ;
                etp18:Scale = 1000.f ;
                etp18:attributes = "" ;
        short shi(Lat, Lon) ;
                shi:Units = "  " ;
                shi:TypeName = "shi" ;
                shi:MissingData = -999.f ;
                shi:Scale = 10.f ;
                shi:attributes = "" ;
        short posh(Lat, Lon) ;
                posh:Units = "% " ;
                posh:TypeName = "posh" ;
                posh:MissingData = -999.f ;
                posh:Scale = 10.f ;
                posh:attributes = "" ;
        short mehs(Lat, Lon) ;
                mehs:Units = "mm" ;
                mehs:TypeName = "mehs" ;
                mehs:MissingData = -999.f ;
                mehs:Scale = 10.f ;
                mehs:attributes = "" ;
        short hsr(Lat, Lon) ;
                hsr:Units = "dBZ" ;
                hsr:TypeName = "hsr" ;
                hsr:MissingData = -999.f ;
                hsr:Scale = 10.f ;
                hsr:attributes = "" ;
        short hsrh(Lat, Lon) ;
                hsrh:Units = "kmAGL" ;
                hsrh:TypeName = "hsrh" ;
                hsrh:MissingData = -1.f ;
                hsrh:Scale = 1000.f ;
                hsrh:attributes = "" ;
        short lcref(Lat, Lon) ;
                lcref:Units = "dBZ" ;
                lcref:TypeName = "lcref" ;
                lcref:MissingData = -999.f ;
                lcref:Scale = 10.f ;
                lcref:attributes = "" ;
        short hgt_lcref(Lat, Lon) ;
                hgt_lcref:Units = "kmMSL" ;
                hgt_lcref:TypeName = "hgt_lcref" ;
                hgt_lcref:MissingData = -1.f ;
                hgt_lcref:Scale = 1000.f ;
                hgt_lcref:attributes = "" ;
        short vil(Lat, Lon) ;
                vil:Units = "kg/m2" ;
                vil:TypeName = "vil" ;
                vil:MissingData = -999.f ;
                vil:Scale = 10.f ;
                vil:attributes = "" ;
        short vilD(Lat, Lon) ;
                vilD:Units = "g/m3" ;
                vilD:TypeName = "vilD" ;
                vilD:MissingData = -999.f ;
                vilD:Scale = 10.f ;
                vilD:attributes = "" ;
        short pcp_flag(Lat, Lon) ;
                pcp_flag:Units = "flag" ;
                pcp_flag:TypeName = "pcp_flag" ;
                pcp_flag:MissingData = -999.f ;
                pcp_flag:attributes = "" ;

// global attributes:
                :DataType = "LatLonGrid" ;
                :Time = 1153773600 ;
                :FractionalTime = 0.f ;
                :RangeFolded = -99901.f ;
                :Latitude = 55.f ;
                :Longitude = -130.f ;
                :Height = 0.f ;
                :LatGridSpacing = 0.01f ;
                :LonGridSpacing = 0.01f ;

The NetCDF code I wrote will not work for your image since it does not match
what we are seeing from NSSL.

Steve Chiswell
Unidata User Support



> Steve,
> 
> I've tried putting both a compressed and uncompressed NetCDF file as
> RADFIL in gpmap, set proj to rad and it segfaults on me.  Are you saying
> this only works in NMAP and not the command line tools (which I need to
> generate these images via scripts)?
> 
> As for the issue of using grib2 - I also had that thought as way to get
> around this issue.  The NSSL software comes with a utility that does
> just that.  A little bit of googling and I found a paper that NSSL ships
> the data to SPC in this form for use with GEMPAK there.  I tried using
> it myself, and dcgrib2 chokes with the following error:
> 
> MergedReflectivityQCComposite_20060721-230818.grib
> [17969] 060724/1604[DC 3]  Starting up. Version 5.9.2
> [17969] 060724/1604[DC -11]  No command line arguments found.
> Opening WMO Originating Center Table wmocenter.tbl...
> Opening Local GRIB2 Parameter Table g2varsp??0.tbl...
> [17969] 060724/1604[GB -14]  Could not find entry ... in originating
> center table.
> [17969] 060724/1604[GB -31]  Could not open parameter table file
> g2varsp??0.tbl.
> [17969] 060724/1604[GB 1]  No GEMPAK parameter name defined for this grid.
> [17969] 060724/1604[DECODE_GRIB2 -34] Could not determine parameter name
> 0 15 192 0 [127]
> 
> Note that there is garbage in the g2 parameter table filename it is
> trying to find.
> 
> I've put a sample of my locally generated 3D mosiacs in both NetCDF and
> GRIB2 on our webserver for you.  Grab them at:
> 
> http://wxserver2.mos.org/jmstuff/MergedReflectivityQCComposite_20060721-230818.grib
> http://wxserver2.mos.org/jmstuff/20060721-230818.netcdf.gz
> 
> I'd be happy to get GEMPAK (command line) tools to display this data
> either as GRIB2 or NetCDF!
> 
> John
> 
> Unidata GEMPAK Support wrote:
> > John,
> >
> > I added the ability to read the 2D and 3D NetCDF grids as a radar type of 
> > image,
> > where the NetCDF file is specified as the RADFIL, or under the $RAD tree 
> > for NMAP2.
> > GEMPAK already had the capability of reading AWIPS NetCDF satellite images,
> > so this is just an extension of that.
> >
> > The 3D grids get pretty sparse above the lowest levels when viewed ad 2d 
> > plan view
> > (the level can be specified in the NMAP2 interface just as the level 2 
> > radar tilts).
> >
> > Given the size of the NetCDF files we are getting from NSSL, and the amount 
> > of CPU needed
> > to un-gzip them, I'm looking at another solution such as reformatting the 
> > grids as GRIB2
> > products (as it takes some 13 GB of tiles to do a 3hr loop at the moment.
> >
> > Steve Chiswell
> > Unidata User Support
> >
> >
> >
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: JXL-995488
> > Department: Support GEMPAK
> > Priority: Normal
> > Status: Closed
> >
> >
> 
> 


Ticket Details
===================
Ticket ID: JXL-995488
Department: Support GEMPAK
Priority: Normal
Status: Closed