[GEMPAK #UYH-961710]: GDGRIB issues

Kim,

Just wanted to update you on the GDGRIB situation.  Unfortunately, at this 
time, pressure difference layer (PDLY) is not a supported vertical coordinate 
for GDGRIB.  I'm looking into what it will take to add support, but must warn 
you that it may be a while before I have it available for you.

Michael James
Unidata



> Thanks Michael, I appreciate you looking into this for me.
> 
> 
> Kim
> 
> ----- Original Message -----
> From: "Unidata GEMPAK Support" <address@hidden>
> To: address@hidden
> Cc: address@hidden
> Sent: Monday, December 13, 2010 7:55:51 PM
> Subject: [GEMPAK #UYH-961710]: GDGRIB issues
> 
> Kim,
> 
> I have a solution for the first part of this ticket.  Because the second 
> scalar input uses a different level than the first scalar input 
> (PRES@0%none), LEVEL1 from both scalars are combined to be the new LEVEL1 and 
> LEVEL2 outputs.  The fix is to use in-line notation when defining GRDNAM, 
> such as GRDNAM = THTA@60:30%pdly.
> 
> The second part of your ticket I've managed to uncover a lack of support for 
> GVCORD = PDLY in GDGRIB, which I'm still looking into and will update you 
> when more is known, and hopefully with a solution shortly.
> 
> Michael
> 
> 
> > Hi Michael,
> >
> > Sorry, I seemed to have sent the wrong version of gdgrib to you! I had to 
> > write different versions for whether I used NARR data or output from my WRF 
> > simulations because gddiag defined the levels differently for each case. 
> > Changing the level to 0:30 will output a grib file, but it is empty. This 
> > happens even if I scale the parameter manually. Does this occur on your end?
> >
> >
> > Thanks,
> >
> > Kim
> >
> > ----- Original Message -----
> > From: "Unidata GEMPAK Support" <address@hidden>
> > To: address@hidden
> > Cc: address@hidden
> > Sent: Tuesday, December 7, 2010 4:18:54 PM
> > Subject: [GEMPAK #UYH-961710]: GDGRIB issues
> >
> > Kim,
> >
> > The incorrect LEVEL2 definition issue may be a bug that you discovered.  
> > I'm waiting to hear back from others about it, and will let you know what I 
> > find out.
> >
> > As for the error with GDGRIB, correct me if I'm wrong, but it seems that 
> > the last grid which was added to your file was
> >
> > GRDNAM   = combinedGGT%PDLY
> >
> > with
> >
> > GFUNC    = ADD(THTEGGT@0:60%PDLY,GGTpdly@30:60%PDLY)
> > GDATTIM  = F000
> > GLEVEL   = 0:60
> > GVCORD   = PDLY
> >
> > however, GDINFO shows combinedGGT saved as
> >
> > NUM       TIME1              TIME2           LEVL1 LEVL2  VCORD PARM
> > 347     080130/0000F000                          0  30     PDLY COMBINEDGGT
> >
> >
> > Can you confirm this on your end? (in GDINFO set GLEVEL = all, GVCORD = 
> > all, GDATTIM = all and GFUNC = COMBINEDGGT)
> >
> > If I run GDGRIB as you have in your script, with GLEVEL = 30:60, I see an 
> > error reporting no grid exists (true).  If I change it to GLEVEL = 0:30, I 
> > am able to write out the grib file as expected.
> >
> > I want to make sure that we're on the same page here, as there are a lot of 
> > steps involved to get to this point, and have COMBINEDGGT written with the 
> > correct time, v-coord and levels.  If we're good up to this point, then 
> > could the problem you're experiencing simply be that GLEVEL is defined 
> > incorrectly in GDGRIB?
> >
> > Let me know what you find and hopefully I'll have some more info for you 
> > about the GDDIAG level error.
> >
> > Michael James
> >
> >
> > Unidata
> >
> >
> >
> >
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: UYH-961710
> > Department: Support GEMPAK
> > Priority: Normal
> > Status: Open
> >
> >
> 
> 
> Ticket Details
> ===================
> Ticket ID: UYH-961710
> Department: Support GEMPAK
> Priority: Normal
> Status: Open
> 
> 


Ticket Details
===================
Ticket ID: UYH-961710
Department: Support GEMPAK
Priority: High
Status: Open