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

[GEMPAK #XCU-941477]: GDGRIB



Kimberly,

Thanks for uploading the gem file.  I played around with it and the solution I 
have at this time is to "manually" adjust the scale of your TFP grid (which is 
currently 10**10) with GDCFIL and GDDIAG by specifying GFUNC = 
mul(tfp,exp(10,10)):

 GEMPAK-GDCFIL>
 GDOUTF   = tfp.gem
 PROJ     =  
 GRDAREA  =  
 KXKY     =  
 MAXGRD   = 10
 CPYFIL   = narr-a_221_20080130_0000_000.gem
 ANLYSS   =  

 GEMPAK-GDDIAG>
 GDFILE   = narr-a_221_20080130_0000_000.gem
 GDOUTF   = tfp2.gem
 GFUNC    = mul(tfp,exp(10,10))
 GDATTIM  = F00
 GLEVEL   = 700:1000
 GVCORD   = pres
 GRDNAM   = TFP
 GRDTYP   = S
 GPACK    =  
 GRDHDR   =  
 PROJ     =  
 GRDAREA  =  
 KXKY     =  
 MAXGRD   = 10
 CPYFIL   = tfp2.gem
 ANLYSS   =  

at this point run GDGRIB as you were before but with CPYFIL and GDFILE = 
tfp2.gem.  I'm not certain why scaling is not adjusted by default when using 
GDGRIB, but it seems that it simply won't work correctly if the data scale is 
below a certain threshold.

Best,

Michael James
Unidata







> 
> Hi Michael,
> 
> Thanks for the quick response. To answer your first question, yes I did at the
> "TFP" parameter to the ncepgrib129.tbl. I did not get any errors when I ran
> gdgrib using this parameter. I've upload both the .gem file and my
> ncepgrib129.tbl to the site as a tar file (khoogewi.tar).
> 
> I think I can get around this by writing a fortran program to convert a text
> file (created from gdlist) into a grib file. However, I think it may be a 
> little
> tricky to read in the data because of the format that gdlist outputs the
> data--particularly for a novice programmer like me! So, I appreciate any help
> that I can get!
> 
> 
> Thanks a bunch,
> 
> Kim
> 
> 
> 
> 
> Quoting Unidata GEMPAK Support <address@hidden>:
> 
> > Kimberly,
> >
> > The first question I have to ask is if you have added an entry for this 
> > "TFP"
> > parameter in ncepgrib129.tbl?
> >
> > Do you see any GDGRIB errors reported such as:
> >
> > [GDGRIB -83]  Cannot find parameter in tables
> >
> > Lastly, it would help if you could upload the .gem file you're using to the
> > RAMADDA repository located at
> >
> > http://motherlode.ucar.edu/repository/alias/gempakuploads/
> >
> > that way I can play around with GDGRIB on my end and see what I can find.
> >
> > Best,
> >
> > Michael James
> > Unidata
> >
> >
> >
> >
> > > Full Name: Kimberly Hoogewind
> > > Email Address: address@hidden
> > > Organization: Purdue University
> > > Package Version: 5.11.1
> > > Operating System:
> > > Hardware:
> > > Description of problem: Hello,
> > >
> > > I am having an issue with gdgrib writing out an empty grib file. I've
> > calculated a rather complex parameter and stored it back into my original
> > .gem file using gddiag. This was successful as I was able to plot the
> > parameter as well as see the values at each grid point using gdlist. For 
> > some
> > reason, though, gdgrib just does not work for this parameter (my program
> > input is listed below). It does, however, seem to work when I use a function
> > such as TMPF or HGHT at a certain level. Could this be due to some grid
> > points containing missing data for my calculated parameter(-9999.0)?
> > >
> > > Any advice would be very much appreciated!
> > >
> > > Thanks!
> > >
> > > Kim
> > >
> > >
> > > file=$1
> > >
> > > $GEMEXE/gdgrib<<EOF
> > >
> > > GDFILE   = $file.gem
> > > GFUNC    = TFP
> > > GDATTIM  = F00
> > > GLEVEL   = 700:1000
> > > GVCORD   = pres
> > > GBTBLS   = ncepgrib129.tbl
> > > GBFILE   = $file-NEW.grb
> > > VERCEN   = 129/7/0/0
> > > PDSVAL   = 223
> > > PRECSN   = d/6
> > > WMOHDR   =
> > > CPYFIL   = $file.gem
> > > PROJ     =
> > > GRDAREA  =
> > > KXKY     =
> > > r
> > >
> > > EOF
> > >
> > >
> > >
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: XCU-941477
> > Department: Support GEMPAK
> > Priority: Normal
> > Status: Open
> >
> >
> 
> 
> 


Ticket Details
===================
Ticket ID: XCU-941477
Department: Support GEMPAK
Priority: Normal
Status: Open