[Met_help] [rt.rap.ucar.edu #66551] History for Functionality of grid_stat with ncdf files
John Halley Gotway via RT
met_help at ucar.edu
Fri May 2 15:09:01 MDT 2014
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello,
I would like to validate a WRF-ARW output file against another WRF-ARW
output file, but my understanding is that this is still not generally
possible in MET v4.1. It seems that grid_stat works only for ncdf files
generated by pcp_combine, which modifies accumulated precip fields.
Indeed, when I try grid_stat with raw WRF output files I get a missing
attribute error.
Is there a way that I can dress up my current WRF output files - perhaps
by adding global attributes - to make them work or is the situation not
as simple as that?
Thanks.
John Henderson
Atmospheric and Environmental Research
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #66551] Functionality of grid_stat with ncdf files
From: John Halley Gotway
Time: Wed Apr 30 14:49:06 2014
John,
You could run them through the pinterp utility which is available
under the "WRF Utilities Downloads" section of the ARW downloads page:
http://www2.mmm.ucar.edu/wrf/users/download/get_sources.html#utilities
That interpolates the native model output to pressure levels, but
leaves the horizontal grid staggered. Then you can use grid_stat to
access non-staggered fields from the WRF file.
Alternatively, you could run them through the Unified PostProcessor
which interpolates to pressure levels and destaggers the grid. Its
output format is GRIB.
Thanks,
John Halley Gotway
met_help at ucar.edu
On 04/30/2014 02:13 PM, jhenders at aer.com via RT wrote:
>
> Wed Apr 30 14:13:06 2014: Request 66551 was acted upon.
> Transaction: Ticket created by jhenders at aer.com
> Queue: met_help
> Subject: Functionality of grid_stat with ncdf files
> Owner: Nobody
> Requestors: jhenders at aer.com
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>
>
> Hello,
>
> I would like to validate a WRF-ARW output file against another WRF-
ARW
> output file, but my understanding is that this is still not
generally
> possible in MET v4.1. It seems that grid_stat works only for ncdf
files
> generated by pcp_combine, which modifies accumulated precip fields.
> Indeed, when I try grid_stat with raw WRF output files I get a
missing
> attribute error.
>
> Is there a way that I can dress up my current WRF output files -
perhaps
> by adding global attributes - to make them work or is the situation
not
> as simple as that?
>
> Thanks.
>
> John Henderson
> Atmospheric and Environmental Research
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #66551] Functionality of grid_stat with ncdf files
From: jhenders at aer.com
Time: Wed Apr 30 15:35:50 2014
Thanks for the clarification. Is direct use of native WRF files under
development for MET or are there benefits from using the post-
processed
output (perhaps apart from the non-staggered grids in the GRIB files)?
Just wondering...
Thanks.
John
On 4/30/14 4:49 PM, John Halley Gotway via RT wrote:
> John,
>
> You could run them through the pinterp utility which is available
under the "WRF Utilities Downloads" section of the ARW downloads page:
>
http://www2.mmm.ucar.edu/wrf/users/download/get_sources.html#utilities
>
> That interpolates the native model output to pressure levels, but
leaves the horizontal grid staggered. Then you can use grid_stat to
access non-staggered fields from the WRF file.
>
> Alternatively, you could run them through the Unified PostProcessor
which interpolates to pressure levels and destaggers the grid. Its
output format is GRIB.
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu
>
> On 04/30/2014 02:13 PM, jhenders at aer.com via RT wrote:
>> Wed Apr 30 14:13:06 2014: Request 66551 was acted upon.
>> Transaction: Ticket created by jhenders at aer.com
>> Queue: met_help
>> Subject: Functionality of grid_stat with ncdf files
>> Owner: Nobody
>> Requestors: jhenders at aer.com
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>
>>
>> Hello,
>>
>> I would like to validate a WRF-ARW output file against another WRF-
ARW
>> output file, but my understanding is that this is still not
generally
>> possible in MET v4.1. It seems that grid_stat works only for ncdf
files
>> generated by pcp_combine, which modifies accumulated precip fields.
>> Indeed, when I try grid_stat with raw WRF output files I get a
missing
>> attribute error.
>>
>> Is there a way that I can dress up my current WRF output files -
perhaps
>> by adding global attributes - to make them work or is the
situation not
>> as simple as that?
>>
>> Thanks.
>>
>> John Henderson
>> Atmospheric and Environmental Research
>>
------------------------------------------------
Subject: Functionality of grid_stat with ncdf files
From: jhenders at aer.com
Time: Thu May 01 12:43:07 2014
Hello again John,
Following your clarification to use grib format, I have passed
WRF-generated maximum updraft helicity through UPP into grib files.
However, I cannot seem to get MET to recognize the presence of this
field:
rec 7:417940:date 2013053106 var236 kpds5=236 kpds6=106 kpds7=12820
levels=(50,20) grid=255 5000-2000 m above gnd valid 0-0hr:
var236=undefined
timerange 2 P1 0 P2 0 TimeU 14 nx 318 ny 210 GDS grid 3 num_in_ave
0
missing 0
center 7 subcenter 0 process 125 Table 129 scan: WE:SN winds(grid)
Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov -98.500000
Latin1 60.000000 Latin2 30.000000 LatSP 0.000000 LonSP 0.000000
North Pole (318 x 210) Dx 2.000000 Dy 2.000000 scan 64 mode 136
min/max data 0 250 num bits 8 BDS_Ref 0 DecScale 0 BinScale 0
I have tried various combinations of "236" and "var236" and "L12820"
and
"Z12820" but always get an apparent problem with this field not being
available in version 2 of NCEP's Table 2 (that lists current grib
codes):
DEBUG 1: Default Config File:
/home/tnehrkor/v35/NWP/MET/METv4.1/data/config/GridStatConfig_default
DEBUG 1: User Config File: GridStatConfig-RO-UH-grib
ERROR :
ERROR : VarInfoGrib::set_dict() - unrecognized GRIB1 field
abbreviation
'var236' for table version 2
ERROR :
I see a file called table_files/nceptab_flat.txt, but I'm not sure of
its relevance. The latest Table 2 version 2 does list var 236 but not
as
updraft helicity. That really shouldn't matter, should it? I would
suspect that MET simply uses whatever it finds in that grib code.
To try to get any field to work, I then tried a field that UPP handles
better:
rec 26:2172702:date 2013053106 PLI kpds5=24 kpds6=116 kpds7=7680
levels=(30,0) grid=255 30-0 mb above gnd 1110min fcst:
PLI=Parcel lifted index (to 500 hPa) [K]
timerange 10 P1 0 P2 37 TimeU 14 nx 318 ny 210 GDS grid 3
num_in_ave
0 missing 0
center 7 subcenter 0 process 125 Table 2 scan: WE:SN winds(grid)
Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov -98.500000
Latin1 60.000000 Latin2 30.000000 LatSP 0.000000 LonSP 0.000000
North Pole (318 x 210) Dx 2.000000 Dy 2.000000 scan 64 mode 136
min/max data -13.5884 3.71162 num bits 8 BDS_Ref -135.884
DecScale
1 BinScale 0
but then MET dies because it can't find it (and similarly for Z7680
and
P30-0) in the grib file:
WARNING:
WARNING: MetGrib1DataFile::data_plane() -> No exact match found for
VarInfo "PLI/L7680" in GRIB file "d2_2013053106_1830-MYNN.grib".
WARNING:
WARNING:
WARNING: process_scores() -> PLI/L7680 not found in file:
d2_2013053106_1830-MYNN.grib
WARNING:
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
Experience in the past few years suggests that use of the kpds5 and
kpds7 parameters is the correct way to go. Table 3 of NCEP's Office
Note
388 shows level type '116' as:
"layer between two levels at specified pressure difference from ground
to level", which somewhat sounds like Pxx-yy, but that doesn't work
either.
Any guidance would be much appreciated.
Thanks.
John
On 4/30/14 4:49 PM, John Halley Gotway via RT wrote:
> John,
>
> You could run them through the pinterp utility which is available
under the "WRF Utilities Downloads" section of the ARW downloads page:
>
http://www2.mmm.ucar.edu/wrf/users/download/get_sources.html#utilities
>
> That interpolates the native model output to pressure levels, but
leaves the horizontal grid staggered. Then you can use grid_stat to
access non-staggered fields from the WRF file.
>
> Alternatively, you could run them through the Unified PostProcessor
which interpolates to pressure levels and destaggers the grid. Its
output format is GRIB.
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu
>
> On 04/30/2014 02:13 PM, jhenders at aer.com via RT wrote:
>> Wed Apr 30 14:13:06 2014: Request 66551 was acted upon.
>> Transaction: Ticket created by jhenders at aer.com
>> Queue: met_help
>> Subject: Functionality of grid_stat with ncdf files
>> Owner: Nobody
>> Requestors: jhenders at aer.com
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>
>>
>> Hello,
>>
>> I would like to validate a WRF-ARW output file against another WRF-
ARW
>> output file, but my understanding is that this is still not
generally
>> possible in MET v4.1. It seems that grid_stat works only for ncdf
files
>> generated by pcp_combine, which modifies accumulated precip fields.
>> Indeed, when I try grid_stat with raw WRF output files I get a
missing
>> attribute error.
>>
>> Is there a way that I can dress up my current WRF output files -
perhaps
>> by adding global attributes - to make them work or is the
situation not
>> as simple as that?
>>
>> Thanks.
>>
>> John Henderson
>> Atmospheric and Environmental Research
>>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #66551] Functionality of grid_stat with ncdf files
From: John Halley Gotway
Time: Thu May 01 13:26:44 2014
John,
Could you please post one of these GRIB files to our anonymous ftp
site. I'll take a look and see if I can get it to extract the field
you're after. Here's the instructions:
http://www.dtcenter.org/met/users/support/met_help.php#ftp
Please write me back once you've posted the data to let me know it's
there.
Thanks,
John
On 05/01/2014 12:43 PM, jhenders at aer.com via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>
> Hello again John,
>
> Following your clarification to use grib format, I have passed
> WRF-generated maximum updraft helicity through UPP into grib files.
> However, I cannot seem to get MET to recognize the presence of this
field:
>
> rec 7:417940:date 2013053106 var236 kpds5=236 kpds6=106 kpds7=12820
> levels=(50,20) grid=255 5000-2000 m above gnd valid 0-0hr:
> var236=undefined
> timerange 2 P1 0 P2 0 TimeU 14 nx 318 ny 210 GDS grid 3
num_in_ave 0
> missing 0
> center 7 subcenter 0 process 125 Table 129 scan: WE:SN
winds(grid)
> Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov -98.500000
> Latin1 60.000000 Latin2 30.000000 LatSP 0.000000 LonSP
0.000000
> North Pole (318 x 210) Dx 2.000000 Dy 2.000000 scan 64 mode
136
> min/max data 0 250 num bits 8 BDS_Ref 0 DecScale 0 BinScale 0
>
> I have tried various combinations of "236" and "var236" and "L12820"
and
> "Z12820" but always get an apparent problem with this field not
being
> available in version 2 of NCEP's Table 2 (that lists current grib
codes):
>
> DEBUG 1: Default Config File:
>
/home/tnehrkor/v35/NWP/MET/METv4.1/data/config/GridStatConfig_default
> DEBUG 1: User Config File: GridStatConfig-RO-UH-grib
> ERROR :
> ERROR : VarInfoGrib::set_dict() - unrecognized GRIB1 field
abbreviation
> 'var236' for table version 2
> ERROR :
>
> I see a file called table_files/nceptab_flat.txt, but I'm not sure
of
> its relevance. The latest Table 2 version 2 does list var 236 but
not as
> updraft helicity. That really shouldn't matter, should it? I would
> suspect that MET simply uses whatever it finds in that grib code.
>
> To try to get any field to work, I then tried a field that UPP
handles
> better:
>
> rec 26:2172702:date 2013053106 PLI kpds5=24 kpds6=116 kpds7=7680
> levels=(30,0) grid=255 30-0 mb above gnd 1110min fcst:
> PLI=Parcel lifted index (to 500 hPa) [K]
> timerange 10 P1 0 P2 37 TimeU 14 nx 318 ny 210 GDS grid 3
num_in_ave
> 0 missing 0
> center 7 subcenter 0 process 125 Table 2 scan: WE:SN winds(grid)
> Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov -98.500000
> Latin1 60.000000 Latin2 30.000000 LatSP 0.000000 LonSP
0.000000
> North Pole (318 x 210) Dx 2.000000 Dy 2.000000 scan 64 mode
136
> min/max data -13.5884 3.71162 num bits 8 BDS_Ref -135.884
DecScale
> 1 BinScale 0
>
> but then MET dies because it can't find it (and similarly for Z7680
and
> P30-0) in the grib file:
>
> WARNING:
> WARNING: MetGrib1DataFile::data_plane() -> No exact match found for
> VarInfo "PLI/L7680" in GRIB file "d2_2013053106_1830-MYNN.grib".
> WARNING:
> WARNING:
> WARNING: process_scores() -> PLI/L7680 not found in file:
> d2_2013053106_1830-MYNN.grib
> WARNING:
> DEBUG 2:
> DEBUG 2:
>
--------------------------------------------------------------------------------
> DEBUG 2:
>
> Experience in the past few years suggests that use of the kpds5 and
> kpds7 parameters is the correct way to go. Table 3 of NCEP's Office
Note
> 388 shows level type '116' as:
>
> "layer between two levels at specified pressure difference from
ground
> to level", which somewhat sounds like Pxx-yy, but that doesn't work
either.
>
> Any guidance would be much appreciated.
>
> Thanks.
>
> John
>
>
> On 4/30/14 4:49 PM, John Halley Gotway via RT wrote:
>> John,
>>
>> You could run them through the pinterp utility which is available
under the "WRF Utilities Downloads" section of the ARW downloads page:
>>
http://www2.mmm.ucar.edu/wrf/users/download/get_sources.html#utilities
>>
>> That interpolates the native model output to pressure levels, but
leaves the horizontal grid staggered. Then you can use grid_stat to
access non-staggered fields from the WRF file.
>>
>> Alternatively, you could run them through the Unified PostProcessor
which interpolates to pressure levels and destaggers the grid. Its
output format is GRIB.
>>
>> Thanks,
>> John Halley Gotway
>> met_help at ucar.edu
>>
>> On 04/30/2014 02:13 PM, jhenders at aer.com via RT wrote:
>>> Wed Apr 30 14:13:06 2014: Request 66551 was acted upon.
>>> Transaction: Ticket created by jhenders at aer.com
>>> Queue: met_help
>>> Subject: Functionality of grid_stat with ncdf files
>>> Owner: Nobody
>>> Requestors: jhenders at aer.com
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>
>>>
>>> Hello,
>>>
>>> I would like to validate a WRF-ARW output file against another
WRF-ARW
>>> output file, but my understanding is that this is still not
generally
>>> possible in MET v4.1. It seems that grid_stat works only for ncdf
files
>>> generated by pcp_combine, which modifies accumulated precip
fields.
>>> Indeed, when I try grid_stat with raw WRF output files I get a
missing
>>> attribute error.
>>>
>>> Is there a way that I can dress up my current WRF output files -
perhaps
>>> by adding global attributes - to make them work or is the
situation not
>>> as simple as that?
>>>
>>> Thanks.
>>>
>>> John Henderson
>>> Atmospheric and Environmental Research
>>>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #66551] Functionality of grid_stat with ncdf files
From: jhenders at aer.com
Time: Thu May 01 13:50:46 2014
Hello John,
I've put both WRF grib files (one is to be used as a forecast, the
other
as validation) in the expected henderson_data directory.
I've also uploaded my UPP v2.1 parm file. There are two updraft
helicity
fields, but the one written out by UPP as grid code 236 (maximum
updraft
helicity) is preferred.
Thanks.
John
On 5/1/14 3:26 PM, John Halley Gotway via RT wrote:
> John,
>
> Could you please post one of these GRIB files to our anonymous ftp
site. I'll take a look and see if I can get it to extract the field
you're after. Here's the instructions:
> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>
> Please write me back once you've posted the data to let me know it's
there.
>
> Thanks,
> John
>
> On 05/01/2014 12:43 PM, jhenders at aer.com via RT wrote:
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>
>> Hello again John,
>>
>> Following your clarification to use grib format, I have passed
>> WRF-generated maximum updraft helicity through UPP into grib files.
>> However, I cannot seem to get MET to recognize the presence of this
field:
>>
>> rec 7:417940:date 2013053106 var236 kpds5=236 kpds6=106 kpds7=12820
>> levels=(50,20) grid=255 5000-2000 m above gnd valid 0-0hr:
>> var236=undefined
>> timerange 2 P1 0 P2 0 TimeU 14 nx 318 ny 210 GDS grid 3
num_in_ave 0
>> missing 0
>> center 7 subcenter 0 process 125 Table 129 scan: WE:SN
winds(grid)
>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov -98.500000
>> Latin1 60.000000 Latin2 30.000000 LatSP 0.000000 LonSP
0.000000
>> North Pole (318 x 210) Dx 2.000000 Dy 2.000000 scan 64
mode 136
>> min/max data 0 250 num bits 8 BDS_Ref 0 DecScale 0 BinScale
0
>>
>> I have tried various combinations of "236" and "var236" and
"L12820" and
>> "Z12820" but always get an apparent problem with this field not
being
>> available in version 2 of NCEP's Table 2 (that lists current grib
codes):
>>
>> DEBUG 1: Default Config File:
>>
/home/tnehrkor/v35/NWP/MET/METv4.1/data/config/GridStatConfig_default
>> DEBUG 1: User Config File: GridStatConfig-RO-UH-grib
>> ERROR :
>> ERROR : VarInfoGrib::set_dict() - unrecognized GRIB1 field
abbreviation
>> 'var236' for table version 2
>> ERROR :
>>
>> I see a file called table_files/nceptab_flat.txt, but I'm not sure
of
>> its relevance. The latest Table 2 version 2 does list var 236 but
not as
>> updraft helicity. That really shouldn't matter, should it? I would
>> suspect that MET simply uses whatever it finds in that grib code.
>>
>> To try to get any field to work, I then tried a field that UPP
handles
>> better:
>>
>> rec 26:2172702:date 2013053106 PLI kpds5=24 kpds6=116 kpds7=7680
>> levels=(30,0) grid=255 30-0 mb above gnd 1110min fcst:
>> PLI=Parcel lifted index (to 500 hPa) [K]
>> timerange 10 P1 0 P2 37 TimeU 14 nx 318 ny 210 GDS grid 3
num_in_ave
>> 0 missing 0
>> center 7 subcenter 0 process 125 Table 2 scan: WE:SN
winds(grid)
>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov -98.500000
>> Latin1 60.000000 Latin2 30.000000 LatSP 0.000000 LonSP
0.000000
>> North Pole (318 x 210) Dx 2.000000 Dy 2.000000 scan 64
mode 136
>> min/max data -13.5884 3.71162 num bits 8 BDS_Ref -135.884
DecScale
>> 1 BinScale 0
>>
>> but then MET dies because it can't find it (and similarly for Z7680
and
>> P30-0) in the grib file:
>>
>> WARNING:
>> WARNING: MetGrib1DataFile::data_plane() -> No exact match found for
>> VarInfo "PLI/L7680" in GRIB file "d2_2013053106_1830-MYNN.grib".
>> WARNING:
>> WARNING:
>> WARNING: process_scores() -> PLI/L7680 not found in file:
>> d2_2013053106_1830-MYNN.grib
>> WARNING:
>> DEBUG 2:
>> DEBUG 2:
>>
--------------------------------------------------------------------------------
>> DEBUG 2:
>>
>> Experience in the past few years suggests that use of the kpds5 and
>> kpds7 parameters is the correct way to go. Table 3 of NCEP's Office
Note
>> 388 shows level type '116' as:
>>
>> "layer between two levels at specified pressure difference from
ground
>> to level", which somewhat sounds like Pxx-yy, but that doesn't work
either.
>>
>> Any guidance would be much appreciated.
>>
>> Thanks.
>>
>> John
>>
>>
>> On 4/30/14 4:49 PM, John Halley Gotway via RT wrote:
>>> John,
>>>
>>> You could run them through the pinterp utility which is available
under the "WRF Utilities Downloads" section of the ARW downloads page:
>>>
http://www2.mmm.ucar.edu/wrf/users/download/get_sources.html#utilities
>>>
>>> That interpolates the native model output to pressure levels, but
leaves the horizontal grid staggered. Then you can use grid_stat to
access non-staggered fields from the WRF file.
>>>
>>> Alternatively, you could run them through the Unified
PostProcessor which interpolates to pressure levels and destaggers the
grid. Its output format is GRIB.
>>>
>>> Thanks,
>>> John Halley Gotway
>>> met_help at ucar.edu
>>>
>>> On 04/30/2014 02:13 PM, jhenders at aer.com via RT wrote:
>>>> Wed Apr 30 14:13:06 2014: Request 66551 was acted upon.
>>>> Transaction: Ticket created by jhenders at aer.com
>>>> Queue: met_help
>>>> Subject: Functionality of grid_stat with ncdf files
>>>> Owner: Nobody
>>>> Requestors: jhenders at aer.com
>>>> Status: new
>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>
>>>>
>>>> Hello,
>>>>
>>>> I would like to validate a WRF-ARW output file against another
WRF-ARW
>>>> output file, but my understanding is that this is still not
generally
>>>> possible in MET v4.1. It seems that grid_stat works only for ncdf
files
>>>> generated by pcp_combine, which modifies accumulated precip
fields.
>>>> Indeed, when I try grid_stat with raw WRF output files I get a
missing
>>>> attribute error.
>>>>
>>>> Is there a way that I can dress up my current WRF output files -
perhaps
>>>> by adding global attributes - to make them work or is the
situation not
>>>> as simple as that?
>>>>
>>>> Thanks.
>>>>
>>>> John Henderson
>>>> Atmospheric and Environmental Research
>>>>
------------------------------------------------
Subject: Functionality of grid_stat with ncdf files
From: John Halley Gotway
Time: Thu May 01 14:21:25 2014
John,
That GRIB record doesn't have a meaningful entry in the table file you
mentioned:
METv4.1/data/table_files/nceptab_flat.txt
Record number 7 in the GRIB files you sent contains a data with
parameter table version number 129 and GRIB code 236. Looking in that
table file I see the following entry on line 750:
236 129 "var236" "undefined" ""
If you have a meaningful interpretation of this data, you could update
that table file. Even if you don't, here's a way you can tell MET to
use that record:
METv4.1/bin/plot_data_plane d2_2013053106_1830-ACM2.grib
d2_2013053106_1830-ACM2.ps 'name="var236"; level="Z50-20";
GRIB1_ptv=129;' -v 3
DEBUG 1: Opening data file: d2_2013053106_1830-ACM2.grib
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found range match
for VarInfo "var236/Z20-50" in GRIB record 7 of GRIB file
"d2_2013053106_1830-ACM2.grib".
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found 1 GRIB
records matching VarInfo "var236/Z20-50" in GRIB file
"d2_2013053106_1830-ACM2.grib".
DEBUG 1: Creating postscript file: d2_2013053106_1830-ACM2.ps
I used "GRIB1_ptv=129" to tell it to look at the table entries for
parameter table version number 129. "var236" is the current
abbreviation for that record. And the level value is "Z50-20". This
can be seen in the wgrib output: levels=(50,20). The 'Z' tells MET to
look for a vertical level, as opposed to a pressure level. And 50 to
20 defines the lower and upper bounds for that vertical level.
That should do the trick. I've attached a png version of the
resulting image.
Please give that a shot and let me know if it works for you. Feel
free to update your version of nceptab_flat.txt to list a more
meaningful abbreviation, long name, and units for this data type.
Thanks,
John
On 05/01/2014 01:50 PM, jhenders at aer.com via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>
> Hello John,
>
> I've put both WRF grib files (one is to be used as a forecast, the
other
> as validation) in the expected henderson_data directory.
>
> I've also uploaded my UPP v2.1 parm file. There are two updraft
helicity
> fields, but the one written out by UPP as grid code 236 (maximum
updraft
> helicity) is preferred.
>
> Thanks.
>
> John
>
> On 5/1/14 3:26 PM, John Halley Gotway via RT wrote:
>> John,
>>
>> Could you please post one of these GRIB files to our anonymous ftp
site. I'll take a look and see if I can get it to extract the field
you're after. Here's the instructions:
>> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>
>> Please write me back once you've posted the data to let me know
it's there.
>>
>> Thanks,
>> John
>>
>> On 05/01/2014 12:43 PM, jhenders at aer.com via RT wrote:
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>
>>> Hello again John,
>>>
>>> Following your clarification to use grib format, I have passed
>>> WRF-generated maximum updraft helicity through UPP into grib
files.
>>> However, I cannot seem to get MET to recognize the presence of
this field:
>>>
>>> rec 7:417940:date 2013053106 var236 kpds5=236 kpds6=106
kpds7=12820
>>> levels=(50,20) grid=255 5000-2000 m above gnd valid 0-0hr:
>>> var236=undefined
>>> timerange 2 P1 0 P2 0 TimeU 14 nx 318 ny 210 GDS grid 3
num_in_ave 0
>>> missing 0
>>> center 7 subcenter 0 process 125 Table 129 scan: WE:SN
winds(grid)
>>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov -98.500000
>>> Latin1 60.000000 Latin2 30.000000 LatSP 0.000000 LonSP
0.000000
>>> North Pole (318 x 210) Dx 2.000000 Dy 2.000000 scan 64
mode 136
>>> min/max data 0 250 num bits 8 BDS_Ref 0 DecScale 0
BinScale 0
>>>
>>> I have tried various combinations of "236" and "var236" and
"L12820" and
>>> "Z12820" but always get an apparent problem with this field not
being
>>> available in version 2 of NCEP's Table 2 (that lists current grib
codes):
>>>
>>> DEBUG 1: Default Config File:
>>>
/home/tnehrkor/v35/NWP/MET/METv4.1/data/config/GridStatConfig_default
>>> DEBUG 1: User Config File: GridStatConfig-RO-UH-grib
>>> ERROR :
>>> ERROR : VarInfoGrib::set_dict() - unrecognized GRIB1 field
abbreviation
>>> 'var236' for table version 2
>>> ERROR :
>>>
>>> I see a file called table_files/nceptab_flat.txt, but I'm not sure
of
>>> its relevance. The latest Table 2 version 2 does list var 236 but
not as
>>> updraft helicity. That really shouldn't matter, should it? I would
>>> suspect that MET simply uses whatever it finds in that grib code.
>>>
>>> To try to get any field to work, I then tried a field that UPP
handles
>>> better:
>>>
>>> rec 26:2172702:date 2013053106 PLI kpds5=24 kpds6=116 kpds7=7680
>>> levels=(30,0) grid=255 30-0 mb above gnd 1110min fcst:
>>> PLI=Parcel lifted index (to 500 hPa) [K]
>>> timerange 10 P1 0 P2 37 TimeU 14 nx 318 ny 210 GDS grid 3
num_in_ave
>>> 0 missing 0
>>> center 7 subcenter 0 process 125 Table 2 scan: WE:SN
winds(grid)
>>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov -98.500000
>>> Latin1 60.000000 Latin2 30.000000 LatSP 0.000000 LonSP
0.000000
>>> North Pole (318 x 210) Dx 2.000000 Dy 2.000000 scan 64
mode 136
>>> min/max data -13.5884 3.71162 num bits 8 BDS_Ref -135.884
DecScale
>>> 1 BinScale 0
>>>
>>> but then MET dies because it can't find it (and similarly for
Z7680 and
>>> P30-0) in the grib file:
>>>
>>> WARNING:
>>> WARNING: MetGrib1DataFile::data_plane() -> No exact match found
for
>>> VarInfo "PLI/L7680" in GRIB file "d2_2013053106_1830-MYNN.grib".
>>> WARNING:
>>> WARNING:
>>> WARNING: process_scores() -> PLI/L7680 not found in file:
>>> d2_2013053106_1830-MYNN.grib
>>> WARNING:
>>> DEBUG 2:
>>> DEBUG 2:
>>>
--------------------------------------------------------------------------------
>>> DEBUG 2:
>>>
>>> Experience in the past few years suggests that use of the kpds5
and
>>> kpds7 parameters is the correct way to go. Table 3 of NCEP's
Office Note
>>> 388 shows level type '116' as:
>>>
>>> "layer between two levels at specified pressure difference from
ground
>>> to level", which somewhat sounds like Pxx-yy, but that doesn't
work either.
>>>
>>> Any guidance would be much appreciated.
>>>
>>> Thanks.
>>>
>>> John
>>>
>>>
>>> On 4/30/14 4:49 PM, John Halley Gotway via RT wrote:
>>>> John,
>>>>
>>>> You could run them through the pinterp utility which is available
under the "WRF Utilities Downloads" section of the ARW downloads page:
>>>>
http://www2.mmm.ucar.edu/wrf/users/download/get_sources.html#utilities
>>>>
>>>> That interpolates the native model output to pressure levels, but
leaves the horizontal grid staggered. Then you can use grid_stat to
access non-staggered fields from the WRF file.
>>>>
>>>> Alternatively, you could run them through the Unified
PostProcessor which interpolates to pressure levels and destaggers the
grid. Its output format is GRIB.
>>>>
>>>> Thanks,
>>>> John Halley Gotway
>>>> met_help at ucar.edu
>>>>
>>>> On 04/30/2014 02:13 PM, jhenders at aer.com via RT wrote:
>>>>> Wed Apr 30 14:13:06 2014: Request 66551 was acted upon.
>>>>> Transaction: Ticket created by jhenders at aer.com
>>>>> Queue: met_help
>>>>> Subject: Functionality of grid_stat with ncdf files
>>>>> Owner: Nobody
>>>>> Requestors: jhenders at aer.com
>>>>> Status: new
>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> I would like to validate a WRF-ARW output file against another
WRF-ARW
>>>>> output file, but my understanding is that this is still not
generally
>>>>> possible in MET v4.1. It seems that grid_stat works only for
ncdf files
>>>>> generated by pcp_combine, which modifies accumulated precip
fields.
>>>>> Indeed, when I try grid_stat with raw WRF output files I get a
missing
>>>>> attribute error.
>>>>>
>>>>> Is there a way that I can dress up my current WRF output files -
perhaps
>>>>> by adding global attributes - to make them work or is the
situation not
>>>>> as simple as that?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> John Henderson
>>>>> Atmospheric and Environmental Research
>>>>>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #66551] Functionality of grid_stat with ncdf files
From: jhenders at aer.com
Time: Thu May 01 15:55:32 2014
John,
Thanks as always for your prompt and very useful response. I was able
to
tweak my config file with your suggestions and MET completed. After
implementing your changes, I still had the default values in place for
the interp section and they were causing a seg fault. When I set
method=[], MET completes properly.
John
On 5/1/14 4:21 PM, John Halley Gotway via RT wrote:
> John,
>
> That GRIB record doesn't have a meaningful entry in the table file
you mentioned:
> METv4.1/data/table_files/nceptab_flat.txt
>
> Record number 7 in the GRIB files you sent contains a data with
parameter table version number 129 and GRIB code 236. Looking in that
table file I see the following entry on line 750:
> 236 129 "var236" "undefined" ""
>
> If you have a meaningful interpretation of this data, you could
update that table file. Even if you don't, here's a way you can tell
MET to use that record:
>
> METv4.1/bin/plot_data_plane d2_2013053106_1830-ACM2.grib
d2_2013053106_1830-ACM2.ps 'name="var236"; level="Z50-20";
GRIB1_ptv=129;' -v 3
> DEBUG 1: Opening data file: d2_2013053106_1830-ACM2.grib
> DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found range
match for VarInfo "var236/Z20-50" in GRIB record 7 of GRIB file
"d2_2013053106_1830-ACM2.grib".
> DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found 1 GRIB
records matching VarInfo "var236/Z20-50" in GRIB file
"d2_2013053106_1830-ACM2.grib".
> DEBUG 1: Creating postscript file: d2_2013053106_1830-ACM2.ps
>
> I used "GRIB1_ptv=129" to tell it to look at the table entries for
parameter table version number 129. "var236" is the current
abbreviation for that record. And the level value is "Z50-20". This
> can be seen in the wgrib output: levels=(50,20). The 'Z' tells MET
to look for a vertical level, as opposed to a pressure level. And 50
to 20 defines the lower and upper bounds for that vertical level.
>
> That should do the trick. I've attached a png version of the
resulting image.
>
> Please give that a shot and let me know if it works for you. Feel
free to update your version of nceptab_flat.txt to list a more
meaningful abbreviation, long name, and units for this data type.
>
> Thanks,
> John
>
> On 05/01/2014 01:50 PM, jhenders at aer.com via RT wrote:
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>
>> Hello John,
>>
>> I've put both WRF grib files (one is to be used as a forecast, the
other
>> as validation) in the expected henderson_data directory.
>>
>> I've also uploaded my UPP v2.1 parm file. There are two updraft
helicity
>> fields, but the one written out by UPP as grid code 236 (maximum
updraft
>> helicity) is preferred.
>>
>> Thanks.
>>
>> John
>>
>> On 5/1/14 3:26 PM, John Halley Gotway via RT wrote:
>>> John,
>>>
>>> Could you please post one of these GRIB files to our anonymous ftp
site. I'll take a look and see if I can get it to extract the field
you're after. Here's the instructions:
>>> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>
>>> Please write me back once you've posted the data to let me know
it's there.
>>>
>>> Thanks,
>>> John
>>>
>>> On 05/01/2014 12:43 PM, jhenders at aer.com via RT wrote:
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>
>>>> Hello again John,
>>>>
>>>> Following your clarification to use grib format, I have passed
>>>> WRF-generated maximum updraft helicity through UPP into grib
files.
>>>> However, I cannot seem to get MET to recognize the presence of
this field:
>>>>
>>>> rec 7:417940:date 2013053106 var236 kpds5=236 kpds6=106
kpds7=12820
>>>> levels=(50,20) grid=255 5000-2000 m above gnd valid 0-0hr:
>>>> var236=undefined
>>>> timerange 2 P1 0 P2 0 TimeU 14 nx 318 ny 210 GDS grid 3
num_in_ave 0
>>>> missing 0
>>>> center 7 subcenter 0 process 125 Table 129 scan: WE:SN
winds(grid)
>>>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov
-98.500000
>>>> Latin1 60.000000 Latin2 30.000000 LatSP 0.000000 LonSP
0.000000
>>>> North Pole (318 x 210) Dx 2.000000 Dy 2.000000 scan 64
mode 136
>>>> min/max data 0 250 num bits 8 BDS_Ref 0 DecScale 0
BinScale 0
>>>>
>>>> I have tried various combinations of "236" and "var236" and
"L12820" and
>>>> "Z12820" but always get an apparent problem with this field not
being
>>>> available in version 2 of NCEP's Table 2 (that lists current grib
codes):
>>>>
>>>> DEBUG 1: Default Config File:
>>>>
/home/tnehrkor/v35/NWP/MET/METv4.1/data/config/GridStatConfig_default
>>>> DEBUG 1: User Config File: GridStatConfig-RO-UH-grib
>>>> ERROR :
>>>> ERROR : VarInfoGrib::set_dict() - unrecognized GRIB1 field
abbreviation
>>>> 'var236' for table version 2
>>>> ERROR :
>>>>
>>>> I see a file called table_files/nceptab_flat.txt, but I'm not
sure of
>>>> its relevance. The latest Table 2 version 2 does list var 236 but
not as
>>>> updraft helicity. That really shouldn't matter, should it? I
would
>>>> suspect that MET simply uses whatever it finds in that grib code.
>>>>
>>>> To try to get any field to work, I then tried a field that UPP
handles
>>>> better:
>>>>
>>>> rec 26:2172702:date 2013053106 PLI kpds5=24 kpds6=116 kpds7=7680
>>>> levels=(30,0) grid=255 30-0 mb above gnd 1110min fcst:
>>>> PLI=Parcel lifted index (to 500 hPa) [K]
>>>> timerange 10 P1 0 P2 37 TimeU 14 nx 318 ny 210 GDS grid 3
num_in_ave
>>>> 0 missing 0
>>>> center 7 subcenter 0 process 125 Table 2 scan: WE:SN
winds(grid)
>>>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov
-98.500000
>>>> Latin1 60.000000 Latin2 30.000000 LatSP 0.000000 LonSP
0.000000
>>>> North Pole (318 x 210) Dx 2.000000 Dy 2.000000 scan 64
mode 136
>>>> min/max data -13.5884 3.71162 num bits 8 BDS_Ref
-135.884 DecScale
>>>> 1 BinScale 0
>>>>
>>>> but then MET dies because it can't find it (and similarly for
Z7680 and
>>>> P30-0) in the grib file:
>>>>
>>>> WARNING:
>>>> WARNING: MetGrib1DataFile::data_plane() -> No exact match found
for
>>>> VarInfo "PLI/L7680" in GRIB file "d2_2013053106_1830-MYNN.grib".
>>>> WARNING:
>>>> WARNING:
>>>> WARNING: process_scores() -> PLI/L7680 not found in file:
>>>> d2_2013053106_1830-MYNN.grib
>>>> WARNING:
>>>> DEBUG 2:
>>>> DEBUG 2:
>>>>
--------------------------------------------------------------------------------
>>>> DEBUG 2:
>>>>
>>>> Experience in the past few years suggests that use of the kpds5
and
>>>> kpds7 parameters is the correct way to go. Table 3 of NCEP's
Office Note
>>>> 388 shows level type '116' as:
>>>>
>>>> "layer between two levels at specified pressure difference from
ground
>>>> to level", which somewhat sounds like Pxx-yy, but that doesn't
work either.
>>>>
>>>> Any guidance would be much appreciated.
>>>>
>>>> Thanks.
>>>>
>>>> John
>>>>
>>>>
>>>> On 4/30/14 4:49 PM, John Halley Gotway via RT wrote:
>>>>> John,
>>>>>
>>>>> You could run them through the pinterp utility which is
available under the "WRF Utilities Downloads" section of the ARW
downloads page:
>>>>>
http://www2.mmm.ucar.edu/wrf/users/download/get_sources.html#utilities
>>>>>
>>>>> That interpolates the native model output to pressure levels,
but leaves the horizontal grid staggered. Then you can use grid_stat
to access non-staggered fields from the WRF file.
>>>>>
>>>>> Alternatively, you could run them through the Unified
PostProcessor which interpolates to pressure levels and destaggers the
grid. Its output format is GRIB.
>>>>>
>>>>> Thanks,
>>>>> John Halley Gotway
>>>>> met_help at ucar.edu
>>>>>
>>>>> On 04/30/2014 02:13 PM, jhenders at aer.com via RT wrote:
>>>>>> Wed Apr 30 14:13:06 2014: Request 66551 was acted upon.
>>>>>> Transaction: Ticket created by jhenders at aer.com
>>>>>> Queue: met_help
>>>>>> Subject: Functionality of grid_stat with ncdf files
>>>>>> Owner: Nobody
>>>>>> Requestors: jhenders at aer.com
>>>>>> Status: new
>>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>>>
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I would like to validate a WRF-ARW output file against another
WRF-ARW
>>>>>> output file, but my understanding is that this is still not
generally
>>>>>> possible in MET v4.1. It seems that grid_stat works only for
ncdf files
>>>>>> generated by pcp_combine, which modifies accumulated precip
fields.
>>>>>> Indeed, when I try grid_stat with raw WRF output files I get a
missing
>>>>>> attribute error.
>>>>>>
>>>>>> Is there a way that I can dress up my current WRF output files
- perhaps
>>>>>> by adding global attributes - to make them work or is the
situation not
>>>>>> as simple as that?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> John Henderson
>>>>>> Atmospheric and Environmental Research
>>>>>>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #66551] Functionality of grid_stat with ncdf files
From: John Halley Gotway
Time: Thu May 01 16:28:31 2014
John,
Seg faults are never good! Could you please send me the config file
and exactly what you typed on the command line to get a seg fault?
I'd like to reproduce the behavior, if possible, catch the problem,
and have it exit more gracefully with a helpful error message.
Thanks,
John
On 05/01/2014 03:55 PM, jhenders at aer.com via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>
> John,
>
> Thanks as always for your prompt and very useful response. I was
able to
> tweak my config file with your suggestions and MET completed. After
> implementing your changes, I still had the default values in place
for
> the interp section and they were causing a seg fault. When I set
> method=[], MET completes properly.
>
> John
>
> On 5/1/14 4:21 PM, John Halley Gotway via RT wrote:
>> John,
>>
>> That GRIB record doesn't have a meaningful entry in the table file
you mentioned:
>> METv4.1/data/table_files/nceptab_flat.txt
>>
>> Record number 7 in the GRIB files you sent contains a data with
parameter table version number 129 and GRIB code 236. Looking in that
table file I see the following entry on line 750:
>> 236 129 "var236" "undefined" ""
>>
>> If you have a meaningful interpretation of this data, you could
update that table file. Even if you don't, here's a way you can tell
MET to use that record:
>>
>> METv4.1/bin/plot_data_plane d2_2013053106_1830-ACM2.grib
d2_2013053106_1830-ACM2.ps 'name="var236"; level="Z50-20";
GRIB1_ptv=129;' -v 3
>> DEBUG 1: Opening data file: d2_2013053106_1830-ACM2.grib
>> DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found range
match for VarInfo "var236/Z20-50" in GRIB record 7 of GRIB file
"d2_2013053106_1830-ACM2.grib".
>> DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found 1 GRIB
records matching VarInfo "var236/Z20-50" in GRIB file
"d2_2013053106_1830-ACM2.grib".
>> DEBUG 1: Creating postscript file: d2_2013053106_1830-ACM2.ps
>>
>> I used "GRIB1_ptv=129" to tell it to look at the table entries for
parameter table version number 129. "var236" is the current
abbreviation for that record. And the level value is "Z50-20". This
>> can be seen in the wgrib output: levels=(50,20). The 'Z' tells MET
to look for a vertical level, as opposed to a pressure level. And 50
to 20 defines the lower and upper bounds for that vertical level.
>>
>> That should do the trick. I've attached a png version of the
resulting image.
>>
>> Please give that a shot and let me know if it works for you. Feel
free to update your version of nceptab_flat.txt to list a more
meaningful abbreviation, long name, and units for this data type.
>>
>> Thanks,
>> John
>>
>> On 05/01/2014 01:50 PM, jhenders at aer.com via RT wrote:
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>
>>> Hello John,
>>>
>>> I've put both WRF grib files (one is to be used as a forecast, the
other
>>> as validation) in the expected henderson_data directory.
>>>
>>> I've also uploaded my UPP v2.1 parm file. There are two updraft
helicity
>>> fields, but the one written out by UPP as grid code 236 (maximum
updraft
>>> helicity) is preferred.
>>>
>>> Thanks.
>>>
>>> John
>>>
>>> On 5/1/14 3:26 PM, John Halley Gotway via RT wrote:
>>>> John,
>>>>
>>>> Could you please post one of these GRIB files to our anonymous
ftp site. I'll take a look and see if I can get it to extract the
field you're after. Here's the instructions:
>>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>
>>>> Please write me back once you've posted the data to let me know
it's there.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>> On 05/01/2014 12:43 PM, jhenders at aer.com via RT wrote:
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>>
>>>>> Hello again John,
>>>>>
>>>>> Following your clarification to use grib format, I have passed
>>>>> WRF-generated maximum updraft helicity through UPP into grib
files.
>>>>> However, I cannot seem to get MET to recognize the presence of
this field:
>>>>>
>>>>> rec 7:417940:date 2013053106 var236 kpds5=236 kpds6=106
kpds7=12820
>>>>> levels=(50,20) grid=255 5000-2000 m above gnd valid 0-0hr:
>>>>> var236=undefined
>>>>> timerange 2 P1 0 P2 0 TimeU 14 nx 318 ny 210 GDS grid 3
num_in_ave 0
>>>>> missing 0
>>>>> center 7 subcenter 0 process 125 Table 129 scan: WE:SN
winds(grid)
>>>>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov
-98.500000
>>>>> Latin1 60.000000 Latin2 30.000000 LatSP 0.000000
LonSP 0.000000
>>>>> North Pole (318 x 210) Dx 2.000000 Dy 2.000000 scan
64 mode 136
>>>>> min/max data 0 250 num bits 8 BDS_Ref 0 DecScale 0
BinScale 0
>>>>>
>>>>> I have tried various combinations of "236" and "var236" and
"L12820" and
>>>>> "Z12820" but always get an apparent problem with this field not
being
>>>>> available in version 2 of NCEP's Table 2 (that lists current
grib codes):
>>>>>
>>>>> DEBUG 1: Default Config File:
>>>>>
/home/tnehrkor/v35/NWP/MET/METv4.1/data/config/GridStatConfig_default
>>>>> DEBUG 1: User Config File: GridStatConfig-RO-UH-grib
>>>>> ERROR :
>>>>> ERROR : VarInfoGrib::set_dict() - unrecognized GRIB1 field
abbreviation
>>>>> 'var236' for table version 2
>>>>> ERROR :
>>>>>
>>>>> I see a file called table_files/nceptab_flat.txt, but I'm not
sure of
>>>>> its relevance. The latest Table 2 version 2 does list var 236
but not as
>>>>> updraft helicity. That really shouldn't matter, should it? I
would
>>>>> suspect that MET simply uses whatever it finds in that grib
code.
>>>>>
>>>>> To try to get any field to work, I then tried a field that UPP
handles
>>>>> better:
>>>>>
>>>>> rec 26:2172702:date 2013053106 PLI kpds5=24 kpds6=116 kpds7=7680
>>>>> levels=(30,0) grid=255 30-0 mb above gnd 1110min fcst:
>>>>> PLI=Parcel lifted index (to 500 hPa) [K]
>>>>> timerange 10 P1 0 P2 37 TimeU 14 nx 318 ny 210 GDS grid
3 num_in_ave
>>>>> 0 missing 0
>>>>> center 7 subcenter 0 process 125 Table 2 scan: WE:SN
winds(grid)
>>>>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov
-98.500000
>>>>> Latin1 60.000000 Latin2 30.000000 LatSP 0.000000
LonSP 0.000000
>>>>> North Pole (318 x 210) Dx 2.000000 Dy 2.000000 scan
64 mode 136
>>>>> min/max data -13.5884 3.71162 num bits 8 BDS_Ref
-135.884 DecScale
>>>>> 1 BinScale 0
>>>>>
>>>>> but then MET dies because it can't find it (and similarly for
Z7680 and
>>>>> P30-0) in the grib file:
>>>>>
>>>>> WARNING:
>>>>> WARNING: MetGrib1DataFile::data_plane() -> No exact match found
for
>>>>> VarInfo "PLI/L7680" in GRIB file "d2_2013053106_1830-MYNN.grib".
>>>>> WARNING:
>>>>> WARNING:
>>>>> WARNING: process_scores() -> PLI/L7680 not found in file:
>>>>> d2_2013053106_1830-MYNN.grib
>>>>> WARNING:
>>>>> DEBUG 2:
>>>>> DEBUG 2:
>>>>>
--------------------------------------------------------------------------------
>>>>> DEBUG 2:
>>>>>
>>>>> Experience in the past few years suggests that use of the kpds5
and
>>>>> kpds7 parameters is the correct way to go. Table 3 of NCEP's
Office Note
>>>>> 388 shows level type '116' as:
>>>>>
>>>>> "layer between two levels at specified pressure difference from
ground
>>>>> to level", which somewhat sounds like Pxx-yy, but that doesn't
work either.
>>>>>
>>>>> Any guidance would be much appreciated.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>> On 4/30/14 4:49 PM, John Halley Gotway via RT wrote:
>>>>>> John,
>>>>>>
>>>>>> You could run them through the pinterp utility which is
available under the "WRF Utilities Downloads" section of the ARW
downloads page:
>>>>>>
http://www2.mmm.ucar.edu/wrf/users/download/get_sources.html#utilities
>>>>>>
>>>>>> That interpolates the native model output to pressure levels,
but leaves the horizontal grid staggered. Then you can use grid_stat
to access non-staggered fields from the WRF file.
>>>>>>
>>>>>> Alternatively, you could run them through the Unified
PostProcessor which interpolates to pressure levels and destaggers the
grid. Its output format is GRIB.
>>>>>>
>>>>>> Thanks,
>>>>>> John Halley Gotway
>>>>>> met_help at ucar.edu
>>>>>>
>>>>>> On 04/30/2014 02:13 PM, jhenders at aer.com via RT wrote:
>>>>>>> Wed Apr 30 14:13:06 2014: Request 66551 was acted upon.
>>>>>>> Transaction: Ticket created by jhenders at aer.com
>>>>>>> Queue: met_help
>>>>>>> Subject: Functionality of grid_stat with ncdf
files
>>>>>>> Owner: Nobody
>>>>>>> Requestors: jhenders at aer.com
>>>>>>> Status: new
>>>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>>>>
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I would like to validate a WRF-ARW output file against another
WRF-ARW
>>>>>>> output file, but my understanding is that this is still not
generally
>>>>>>> possible in MET v4.1. It seems that grid_stat works only for
ncdf files
>>>>>>> generated by pcp_combine, which modifies accumulated precip
fields.
>>>>>>> Indeed, when I try grid_stat with raw WRF output files I get a
missing
>>>>>>> attribute error.
>>>>>>>
>>>>>>> Is there a way that I can dress up my current WRF output files
- perhaps
>>>>>>> by adding global attributes - to make them work or is the
situation not
>>>>>>> as simple as that?
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> John Henderson
>>>>>>> Atmospheric and Environmental Research
>>>>>>>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #66551] Functionality of grid_stat with ncdf files
From: jhenders at aer.com
Time: Fri May 02 10:34:02 2014
Hi John,
I've uploaded the grid_stat config file that works - i.e., it doesn't
have an entry for interp method. Going from memory of my set up
yesterday, simply putting back the default interp method caused a seg
fault. The command line simply was the MET v4.1 grid_stat executable
with the two forecast files and the config file.
Please let me know if you can't reproduce it.
Thanks.
John
On 5/1/14 6:28 PM, John Halley Gotway via RT wrote:
> John,
>
> Seg faults are never good! Could you please send me the config file
and exactly what you typed on the command line to get a seg fault?
>
> I'd like to reproduce the behavior, if possible, catch the problem,
and have it exit more gracefully with a helpful error message.
>
> Thanks,
> John
>
> On 05/01/2014 03:55 PM, jhenders at aer.com via RT wrote:
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>
>> John,
>>
>> Thanks as always for your prompt and very useful response. I was
able to
>> tweak my config file with your suggestions and MET completed. After
>> implementing your changes, I still had the default values in place
for
>> the interp section and they were causing a seg fault. When I set
>> method=[], MET completes properly.
>>
>> John
>>
>> On 5/1/14 4:21 PM, John Halley Gotway via RT wrote:
>>> John,
>>>
>>> That GRIB record doesn't have a meaningful entry in the table file
you mentioned:
>>> METv4.1/data/table_files/nceptab_flat.txt
>>>
>>> Record number 7 in the GRIB files you sent contains a data with
parameter table version number 129 and GRIB code 236. Looking in that
table file I see the following entry on line 750:
>>> 236 129 "var236" "undefined" ""
>>>
>>> If you have a meaningful interpretation of this data, you could
update that table file. Even if you don't, here's a way you can tell
MET to use that record:
>>>
>>> METv4.1/bin/plot_data_plane d2_2013053106_1830-ACM2.grib
d2_2013053106_1830-ACM2.ps 'name="var236"; level="Z50-20";
GRIB1_ptv=129;' -v 3
>>> DEBUG 1: Opening data file: d2_2013053106_1830-ACM2.grib
>>> DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found
range match for VarInfo "var236/Z20-50" in GRIB record 7 of GRIB file
"d2_2013053106_1830-ACM2.grib".
>>> DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found 1
GRIB records matching VarInfo "var236/Z20-50" in GRIB file
"d2_2013053106_1830-ACM2.grib".
>>> DEBUG 1: Creating postscript file: d2_2013053106_1830-
ACM2.ps
>>>
>>> I used "GRIB1_ptv=129" to tell it to look at the table entries for
parameter table version number 129. "var236" is the current
abbreviation for that record. And the level value is "Z50-20". This
>>> can be seen in the wgrib output: levels=(50,20). The 'Z' tells
MET to look for a vertical level, as opposed to a pressure level. And
50 to 20 defines the lower and upper bounds for that vertical level.
>>>
>>> That should do the trick. I've attached a png version of the
resulting image.
>>>
>>> Please give that a shot and let me know if it works for you. Feel
free to update your version of nceptab_flat.txt to list a more
meaningful abbreviation, long name, and units for this data type.
>>>
>>> Thanks,
>>> John
>>>
>>> On 05/01/2014 01:50 PM, jhenders at aer.com via RT wrote:
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>
>>>> Hello John,
>>>>
>>>> I've put both WRF grib files (one is to be used as a forecast,
the other
>>>> as validation) in the expected henderson_data directory.
>>>>
>>>> I've also uploaded my UPP v2.1 parm file. There are two updraft
helicity
>>>> fields, but the one written out by UPP as grid code 236 (maximum
updraft
>>>> helicity) is preferred.
>>>>
>>>> Thanks.
>>>>
>>>> John
>>>>
>>>> On 5/1/14 3:26 PM, John Halley Gotway via RT wrote:
>>>>> John,
>>>>>
>>>>> Could you please post one of these GRIB files to our anonymous
ftp site. I'll take a look and see if I can get it to extract the
field you're after. Here's the instructions:
>>>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>>
>>>>> Please write me back once you've posted the data to let me know
it's there.
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>> On 05/01/2014 12:43 PM, jhenders at aer.com via RT wrote:
>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>>>
>>>>>> Hello again John,
>>>>>>
>>>>>> Following your clarification to use grib format, I have passed
>>>>>> WRF-generated maximum updraft helicity through UPP into grib
files.
>>>>>> However, I cannot seem to get MET to recognize the presence of
this field:
>>>>>>
>>>>>> rec 7:417940:date 2013053106 var236 kpds5=236 kpds6=106
kpds7=12820
>>>>>> levels=(50,20) grid=255 5000-2000 m above gnd valid 0-0hr:
>>>>>> var236=undefined
>>>>>> timerange 2 P1 0 P2 0 TimeU 14 nx 318 ny 210 GDS grid
3 num_in_ave 0
>>>>>> missing 0
>>>>>> center 7 subcenter 0 process 125 Table 129 scan: WE:SN
winds(grid)
>>>>>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov
-98.500000
>>>>>> Latin1 60.000000 Latin2 30.000000 LatSP 0.000000
LonSP 0.000000
>>>>>> North Pole (318 x 210) Dx 2.000000 Dy 2.000000
scan 64 mode 136
>>>>>> min/max data 0 250 num bits 8 BDS_Ref 0 DecScale 0
BinScale 0
>>>>>>
>>>>>> I have tried various combinations of "236" and "var236" and
"L12820" and
>>>>>> "Z12820" but always get an apparent problem with this field not
being
>>>>>> available in version 2 of NCEP's Table 2 (that lists current
grib codes):
>>>>>>
>>>>>> DEBUG 1: Default Config File:
>>>>>>
/home/tnehrkor/v35/NWP/MET/METv4.1/data/config/GridStatConfig_default
>>>>>> DEBUG 1: User Config File: GridStatConfig-RO-UH-grib
>>>>>> ERROR :
>>>>>> ERROR : VarInfoGrib::set_dict() - unrecognized GRIB1 field
abbreviation
>>>>>> 'var236' for table version 2
>>>>>> ERROR :
>>>>>>
>>>>>> I see a file called table_files/nceptab_flat.txt, but I'm not
sure of
>>>>>> its relevance. The latest Table 2 version 2 does list var 236
but not as
>>>>>> updraft helicity. That really shouldn't matter, should it? I
would
>>>>>> suspect that MET simply uses whatever it finds in that grib
code.
>>>>>>
>>>>>> To try to get any field to work, I then tried a field that UPP
handles
>>>>>> better:
>>>>>>
>>>>>> rec 26:2172702:date 2013053106 PLI kpds5=24 kpds6=116
kpds7=7680
>>>>>> levels=(30,0) grid=255 30-0 mb above gnd 1110min fcst:
>>>>>> PLI=Parcel lifted index (to 500 hPa) [K]
>>>>>> timerange 10 P1 0 P2 37 TimeU 14 nx 318 ny 210 GDS
grid 3 num_in_ave
>>>>>> 0 missing 0
>>>>>> center 7 subcenter 0 process 125 Table 2 scan: WE:SN
winds(grid)
>>>>>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov
-98.500000
>>>>>> Latin1 60.000000 Latin2 30.000000 LatSP 0.000000
LonSP 0.000000
>>>>>> North Pole (318 x 210) Dx 2.000000 Dy 2.000000
scan 64 mode 136
>>>>>> min/max data -13.5884 3.71162 num bits 8 BDS_Ref
-135.884 DecScale
>>>>>> 1 BinScale 0
>>>>>>
>>>>>> but then MET dies because it can't find it (and similarly for
Z7680 and
>>>>>> P30-0) in the grib file:
>>>>>>
>>>>>> WARNING:
>>>>>> WARNING: MetGrib1DataFile::data_plane() -> No exact match found
for
>>>>>> VarInfo "PLI/L7680" in GRIB file "d2_2013053106_1830-
MYNN.grib".
>>>>>> WARNING:
>>>>>> WARNING:
>>>>>> WARNING: process_scores() -> PLI/L7680 not found in file:
>>>>>> d2_2013053106_1830-MYNN.grib
>>>>>> WARNING:
>>>>>> DEBUG 2:
>>>>>> DEBUG 2:
>>>>>>
--------------------------------------------------------------------------------
>>>>>> DEBUG 2:
>>>>>>
>>>>>> Experience in the past few years suggests that use of the kpds5
and
>>>>>> kpds7 parameters is the correct way to go. Table 3 of NCEP's
Office Note
>>>>>> 388 shows level type '116' as:
>>>>>>
>>>>>> "layer between two levels at specified pressure difference from
ground
>>>>>> to level", which somewhat sounds like Pxx-yy, but that doesn't
work either.
>>>>>>
>>>>>> Any guidance would be much appreciated.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>> On 4/30/14 4:49 PM, John Halley Gotway via RT wrote:
>>>>>>> John,
>>>>>>>
>>>>>>> You could run them through the pinterp utility which is
available under the "WRF Utilities Downloads" section of the ARW
downloads page:
>>>>>>>
http://www2.mmm.ucar.edu/wrf/users/download/get_sources.html#utilities
>>>>>>>
>>>>>>> That interpolates the native model output to pressure levels,
but leaves the horizontal grid staggered. Then you can use grid_stat
to access non-staggered fields from the WRF file.
>>>>>>>
>>>>>>> Alternatively, you could run them through the Unified
PostProcessor which interpolates to pressure levels and destaggers the
grid. Its output format is GRIB.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> John Halley Gotway
>>>>>>> met_help at ucar.edu
>>>>>>>
>>>>>>> On 04/30/2014 02:13 PM, jhenders at aer.com via RT wrote:
>>>>>>>> Wed Apr 30 14:13:06 2014: Request 66551 was acted upon.
>>>>>>>> Transaction: Ticket created by jhenders at aer.com
>>>>>>>> Queue: met_help
>>>>>>>> Subject: Functionality of grid_stat with ncdf
files
>>>>>>>> Owner: Nobody
>>>>>>>> Requestors: jhenders at aer.com
>>>>>>>> Status: new
>>>>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>>>>>
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I would like to validate a WRF-ARW output file against
another WRF-ARW
>>>>>>>> output file, but my understanding is that this is still not
generally
>>>>>>>> possible in MET v4.1. It seems that grid_stat works only for
ncdf files
>>>>>>>> generated by pcp_combine, which modifies accumulated precip
fields.
>>>>>>>> Indeed, when I try grid_stat with raw WRF output files I get
a missing
>>>>>>>> attribute error.
>>>>>>>>
>>>>>>>> Is there a way that I can dress up my current WRF output
files - perhaps
>>>>>>>> by adding global attributes - to make them work or is the
situation not
>>>>>>>> as simple as that?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> John Henderson
>>>>>>>> Atmospheric and Environmental Research
>>>>>>>>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #66551] Functionality of grid_stat with ncdf files
From: John Halley Gotway
Time: Fri May 02 11:36:06 2014
John,
Thanks for sending that data. The segfault you're seeing happens
because that entry in METv4.1/data/table_files/nceptab_flat.txt for
variable 236 has an empty string for the units. When Grid-Stat is
writing the output NetCDF matched pairs file, it segfaults when
writing the units as a variable attribute because we call "strlen"
(string length) on a null pointer. Even though you were able to make
the segfault go away, Grid-Stat is not working as it should. By
setting "method = []", you're defining zero interpolation methods
which skips over the logic for writing out the NetCDF matched pairs
file. Since that code isn't exercised, you don't get the segfault.
For now, I'd suggest just disabling the NetCDF matched pairs file by
setting:
nc_pairs_flag = FALSE;
Then, set the interpolation method to this:
type = [
{
method = UW_MEAN;
width = 1;
}
];
I'll work on making it handle the empty strings in that table file
more graceful.
Also, I'm adding a check to the next version of MET to make sure the
user defines at least one interpolation method. Otherwise, you'll get
this error:
ERROR :
ERROR : parse_conf_interp() -> Must define at least one interpolation
method in the config file.
ERROR :
In your case, you only have neighborhood methods turned on, which
operate on the raw data fields and are not affected by the
interpolation method settings. But it seems like a reasonable
requirement
that the user specify at least one, even if it's not actually used.
Thanks,
John
On 05/02/2014 10:34 AM, jhenders at aer.com via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>
> Hi John,
>
> I've uploaded the grid_stat config file that works - i.e., it
doesn't
> have an entry for interp method. Going from memory of my set up
> yesterday, simply putting back the default interp method caused a
seg
> fault. The command line simply was the MET v4.1 grid_stat executable
> with the two forecast files and the config file.
>
> Please let me know if you can't reproduce it.
>
> Thanks.
>
> John
>
>
>
> On 5/1/14 6:28 PM, John Halley Gotway via RT wrote:
>> John,
>>
>> Seg faults are never good! Could you please send me the config
file and exactly what you typed on the command line to get a seg
fault?
>>
>> I'd like to reproduce the behavior, if possible, catch the problem,
and have it exit more gracefully with a helpful error message.
>>
>> Thanks,
>> John
>>
>> On 05/01/2014 03:55 PM, jhenders at aer.com via RT wrote:
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>
>>> John,
>>>
>>> Thanks as always for your prompt and very useful response. I was
able to
>>> tweak my config file with your suggestions and MET completed.
After
>>> implementing your changes, I still had the default values in place
for
>>> the interp section and they were causing a seg fault. When I set
>>> method=[], MET completes properly.
>>>
>>> John
>>>
>>> On 5/1/14 4:21 PM, John Halley Gotway via RT wrote:
>>>> John,
>>>>
>>>> That GRIB record doesn't have a meaningful entry in the table
file you mentioned:
>>>> METv4.1/data/table_files/nceptab_flat.txt
>>>>
>>>> Record number 7 in the GRIB files you sent contains a data with
parameter table version number 129 and GRIB code 236. Looking in that
table file I see the following entry on line 750:
>>>> 236 129 "var236" "undefined" ""
>>>>
>>>> If you have a meaningful interpretation of this data, you could
update that table file. Even if you don't, here's a way you can tell
MET to use that record:
>>>>
>>>> METv4.1/bin/plot_data_plane d2_2013053106_1830-ACM2.grib
d2_2013053106_1830-ACM2.ps 'name="var236"; level="Z50-20";
GRIB1_ptv=129;' -v 3
>>>> DEBUG 1: Opening data file: d2_2013053106_1830-ACM2.grib
>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found
range match for VarInfo "var236/Z20-50" in GRIB record 7 of GRIB file
"d2_2013053106_1830-ACM2.grib".
>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found 1
GRIB records matching VarInfo "var236/Z20-50" in GRIB file
"d2_2013053106_1830-ACM2.grib".
>>>> DEBUG 1: Creating postscript file: d2_2013053106_1830-
ACM2.ps
>>>>
>>>> I used "GRIB1_ptv=129" to tell it to look at the table entries
for parameter table version number 129. "var236" is the current
abbreviation for that record. And the level value is "Z50-20". This
>>>> can be seen in the wgrib output: levels=(50,20). The 'Z' tells
MET to look for a vertical level, as opposed to a pressure level. And
50 to 20 defines the lower and upper bounds for that vertical level.
>>>>
>>>> That should do the trick. I've attached a png version of the
resulting image.
>>>>
>>>> Please give that a shot and let me know if it works for you.
Feel free to update your version of nceptab_flat.txt to list a more
meaningful abbreviation, long name, and units for this data type.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>> On 05/01/2014 01:50 PM, jhenders at aer.com via RT wrote:
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>>
>>>>> Hello John,
>>>>>
>>>>> I've put both WRF grib files (one is to be used as a forecast,
the other
>>>>> as validation) in the expected henderson_data directory.
>>>>>
>>>>> I've also uploaded my UPP v2.1 parm file. There are two updraft
helicity
>>>>> fields, but the one written out by UPP as grid code 236 (maximum
updraft
>>>>> helicity) is preferred.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> John
>>>>>
>>>>> On 5/1/14 3:26 PM, John Halley Gotway via RT wrote:
>>>>>> John,
>>>>>>
>>>>>> Could you please post one of these GRIB files to our anonymous
ftp site. I'll take a look and see if I can get it to extract the
field you're after. Here's the instructions:
>>>>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>>>
>>>>>> Please write me back once you've posted the data to let me know
it's there.
>>>>>>
>>>>>> Thanks,
>>>>>> John
>>>>>>
>>>>>> On 05/01/2014 12:43 PM, jhenders at aer.com via RT wrote:
>>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551
>
>>>>>>>
>>>>>>> Hello again John,
>>>>>>>
>>>>>>> Following your clarification to use grib format, I have passed
>>>>>>> WRF-generated maximum updraft helicity through UPP into grib
files.
>>>>>>> However, I cannot seem to get MET to recognize the presence of
this field:
>>>>>>>
>>>>>>> rec 7:417940:date 2013053106 var236 kpds5=236 kpds6=106
kpds7=12820
>>>>>>> levels=(50,20) grid=255 5000-2000 m above gnd valid 0-0hr:
>>>>>>> var236=undefined
>>>>>>> timerange 2 P1 0 P2 0 TimeU 14 nx 318 ny 210 GDS
grid 3 num_in_ave 0
>>>>>>> missing 0
>>>>>>> center 7 subcenter 0 process 125 Table 129 scan:
WE:SN winds(grid)
>>>>>>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov
-98.500000
>>>>>>> Latin1 60.000000 Latin2 30.000000 LatSP 0.000000
LonSP 0.000000
>>>>>>> North Pole (318 x 210) Dx 2.000000 Dy 2.000000
scan 64 mode 136
>>>>>>> min/max data 0 250 num bits 8 BDS_Ref 0 DecScale
0 BinScale 0
>>>>>>>
>>>>>>> I have tried various combinations of "236" and "var236" and
"L12820" and
>>>>>>> "Z12820" but always get an apparent problem with this field
not being
>>>>>>> available in version 2 of NCEP's Table 2 (that lists current
grib codes):
>>>>>>>
>>>>>>> DEBUG 1: Default Config File:
>>>>>>>
/home/tnehrkor/v35/NWP/MET/METv4.1/data/config/GridStatConfig_default
>>>>>>> DEBUG 1: User Config File: GridStatConfig-RO-UH-grib
>>>>>>> ERROR :
>>>>>>> ERROR : VarInfoGrib::set_dict() - unrecognized GRIB1 field
abbreviation
>>>>>>> 'var236' for table version 2
>>>>>>> ERROR :
>>>>>>>
>>>>>>> I see a file called table_files/nceptab_flat.txt, but I'm not
sure of
>>>>>>> its relevance. The latest Table 2 version 2 does list var 236
but not as
>>>>>>> updraft helicity. That really shouldn't matter, should it? I
would
>>>>>>> suspect that MET simply uses whatever it finds in that grib
code.
>>>>>>>
>>>>>>> To try to get any field to work, I then tried a field that UPP
handles
>>>>>>> better:
>>>>>>>
>>>>>>> rec 26:2172702:date 2013053106 PLI kpds5=24 kpds6=116
kpds7=7680
>>>>>>> levels=(30,0) grid=255 30-0 mb above gnd 1110min fcst:
>>>>>>> PLI=Parcel lifted index (to 500 hPa) [K]
>>>>>>> timerange 10 P1 0 P2 37 TimeU 14 nx 318 ny 210 GDS
grid 3 num_in_ave
>>>>>>> 0 missing 0
>>>>>>> center 7 subcenter 0 process 125 Table 2 scan: WE:SN
winds(grid)
>>>>>>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov
-98.500000
>>>>>>> Latin1 60.000000 Latin2 30.000000 LatSP 0.000000
LonSP 0.000000
>>>>>>> North Pole (318 x 210) Dx 2.000000 Dy 2.000000
scan 64 mode 136
>>>>>>> min/max data -13.5884 3.71162 num bits 8 BDS_Ref
-135.884 DecScale
>>>>>>> 1 BinScale 0
>>>>>>>
>>>>>>> but then MET dies because it can't find it (and similarly for
Z7680 and
>>>>>>> P30-0) in the grib file:
>>>>>>>
>>>>>>> WARNING:
>>>>>>> WARNING: MetGrib1DataFile::data_plane() -> No exact match
found for
>>>>>>> VarInfo "PLI/L7680" in GRIB file "d2_2013053106_1830-
MYNN.grib".
>>>>>>> WARNING:
>>>>>>> WARNING:
>>>>>>> WARNING: process_scores() -> PLI/L7680 not found in file:
>>>>>>> d2_2013053106_1830-MYNN.grib
>>>>>>> WARNING:
>>>>>>> DEBUG 2:
>>>>>>> DEBUG 2:
>>>>>>>
--------------------------------------------------------------------------------
>>>>>>> DEBUG 2:
>>>>>>>
>>>>>>> Experience in the past few years suggests that use of the
kpds5 and
>>>>>>> kpds7 parameters is the correct way to go. Table 3 of NCEP's
Office Note
>>>>>>> 388 shows level type '116' as:
>>>>>>>
>>>>>>> "layer between two levels at specified pressure difference
from ground
>>>>>>> to level", which somewhat sounds like Pxx-yy, but that doesn't
work either.
>>>>>>>
>>>>>>> Any guidance would be much appreciated.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>> On 4/30/14 4:49 PM, John Halley Gotway via RT wrote:
>>>>>>>> John,
>>>>>>>>
>>>>>>>> You could run them through the pinterp utility which is
available under the "WRF Utilities Downloads" section of the ARW
downloads page:
>>>>>>>>
http://www2.mmm.ucar.edu/wrf/users/download/get_sources.html#utilities
>>>>>>>>
>>>>>>>> That interpolates the native model output to pressure levels,
but leaves the horizontal grid staggered. Then you can use grid_stat
to access non-staggered fields from the WRF file.
>>>>>>>>
>>>>>>>> Alternatively, you could run them through the Unified
PostProcessor which interpolates to pressure levels and destaggers the
grid. Its output format is GRIB.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> John Halley Gotway
>>>>>>>> met_help at ucar.edu
>>>>>>>>
>>>>>>>> On 04/30/2014 02:13 PM, jhenders at aer.com via RT wrote:
>>>>>>>>> Wed Apr 30 14:13:06 2014: Request 66551 was acted upon.
>>>>>>>>> Transaction: Ticket created by jhenders at aer.com
>>>>>>>>> Queue: met_help
>>>>>>>>> Subject: Functionality of grid_stat with ncdf
files
>>>>>>>>> Owner: Nobody
>>>>>>>>> Requestors: jhenders at aer.com
>>>>>>>>> Status: new
>>>>>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I would like to validate a WRF-ARW output file against
another WRF-ARW
>>>>>>>>> output file, but my understanding is that this is still not
generally
>>>>>>>>> possible in MET v4.1. It seems that grid_stat works only for
ncdf files
>>>>>>>>> generated by pcp_combine, which modifies accumulated precip
fields.
>>>>>>>>> Indeed, when I try grid_stat with raw WRF output files I get
a missing
>>>>>>>>> attribute error.
>>>>>>>>>
>>>>>>>>> Is there a way that I can dress up my current WRF output
files - perhaps
>>>>>>>>> by adding global attributes - to make them work or is the
situation not
>>>>>>>>> as simple as that?
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> John Henderson
>>>>>>>>> Atmospheric and Environmental Research
>>>>>>>>>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #66551] Functionality of grid_stat with ncdf files
From: jhenders at aer.com
Time: Fri May 02 12:45:14 2014
Hi John,
Could I circumvent the problem simply by correctly specifying units in
the var236 table? They are known (m2/s2), of course. I would like the
matched pairs. Come to think of it, a quick glance in that current
file
indicates just lat/lon pairs and no values!
John
On 5/2/14 1:36 PM, John Halley Gotway via RT wrote:
> John,
>
> Thanks for sending that data. The segfault you're seeing happens
because that entry in METv4.1/data/table_files/nceptab_flat.txt for
variable 236 has an empty string for the units. When Grid-Stat is
> writing the output NetCDF matched pairs file, it segfaults when
writing the units as a variable attribute because we call "strlen"
(string length) on a null pointer. Even though you were able to make
> the segfault go away, Grid-Stat is not working as it should. By
setting "method = []", you're defining zero interpolation methods
which skips over the logic for writing out the NetCDF matched pairs
> file. Since that code isn't exercised, you don't get the segfault.
>
> For now, I'd suggest just disabling the NetCDF matched pairs file by
setting:
> nc_pairs_flag = FALSE;
>
> Then, set the interpolation method to this:
> type = [
> {
> method = UW_MEAN;
> width = 1;
> }
> ];
>
>
> I'll work on making it handle the empty strings in that table file
more graceful.
>
> Also, I'm adding a check to the next version of MET to make sure the
user defines at least one interpolation method. Otherwise, you'll get
this error:
> ERROR :
> ERROR : parse_conf_interp() -> Must define at least one
interpolation method in the config file.
> ERROR :
>
> In your case, you only have neighborhood methods turned on, which
operate on the raw data fields and are not affected by the
interpolation method settings. But it seems like a reasonable
requirement
> that the user specify at least one, even if it's not actually used.
>
> Thanks,
> John
>
>
> On 05/02/2014 10:34 AM, jhenders at aer.com via RT wrote:
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>
>> Hi John,
>>
>> I've uploaded the grid_stat config file that works - i.e., it
doesn't
>> have an entry for interp method. Going from memory of my set up
>> yesterday, simply putting back the default interp method caused a
seg
>> fault. The command line simply was the MET v4.1 grid_stat
executable
>> with the two forecast files and the config file.
>>
>> Please let me know if you can't reproduce it.
>>
>> Thanks.
>>
>> John
>>
>>
>>
>> On 5/1/14 6:28 PM, John Halley Gotway via RT wrote:
>>> John,
>>>
>>> Seg faults are never good! Could you please send me the config
file and exactly what you typed on the command line to get a seg
fault?
>>>
>>> I'd like to reproduce the behavior, if possible, catch the
problem, and have it exit more gracefully with a helpful error
message.
>>>
>>> Thanks,
>>> John
>>>
>>> On 05/01/2014 03:55 PM, jhenders at aer.com via RT wrote:
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>
>>>> John,
>>>>
>>>> Thanks as always for your prompt and very useful response. I was
able to
>>>> tweak my config file with your suggestions and MET completed.
After
>>>> implementing your changes, I still had the default values in
place for
>>>> the interp section and they were causing a seg fault. When I set
>>>> method=[], MET completes properly.
>>>>
>>>> John
>>>>
>>>> On 5/1/14 4:21 PM, John Halley Gotway via RT wrote:
>>>>> John,
>>>>>
>>>>> That GRIB record doesn't have a meaningful entry in the table
file you mentioned:
>>>>> METv4.1/data/table_files/nceptab_flat.txt
>>>>>
>>>>> Record number 7 in the GRIB files you sent contains a data with
parameter table version number 129 and GRIB code 236. Looking in that
table file I see the following entry on line 750:
>>>>> 236 129 "var236" "undefined" ""
>>>>>
>>>>> If you have a meaningful interpretation of this data, you could
update that table file. Even if you don't, here's a way you can tell
MET to use that record:
>>>>>
>>>>> METv4.1/bin/plot_data_plane d2_2013053106_1830-
ACM2.grib d2_2013053106_1830-ACM2.ps 'name="var236"; level="Z50-20";
GRIB1_ptv=129;' -v 3
>>>>> DEBUG 1: Opening data file: d2_2013053106_1830-
ACM2.grib
>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found
range match for VarInfo "var236/Z20-50" in GRIB record 7 of GRIB file
"d2_2013053106_1830-ACM2.grib".
>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found
1 GRIB records matching VarInfo "var236/Z20-50" in GRIB file
"d2_2013053106_1830-ACM2.grib".
>>>>> DEBUG 1: Creating postscript file: d2_2013053106_1830-
ACM2.ps
>>>>>
>>>>> I used "GRIB1_ptv=129" to tell it to look at the table entries
for parameter table version number 129. "var236" is the current
abbreviation for that record. And the level value is "Z50-20". This
>>>>> can be seen in the wgrib output: levels=(50,20). The 'Z' tells
MET to look for a vertical level, as opposed to a pressure level. And
50 to 20 defines the lower and upper bounds for that vertical level.
>>>>>
>>>>> That should do the trick. I've attached a png version of the
resulting image.
>>>>>
>>>>> Please give that a shot and let me know if it works for you.
Feel free to update your version of nceptab_flat.txt to list a more
meaningful abbreviation, long name, and units for this data type.
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>> On 05/01/2014 01:50 PM, jhenders at aer.com via RT wrote:
>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>>>
>>>>>> Hello John,
>>>>>>
>>>>>> I've put both WRF grib files (one is to be used as a forecast,
the other
>>>>>> as validation) in the expected henderson_data directory.
>>>>>>
>>>>>> I've also uploaded my UPP v2.1 parm file. There are two updraft
helicity
>>>>>> fields, but the one written out by UPP as grid code 236
(maximum updraft
>>>>>> helicity) is preferred.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> John
>>>>>>
>>>>>> On 5/1/14 3:26 PM, John Halley Gotway via RT wrote:
>>>>>>> John,
>>>>>>>
>>>>>>> Could you please post one of these GRIB files to our anonymous
ftp site. I'll take a look and see if I can get it to extract the
field you're after. Here's the instructions:
>>>>>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>>>>
>>>>>>> Please write me back once you've posted the data to let me
know it's there.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> John
>>>>>>>
>>>>>>> On 05/01/2014 12:43 PM, jhenders at aer.com via RT wrote:
>>>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551
>
>>>>>>>>
>>>>>>>> Hello again John,
>>>>>>>>
>>>>>>>> Following your clarification to use grib format, I have
passed
>>>>>>>> WRF-generated maximum updraft helicity through UPP into grib
files.
>>>>>>>> However, I cannot seem to get MET to recognize the presence
of this field:
>>>>>>>>
>>>>>>>> rec 7:417940:date 2013053106 var236 kpds5=236 kpds6=106
kpds7=12820
>>>>>>>> levels=(50,20) grid=255 5000-2000 m above gnd valid 0-0hr:
>>>>>>>> var236=undefined
>>>>>>>> timerange 2 P1 0 P2 0 TimeU 14 nx 318 ny 210 GDS
grid 3 num_in_ave 0
>>>>>>>> missing 0
>>>>>>>> center 7 subcenter 0 process 125 Table 129 scan:
WE:SN winds(grid)
>>>>>>>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov
-98.500000
>>>>>>>> Latin1 60.000000 Latin2 30.000000 LatSP
0.000000 LonSP 0.000000
>>>>>>>> North Pole (318 x 210) Dx 2.000000 Dy 2.000000
scan 64 mode 136
>>>>>>>> min/max data 0 250 num bits 8 BDS_Ref 0
DecScale 0 BinScale 0
>>>>>>>>
>>>>>>>> I have tried various combinations of "236" and "var236" and
"L12820" and
>>>>>>>> "Z12820" but always get an apparent problem with this field
not being
>>>>>>>> available in version 2 of NCEP's Table 2 (that lists current
grib codes):
>>>>>>>>
>>>>>>>> DEBUG 1: Default Config File:
>>>>>>>>
/home/tnehrkor/v35/NWP/MET/METv4.1/data/config/GridStatConfig_default
>>>>>>>> DEBUG 1: User Config File: GridStatConfig-RO-UH-grib
>>>>>>>> ERROR :
>>>>>>>> ERROR : VarInfoGrib::set_dict() - unrecognized GRIB1 field
abbreviation
>>>>>>>> 'var236' for table version 2
>>>>>>>> ERROR :
>>>>>>>>
>>>>>>>> I see a file called table_files/nceptab_flat.txt, but I'm not
sure of
>>>>>>>> its relevance. The latest Table 2 version 2 does list var 236
but not as
>>>>>>>> updraft helicity. That really shouldn't matter, should it? I
would
>>>>>>>> suspect that MET simply uses whatever it finds in that grib
code.
>>>>>>>>
>>>>>>>> To try to get any field to work, I then tried a field that
UPP handles
>>>>>>>> better:
>>>>>>>>
>>>>>>>> rec 26:2172702:date 2013053106 PLI kpds5=24 kpds6=116
kpds7=7680
>>>>>>>> levels=(30,0) grid=255 30-0 mb above gnd 1110min fcst:
>>>>>>>> PLI=Parcel lifted index (to 500 hPa) [K]
>>>>>>>> timerange 10 P1 0 P2 37 TimeU 14 nx 318 ny 210
GDS grid 3 num_in_ave
>>>>>>>> 0 missing 0
>>>>>>>> center 7 subcenter 0 process 125 Table 2 scan:
WE:SN winds(grid)
>>>>>>>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000 Lov
-98.500000
>>>>>>>> Latin1 60.000000 Latin2 30.000000 LatSP
0.000000 LonSP 0.000000
>>>>>>>> North Pole (318 x 210) Dx 2.000000 Dy 2.000000
scan 64 mode 136
>>>>>>>> min/max data -13.5884 3.71162 num bits 8 BDS_Ref
-135.884 DecScale
>>>>>>>> 1 BinScale 0
>>>>>>>>
>>>>>>>> but then MET dies because it can't find it (and similarly for
Z7680 and
>>>>>>>> P30-0) in the grib file:
>>>>>>>>
>>>>>>>> WARNING:
>>>>>>>> WARNING: MetGrib1DataFile::data_plane() -> No exact match
found for
>>>>>>>> VarInfo "PLI/L7680" in GRIB file "d2_2013053106_1830-
MYNN.grib".
>>>>>>>> WARNING:
>>>>>>>> WARNING:
>>>>>>>> WARNING: process_scores() -> PLI/L7680 not found in file:
>>>>>>>> d2_2013053106_1830-MYNN.grib
>>>>>>>> WARNING:
>>>>>>>> DEBUG 2:
>>>>>>>> DEBUG 2:
>>>>>>>>
--------------------------------------------------------------------------------
>>>>>>>> DEBUG 2:
>>>>>>>>
>>>>>>>> Experience in the past few years suggests that use of the
kpds5 and
>>>>>>>> kpds7 parameters is the correct way to go. Table 3 of NCEP's
Office Note
>>>>>>>> 388 shows level type '116' as:
>>>>>>>>
>>>>>>>> "layer between two levels at specified pressure difference
from ground
>>>>>>>> to level", which somewhat sounds like Pxx-yy, but that
doesn't work either.
>>>>>>>>
>>>>>>>> Any guidance would be much appreciated.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/30/14 4:49 PM, John Halley Gotway via RT wrote:
>>>>>>>>> John,
>>>>>>>>>
>>>>>>>>> You could run them through the pinterp utility which is
available under the "WRF Utilities Downloads" section of the ARW
downloads page:
>>>>>>>>>
http://www2.mmm.ucar.edu/wrf/users/download/get_sources.html#utilities
>>>>>>>>>
>>>>>>>>> That interpolates the native model output to pressure
levels, but leaves the horizontal grid staggered. Then you can use
grid_stat to access non-staggered fields from the WRF file.
>>>>>>>>>
>>>>>>>>> Alternatively, you could run them through the Unified
PostProcessor which interpolates to pressure levels and destaggers the
grid. Its output format is GRIB.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> John Halley Gotway
>>>>>>>>> met_help at ucar.edu
>>>>>>>>>
>>>>>>>>> On 04/30/2014 02:13 PM, jhenders at aer.com via RT wrote:
>>>>>>>>>> Wed Apr 30 14:13:06 2014: Request 66551 was acted upon.
>>>>>>>>>> Transaction: Ticket created by jhenders at aer.com
>>>>>>>>>> Queue: met_help
>>>>>>>>>> Subject: Functionality of grid_stat with
ncdf files
>>>>>>>>>> Owner: Nobody
>>>>>>>>>> Requestors: jhenders at aer.com
>>>>>>>>>> Status: new
>>>>>>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I would like to validate a WRF-ARW output file against
another WRF-ARW
>>>>>>>>>> output file, but my understanding is that this is still not
generally
>>>>>>>>>> possible in MET v4.1. It seems that grid_stat works only
for ncdf files
>>>>>>>>>> generated by pcp_combine, which modifies accumulated precip
fields.
>>>>>>>>>> Indeed, when I try grid_stat with raw WRF output files I
get a missing
>>>>>>>>>> attribute error.
>>>>>>>>>>
>>>>>>>>>> Is there a way that I can dress up my current WRF output
files - perhaps
>>>>>>>>>> by adding global attributes - to make them work or is the
situation not
>>>>>>>>>> as simple as that?
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> John Henderson
>>>>>>>>>> Atmospheric and Environmental Research
>>>>>>>>>>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #66551] Functionality of grid_stat with ncdf files
From: John Halley Gotway
Time: Fri May 02 12:58:55 2014
John,
Yep, if you edit line number 750 of that file
METv4.1/data/table_files/nceptab_flat.txt and use meaningful strings,
the problem should go away.
FYI, our intention is for that file to contain the table definitions
used here:
http://www.nco.ncep.noaa.gov/pmb/docs/on388/table2.html#TABLE129
However, I see that NCEP updated those definitions last August, and we
haven't updated our table yet. I'll add that as another development
task for the next release.
According to the website, line 750 should read:
236 129 "MXUPHL" "Hourly Maximum of Updraft Helicity over layer
2km to 5 km AGL" "m^2/s^2"
And in the GridStatConfig file, you'd use:
name = "MXUPHL" ;
level = [ "Z50-20" ];
Thanks,
John
On 05/02/2014 12:45 PM, jhenders at aer.com via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>
> Hi John,
>
> Could I circumvent the problem simply by correctly specifying units
in
> the var236 table? They are known (m2/s2), of course. I would like
the
> matched pairs. Come to think of it, a quick glance in that current
file
> indicates just lat/lon pairs and no values!
>
> John
>
> On 5/2/14 1:36 PM, John Halley Gotway via RT wrote:
>> John,
>>
>> Thanks for sending that data. The segfault you're seeing happens
because that entry in METv4.1/data/table_files/nceptab_flat.txt for
variable 236 has an empty string for the units. When Grid-Stat is
>> writing the output NetCDF matched pairs file, it segfaults when
writing the units as a variable attribute because we call "strlen"
(string length) on a null pointer. Even though you were able to make
>> the segfault go away, Grid-Stat is not working as it should. By
setting "method = []", you're defining zero interpolation methods
which skips over the logic for writing out the NetCDF matched pairs
>> file. Since that code isn't exercised, you don't get the segfault.
>>
>> For now, I'd suggest just disabling the NetCDF matched pairs file
by setting:
>> nc_pairs_flag = FALSE;
>>
>> Then, set the interpolation method to this:
>> type = [
>> {
>> method = UW_MEAN;
>> width = 1;
>> }
>> ];
>>
>>
>> I'll work on making it handle the empty strings in that table file
more graceful.
>>
>> Also, I'm adding a check to the next version of MET to make sure
the user defines at least one interpolation method. Otherwise, you'll
get this error:
>> ERROR :
>> ERROR : parse_conf_interp() -> Must define at least one
interpolation method in the config file.
>> ERROR :
>>
>> In your case, you only have neighborhood methods turned on, which
operate on the raw data fields and are not affected by the
interpolation method settings. But it seems like a reasonable
requirement
>> that the user specify at least one, even if it's not actually used.
>>
>> Thanks,
>> John
>>
>>
>> On 05/02/2014 10:34 AM, jhenders at aer.com via RT wrote:
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>
>>> Hi John,
>>>
>>> I've uploaded the grid_stat config file that works - i.e., it
doesn't
>>> have an entry for interp method. Going from memory of my set up
>>> yesterday, simply putting back the default interp method caused a
seg
>>> fault. The command line simply was the MET v4.1 grid_stat
executable
>>> with the two forecast files and the config file.
>>>
>>> Please let me know if you can't reproduce it.
>>>
>>> Thanks.
>>>
>>> John
>>>
>>>
>>>
>>> On 5/1/14 6:28 PM, John Halley Gotway via RT wrote:
>>>> John,
>>>>
>>>> Seg faults are never good! Could you please send me the config
file and exactly what you typed on the command line to get a seg
fault?
>>>>
>>>> I'd like to reproduce the behavior, if possible, catch the
problem, and have it exit more gracefully with a helpful error
message.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>> On 05/01/2014 03:55 PM, jhenders at aer.com via RT wrote:
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>>
>>>>> John,
>>>>>
>>>>> Thanks as always for your prompt and very useful response. I was
able to
>>>>> tweak my config file with your suggestions and MET completed.
After
>>>>> implementing your changes, I still had the default values in
place for
>>>>> the interp section and they were causing a seg fault. When I
set
>>>>> method=[], MET completes properly.
>>>>>
>>>>> John
>>>>>
>>>>> On 5/1/14 4:21 PM, John Halley Gotway via RT wrote:
>>>>>> John,
>>>>>>
>>>>>> That GRIB record doesn't have a meaningful entry in the table
file you mentioned:
>>>>>> METv4.1/data/table_files/nceptab_flat.txt
>>>>>>
>>>>>> Record number 7 in the GRIB files you sent contains a data with
parameter table version number 129 and GRIB code 236. Looking in that
table file I see the following entry on line 750:
>>>>>> 236 129 "var236" "undefined" ""
>>>>>>
>>>>>> If you have a meaningful interpretation of this data, you could
update that table file. Even if you don't, here's a way you can tell
MET to use that record:
>>>>>>
>>>>>> METv4.1/bin/plot_data_plane d2_2013053106_1830-
ACM2.grib d2_2013053106_1830-ACM2.ps 'name="var236"; level="Z50-20";
GRIB1_ptv=129;' -v 3
>>>>>> DEBUG 1: Opening data file: d2_2013053106_1830-
ACM2.grib
>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->
Found range match for VarInfo "var236/Z20-50" in GRIB record 7 of GRIB
file "d2_2013053106_1830-ACM2.grib".
>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->
Found 1 GRIB records matching VarInfo "var236/Z20-50" in GRIB file
"d2_2013053106_1830-ACM2.grib".
>>>>>> DEBUG 1: Creating postscript file:
d2_2013053106_1830-ACM2.ps
>>>>>>
>>>>>> I used "GRIB1_ptv=129" to tell it to look at the table entries
for parameter table version number 129. "var236" is the current
abbreviation for that record. And the level value is "Z50-20". This
>>>>>> can be seen in the wgrib output: levels=(50,20). The 'Z' tells
MET to look for a vertical level, as opposed to a pressure level. And
50 to 20 defines the lower and upper bounds for that vertical level.
>>>>>>
>>>>>> That should do the trick. I've attached a png version of the
resulting image.
>>>>>>
>>>>>> Please give that a shot and let me know if it works for you.
Feel free to update your version of nceptab_flat.txt to list a more
meaningful abbreviation, long name, and units for this data type.
>>>>>>
>>>>>> Thanks,
>>>>>> John
>>>>>>
>>>>>> On 05/01/2014 01:50 PM, jhenders at aer.com via RT wrote:
>>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551
>
>>>>>>>
>>>>>>> Hello John,
>>>>>>>
>>>>>>> I've put both WRF grib files (one is to be used as a forecast,
the other
>>>>>>> as validation) in the expected henderson_data directory.
>>>>>>>
>>>>>>> I've also uploaded my UPP v2.1 parm file. There are two
updraft helicity
>>>>>>> fields, but the one written out by UPP as grid code 236
(maximum updraft
>>>>>>> helicity) is preferred.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>> On 5/1/14 3:26 PM, John Halley Gotway via RT wrote:
>>>>>>>> John,
>>>>>>>>
>>>>>>>> Could you please post one of these GRIB files to our
anonymous ftp site. I'll take a look and see if I can get it to
extract the field you're after. Here's the instructions:
>>>>>>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>>>>>
>>>>>>>> Please write me back once you've posted the data to let me
know it's there.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> John
>>>>>>>>
>>>>>>>> On 05/01/2014 12:43 PM, jhenders at aer.com via RT wrote:
>>>>>>>>> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>>>>>>
>>>>>>>>> Hello again John,
>>>>>>>>>
>>>>>>>>> Following your clarification to use grib format, I have
passed
>>>>>>>>> WRF-generated maximum updraft helicity through UPP into grib
files.
>>>>>>>>> However, I cannot seem to get MET to recognize the presence
of this field:
>>>>>>>>>
>>>>>>>>> rec 7:417940:date 2013053106 var236 kpds5=236 kpds6=106
kpds7=12820
>>>>>>>>> levels=(50,20) grid=255 5000-2000 m above gnd valid 0-0hr:
>>>>>>>>> var236=undefined
>>>>>>>>> timerange 2 P1 0 P2 0 TimeU 14 nx 318 ny 210
GDS grid 3 num_in_ave 0
>>>>>>>>> missing 0
>>>>>>>>> center 7 subcenter 0 process 125 Table 129 scan:
WE:SN winds(grid)
>>>>>>>>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000
Lov -98.500000
>>>>>>>>> Latin1 60.000000 Latin2 30.000000 LatSP
0.000000 LonSP 0.000000
>>>>>>>>> North Pole (318 x 210) Dx 2.000000 Dy
2.000000 scan 64 mode 136
>>>>>>>>> min/max data 0 250 num bits 8 BDS_Ref 0
DecScale 0 BinScale 0
>>>>>>>>>
>>>>>>>>> I have tried various combinations of "236" and "var236" and
"L12820" and
>>>>>>>>> "Z12820" but always get an apparent problem with this field
not being
>>>>>>>>> available in version 2 of NCEP's Table 2 (that lists current
grib codes):
>>>>>>>>>
>>>>>>>>> DEBUG 1: Default Config File:
>>>>>>>>>
/home/tnehrkor/v35/NWP/MET/METv4.1/data/config/GridStatConfig_default
>>>>>>>>> DEBUG 1: User Config File: GridStatConfig-RO-UH-grib
>>>>>>>>> ERROR :
>>>>>>>>> ERROR : VarInfoGrib::set_dict() - unrecognized GRIB1 field
abbreviation
>>>>>>>>> 'var236' for table version 2
>>>>>>>>> ERROR :
>>>>>>>>>
>>>>>>>>> I see a file called table_files/nceptab_flat.txt, but I'm
not sure of
>>>>>>>>> its relevance. The latest Table 2 version 2 does list var
236 but not as
>>>>>>>>> updraft helicity. That really shouldn't matter, should it? I
would
>>>>>>>>> suspect that MET simply uses whatever it finds in that grib
code.
>>>>>>>>>
>>>>>>>>> To try to get any field to work, I then tried a field that
UPP handles
>>>>>>>>> better:
>>>>>>>>>
>>>>>>>>> rec 26:2172702:date 2013053106 PLI kpds5=24 kpds6=116
kpds7=7680
>>>>>>>>> levels=(30,0) grid=255 30-0 mb above gnd 1110min fcst:
>>>>>>>>> PLI=Parcel lifted index (to 500 hPa) [K]
>>>>>>>>> timerange 10 P1 0 P2 37 TimeU 14 nx 318 ny 210
GDS grid 3 num_in_ave
>>>>>>>>> 0 missing 0
>>>>>>>>> center 7 subcenter 0 process 125 Table 2 scan:
WE:SN winds(grid)
>>>>>>>>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000
Lov -98.500000
>>>>>>>>> Latin1 60.000000 Latin2 30.000000 LatSP
0.000000 LonSP 0.000000
>>>>>>>>> North Pole (318 x 210) Dx 2.000000 Dy
2.000000 scan 64 mode 136
>>>>>>>>> min/max data -13.5884 3.71162 num bits 8
BDS_Ref -135.884 DecScale
>>>>>>>>> 1 BinScale 0
>>>>>>>>>
>>>>>>>>> but then MET dies because it can't find it (and similarly
for Z7680 and
>>>>>>>>> P30-0) in the grib file:
>>>>>>>>>
>>>>>>>>> WARNING:
>>>>>>>>> WARNING: MetGrib1DataFile::data_plane() -> No exact match
found for
>>>>>>>>> VarInfo "PLI/L7680" in GRIB file "d2_2013053106_1830-
MYNN.grib".
>>>>>>>>> WARNING:
>>>>>>>>> WARNING:
>>>>>>>>> WARNING: process_scores() -> PLI/L7680 not found in file:
>>>>>>>>> d2_2013053106_1830-MYNN.grib
>>>>>>>>> WARNING:
>>>>>>>>> DEBUG 2:
>>>>>>>>> DEBUG 2:
>>>>>>>>>
--------------------------------------------------------------------------------
>>>>>>>>> DEBUG 2:
>>>>>>>>>
>>>>>>>>> Experience in the past few years suggests that use of the
kpds5 and
>>>>>>>>> kpds7 parameters is the correct way to go. Table 3 of NCEP's
Office Note
>>>>>>>>> 388 shows level type '116' as:
>>>>>>>>>
>>>>>>>>> "layer between two levels at specified pressure difference
from ground
>>>>>>>>> to level", which somewhat sounds like Pxx-yy, but that
doesn't work either.
>>>>>>>>>
>>>>>>>>> Any guidance would be much appreciated.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/30/14 4:49 PM, John Halley Gotway via RT wrote:
>>>>>>>>>> John,
>>>>>>>>>>
>>>>>>>>>> You could run them through the pinterp utility which is
available under the "WRF Utilities Downloads" section of the ARW
downloads page:
>>>>>>>>>>
http://www2.mmm.ucar.edu/wrf/users/download/get_sources.html#utilities
>>>>>>>>>>
>>>>>>>>>> That interpolates the native model output to pressure
levels, but leaves the horizontal grid staggered. Then you can use
grid_stat to access non-staggered fields from the WRF file.
>>>>>>>>>>
>>>>>>>>>> Alternatively, you could run them through the Unified
PostProcessor which interpolates to pressure levels and destaggers the
grid. Its output format is GRIB.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> John Halley Gotway
>>>>>>>>>> met_help at ucar.edu
>>>>>>>>>>
>>>>>>>>>> On 04/30/2014 02:13 PM, jhenders at aer.com via RT wrote:
>>>>>>>>>>> Wed Apr 30 14:13:06 2014: Request 66551 was acted upon.
>>>>>>>>>>> Transaction: Ticket created by jhenders at aer.com
>>>>>>>>>>> Queue: met_help
>>>>>>>>>>> Subject: Functionality of grid_stat with
ncdf files
>>>>>>>>>>> Owner: Nobody
>>>>>>>>>>> Requestors: jhenders at aer.com
>>>>>>>>>>> Status: new
>>>>>>>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> I would like to validate a WRF-ARW output file against
another WRF-ARW
>>>>>>>>>>> output file, but my understanding is that this is still
not generally
>>>>>>>>>>> possible in MET v4.1. It seems that grid_stat works only
for ncdf files
>>>>>>>>>>> generated by pcp_combine, which modifies accumulated
precip fields.
>>>>>>>>>>> Indeed, when I try grid_stat with raw WRF output files I
get a missing
>>>>>>>>>>> attribute error.
>>>>>>>>>>>
>>>>>>>>>>> Is there a way that I can dress up my current WRF output
files - perhaps
>>>>>>>>>>> by adding global attributes - to make them work or is the
situation not
>>>>>>>>>>> as simple as that?
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> John Henderson
>>>>>>>>>>> Atmospheric and Environmental Research
>>>>>>>>>>>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #66551] Functionality of grid_stat with ncdf files
From: jhenders at aer.com
Time: Fri May 02 13:26:05 2014
Much appreciated John!
John
On 5/2/14 2:58 PM, John Halley Gotway via RT wrote:
> John,
>
> Yep, if you edit line number 750 of that file
METv4.1/data/table_files/nceptab_flat.txt and use meaningful strings,
the problem should go away.
>
> FYI, our intention is for that file to contain the table definitions
used here:
>
http://www.nco.ncep.noaa.gov/pmb/docs/on388/table2.html#TABLE129
>
> However, I see that NCEP updated those definitions last August, and
we haven't updated our table yet. I'll add that as another
development task for the next release.
>
> According to the website, line 750 should read:
> 236 129 "MXUPHL" "Hourly Maximum of Updraft Helicity over layer
2km to 5 km AGL" "m^2/s^2"
>
> And in the GridStatConfig file, you'd use:
> name = "MXUPHL" ;
> level = [ "Z50-20" ];
>
> Thanks,
> John
>
> On 05/02/2014 12:45 PM, jhenders at aer.com via RT wrote:
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>
>> Hi John,
>>
>> Could I circumvent the problem simply by correctly specifying units
in
>> the var236 table? They are known (m2/s2), of course. I would like
the
>> matched pairs. Come to think of it, a quick glance in that current
file
>> indicates just lat/lon pairs and no values!
>>
>> John
>>
>> On 5/2/14 1:36 PM, John Halley Gotway via RT wrote:
>>> John,
>>>
>>> Thanks for sending that data. The segfault you're seeing happens
because that entry in METv4.1/data/table_files/nceptab_flat.txt for
variable 236 has an empty string for the units. When Grid-Stat is
>>> writing the output NetCDF matched pairs file, it segfaults when
writing the units as a variable attribute because we call "strlen"
(string length) on a null pointer. Even though you were able to make
>>> the segfault go away, Grid-Stat is not working as it should. By
setting "method = []", you're defining zero interpolation methods
which skips over the logic for writing out the NetCDF matched pairs
>>> file. Since that code isn't exercised, you don't get the
segfault.
>>>
>>> For now, I'd suggest just disabling the NetCDF matched pairs file
by setting:
>>> nc_pairs_flag = FALSE;
>>>
>>> Then, set the interpolation method to this:
>>> type = [
>>> {
>>> method = UW_MEAN;
>>> width = 1;
>>> }
>>> ];
>>>
>>>
>>> I'll work on making it handle the empty strings in that table file
more graceful.
>>>
>>> Also, I'm adding a check to the next version of MET to make sure
the user defines at least one interpolation method. Otherwise, you'll
get this error:
>>> ERROR :
>>> ERROR : parse_conf_interp() -> Must define at least one
interpolation method in the config file.
>>> ERROR :
>>>
>>> In your case, you only have neighborhood methods turned on, which
operate on the raw data fields and are not affected by the
interpolation method settings. But it seems like a reasonable
requirement
>>> that the user specify at least one, even if it's not actually
used.
>>>
>>> Thanks,
>>> John
>>>
>>>
>>> On 05/02/2014 10:34 AM, jhenders at aer.com via RT wrote:
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>
>>>> Hi John,
>>>>
>>>> I've uploaded the grid_stat config file that works - i.e., it
doesn't
>>>> have an entry for interp method. Going from memory of my set up
>>>> yesterday, simply putting back the default interp method caused a
seg
>>>> fault. The command line simply was the MET v4.1 grid_stat
executable
>>>> with the two forecast files and the config file.
>>>>
>>>> Please let me know if you can't reproduce it.
>>>>
>>>> Thanks.
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>> On 5/1/14 6:28 PM, John Halley Gotway via RT wrote:
>>>>> John,
>>>>>
>>>>> Seg faults are never good! Could you please send me the config
file and exactly what you typed on the command line to get a seg
fault?
>>>>>
>>>>> I'd like to reproduce the behavior, if possible, catch the
problem, and have it exit more gracefully with a helpful error
message.
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>> On 05/01/2014 03:55 PM, jhenders at aer.com via RT wrote:
>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>>>
>>>>>> John,
>>>>>>
>>>>>> Thanks as always for your prompt and very useful response. I
was able to
>>>>>> tweak my config file with your suggestions and MET completed.
After
>>>>>> implementing your changes, I still had the default values in
place for
>>>>>> the interp section and they were causing a seg fault. When I
set
>>>>>> method=[], MET completes properly.
>>>>>>
>>>>>> John
>>>>>>
>>>>>> On 5/1/14 4:21 PM, John Halley Gotway via RT wrote:
>>>>>>> John,
>>>>>>>
>>>>>>> That GRIB record doesn't have a meaningful entry in the table
file you mentioned:
>>>>>>> METv4.1/data/table_files/nceptab_flat.txt
>>>>>>>
>>>>>>> Record number 7 in the GRIB files you sent contains a data
with parameter table version number 129 and GRIB code 236. Looking in
that table file I see the following entry on line 750:
>>>>>>> 236 129 "var236" "undefined" ""
>>>>>>>
>>>>>>> If you have a meaningful interpretation of this data, you
could update that table file. Even if you don't, here's a way you can
tell MET to use that record:
>>>>>>>
>>>>>>> METv4.1/bin/plot_data_plane d2_2013053106_1830-
ACM2.grib d2_2013053106_1830-ACM2.ps 'name="var236"; level="Z50-20";
GRIB1_ptv=129;' -v 3
>>>>>>> DEBUG 1: Opening data file: d2_2013053106_1830-
ACM2.grib
>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->
Found range match for VarInfo "var236/Z20-50" in GRIB record 7 of GRIB
file "d2_2013053106_1830-ACM2.grib".
>>>>>>> DEBUG 3: MetGrib1DataFile::data_plane_array() ->
Found 1 GRIB records matching VarInfo "var236/Z20-50" in GRIB file
"d2_2013053106_1830-ACM2.grib".
>>>>>>> DEBUG 1: Creating postscript file:
d2_2013053106_1830-ACM2.ps
>>>>>>>
>>>>>>> I used "GRIB1_ptv=129" to tell it to look at the table entries
for parameter table version number 129. "var236" is the current
abbreviation for that record. And the level value is "Z50-20". This
>>>>>>> can be seen in the wgrib output: levels=(50,20). The 'Z'
tells MET to look for a vertical level, as opposed to a pressure
level. And 50 to 20 defines the lower and upper bounds for that
vertical level.
>>>>>>>
>>>>>>> That should do the trick. I've attached a png version of the
resulting image.
>>>>>>>
>>>>>>> Please give that a shot and let me know if it works for you.
Feel free to update your version of nceptab_flat.txt to list a more
meaningful abbreviation, long name, and units for this data type.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> John
>>>>>>>
>>>>>>> On 05/01/2014 01:50 PM, jhenders at aer.com via RT wrote:
>>>>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551
>
>>>>>>>>
>>>>>>>> Hello John,
>>>>>>>>
>>>>>>>> I've put both WRF grib files (one is to be used as a
forecast, the other
>>>>>>>> as validation) in the expected henderson_data directory.
>>>>>>>>
>>>>>>>> I've also uploaded my UPP v2.1 parm file. There are two
updraft helicity
>>>>>>>> fields, but the one written out by UPP as grid code 236
(maximum updraft
>>>>>>>> helicity) is preferred.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>> On 5/1/14 3:26 PM, John Halley Gotway via RT wrote:
>>>>>>>>> John,
>>>>>>>>>
>>>>>>>>> Could you please post one of these GRIB files to our
anonymous ftp site. I'll take a look and see if I can get it to
extract the field you're after. Here's the instructions:
>>>>>>>>>
http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>>>>>>
>>>>>>>>> Please write me back once you've posted the data to let me
know it's there.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>> On 05/01/2014 12:43 PM, jhenders at aer.com via RT wrote:
>>>>>>>>>> <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>>>>>>>
>>>>>>>>>> Hello again John,
>>>>>>>>>>
>>>>>>>>>> Following your clarification to use grib format, I have
passed
>>>>>>>>>> WRF-generated maximum updraft helicity through UPP into
grib files.
>>>>>>>>>> However, I cannot seem to get MET to recognize the presence
of this field:
>>>>>>>>>>
>>>>>>>>>> rec 7:417940:date 2013053106 var236 kpds5=236 kpds6=106
kpds7=12820
>>>>>>>>>> levels=(50,20) grid=255 5000-2000 m above gnd valid 0-0hr:
>>>>>>>>>> var236=undefined
>>>>>>>>>> timerange 2 P1 0 P2 0 TimeU 14 nx 318 ny 210
GDS grid 3 num_in_ave 0
>>>>>>>>>> missing 0
>>>>>>>>>> center 7 subcenter 0 process 125 Table 129
scan: WE:SN winds(grid)
>>>>>>>>>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000
Lov -98.500000
>>>>>>>>>> Latin1 60.000000 Latin2 30.000000 LatSP
0.000000 LonSP 0.000000
>>>>>>>>>> North Pole (318 x 210) Dx 2.000000 Dy
2.000000 scan 64 mode 136
>>>>>>>>>> min/max data 0 250 num bits 8 BDS_Ref 0
DecScale 0 BinScale 0
>>>>>>>>>>
>>>>>>>>>> I have tried various combinations of "236" and "var236" and
"L12820" and
>>>>>>>>>> "Z12820" but always get an apparent problem with this field
not being
>>>>>>>>>> available in version 2 of NCEP's Table 2 (that lists
current grib codes):
>>>>>>>>>>
>>>>>>>>>> DEBUG 1: Default Config File:
>>>>>>>>>>
/home/tnehrkor/v35/NWP/MET/METv4.1/data/config/GridStatConfig_default
>>>>>>>>>> DEBUG 1: User Config File: GridStatConfig-RO-UH-grib
>>>>>>>>>> ERROR :
>>>>>>>>>> ERROR : VarInfoGrib::set_dict() - unrecognized GRIB1 field
abbreviation
>>>>>>>>>> 'var236' for table version 2
>>>>>>>>>> ERROR :
>>>>>>>>>>
>>>>>>>>>> I see a file called table_files/nceptab_flat.txt, but I'm
not sure of
>>>>>>>>>> its relevance. The latest Table 2 version 2 does list var
236 but not as
>>>>>>>>>> updraft helicity. That really shouldn't matter, should it?
I would
>>>>>>>>>> suspect that MET simply uses whatever it finds in that grib
code.
>>>>>>>>>>
>>>>>>>>>> To try to get any field to work, I then tried a field that
UPP handles
>>>>>>>>>> better:
>>>>>>>>>>
>>>>>>>>>> rec 26:2172702:date 2013053106 PLI kpds5=24 kpds6=116
kpds7=7680
>>>>>>>>>> levels=(30,0) grid=255 30-0 mb above gnd 1110min fcst:
>>>>>>>>>> PLI=Parcel lifted index (to 500 hPa) [K]
>>>>>>>>>> timerange 10 P1 0 P2 37 TimeU 14 nx 318 ny
210 GDS grid 3 num_in_ave
>>>>>>>>>> 0 missing 0
>>>>>>>>>> center 7 subcenter 0 process 125 Table 2 scan:
WE:SN winds(grid)
>>>>>>>>>> Lambert Conf: Lat1 33.349000 Lon1 -101.109000
Lov -98.500000
>>>>>>>>>> Latin1 60.000000 Latin2 30.000000 LatSP
0.000000 LonSP 0.000000
>>>>>>>>>> North Pole (318 x 210) Dx 2.000000 Dy
2.000000 scan 64 mode 136
>>>>>>>>>> min/max data -13.5884 3.71162 num bits 8
BDS_Ref -135.884 DecScale
>>>>>>>>>> 1 BinScale 0
>>>>>>>>>>
>>>>>>>>>> but then MET dies because it can't find it (and similarly
for Z7680 and
>>>>>>>>>> P30-0) in the grib file:
>>>>>>>>>>
>>>>>>>>>> WARNING:
>>>>>>>>>> WARNING: MetGrib1DataFile::data_plane() -> No exact match
found for
>>>>>>>>>> VarInfo "PLI/L7680" in GRIB file "d2_2013053106_1830-
MYNN.grib".
>>>>>>>>>> WARNING:
>>>>>>>>>> WARNING:
>>>>>>>>>> WARNING: process_scores() -> PLI/L7680 not found in file:
>>>>>>>>>> d2_2013053106_1830-MYNN.grib
>>>>>>>>>> WARNING:
>>>>>>>>>> DEBUG 2:
>>>>>>>>>> DEBUG 2:
>>>>>>>>>>
--------------------------------------------------------------------------------
>>>>>>>>>> DEBUG 2:
>>>>>>>>>>
>>>>>>>>>> Experience in the past few years suggests that use of the
kpds5 and
>>>>>>>>>> kpds7 parameters is the correct way to go. Table 3 of
NCEP's Office Note
>>>>>>>>>> 388 shows level type '116' as:
>>>>>>>>>>
>>>>>>>>>> "layer between two levels at specified pressure difference
from ground
>>>>>>>>>> to level", which somewhat sounds like Pxx-yy, but that
doesn't work either.
>>>>>>>>>>
>>>>>>>>>> Any guidance would be much appreciated.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> John
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 4/30/14 4:49 PM, John Halley Gotway via RT wrote:
>>>>>>>>>>> John,
>>>>>>>>>>>
>>>>>>>>>>> You could run them through the pinterp utility which is
available under the "WRF Utilities Downloads" section of the ARW
downloads page:
>>>>>>>>>>>
http://www2.mmm.ucar.edu/wrf/users/download/get_sources.html#utilities
>>>>>>>>>>>
>>>>>>>>>>> That interpolates the native model output to pressure
levels, but leaves the horizontal grid staggered. Then you can use
grid_stat to access non-staggered fields from the WRF file.
>>>>>>>>>>>
>>>>>>>>>>> Alternatively, you could run them through the Unified
PostProcessor which interpolates to pressure levels and destaggers the
grid. Its output format is GRIB.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> John Halley Gotway
>>>>>>>>>>> met_help at ucar.edu
>>>>>>>>>>>
>>>>>>>>>>> On 04/30/2014 02:13 PM, jhenders at aer.com via RT wrote:
>>>>>>>>>>>> Wed Apr 30 14:13:06 2014: Request 66551 was acted upon.
>>>>>>>>>>>> Transaction: Ticket created by jhenders at aer.com
>>>>>>>>>>>> Queue: met_help
>>>>>>>>>>>> Subject: Functionality of grid_stat with
ncdf files
>>>>>>>>>>>> Owner: Nobody
>>>>>>>>>>>> Requestors: jhenders at aer.com
>>>>>>>>>>>> Status: new
>>>>>>>>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=66551 >
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> I would like to validate a WRF-ARW output file against
another WRF-ARW
>>>>>>>>>>>> output file, but my understanding is that this is still
not generally
>>>>>>>>>>>> possible in MET v4.1. It seems that grid_stat works only
for ncdf files
>>>>>>>>>>>> generated by pcp_combine, which modifies accumulated
precip fields.
>>>>>>>>>>>> Indeed, when I try grid_stat with raw WRF output files I
get a missing
>>>>>>>>>>>> attribute error.
>>>>>>>>>>>>
>>>>>>>>>>>> Is there a way that I can dress up my current WRF output
files - perhaps
>>>>>>>>>>>> by adding global attributes - to make them work or is
the situation not
>>>>>>>>>>>> as simple as that?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> John Henderson
>>>>>>>>>>>> Atmospheric and Environmental Research
>>>>>>>>>>>>
------------------------------------------------
More information about the Met_help
mailing list