[gembud] GEMPAK GRIB Bug?

[pmanousos at firstenergycorp.com]

Easy now.  That is not what was said or implicated.

gembud-bounces at unidata.ucar.edu wrote on 05/15/2008 04:27:52 PM:

> So basically NCEP made a mistake and is blaming it on Unidata.
> 
> 
> From: gembud-bounces at unidata.ucar.edu [mailto:gembud-
> bounces at unidata.ucar.edu] On Behalf Of Scott Jacobs
> Sent: Thursday, May 15, 2008 1:26 PM
> To: Brent L Shaw
> Cc: gembud at unidata.ucar.edu; support-gempak at unidata.ucar.edu
> 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
>  [image removed] 
> Weather Decision Technologies Inc.
> 3100 Monitor Ave.
> Norman, OK 73072
> Office:  (405) 579-7675 x246
> Mobile: (405) 397-9950
> 
> 
> 
> 
> 

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



-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.unidata.ucar.edu/mailing_lists/archives/gembud/attachments/20080515/b303efc3/attachment.html