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

Re: [gembud] GEMPAK GRIB Bug?

Unidata made one change and NCEP made a different one to the routine
to handle the constant grids.  There is no blame here - Scott showed
me the message before he sent it (I've been at NCEP all week) and
I approved what he said.  We will get the Unidata distribution fixed,
but might wait until the 5.11.3 release.

Brent, which version of GEMPAK were you using for your tests?
I didn't see that in your e-mail. (You can answer offline if you want).

Don


John Huddleston wrote:

So basically NCEP made a mistake and is blaming it on Unidata.
_____ 
From: address@hidden
[mailto:address@hidden] On Behalf Of Scott Jacobs
Sent: Thursday, May 15, 2008 1:26 PM
To: Brent L Shaw
Cc: address@hidden; address@hidden
Subject: Re: [gembud] GEMPAK GRIB Bug?


Brent, et al.,

We fixed this problem with constant grids in 5.11.1. However, looking at the
Unidata release of 5.11.1, there is a discrepancy with the function that we
modified. We will work with the Unidata team to get this fixed in their copy
of NAWIPS/GEMPAK so that it can be made available to the entire community.

Scott Jacobs
NCEP NAWIPS Development Team
Brent L Shaw wrote: 
I have searched the GEMBUD and GEMPAK support lists and have not found this
reported by anyone else, but it seems that NAWIPS/GEMPAK has an issue with
GRIB records where the decoded values should be an entire grid of zeros (as
sometimes happens with precipitation and hydrometeor fields in limited area
mesoscale models).  I have found this problem using a Linux build of
NAWIPS/GEMPAK that I have built from source using g77 and gcc.  I have found
it to be a problem on both 32-bit Linux and 64-bit Linux (RedHat in both
cases).  Here is a detailed description of what I did and observed:


1.      GRIB edition 1 files (created by the NCEP-developed WRF
myfile.grb
2.      Rendered the total precipitation forecast from the resulting GEMPAK
file and find a corrupted, noisy image that changes patterns each time I hit
reload.  Additionally, the rendering generates the following error in the
Error status window:

[DG2] Too many maxs found -- increase radius or reduce range

3.      Ran the GEMPAK file through "gdlist" to see min/max values actually
contained in the GEMPAK file.  It reports a combination of zeros, 10.0s,
20.0s, and 30.0s.
4.      Ran the original GRIB file through wgrib and IDV and verified the
original GRIB field is encoded correctly and that all grid points actually
are 0.


The attached tar ball has the original GRIB record, the resulting GEMPAK
file created from dcgrib2, and the sample NAWIPS image demonstrating the
problem.


Thanks for your help in advance!  Please let me know if you need anything
else from me.


Best regards,


Brent


Brent Shaw

Senior Meteorologist and Project Manager


Weather <http://www.wdtinc.com/>  Decision Technologies Inc.

3100 Monitor Ave.

Norman, OK 73072

Office:  (405) 579-7675 x246

Mobile: (405) 397-9950
_____
_______________________________________________ 
gembud mailing list
address@hidden
For list information or to unsubscribe,  visit:
http://www.unidata.ucar.edu/mailing_lists/ 


------------------------------------------------------------------------

_______________________________________________
gembud mailing list
address@hidden
For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/ 

--
*************************************************************
Don Murray                               UCAR Unidata Program
address@hidden                        P.O. Box 3000
(303) 497-8628                              Boulder, CO 80307
http://www.unidata.ucar.edu/staff/donm
*************************************************************