This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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