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, 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