[Met_help] [rt.rap.ucar.edu #68617] History for grib2 error message in pcp_combine
John Halley Gotway via RT
met_help at ucar.edu
Thu Aug 14 14:38:33 MDT 2014
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi MET help,
I have a NDFD grib2 file with QPF data over the Mid Atlantic sector. I
would like to convert it to a netcdf file that I can eventually run
through grid_stat with a netcdf Stage IV data file. However, when I try
to run pcp_combine, I get the following error.
[esukovich at linux64 NDFD_Data]$ pcp_combine 00000000_000000 06
20091206_120000 06 TestGrb2file.nc
DEBUG 1: [1] File ./YICZ98_KWBN_200912051301 matches valid time of
20091206_120000
DEBUG 1: [1] Reading input file: ./YICZ98_KWBN_200912051301
ERROR : MetGrib2DataFile::data_plane() found unrecognized ScanMode (80)
ERROR :
I have checked that the appropriate flags are activated in the
user_defs.mk file but I am still missing something. Any ideas? I have
attached the NDFD file for reference.
Thank you!
Ellen
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: grib2 error message in pcp_combine
From: John Halley Gotway
Time: Tue Aug 12 12:07:47 2014
Ellen,
Thanks for sending that data file. I'll take a look at it and let you
know
what I find.
Thanks,
John Halley Gotway
met_help at ucar.edu
On Tue, Aug 12, 2014 at 11:22 AM, Ellen.Sukovich at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> Tue Aug 12 11:22:15 2014: Request 68617 was acted upon.
> Transaction: Ticket created by Ellen.Sukovich at noaa.gov
> Queue: met_help
> Subject: grib2 error message in pcp_combine
> Owner: Nobody
> Requestors: Ellen.Sukovich at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68617 >
>
>
> Hi MET help,
>
> I have a NDFD grib2 file with QPF data over the Mid Atlantic sector.
I
> would like to convert it to a netcdf file that I can eventually run
> through grid_stat with a netcdf Stage IV data file. However, when I
try
> to run pcp_combine, I get the following error.
>
> [esukovich at linux64 NDFD_Data]$ pcp_combine 00000000_000000 06
> 20091206_120000 06 TestGrb2file.nc
> DEBUG 1: [1] File ./YICZ98_KWBN_200912051301 matches valid time of
> 20091206_120000
> DEBUG 1: [1] Reading input file: ./YICZ98_KWBN_200912051301
> ERROR : MetGrib2DataFile::data_plane() found unrecognized ScanMode
(80)
> ERROR :
>
> I have checked that the appropriate flags are activated in the
> user_defs.mk file but I am still missing something. Any ideas? I
have
> attached the NDFD file for reference.
>
> Thank you!
> Ellen
>
>
>
>
------------------------------------------------
Subject: grib2 error message in pcp_combine
From: John Halley Gotway
Time: Tue Aug 12 15:29:53 2014
Ellen,
I ran this through the debugger and this is just a variant of the
GRIB2
Scanning Mode flag we have not yet encountered:
http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table3-4.shtml
A value of 80 translates to 0101 0000 in bits, meaning +x and -y
direction. But adjacent rows scan in the opposite direction. Meaning
the
data is stored in a zig-zag pattern (right to left, left to right,
right to
left, and so on). I added another entry to a case statement to handle
this
combination which produces the attached image for the first time step
in
that file.
I also plotted this dataset using IDV which produces a similar pattern
(image also attached). The pattern does look pretty odd, but its the
same
in both images. So I'm pretty sure we're now reading the data
correctly.
However, MET is treating the value of 9999 as real data values while
IDV is
correctly ignoring it as fill data. That GRIB2 file doesn't use a
bitmap
section, which is the only way I've seen missing data specified in
GRIB
files. I don't know how you specify a missing data value in GRIB2.
So I'm
still looking into that.
Thanks,
John
On Tue, Aug 12, 2014 at 12:07 PM, The RT System itself via RT <
met_help at ucar.edu> wrote:
>
> Tue Aug 12 12:07:48 2014: Request 68617 was acted upon.
> Transaction: Given to johnhg by RT_System
> Queue: met_help
> Subject: grib2 error message in pcp_combine
> Owner: johnhg
> Requestors: Ellen.Sukovich at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68617 >
>
>
> This transaction appears to have no content
>
------------------------------------------------
Subject: grib2 error message in pcp_combine
From: John Halley Gotway
Time: Tue Aug 12 17:49:26 2014
Ellen,
I just posted a METv4.1 patch for this issue here:
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
The patch adds support for the Scanning Mode value of 80 and also
retrieves
the missing data value(s) from the GRIB2 metadata and checks for them
when
parsing the data.
Please give that a shot and let us know if you run into any more
problems
using NDFD data in MET. The attached image demonstrates that MET is
now
treating the missing data correctly. The ocean is now gray (missing
data)
rather than pink (large data values).
METv4.1/bin/plot_data_plane \
YICZ98_KWBN_200912051301 \
YICZ98_KWBN_200912051301_patch.ps \
'name="APCP"; level="A06";'
Thanks,
John
On Tue, Aug 12, 2014 at 3:29 PM, John Halley Gotway <johnhg at ucar.edu>
wrote:
> Ellen,
>
> I ran this through the debugger and this is just a variant of the
GRIB2
> Scanning Mode flag we have not yet encountered:
> http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table3-4.shtml
>
> A value of 80 translates to 0101 0000 in bits, meaning +x and -y
> direction. But adjacent rows scan in the opposite direction.
Meaning the
> data is stored in a zig-zag pattern (right to left, left to right,
right to
> left, and so on). I added another entry to a case statement to
handle this
> combination which produces the attached image for the first time
step in
> that file.
>
> I also plotted this dataset using IDV which produces a similar
pattern
> (image also attached). The pattern does look pretty odd, but its
the same
> in both images. So I'm pretty sure we're now reading the data
correctly.
>
> However, MET is treating the value of 9999 as real data values while
IDV
> is correctly ignoring it as fill data. That GRIB2 file doesn't use
a
> bitmap section, which is the only way I've seen missing data
specified in
> GRIB files. I don't know how you specify a missing data value in
GRIB2.
> So I'm still looking into that.
>
> Thanks,
> John
>
>
>
>
> On Tue, Aug 12, 2014 at 12:07 PM, The RT System itself via RT <
> met_help at ucar.edu> wrote:
>
>>
>> Tue Aug 12 12:07:48 2014: Request 68617 was acted upon.
>> Transaction: Given to johnhg by RT_System
>> Queue: met_help
>> Subject: grib2 error message in pcp_combine
>> Owner: johnhg
>> Requestors: Ellen.Sukovich at noaa.gov
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68617 >
>>
>>
>> This transaction appears to have no content
>>
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #68617] grib2 error message in pcp_combine
From: Ellen.Sukovich at noaa.gov
Time: Thu Aug 14 13:58:32 2014
Hi John,
Sorry for the delayed response. I had to get someone with Admin
privileges to apply the patch and recompile.
Anyway, now it works! Thank you so much!
Cheers,
Ellen
On 8/12/2014 5:49 PM, John Halley Gotway via RT wrote:
> Ellen,
>
> I just posted a METv4.1 patch for this issue here:
>
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
>
> The patch adds support for the Scanning Mode value of 80 and also
retrieves
> the missing data value(s) from the GRIB2 metadata and checks for
them when
> parsing the data.
>
> Please give that a shot and let us know if you run into any more
problems
> using NDFD data in MET. The attached image demonstrates that MET is
now
> treating the missing data correctly. The ocean is now gray (missing
data)
> rather than pink (large data values).
>
> METv4.1/bin/plot_data_plane \
> YICZ98_KWBN_200912051301 \
> YICZ98_KWBN_200912051301_patch.ps \
> 'name="APCP"; level="A06";'
>
> Thanks,
> John
>
>
>
> On Tue, Aug 12, 2014 at 3:29 PM, John Halley Gotway
<johnhg at ucar.edu> wrote:
>
>> Ellen,
>>
>> I ran this through the debugger and this is just a variant of the
GRIB2
>> Scanning Mode flag we have not yet encountered:
>> http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table3-4.shtml
>>
>> A value of 80 translates to 0101 0000 in bits, meaning +x and -y
>> direction. But adjacent rows scan in the opposite direction.
Meaning the
>> data is stored in a zig-zag pattern (right to left, left to right,
right to
>> left, and so on). I added another entry to a case statement to
handle this
>> combination which produces the attached image for the first time
step in
>> that file.
>>
>> I also plotted this dataset using IDV which produces a similar
pattern
>> (image also attached). The pattern does look pretty odd, but its
the same
>> in both images. So I'm pretty sure we're now reading the data
correctly.
>>
>> However, MET is treating the value of 9999 as real data values
while IDV
>> is correctly ignoring it as fill data. That GRIB2 file doesn't use
a
>> bitmap section, which is the only way I've seen missing data
specified in
>> GRIB files. I don't know how you specify a missing data value in
GRIB2.
>> So I'm still looking into that.
>>
>> Thanks,
>> John
>>
>>
>>
>>
>> On Tue, Aug 12, 2014 at 12:07 PM, The RT System itself via RT <
>> met_help at ucar.edu> wrote:
>>
>>> Tue Aug 12 12:07:48 2014: Request 68617 was acted upon.
>>> Transaction: Given to johnhg by RT_System
>>> Queue: met_help
>>> Subject: grib2 error message in pcp_combine
>>> Owner: johnhg
>>> Requestors: Ellen.Sukovich at noaa.gov
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=68617 >
>>>
>>>
>>> This transaction appears to have no content
>>>
>>
------------------------------------------------
More information about the Met_help
mailing list