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.
Hi Kimberly, I remember the GDGRIB issue before, and would like to see what I can find by debugging your process. Can you supply me with the full GDDIAG and GDGRIB variable definitions you're using? Michael James Unidata > Full Name: Kimberly Hoogewind > Email Address: address@hidden > Organization: Purdue University > Package Version: > Operating System: > Hardware: > Description of problem: Greetings, > > I am having some difficulties using gdgrib once again. I am encountering a > similar problem that I had on a previous occasion where the gdgrib program > was outputting an empty grib file. The suggested solution of manually scaling > my parameter using gddiag before using gdgrib worked well for that particular > issue, however, it is not working for this new case. > > I am computing a parameter in gddiag that uses thta on pressure depth layers > (PDLY) within the boundary layer. While gddiag does not seem to store the > parameter on the specified layer (it seems to create its own new layer, i.e. > 30:60 becomes 0:60), I am able to get around this so long as I am aware of > which level the parameter is stored at. But the real issue occurs when I try > to output this new parameter in a grib file; either the process just hangs or > an empty grib file is output. I have tried using different versions of GEMPAK > (5.11.1 and the newest 6.2.0), but this does not make a difference. Any > ideas? I can upload some data if necessary. > > Thanks! > > Kim > > Ticket Details =================== Ticket ID: UYH-961710 Department: Support GEMPAK Priority: Normal Status: Open