Re: [gembud] GEMPAK GRIB Bug?

That is not what I read. What I read is that NCEP fixed
a bug that somehow did not get into the Unidata release.
I do not see anybody trying to blame anybody else. I see
two groups working cooperatively to fix a bug in
the code. This is a GOOD thing. Thanks NCEP and Unidata.
All code of this complexity has bugs - thanks Scott
for tracking down where the bug was and making the fix
available to all. And thanks Brent for pointing out
and documenting the bug.

David

> John Huddleston wrote:
> So basically NCEP made a mistake and is blaming it on Unidata.
> 
>  
> 
>   _____  
> 
> From: gembud-bounces@xxxxxxxxxxxxxxxx
> [mailto:gembud-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Scott Jacobs
> Sent: Thursday, May 15, 2008 1:26 PM
> To: Brent L Shaw
> Cc: gembud@xxxxxxxxxxxxxxxx; support-gempak@xxxxxxxxxxxxxxxx
> 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
> post-processor) are decoded with dcgrib2 as follows:  dcgrib2 myfile.gem <
> 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
> gembud@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe,  visit:
> http://www.unidata.ucar.edu/mailing_lists/ 

[image/gif is not supported, skipping...]

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