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/
