[Met_help] [rt.rap.ucar.edu #89339] History for Multiple matching
John Halley Gotway via RT
met_help at ucar.edu
Fri Mar 22 14:27:40 MDT 2019
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
I have a grib22 file that contains 3 T2m fields, using wgrib2 has following
73:12900557:d=2019031300:TMP:2 m above ground:12 hour fcst:ENS=? table4.6=192 pert=10
74:13105658:d=2019031300:TMP:2 m above ground:6-12 hour max fcst:ENS=? table4.6=192 pert=10
75:13312997:d=2019031300:TMP:2 m above ground:6-12 hour min fcst:ENS=? table4.6=192 pert=10
Then, in fcst entry of a config file, how to specify the first one?
I remember using " GRIB_lvl_typ" ? How to find its value for each of them?
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Multiple matching
From: John Halley Gotway
Time: Thu Mar 14 13:55:59 2019
Binbin,
I moved your question over to met-help.
Looks like these 3 records differ by the "12 hour fcst" vs "6-12 hour
max fcst" vs "6-12 hour min fcst". With a sample data file I could
confirm, but I'm guessing these records would differ in Section 4,
Octet 35:
https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table4-
7.shtml
Try checking the values by running:
wgrib2 -get_byte 4 35 1 infile.grib2
I'm guessing records 73, 74, and 75 would have values of 0, 9, and 8.
If that is actually the case, you'd distinguish these by setting:
GRIB2_der_type = 8; // or 0 or 9
Make sense?
Thanks,
John
------------------------------------------------
Subject: Multiple matching
From: Binbin.Zhou at noaa.gov
Time: Thu Mar 14 18:12:38 2019
John,
I tried your method, it seems not working. The outfputs for 3 fields
is
"192" . The reason maybe my file is Navy ensemble files which are
not
standard MCEP's GRIB2 format.
I have put one sample file fnmoc01.t00z.grid4.f12.grib2.t2m
in theia directory
/scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_navy/data_full
This file only has 3 TMP/Z2 records.
Binbin
On Thu, Mar 14, 2019 at 3:56 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binbin,
>
> I moved your question over to met-help.
>
> Looks like these 3 records differ by the "12 hour fcst" vs "6-12
hour max
> fcst" vs "6-12 hour min fcst". With a sample data file I could
confirm,
> but I'm guessing these records would differ in Section 4, Octet 35:
>
> https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table4-
7.shtml
>
> Try checking the values by running:
> wgrib2 -get_byte 4 35 1 infile.grib2
>
> I'm guessing records 73, 74, and 75 would have values of 0, 9, and
8. If
> that is actually the case, you'd distinguish these by setting:
> GRIB2_der_type = 8; // or 0 or 9
>
> Make sense?
>
> Thanks,
> John
>
------------------------------------------------
Subject: Multiple matching
From: John Halley Gotway
Time: Fri Mar 15 10:23:28 2019
Binbin,
Thanks for pointing me to the fnmoc sample data. There's a lot of
details
to sift through in through in these GRIB2 files.
One oddity (that coincidentally came up on another met-help ticket
this
week), is the contents of Section 1, Octet 12 which is described here:
https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table1-
2.shtml
*wgrib2 -get_byte 1 12 1
fnmoc01.t00z.grid4.f12.grib2.t2m1:0:1-12=02:205496:1-12=03:413098:1-
12=0*
This fnmoc data has a 0 there indicating that main timestamp is the
analysis time, when clearly its the model initialization time.
NCEP-produced GRIB2 files specify 1 there as far as I know.
This setting leads to a runtime error in the current development
version of
MET. When the reference time is the analysis time, then the file
shouldn't
contain any forecast hours > 0. But it does.
So what do we do here? It probably isn't realistic for fnmoc to
change
these GRIB2 files. I propose that we tell MET to interpret a value of
0
(Analysis) in the same way as a value of 1 (Start of Forecast).
Does that sound sensible to you?
Thanks,
John
On Thu, Mar 14, 2019 at 6:12 PM Binbin.Zhou at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=89339 >
>
> John,
>
> I tried your method, it seems not working. The outfputs for 3
fields is
> "192" . The reason maybe my file is Navy ensemble files which are
not
> standard MCEP's GRIB2 format.
>
> I have put one sample file fnmoc01.t00z.grid4.f12.grib2.t2m
> in theia directory
>
> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_navy/data_full
>
> This file only has 3 TMP/Z2 records.
>
> Binbin
>
>
>
>
> On Thu, Mar 14, 2019 at 3:56 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Binbin,
> >
> > I moved your question over to met-help.
> >
> > Looks like these 3 records differ by the "12 hour fcst" vs "6-12
hour max
> > fcst" vs "6-12 hour min fcst". With a sample data file I could
confirm,
> > but I'm guessing these records would differ in Section 4, Octet
35:
> >
> >
> https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table4-
7.shtml
> >
> > Try checking the values by running:
> > wgrib2 -get_byte 4 35 1 infile.grib2
> >
> > I'm guessing records 73, 74, and 75 would have values of 0, 9, and
8. If
> > that is actually the case, you'd distinguish these by setting:
> > GRIB2_der_type = 8; // or 0 or 9
> >
> > Make sense?
> >
> > Thanks,
> > John
> >
>
>
------------------------------------------------
Subject: Multiple matching
From: Binbin.Zhou at noaa.gov
Time: Fri Mar 15 10:57:05 2019
John,
Thanks! Hope this issue can be resolved in the future. For short
term
solution I can retrieve TMP/L2 record from
FNMOC files and save it in another GRIB2 file (it only contains one
TMP/Z2
field).
Binbin
On Fri, Mar 15, 2019 at 12:23 PM John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Binbin,
>
> Thanks for pointing me to the fnmoc sample data. There's a lot of
details
> to sift through in through in these GRIB2 files.
>
> One oddity (that coincidentally came up on another met-help ticket
this
> week), is the contents of Section 1, Octet 12 which is described
here:
> https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table1-
2.shtml
>
>
>
>
> *wgrib2 -get_byte 1 12 1
> fnmoc01.t00z.grid4.f12.grib2.t2m1:0:1-12=02:205496:1-12=03:413098:1-
12=0*
>
> This fnmoc data has a 0 there indicating that main timestamp is the
> analysis time, when clearly its the model initialization time.
> NCEP-produced GRIB2 files specify 1 there as far as I know.
>
> This setting leads to a runtime error in the current development
version of
> MET. When the reference time is the analysis time, then the file
shouldn't
> contain any forecast hours > 0. But it does.
>
> So what do we do here? It probably isn't realistic for fnmoc to
change
> these GRIB2 files. I propose that we tell MET to interpret a value
of 0
> (Analysis) in the same way as a value of 1 (Start of Forecast).
>
> Does that sound sensible to you?
>
> Thanks,
> John
>
> On Thu, Mar 14, 2019 at 6:12 PM Binbin.Zhou at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=89339 >
> >
> > John,
> >
> > I tried your method, it seems not working. The outfputs for 3
fields is
> > "192" . The reason maybe my file is Navy ensemble files which
are not
> > standard MCEP's GRIB2 format.
> >
> > I have put one sample file fnmoc01.t00z.grid4.f12.grib2.t2m
> > in theia directory
> >
> >
> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_navy/data_full
> >
> > This file only has 3 TMP/Z2 records.
> >
> > Binbin
> >
> >
> >
> >
> > On Thu, Mar 14, 2019 at 3:56 PM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > Binbin,
> > >
> > > I moved your question over to met-help.
> > >
> > > Looks like these 3 records differ by the "12 hour fcst" vs "6-12
hour
> max
> > > fcst" vs "6-12 hour min fcst". With a sample data file I could
> confirm,
> > > but I'm guessing these records would differ in Section 4, Octet
35:
> > >
> > >
> >
> https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table4-
7.shtml
> > >
> > > Try checking the values by running:
> > > wgrib2 -get_byte 4 35 1 infile.grib2
> > >
> > > I'm guessing records 73, 74, and 75 would have values of 0, 9,
and 8.
> If
> > > that is actually the case, you'd distinguish these by setting:
> > > GRIB2_der_type = 8; // or 0 or 9
> > >
> > > Make sense?
> > >
> > > Thanks,
> > > John
> > >
> >
> >
>
>
------------------------------------------------
Subject: Multiple matching
From: John Halley Gotway
Time: Fri Mar 22 11:14:12 2019
Binbin,
FYI, I just committed some changes to the development version of MET
to
make it better handle this case. It's not a great solution, but it
works.
Here's the warning message I see when I run the fnmoc data through
plot_data_plane using met-8.0:
/usr/local/met-8.0/bin/plot_data_plane
fnmoc01.t00z.grid4.f12.grib2.t2m
plot.ps 'name="TMP"; level="Z2";'
*WARNING: MetGrib2DataFile::data_plane() - Multiple matching records
found
for 'TMP/Z2' - 1, 2, 3 - using 1*
Using the development version for met-8.1, the warning message is now
this:
*WARNING: MetGrib2DataFile::data_plane() -> Using the first of 3
matching
records for "TMP/Z2":WARNING: record 1 field 1: ipdtmpl[18] = 0, 0, 4,
58,
50, 0, 0, 1, 12, 103, 0, 2, 255, 0, 0, 192, 1, 20WARNING: record 2
field 1:
ipdtmpl[32] = 0, 0, 4, 58, 50, 0, 0, 11, 1, 103, 0, 2, 255, 0, 0, 192,
1,
20, 2019, 3, 13, 12, 0, 0, 1, 0, 2, 2, 11, 1, 255, 0WARNING: record 3
field
1: ipdtmpl[32] = 0, 0, 4, 58, 50, 0, 0, 11, 1, 103, 0, 2, 255, 0, 0,
192,
1, 20, 2019, 3, 13, 12, 0, 0, 1, 0, 3, 2, 11, 1, 255, 0WARNING: Try
setting
the 0-based "GRIB2_ipdtmpl_index" and "GRIB2_ipdtmpl_val" config file
options to select one.*
The warning message now includes the GRIB2 array of identifying values
for
all matching records. Let's say I want the 2nd record. Looking
carefully,
I see that the 9-th array element has a value of 1 and the 27-th array
element has a value of 2. So I set the new GRIB2_ipdtmpl_index (0-
based)
and GRIB2_ipdtmpl_val config file options. And that finds a single
matching record:
*trunk/met/bin/plot_data_plane fnmoc01.t00z.grid4.f12.grib2.t2m
plot.ps
<http://plot.ps> 'name="TMP"; level="Z2"; GRIB2_ipdtmpl_index=[8,26];
GRIB2_ipdtmpl_val=[1,2];'*
I realize that this isn't a very user-friendly solution but it should
give
us a way to address many issues like this in the future.
Make sense?
Thanks,
John
On Fri, Mar 15, 2019 at 10:57 AM Binbin.Zhou at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=89339 >
>
> John,
>
> Thanks! Hope this issue can be resolved in the future. For
short term
> solution I can retrieve TMP/L2 record from
> FNMOC files and save it in another GRIB2 file (it only contains one
TMP/Z2
> field).
>
> Binbin
>
> On Fri, Mar 15, 2019 at 12:23 PM John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Binbin,
> >
> > Thanks for pointing me to the fnmoc sample data. There's a lot of
> details
> > to sift through in through in these GRIB2 files.
> >
> > One oddity (that coincidentally came up on another met-help ticket
this
> > week), is the contents of Section 1, Octet 12 which is described
here:
> >
> https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table1-
2.shtml
> >
> >
> >
> >
> > *wgrib2 -get_byte 1 12 1
> > fnmoc01.t00z.grid4.f12.grib2.t2m1:0:1-12=02:205496:1-
12=03:413098:1-12=0*
> >
> > This fnmoc data has a 0 there indicating that main timestamp is
the
> > analysis time, when clearly its the model initialization time.
> > NCEP-produced GRIB2 files specify 1 there as far as I know.
> >
> > This setting leads to a runtime error in the current development
version
> of
> > MET. When the reference time is the analysis time, then the file
> shouldn't
> > contain any forecast hours > 0. But it does.
> >
> > So what do we do here? It probably isn't realistic for fnmoc to
change
> > these GRIB2 files. I propose that we tell MET to interpret a
value of 0
> > (Analysis) in the same way as a value of 1 (Start of Forecast).
> >
> > Does that sound sensible to you?
> >
> > Thanks,
> > John
> >
> > On Thu, Mar 14, 2019 at 6:12 PM Binbin.Zhou at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=89339 >
> > >
> > > John,
> > >
> > > I tried your method, it seems not working. The outfputs for 3
fields
> is
> > > "192" . The reason maybe my file is Navy ensemble files which
are not
> > > standard MCEP's GRIB2 format.
> > >
> > > I have put one sample file fnmoc01.t00z.grid4.f12.grib2.t2m
> > > in theia directory
> > >
> > >
> >
> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_navy/data_full
> > >
> > > This file only has 3 TMP/Z2 records.
> > >
> > > Binbin
> > >
> > >
> > >
> > >
> > > On Thu, Mar 14, 2019 at 3:56 PM John Halley Gotway via RT <
> > > met_help at ucar.edu>
> > > wrote:
> > >
> > > > Binbin,
> > > >
> > > > I moved your question over to met-help.
> > > >
> > > > Looks like these 3 records differ by the "12 hour fcst" vs "6-
12 hour
> > max
> > > > fcst" vs "6-12 hour min fcst". With a sample data file I
could
> > confirm,
> > > > but I'm guessing these records would differ in Section 4,
Octet 35:
> > > >
> > > >
> > >
> >
> https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table4-
7.shtml
> > > >
> > > > Try checking the values by running:
> > > > wgrib2 -get_byte 4 35 1 infile.grib2
> > > >
> > > > I'm guessing records 73, 74, and 75 would have values of 0, 9,
and 8.
> > If
> > > > that is actually the case, you'd distinguish these by setting:
> > > > GRIB2_der_type = 8; // or 0 or 9
> > > >
> > > > Make sense?
> > > >
> > > > Thanks,
> > > > John
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Multiple matching
From: Binbin.Zhou at noaa.gov
Time: Fri Mar 22 13:24:08 2019
John,
It seems /usr/local/met-8.0 is not on theia, so I can not test.
But I
am fine
to wait until this update is done on WCOSS.
Thanks!
Binbin
On Fri, Mar 22, 2019 at 1:14 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binbin,
>
> FYI, I just committed some changes to the development version of MET
to
> make it better handle this case. It's not a great solution, but it
works.
> Here's the warning message I see when I run the fnmoc data through
> plot_data_plane using met-8.0:
>
> /usr/local/met-8.0/bin/plot_data_plane
fnmoc01.t00z.grid4.f12.grib2.t2m
> plot.ps 'name="TMP"; level="Z2";'
> *WARNING: MetGrib2DataFile::data_plane() - Multiple matching records
found
> for 'TMP/Z2' - 1, 2, 3 - using 1*
>
> Using the development version for met-8.1, the warning message is
now this:
>
>
>
>
>
> *WARNING: MetGrib2DataFile::data_plane() -> Using the first of 3
matching
> records for "TMP/Z2":WARNING: record 1 field 1: ipdtmpl[18] = 0, 0,
4, 58,
> 50, 0, 0, 1, 12, 103, 0, 2, 255, 0, 0, 192, 1, 20WARNING: record 2
field 1:
> ipdtmpl[32] = 0, 0, 4, 58, 50, 0, 0, 11, 1, 103, 0, 2, 255, 0, 0,
192, 1,
> 20, 2019, 3, 13, 12, 0, 0, 1, 0, 2, 2, 11, 1, 255, 0WARNING: record
3 field
> 1: ipdtmpl[32] = 0, 0, 4, 58, 50, 0, 0, 11, 1, 103, 0, 2, 255, 0, 0,
192,
> 1, 20, 2019, 3, 13, 12, 0, 0, 1, 0, 3, 2, 11, 1, 255, 0WARNING: Try
setting
> the 0-based "GRIB2_ipdtmpl_index" and "GRIB2_ipdtmpl_val" config
file
> options to select one.*
>
> The warning message now includes the GRIB2 array of identifying
values for
> all matching records. Let's say I want the 2nd record. Looking
carefully,
> I see that the 9-th array element has a value of 1 and the 27-th
array
> element has a value of 2. So I set the new GRIB2_ipdtmpl_index (0-
based)
> and GRIB2_ipdtmpl_val config file options. And that finds a single
> matching record:
>
> *trunk/met/bin/plot_data_plane fnmoc01.t00z.grid4.f12.grib2.t2m
plot.ps
> <http://plot.ps> 'name="TMP"; level="Z2";
GRIB2_ipdtmpl_index=[8,26];
> GRIB2_ipdtmpl_val=[1,2];'*
>
> I realize that this isn't a very user-friendly solution but it
should give
> us a way to address many issues like this in the future.
>
> Make sense?
>
> Thanks,
> John
>
> On Fri, Mar 15, 2019 at 10:57 AM Binbin.Zhou at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=89339 >
> >
> > John,
> >
> > Thanks! Hope this issue can be resolved in the future. For
short
> term
> > solution I can retrieve TMP/L2 record from
> > FNMOC files and save it in another GRIB2 file (it only contains
one
> TMP/Z2
> > field).
> >
> > Binbin
> >
> > On Fri, Mar 15, 2019 at 12:23 PM John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Binbin,
> > >
> > > Thanks for pointing me to the fnmoc sample data. There's a lot
of
> > details
> > > to sift through in through in these GRIB2 files.
> > >
> > > One oddity (that coincidentally came up on another met-help
ticket this
> > > week), is the contents of Section 1, Octet 12 which is described
here:
> > >
> >
> https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table1-
2.shtml
> > >
> > >
> > >
> > >
> > > *wgrib2 -get_byte 1 12 1
> > >
> fnmoc01.t00z.grid4.f12.grib2.t2m1:0:1-12=02:205496:1-12=03:413098:1-
12=0*
> > >
> > > This fnmoc data has a 0 there indicating that main timestamp is
the
> > > analysis time, when clearly its the model initialization time.
> > > NCEP-produced GRIB2 files specify 1 there as far as I know.
> > >
> > > This setting leads to a runtime error in the current development
> version
> > of
> > > MET. When the reference time is the analysis time, then the
file
> > shouldn't
> > > contain any forecast hours > 0. But it does.
> > >
> > > So what do we do here? It probably isn't realistic for fnmoc to
change
> > > these GRIB2 files. I propose that we tell MET to interpret a
value of
> 0
> > > (Analysis) in the same way as a value of 1 (Start of Forecast).
> > >
> > > Does that sound sensible to you?
> > >
> > > Thanks,
> > > John
> > >
> > > On Thu, Mar 14, 2019 at 6:12 PM Binbin.Zhou at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=89339
>
> > > >
> > > > John,
> > > >
> > > > I tried your method, it seems not working. The outfputs for
3
> fields
> > is
> > > > "192" . The reason maybe my file is Navy ensemble files
which are
> not
> > > > standard MCEP's GRIB2 format.
> > > >
> > > > I have put one sample file fnmoc01.t00z.grid4.f12.grib2.t2m
> > > > in theia directory
> > > >
> > > >
> > >
> >
> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_navy/data_full
> > > >
> > > > This file only has 3 TMP/Z2 records.
> > > >
> > > > Binbin
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Mar 14, 2019 at 3:56 PM John Halley Gotway via RT <
> > > > met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > > Binbin,
> > > > >
> > > > > I moved your question over to met-help.
> > > > >
> > > > > Looks like these 3 records differ by the "12 hour fcst" vs
"6-12
> hour
> > > max
> > > > > fcst" vs "6-12 hour min fcst". With a sample data file I
could
> > > confirm,
> > > > > but I'm guessing these records would differ in Section 4,
Octet 35:
> > > > >
> > > > >
> > > >
> > >
> >
> https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table4-
7.shtml
> > > > >
> > > > > Try checking the values by running:
> > > > > wgrib2 -get_byte 4 35 1 infile.grib2
> > > > >
> > > > > I'm guessing records 73, 74, and 75 would have values of 0,
9, and
> 8.
> > > If
> > > > > that is actually the case, you'd distinguish these by
setting:
> > > > > GRIB2_der_type = 8; // or 0 or 9
> > > > >
> > > > > Make sense?
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Multiple matching
From: John Halley Gotway
Time: Fri Mar 22 14:24:45 2019
Binbin,
Sorry, I didn't mean to imply that the new functionality is available
yet.
Just letting you know that this fix will be included in future
releases of
MET.
Thanks,
John
On Fri, Mar 22, 2019 at 1:24 PM Binbin.Zhou at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=89339 >
>
> John,
>
> It seems /usr/local/met-8.0 is not on theia, so I can not test.
But I
> am fine
> to wait until this update is done on WCOSS.
>
> Thanks!
>
> Binbin
>
> On Fri, Mar 22, 2019 at 1:14 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Binbin,
> >
> > FYI, I just committed some changes to the development version of
MET to
> > make it better handle this case. It's not a great solution, but
it
> works.
> > Here's the warning message I see when I run the fnmoc data through
> > plot_data_plane using met-8.0:
> >
> > /usr/local/met-8.0/bin/plot_data_plane
fnmoc01.t00z.grid4.f12.grib2.t2m
> > plot.ps 'name="TMP"; level="Z2";'
> > *WARNING: MetGrib2DataFile::data_plane() - Multiple matching
records
> found
> > for 'TMP/Z2' - 1, 2, 3 - using 1*
> >
> > Using the development version for met-8.1, the warning message is
now
> this:
> >
> >
> >
> >
> >
> > *WARNING: MetGrib2DataFile::data_plane() -> Using the first of 3
matching
> > records for "TMP/Z2":WARNING: record 1 field 1: ipdtmpl[18] = 0,
0, 4,
> 58,
> > 50, 0, 0, 1, 12, 103, 0, 2, 255, 0, 0, 192, 1, 20WARNING: record 2
field
> 1:
> > ipdtmpl[32] = 0, 0, 4, 58, 50, 0, 0, 11, 1, 103, 0, 2, 255, 0, 0,
192, 1,
> > 20, 2019, 3, 13, 12, 0, 0, 1, 0, 2, 2, 11, 1, 255, 0WARNING:
record 3
> field
> > 1: ipdtmpl[32] = 0, 0, 4, 58, 50, 0, 0, 11, 1, 103, 0, 2, 255, 0,
0, 192,
> > 1, 20, 2019, 3, 13, 12, 0, 0, 1, 0, 3, 2, 11, 1, 255, 0WARNING:
Try
> setting
> > the 0-based "GRIB2_ipdtmpl_index" and "GRIB2_ipdtmpl_val" config
file
> > options to select one.*
> >
> > The warning message now includes the GRIB2 array of identifying
values
> for
> > all matching records. Let's say I want the 2nd record. Looking
> carefully,
> > I see that the 9-th array element has a value of 1 and the 27-th
array
> > element has a value of 2. So I set the new GRIB2_ipdtmpl_index
(0-based)
> > and GRIB2_ipdtmpl_val config file options. And that finds a
single
> > matching record:
> >
> > *trunk/met/bin/plot_data_plane fnmoc01.t00z.grid4.f12.grib2.t2m
plot.ps
> > <http://plot.ps> 'name="TMP"; level="Z2";
GRIB2_ipdtmpl_index=[8,26];
> > GRIB2_ipdtmpl_val=[1,2];'*
> >
> > I realize that this isn't a very user-friendly solution but it
should
> give
> > us a way to address many issues like this in the future.
> >
> > Make sense?
> >
> > Thanks,
> > John
> >
> > On Fri, Mar 15, 2019 at 10:57 AM Binbin.Zhou at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=89339 >
> > >
> > > John,
> > >
> > > Thanks! Hope this issue can be resolved in the future. For
short
> > term
> > > solution I can retrieve TMP/L2 record from
> > > FNMOC files and save it in another GRIB2 file (it only contains
one
> > TMP/Z2
> > > field).
> > >
> > > Binbin
> > >
> > > On Fri, Mar 15, 2019 at 12:23 PM John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > Binbin,
> > > >
> > > > Thanks for pointing me to the fnmoc sample data. There's a
lot of
> > > details
> > > > to sift through in through in these GRIB2 files.
> > > >
> > > > One oddity (that coincidentally came up on another met-help
ticket
> this
> > > > week), is the contents of Section 1, Octet 12 which is
described
> here:
> > > >
> > >
> >
> https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table1-
2.shtml
> > > >
> > > >
> > > >
> > > >
> > > > *wgrib2 -get_byte 1 12 1
> > > >
> > fnmoc01.t00z.grid4.f12.grib2.t2m1:0:1-12=02:205496:1-
12=03:413098:1-12=0*
> > > >
> > > > This fnmoc data has a 0 there indicating that main timestamp
is the
> > > > analysis time, when clearly its the model initialization time.
> > > > NCEP-produced GRIB2 files specify 1 there as far as I know.
> > > >
> > > > This setting leads to a runtime error in the current
development
> > version
> > > of
> > > > MET. When the reference time is the analysis time, then the
file
> > > shouldn't
> > > > contain any forecast hours > 0. But it does.
> > > >
> > > > So what do we do here? It probably isn't realistic for fnmoc
to
> change
> > > > these GRIB2 files. I propose that we tell MET to interpret a
value
> of
> > 0
> > > > (Analysis) in the same way as a value of 1 (Start of
Forecast).
> > > >
> > > > Does that sound sensible to you?
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > > On Thu, Mar 14, 2019 at 6:12 PM Binbin.Zhou at noaa.gov via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=89339 >
> > > > >
> > > > > John,
> > > > >
> > > > > I tried your method, it seems not working. The outfputs
for 3
> > fields
> > > is
> > > > > "192" . The reason maybe my file is Navy ensemble files
which are
> > not
> > > > > standard MCEP's GRIB2 format.
> > > > >
> > > > > I have put one sample file fnmoc01.t00z.grid4.f12.grib2.t2m
> > > > > in theia directory
> > > > >
> > > > >
> > > >
> > >
> >
> /scratch4/NCEPDEV/fv3-
cam/noscrub/Binbin.Zhou/met_test/g2o_ensemble_navy/data_full
> > > > >
> > > > > This file only has 3 TMP/Z2 records.
> > > > >
> > > > > Binbin
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Mar 14, 2019 at 3:56 PM John Halley Gotway via RT <
> > > > > met_help at ucar.edu>
> > > > > wrote:
> > > > >
> > > > > > Binbin,
> > > > > >
> > > > > > I moved your question over to met-help.
> > > > > >
> > > > > > Looks like these 3 records differ by the "12 hour fcst" vs
"6-12
> > hour
> > > > max
> > > > > > fcst" vs "6-12 hour min fcst". With a sample data file I
could
> > > > confirm,
> > > > > > but I'm guessing these records would differ in Section 4,
Octet
> 35:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table4-
7.shtml
> > > > > >
> > > > > > Try checking the values by running:
> > > > > > wgrib2 -get_byte 4 35 1 infile.grib2
> > > > > >
> > > > > > I'm guessing records 73, 74, and 75 would have values of
0, 9,
> and
> > 8.
> > > > If
> > > > > > that is actually the case, you'd distinguish these by
setting:
> > > > > > GRIB2_der_type = 8; // or 0 or 9
> > > > > >
> > > > > > Make sense?
> > > > > >
> > > > > > Thanks,
> > > > > > John
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
More information about the Met_help
mailing list