[Met_help] [rt.rap.ucar.edu #64405] History for Issue with wind forecast verification
John Halley Gotway via RT
met_help at ucar.edu
Mon Dec 2 15:08:19 MST 2013
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Good afternoon,
I am running Point-stat for an annual WRF model run; the WRF-ARW data is being fed through UPP to get the forecast data into the proper format, then "copygb" is used to group the hourly forecast files together into one big file so I can look at daily verification data instead of one hour at a time. I am analyzing temperature, dewpoint, absolute & relative humidity data, and I want to analyze wind data as well. However, MET will not produce the partial vector sums for wind (only partial scalar sums), and I want to analyze both wind direction and speed. I have attempted to work around this problem by running the WRF data through p_interp (see ticket #64317), to no avail as it now gives me the following error:
*** Running Point-Stat on EPA WRF data ***
DEBUG 1: Default Config File: /opt/storage/high-speed/EMT2/METv4.1/METv4.1/data/config/PointStatConfig_default
DEBUG 1: User Config File: /opt/storage/high-speed/EMT2/METv4.1/METv4.1/data/config/PointStatConfig_nc
ERROR :
ERROR : Dictionary::lookup_string_array() -> lookup failed for name "message_type"
ERROR :
I would greatly appreciate any help on getting MET to produce partial vector sums for wind direction and wind speed verification analysis, either through running p_interp or UPP. I have sent some files via ftp, using the instructions given on your website, for your consideration. I will be happy to answer any questions.
Thanks for your time and have a great weekend,
Elliot Tardif, Meteorologist II
NC DENR, Division of Air Quality
Planning Section, Attainment Planning Branch
1641 Mail Service Center
Raleigh, NC 27699-1641
Phone/Fax: 919-707-8483
Email: Elliot.Tardif at ncdenr.gov<mailto:Nick.Witcraft at ncdenr.gov>
Web : http://www.ncair.org<http://www.ncair.org/>
Email correspondence to and from this address is subject to the North Carolina Public Records Law and may be disclosed to third parties unless the content is exempt by statue or other regulation.
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #64405] AutoReply: Issue with wind forecast verification
From: Tardif, Elliot M
Time: Fri Nov 22 13:21:42 2013
Good afternoon, I need to leave the office for the day, and I was not
able to complete the ftp transfer of all the files. I will do this on
Monday when I return. I apologize for any inconvenience.
Thanks again and have a great weekend,
Elliot Tardif, Meteorologist II
NC DENR, Division of Air Quality
Planning Section, Attainment Planning Branch
1641 Mail Service Center
Raleigh, NC 27699-1641
Phone/Fax: 919-707-8483
Email: Elliot.Tardif at ncdenr.gov
Web : http://www.ncair.org
Email correspondence to and from this address is subject to the North
Carolina Public Records Law and may be disclosed to third parties
unless the content is exempt by statue or other regulation.
-----Original Message-----
From: met_help at ucar.edu via RT [mailto:met_help at ucar.edu]
Sent: Friday, November 22, 2013 2:46 PM
To: Tardif, Elliot M
Subject: [rt.rap.ucar.edu #64405] AutoReply: Issue with wind forecast
verification
Greetings,
This message has been automatically generated in response to the
creation of a trouble ticket regarding:
"Issue with wind forecast verification", a summary of which appears
below.
There is no need to reply to this message right now. Your ticket has
been assigned an ID of [rt.rap.ucar.edu #64405].
Please include the string:
[rt.rap.ucar.edu #64405]
in the subject line of all future correspondence about this issue. To
do so, you may reply to this message.
Thank you,
met_help at ucar.edu
-------------------------------------------------------------------------
Good afternoon,
I am running Point-stat for an annual WRF model run; the WRF-ARW data
is being fed through UPP to get the forecast data into the proper
format, then "copygb" is used to group the hourly forecast files
together into one big file so I can look at daily verification data
instead of one hour at a time. I am analyzing temperature, dewpoint,
absolute & relative humidity data, and I want to analyze wind data as
well. However, MET will not produce the partial vector sums for wind
(only partial scalar sums), and I want to analyze both wind direction
and speed. I have attempted to work around this problem by running
the WRF data through p_interp (see ticket #64317), to no avail as it
now gives me the following error:
*** Running Point-Stat on EPA WRF data *** DEBUG 1: Default Config
File: /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConfig_default
DEBUG 1: User Config File: /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConfig_nc
ERROR :
ERROR : Dictionary::lookup_string_array() -> lookup failed for name
"message_type"
ERROR :
I would greatly appreciate any help on getting MET to produce partial
vector sums for wind direction and wind speed verification analysis,
either through running p_interp or UPP. I have sent some files via
ftp, using the instructions given on your website, for your
consideration. I will be happy to answer any questions.
Thanks for your time and have a great weekend,
Elliot Tardif, Meteorologist II
NC DENR, Division of Air Quality
Planning Section, Attainment Planning Branch
1641 Mail Service Center
Raleigh, NC 27699-1641
Phone/Fax: 919-707-8483
Email: Elliot.Tardif at ncdenr.gov<mailto:Nick.Witcraft at ncdenr.gov>
Web : http://www.ncair.org<http://www.ncair.org/>
Email correspondence to and from this address is subject to the North
Carolina Public Records Law and may be disclosed to third parties
unless the content is exempt by statue or other regulation.
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #64405] Issue with wind forecast verification
From: John Halley Gotway
Time: Fri Nov 22 14:06:59 2013
Elliot,
Thanks for sending the detailed description of the problem and some
sample data that you're using. I see that you're having trouble
getting the VL1L2 vector partial sums from the Point-Stat tool.
There may be a problem with the WRFPRS_d01.all data file you sent.
When I try to run it through wgrib to inventory it, I get the
following error:
error, could not read to end of record 8461
And when I try to run it through Point-Stat, I get:
GribFile::read() -> file read error ... requested 201498 bytes,
got 123540
Perhaps the file was truncated when you were writing it to our ftp
site. To get around the problem, I used wgrib to extract the first
8460 records from that file. That got me around the error from
Point-Stat. (I'm just now seeing your message that you weren't able
to complete the ftp. So that's the likely source of this problem).
When I ran Point-Stat, I did not get the
"Dictionary::lookup_string_array()" error you saw, but I have a
suggestion. This is the config file that produced that error:
/opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConfig_nc
In that config file, I'm guessing you defined the "fcst" and "obs"
dictionaries separately. And I'll be that you have the "message_type"
setting in the "fcst" dictionary and not in the "obs"
dictionary. It belongs in the "obs" dictionary since it specifying
information about the point observations. Try moving "message_type"
into the "obs" dictionary and see if that error goes away.
So to test things out, I ran the following command:
METv4.1/bin/point_stat \
WRFPRS_d01.all \
gdas.42112.2011092800.nc \
PointStatConfig_emt \
-outdir out \
-log run_ps.log \
-v 4
And like you, I see no VL1L2 lines in the output. This is due to a
rather unfortunate convention we chose a while back. In order to
produce VL1L2 vector partial sums, the UGRD field must be
immediately followed by the VGRD at the same vertical level. That
simplifies the logic so that the code doesn't have to hunt through the
config file to match up UGRD and VGRD pairs. In your config
file, UGRD is followed by VGRD but for 4 different levels, as shown
here:
{
name = "UGRD";
level = [ "Z10", "P850", "P700", "P500" ];
cat_thresh = [ >1.0 ];
},
{
name = "VGRD";
level = [ "Z10", "P850", "P700", "P500" ];
cat_thresh = [ >1.0 ];
},
When the code expands this it sees: UGRD/Z10, UGRD/P850, UGRD/P700,
UGRD/P500, VGRD/Z10, VGRD/P850, VGRD/P700, VGRD/P500
So the convention is not met since UGRD is not followed by VGRD at the
same vertical level. When I remove the first 3 levels, leaving only
"P500" and rerun Point-Stat, I do get VL1L2 partial sums in
the output. I order to get the desired behavior, you'd have to set up
the config file like list:
{ name = "UGRD"; level = ["Z10"]; cat_thresh = [ >1.0 ]; },
{ name = "VGRD"; level = ["Z10"]; cat_thresh = [ >1.0 ]; },
{ name = "UGRD"; level = ["P850"]; cat_thresh = [ >1.0 ]; },
{ name = "VGRD"; level = ["P850"]; cat_thresh = [ >1.0 ]; },
{ name = "UGRD"; level = ["P700"]; cat_thresh = [ >1.0 ]; },
{ name = "VGRD"; level = ["P700"]; cat_thresh = [ >1.0 ]; },
{ name = "UGRD"; level = ["P500"]; cat_thresh = [ >1.0 ]; },
{ name = "VGRD"; level = ["P500"]; cat_thresh = [ >1.0 ]; },
In this way, UGRD is immediately followed by VGRD at the same vertical
level. I realize that's more cumbersome, but it should solve your
problem.
Lastly, I want to mention something about how you've prepared your
data for Point-Stat. You've grouped all the forecast lead times into
a single GRIB file. When I run Point-Stat and verify 500 mb
temperature, for example, I see the following log message:
DEBUG 2: For TMP/P500 found 25 forecast levels and 0 climatology
levels.
Looking at the (truncated) GRIB file you sent, I see 25 records of
temperature at 500 mb, for hourly forecasts from 25 to 36 hours:
wgrib WRFPRS_d01.all | grep TMP | grep "kpds7=500"
Point-Stat is not verifying them one-by-one. Instead it's just using
the first one it finds. If you'd like to organize your data in this
way, you'll need to tell Point-Stat which forecast lead time
you'd like to evaluate. You do this using the "lead_time" setting in
the config file. I see that you have "lead_time" listed in the config
file you sent but it's commented out. If your forecast
data is organized in this way, you should be setting "lead_time".
Hope that helps clarify.
Thanks,
John Halley Gotway
met_help at ucar.edu
On 11/22/2013 12:46 PM, Tardif, Elliot M via RT wrote:
>
> Fri Nov 22 12:46:10 2013: Request 64405 was acted upon.
> Transaction: Ticket created by elliot.tardif at ncdenr.gov
> Queue: met_help
> Subject: Issue with wind forecast verification
> Owner: Nobody
> Requestors: elliot.tardif at ncdenr.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=64405 >
>
>
> Good afternoon,
>
> I am running Point-stat for an annual WRF model run; the WRF-ARW
data is being fed through UPP to get the forecast data into the proper
format, then "copygb" is used to group the hourly forecast files
together into one big file so I can look at daily verification data
instead of one hour at a time. I am analyzing temperature, dewpoint,
absolute & relative humidity data, and I want to analyze wind data as
well. However, MET will not produce the partial vector sums for wind
(only partial scalar sums), and I want to analyze both wind direction
and speed. I have attempted to work around this problem by running
the WRF data through p_interp (see ticket #64317), to no avail as it
now gives me the following error:
>
> *** Running Point-Stat on EPA WRF data ***
> DEBUG 1: Default Config File: /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConfig_default
> DEBUG 1: User Config File: /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConfig_nc
> ERROR :
> ERROR : Dictionary::lookup_string_array() -> lookup failed for name
"message_type"
> ERROR :
>
> I would greatly appreciate any help on getting MET to produce
partial vector sums for wind direction and wind speed verification
analysis, either through running p_interp or UPP. I have sent some
files via ftp, using the instructions given on your website, for your
consideration. I will be happy to answer any questions.
>
> Thanks for your time and have a great weekend,
>
> Elliot Tardif, Meteorologist II
> NC DENR, Division of Air Quality
> Planning Section, Attainment Planning Branch
> 1641 Mail Service Center
> Raleigh, NC 27699-1641
> Phone/Fax: 919-707-8483
> Email: Elliot.Tardif at ncdenr.gov<mailto:Nick.Witcraft at ncdenr.gov>
> Web : http://www.ncair.org<http://www.ncair.org/>
>
> Email correspondence to and from this address is subject to the
North Carolina Public Records Law and may be disclosed to third
parties unless the content is exempt by statue or other regulation.
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #64405] Issue with wind forecast verification
From: Tardif, Elliot M
Time: Mon Nov 25 10:28:29 2013
Good morning John,
First, thank you very much for your help in resolving the vl1l2 issue
I was having. I tried setting the fcst wind variables back-to-back in
my PointStatConfig file as you suggested, looking only at one level in
this case (Z10) as a test to see if it would work. I have attached
this part of my PointStatConfig file below:
{
name = "UGRD";
level = [ "Z10" ];
cat_thresh = [ >1.0 ];
},
{
name = "VGRD";
level = [ "Z10" ];
cat_thresh = [ >1.0 ];
},
This change resulted in me getting VL1L2 data. I will run this
through Stat_Analysis later to get the wind direction data I need.
Second, I also wanted to follow up on the point you made about the
"valid_time", "lead_time" and "init_time" values that can be set in
PointStatConfig for forecast files that have multiple times set
together, like mine. I attempted to set these variables in the
PointStatConfig file at the start of this project, but it would not
work for me, so I just left them aside. I attempted to set these
variables again in PointStatConfig based on your advice on Friday, and
again Point Stat is not finding the WRF data in my WRFPRS_d01.all
file. Please see output below:
*** Running Point-Stat on EPA WRF data ***
DEBUG 1: Default Config File: /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConfig_default
DEBUG 1: User Config File: /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConfig_emt
GSL_RNG_TYPE=mt19937
GSL_RNG_SEED=109417298
DEBUG 1: Forecast File: /opt/storage/high-
speed/EMT2/UPPVspace/postprd/WRFPRS_d01.all
DEBUG 1: Climatology File: none
DEBUG 1: Observation File: /opt/storage/high-
speed/EMT2/2011MetData/gdas.42112.2011102000.nc
DEBUG 1: Observation File: /opt/storage/high-
speed/EMT2/2011MetData/gdas.42112.2011102006.nc
DEBUG 1: Observation File: /opt/storage/high-
speed/EMT2/2011MetData/gdas.42112.2011102012.nc
DEBUG 1: Observation File: /opt/storage/high-
speed/EMT2/2011MetData/gdas.42112.2011102018.nc
DEBUG 1: Observation File: /opt/storage/high-
speed/EMT2/2011MetData/gdas.42112.2011102100.nc
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Reading data for TMP/Z2.
WARNING:
WARNING: process_fcst_climo_files() -> no fields matching TMP/Z2 found
in file: /opt/storage/high-speed/EMT2/UPPVspace/postprd/WRFPRS_d01.all
WARNING:
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Reading data for TMP/P850.
WARNING:
WARNING: process_fcst_climo_files() -> no fields matching TMP/P850
found in file: /opt/storage/high-
speed/EMT2/UPPVspace/postprd/WRFPRS_d01.all
WARNING:
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
This is how I currently have the variables set in my PointStatConfig
file:
fcst = {
wind_thresh = [ NA ];
message_type = [ "ADPSFC", "ADPUPA" ];
init_time = "20111020_00";
valid_time = "20111021_00";
lead_time = "24";
Based on the files I sent you on Friday, how should I set these three
variables?
Thanks again for your help,
Elliot Tardif, Meteorologist II
NC DENR, Division of Air Quality
Planning Section, Attainment Planning Branch
1641 Mail Service Center
Raleigh, NC 27699-1641
Phone/Fax: 919-707-8483
Email: Elliot.Tardif at ncdenr.gov
Web : http://www.ncair.org
Email correspondence to and from this address is subject to the North
Carolina Public Records Law and may be disclosed to third parties
unless the content is exempt by statue or other regulation.
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Friday, November 22, 2013 4:07 PM
To: Tardif, Elliot M
Subject: Re: [rt.rap.ucar.edu #64405] Issue with wind forecast
verification
Elliot,
Thanks for sending the detailed description of the problem and some
sample data that you're using. I see that you're having trouble
getting the VL1L2 vector partial sums from the Point-Stat tool.
There may be a problem with the WRFPRS_d01.all data file you sent.
When I try to run it through wgrib to inventory it, I get the
following error:
error, could not read to end of record 8461
And when I try to run it through Point-Stat, I get:
GribFile::read() -> file read error ... requested 201498 bytes,
got 123540
Perhaps the file was truncated when you were writing it to our ftp
site. To get around the problem, I used wgrib to extract the first
8460 records from that file. That got me around the error from Point-
Stat. (I'm just now seeing your message that you weren't able to
complete the ftp. So that's the likely source of this problem).
When I ran Point-Stat, I did not get the
"Dictionary::lookup_string_array()" error you saw, but I have a
suggestion. This is the config file that produced that error:
/opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConfig_nc
In that config file, I'm guessing you defined the "fcst" and "obs"
dictionaries separately. And I'll be that you have the "message_type"
setting in the "fcst" dictionary and not in the "obs"
dictionary. It belongs in the "obs" dictionary since it specifying
information about the point observations. Try moving "message_type"
into the "obs" dictionary and see if that error goes away.
So to test things out, I ran the following command:
METv4.1/bin/point_stat \
WRFPRS_d01.all \
gdas.42112.2011092800.nc \
PointStatConfig_emt \
-outdir out \
-log run_ps.log \
-v 4
And like you, I see no VL1L2 lines in the output. This is due to a
rather unfortunate convention we chose a while back. In order to
produce VL1L2 vector partial sums, the UGRD field must be immediately
followed by the VGRD at the same vertical level. That simplifies the
logic so that the code doesn't have to hunt through the config file to
match up UGRD and VGRD pairs. In your config file, UGRD is followed
by VGRD but for 4 different levels, as shown here:
{
name = "UGRD";
level = [ "Z10", "P850", "P700", "P500" ];
cat_thresh = [ >1.0 ];
},
{
name = "VGRD";
level = [ "Z10", "P850", "P700", "P500" ];
cat_thresh = [ >1.0 ];
},
When the code expands this it sees: UGRD/Z10, UGRD/P850, UGRD/P700,
UGRD/P500, VGRD/Z10, VGRD/P850, VGRD/P700, VGRD/P500 So the convention
is not met since UGRD is not followed by VGRD at the same vertical
level. When I remove the first 3 levels, leaving only "P500" and
rerun Point-Stat, I do get VL1L2 partial sums in the output. I order
to get the desired behavior, you'd have to set up the config file like
list:
{ name = "UGRD"; level = ["Z10"]; cat_thresh = [ >1.0 ]; },
{ name = "VGRD"; level = ["Z10"]; cat_thresh = [ >1.0 ]; },
{ name = "UGRD"; level = ["P850"]; cat_thresh = [ >1.0 ]; },
{ name = "VGRD"; level = ["P850"]; cat_thresh = [ >1.0 ]; },
{ name = "UGRD"; level = ["P700"]; cat_thresh = [ >1.0 ]; },
{ name = "VGRD"; level = ["P700"]; cat_thresh = [ >1.0 ]; },
{ name = "UGRD"; level = ["P500"]; cat_thresh = [ >1.0 ]; },
{ name = "VGRD"; level = ["P500"]; cat_thresh = [ >1.0 ]; },
In this way, UGRD is immediately followed by VGRD at the same vertical
level. I realize that's more cumbersome, but it should solve your
problem.
Lastly, I want to mention something about how you've prepared your
data for Point-Stat. You've grouped all the forecast lead times into
a single GRIB file. When I run Point-Stat and verify 500 mb
temperature, for example, I see the following log message:
DEBUG 2: For TMP/P500 found 25 forecast levels and 0 climatology
levels.
Looking at the (truncated) GRIB file you sent, I see 25 records of
temperature at 500 mb, for hourly forecasts from 25 to 36 hours:
wgrib WRFPRS_d01.all | grep TMP | grep "kpds7=500"
Point-Stat is not verifying them one-by-one. Instead it's just using
the first one it finds. If you'd like to organize your data in this
way, you'll need to tell Point-Stat which forecast lead time you'd
like to evaluate. You do this using the "lead_time" setting in the
config file. I see that you have "lead_time" listed in the config
file you sent but it's commented out. If your forecast data is
organized in this way, you should be setting "lead_time".
Hope that helps clarify.
Thanks,
John Halley Gotway
met_help at ucar.edu
On 11/22/2013 12:46 PM, Tardif, Elliot M via RT wrote:
>
> Fri Nov 22 12:46:10 2013: Request 64405 was acted upon.
> Transaction: Ticket created by elliot.tardif at ncdenr.gov
> Queue: met_help
> Subject: Issue with wind forecast verification
> Owner: Nobody
> Requestors: elliot.tardif at ncdenr.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=64405
> >
>
>
> Good afternoon,
>
> I am running Point-stat for an annual WRF model run; the WRF-ARW
data is being fed through UPP to get the forecast data into the proper
format, then "copygb" is used to group the hourly forecast files
together into one big file so I can look at daily verification data
instead of one hour at a time. I am analyzing temperature, dewpoint,
absolute & relative humidity data, and I want to analyze wind data as
well. However, MET will not produce the partial vector sums for wind
(only partial scalar sums), and I want to analyze both wind direction
and speed. I have attempted to work around this problem by running
the WRF data through p_interp (see ticket #64317), to no avail as it
now gives me the following error:
>
> *** Running Point-Stat on EPA WRF data *** DEBUG 1: Default Config
> File:
> /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConf
> ig_default DEBUG 1: User Config File:
> /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConf
> ig_nc
> ERROR :
> ERROR : Dictionary::lookup_string_array() -> lookup failed for name
"message_type"
> ERROR :
>
> I would greatly appreciate any help on getting MET to produce
partial vector sums for wind direction and wind speed verification
analysis, either through running p_interp or UPP. I have sent some
files via ftp, using the instructions given on your website, for your
consideration. I will be happy to answer any questions.
>
> Thanks for your time and have a great weekend,
>
> Elliot Tardif, Meteorologist II
> NC DENR, Division of Air Quality
> Planning Section, Attainment Planning Branch
> 1641 Mail Service Center
> Raleigh, NC 27699-1641
> Phone/Fax: 919-707-8483
> Email: Elliot.Tardif at ncdenr.gov<mailto:Nick.Witcraft at ncdenr.gov>
> Web : http://www.ncair.org<http://www.ncair.org/>
>
> Email correspondence to and from this address is subject to the
North Carolina Public Records Law and may be disclosed to third
parties unless the content is exempt by statue or other regulation.
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #64405] Issue with wind forecast verification
From: Tardif, Elliot M
Time: Mon Nov 25 14:52:14 2013
Good afternoon John, I believe I have found a resolution to the
problem you pointed out to me at the bottom of your reply, regarding
the grouping of the data into one big file. Here is the adjustment I
made in my PointStatConfig file:
fcst = {
wind_thresh = [ NA ];
message_type = [ "ADPSFC", "ADPUPA" ];
init_time = "20111017_12";
valid_time = "20111019_00";
lead_time = "36";
Output:
DEBUG 1: Forecast File: /opt/storage/high-
speed/EMT2/UPPVspace/postprd/WRFPRS_d01.all
DEBUG 1: Climatology File: none
DEBUG 1: Observation File: /opt/storage/high-
speed/EMT2/2011MetData/gdas.42112.2011101900.nc
DEBUG 1: Observation File: /opt/storage/high-
speed/EMT2/2011MetData/gdas.42112.2011101906.nc
DEBUG 1: Observation File: /opt/storage/high-
speed/EMT2/2011MetData/gdas.42112.2011101912.nc
DEBUG 1: Observation File: /opt/storage/high-
speed/EMT2/2011MetData/gdas.42112.2011101918.nc
DEBUG 1: Observation File: /opt/storage/high-
speed/EMT2/2011MetData/gdas.42112.2011102000.nc
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Reading data for TMP/Z2.
DEBUG 2: For TMP/Z2 found 1 forecast levels and 0 climatology levels.
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
DEBUG 2:
DEBUG 2: Reading data for TMP/P850.
DEBUG 2: For TMP/P850 found 1 forecast levels and 0 climatology
levels.
DEBUG 2:
DEBUG 2:
--------------------------------------------------------------------------------
However, resolving this problem has opened up a far larger problem for
me: I discovered that MET is only looking at the first hour's WRF
data across all 24 hours of observation data at each given
verification point (please see the file
"point_stat_360000L_20111019_000000V_mpr.txt" that I have sent to you
via FTP). I want to compare hourly model data versus corresponding
hourly observed data over the course of 24 hours (e.g., 3Z WRF output
vs. ~3Z obs, 9Z WRF output vs. ~9Z obs, etc.), not the same hour of
forecast data against 24 hours of observed data. Is there a way to do
that in MET?
Thanks again for your help,
Elliot Tardif, Meteorologist II
NC DENR, Division of Air Quality
Planning Section, Attainment Planning Branch
1641 Mail Service Center
Raleigh, NC 27699-1641
Phone/Fax: 919-707-8483
Email: Elliot.Tardif at ncdenr.gov
Web : http://www.ncair.org
Email correspondence to and from this address is subject to the North
Carolina Public Records Law and may be disclosed to third parties
unless the content is exempt by statue or other regulation.
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Friday, November 22, 2013 4:07 PM
To: Tardif, Elliot M
Subject: Re: [rt.rap.ucar.edu #64405] Issue with wind forecast
verification
Elliot,
Thanks for sending the detailed description of the problem and some
sample data that you're using. I see that you're having trouble
getting the VL1L2 vector partial sums from the Point-Stat tool.
There may be a problem with the WRFPRS_d01.all data file you sent.
When I try to run it through wgrib to inventory it, I get the
following error:
error, could not read to end of record 8461
And when I try to run it through Point-Stat, I get:
GribFile::read() -> file read error ... requested 201498 bytes,
got 123540
Perhaps the file was truncated when you were writing it to our ftp
site. To get around the problem, I used wgrib to extract the first
8460 records from that file. That got me around the error from Point-
Stat. (I'm just now seeing your message that you weren't able to
complete the ftp. So that's the likely source of this problem).
When I ran Point-Stat, I did not get the
"Dictionary::lookup_string_array()" error you saw, but I have a
suggestion. This is the config file that produced that error:
/opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConfig_nc
In that config file, I'm guessing you defined the "fcst" and "obs"
dictionaries separately. And I'll be that you have the "message_type"
setting in the "fcst" dictionary and not in the "obs"
dictionary. It belongs in the "obs" dictionary since it specifying
information about the point observations. Try moving "message_type"
into the "obs" dictionary and see if that error goes away.
So to test things out, I ran the following command:
METv4.1/bin/point_stat \
WRFPRS_d01.all \
gdas.42112.2011092800.nc \
PointStatConfig_emt \
-outdir out \
-log run_ps.log \
-v 4
And like you, I see no VL1L2 lines in the output. This is due to a
rather unfortunate convention we chose a while back. In order to
produce VL1L2 vector partial sums, the UGRD field must be immediately
followed by the VGRD at the same vertical level. That simplifies the
logic so that the code doesn't have to hunt through the config file to
match up UGRD and VGRD pairs. In your config file, UGRD is followed
by VGRD but for 4 different levels, as shown here:
{
name = "UGRD";
level = [ "Z10", "P850", "P700", "P500" ];
cat_thresh = [ >1.0 ];
},
{
name = "VGRD";
level = [ "Z10", "P850", "P700", "P500" ];
cat_thresh = [ >1.0 ];
},
When the code expands this it sees: UGRD/Z10, UGRD/P850, UGRD/P700,
UGRD/P500, VGRD/Z10, VGRD/P850, VGRD/P700, VGRD/P500 So the convention
is not met since UGRD is not followed by VGRD at the same vertical
level. When I remove the first 3 levels, leaving only "P500" and
rerun Point-Stat, I do get VL1L2 partial sums in the output. I order
to get the desired behavior, you'd have to set up the config file like
list:
{ name = "UGRD"; level = ["Z10"]; cat_thresh = [ >1.0 ]; },
{ name = "VGRD"; level = ["Z10"]; cat_thresh = [ >1.0 ]; },
{ name = "UGRD"; level = ["P850"]; cat_thresh = [ >1.0 ]; },
{ name = "VGRD"; level = ["P850"]; cat_thresh = [ >1.0 ]; },
{ name = "UGRD"; level = ["P700"]; cat_thresh = [ >1.0 ]; },
{ name = "VGRD"; level = ["P700"]; cat_thresh = [ >1.0 ]; },
{ name = "UGRD"; level = ["P500"]; cat_thresh = [ >1.0 ]; },
{ name = "VGRD"; level = ["P500"]; cat_thresh = [ >1.0 ]; },
In this way, UGRD is immediately followed by VGRD at the same vertical
level. I realize that's more cumbersome, but it should solve your
problem.
Lastly, I want to mention something about how you've prepared your
data for Point-Stat. You've grouped all the forecast lead times into
a single GRIB file. When I run Point-Stat and verify 500 mb
temperature, for example, I see the following log message:
DEBUG 2: For TMP/P500 found 25 forecast levels and 0 climatology
levels.
Looking at the (truncated) GRIB file you sent, I see 25 records of
temperature at 500 mb, for hourly forecasts from 25 to 36 hours:
wgrib WRFPRS_d01.all | grep TMP | grep "kpds7=500"
Point-Stat is not verifying them one-by-one. Instead it's just using
the first one it finds. If you'd like to organize your data in this
way, you'll need to tell Point-Stat which forecast lead time you'd
like to evaluate. You do this using the "lead_time" setting in the
config file. I see that you have "lead_time" listed in the config
file you sent but it's commented out. If your forecast data is
organized in this way, you should be setting "lead_time".
Hope that helps clarify.
Thanks,
John Halley Gotway
met_help at ucar.edu
On 11/22/2013 12:46 PM, Tardif, Elliot M via RT wrote:
>
> Fri Nov 22 12:46:10 2013: Request 64405 was acted upon.
> Transaction: Ticket created by elliot.tardif at ncdenr.gov
> Queue: met_help
> Subject: Issue with wind forecast verification
> Owner: Nobody
> Requestors: elliot.tardif at ncdenr.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=64405
> >
>
>
> Good afternoon,
>
> I am running Point-stat for an annual WRF model run; the WRF-ARW
data is being fed through UPP to get the forecast data into the proper
format, then "copygb" is used to group the hourly forecast files
together into one big file so I can look at daily verification data
instead of one hour at a time. I am analyzing temperature, dewpoint,
absolute & relative humidity data, and I want to analyze wind data as
well. However, MET will not produce the partial vector sums for wind
(only partial scalar sums), and I want to analyze both wind direction
and speed. I have attempted to work around this problem by running
the WRF data through p_interp (see ticket #64317), to no avail as it
now gives me the following error:
>
> *** Running Point-Stat on EPA WRF data *** DEBUG 1: Default Config
> File:
> /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConf
> ig_default DEBUG 1: User Config File:
> /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConf
> ig_nc
> ERROR :
> ERROR : Dictionary::lookup_string_array() -> lookup failed for name
"message_type"
> ERROR :
>
> I would greatly appreciate any help on getting MET to produce
partial vector sums for wind direction and wind speed verification
analysis, either through running p_interp or UPP. I have sent some
files via ftp, using the instructions given on your website, for your
consideration. I will be happy to answer any questions.
>
> Thanks for your time and have a great weekend,
>
> Elliot Tardif, Meteorologist II
> NC DENR, Division of Air Quality
> Planning Section, Attainment Planning Branch
> 1641 Mail Service Center
> Raleigh, NC 27699-1641
> Phone/Fax: 919-707-8483
> Email: Elliot.Tardif at ncdenr.gov<mailto:Nick.Witcraft at ncdenr.gov>
> Web : http://www.ncair.org<http://www.ncair.org/>
>
> Email correspondence to and from this address is subject to the
North Carolina Public Records Law and may be disclosed to third
parties unless the content is exempt by statue or other regulation.
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #64405] Issue with wind forecast verification
From: John Halley Gotway
Time: Mon Nov 25 20:55:44 2013
Elliot,
Using the data you sent last week, I added the following to the Point-
Stat
config file...
init_time = "20110927_12";
valid_time = "20110929_00";
lead_time = "36";
That results in a single GRIB record being found. For example, here's
some log output showing that it found a single record:
DEBUG 2: Reading data for TMP/P500.
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found range match for
VarInfo "TMP/P500" in GRIB record 8386 of GRIB file "WRFPRS_d01.all".
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found 1 GRIB records
matching VarInfo "TMP/P500" in GRIB file "WRFPRS_d01.all".
DEBUG 2: For TMP/P500 found 1 forecast levels and 0 climatology
levels.
However, specifying all 3 of these settings is overkill. All you
really
need to specify is "lead_time" since that what varies from record to
record. Just specifying the lead_time is sufficient:
lead_time = "36";
That results in a single GRIB record being found.
As for verifying all of the forecast hours in your GRIB file, you have
two
options.
(1) You could set up the config file to explicitly list all the
forecast
variables, levels, and lead times you'd like to evaluate. But this
would
make for a very *LONG* config file. For example, for 500mb TMP, you'd
list:
{ name = "TMP"; level = "P500"; fcst_lead = "00"; },
{ name = "TMP"; level = "P500"; fcst_lead = "03"; },
{ name = "TMP"; level = "P500"; fcst_lead = "06"; },
... and so on for all lead times in your file!
Since you have a lot of variables/levels/lead times, that'd make a
really
long config file.
(2) I think that the second option is easier. Just set the lead_time
using an environment variable like this:
lead_time = "${FCST_LEAD_TIME}";
Then call Point-Stat from a script that loops through the lead times
you'd
like to evaluate. Before calling Point-Stat, set the FCST_LEAD_TIME
environment variable. So you'll be calling Point-Stat once for each
lead
time and changing the "FCST_LEAD_TIME" environment variable each time.
Now, when Point-Stat finds a GRIB record to be evaluated, it extracts
the
valid time from that record. Then it uses the "obs_window" setting to
define a verifying time window. Here's that setting from the data you
sent:
obs_window = {
beg = -600;
end = 600;
}
So Point-Stat will only use observations that fall within +/- 10
minutes
(i.e. +/- 600 seconds) around the valid time of the forecast being
evaluated. That sounds like a pretty reasonable setting to me.
Hope that helps clarify.
Thanks,
John
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=64405 >
>
> Good afternoon John, I believe I have found a resolution to the
problem
> you pointed out to me at the bottom of your reply, regarding the
grouping
> of the data into one big file. Here is the adjustment I made in my
> PointStatConfig file:
>
> fcst = {
> wind_thresh = [ NA ];
> message_type = [ "ADPSFC", "ADPUPA" ];
> init_time = "20111017_12";
> valid_time = "20111019_00";
> lead_time = "36";
>
> Output:
> DEBUG 1: Forecast File:
> /opt/storage/high-speed/EMT2/UPPVspace/postprd/WRFPRS_d01.all
> DEBUG 1: Climatology File: none
> DEBUG 1: Observation File:
> /opt/storage/high-speed/EMT2/2011MetData/gdas.42112.2011101900.nc
> DEBUG 1: Observation File:
> /opt/storage/high-speed/EMT2/2011MetData/gdas.42112.2011101906.nc
> DEBUG 1: Observation File:
> /opt/storage/high-speed/EMT2/2011MetData/gdas.42112.2011101912.nc
> DEBUG 1: Observation File:
> /opt/storage/high-speed/EMT2/2011MetData/gdas.42112.2011101918.nc
> DEBUG 1: Observation File:
> /opt/storage/high-speed/EMT2/2011MetData/gdas.42112.2011102000.nc
> DEBUG 2:
> DEBUG 2:
>
--------------------------------------------------------------------------------
> DEBUG 2:
> DEBUG 2: Reading data for TMP/Z2.
> DEBUG 2: For TMP/Z2 found 1 forecast levels and 0 climatology
levels.
> DEBUG 2:
> DEBUG 2:
>
--------------------------------------------------------------------------------
> DEBUG 2:
> DEBUG 2: Reading data for TMP/P850.
> DEBUG 2: For TMP/P850 found 1 forecast levels and 0 climatology
levels.
> DEBUG 2:
> DEBUG 2:
>
--------------------------------------------------------------------------------
>
> However, resolving this problem has opened up a far larger problem
for me:
> I discovered that MET is only looking at the first hour's WRF data
across
> all 24 hours of observation data at each given verification point
(please
> see the file "point_stat_360000L_20111019_000000V_mpr.txt" that I
have
> sent to you via FTP). I want to compare hourly model data versus
> corresponding hourly observed data over the course of 24 hours
(e.g., 3Z
> WRF output vs. ~3Z obs, 9Z WRF output vs. ~9Z obs, etc.), not the
same
> hour of forecast data against 24 hours of observed data. Is there a
way
> to do that in MET?
>
> Thanks again for your help,
>
> Elliot Tardif, Meteorologist II
> NC DENR, Division of Air Quality
> Planning Section, Attainment Planning Branch
> 1641 Mail Service Center
> Raleigh, NC 27699-1641
> Phone/Fax:Â 919-707-8483
> Email:Â Elliot.Tardif at ncdenr.gov
> Web : http://www.ncair.org
>
> Email correspondence to and from this address is subject to the
North
> Carolina Public Records Law and may be disclosed to third parties
unless
> the content is exempt by statue or other regulation.
>
>
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Friday, November 22, 2013 4:07 PM
> To: Tardif, Elliot M
> Subject: Re: [rt.rap.ucar.edu #64405] Issue with wind forecast
> verification
>
> Elliot,
>
> Thanks for sending the detailed description of the problem and some
sample
> data that you're using. I see that you're having trouble getting
the
> VL1L2 vector partial sums from the Point-Stat tool.
>
> There may be a problem with the WRFPRS_d01.all data file you sent.
When I
> try to run it through wgrib to inventory it, I get the following
error:
> error, could not read to end of record 8461
>
> And when I try to run it through Point-Stat, I get:
> GribFile::read() -> file read error ... requested 201498 bytes,
got
> 123540
>
> Perhaps the file was truncated when you were writing it to our ftp
site.
> To get around the problem, I used wgrib to extract the first 8460
records
> from that file. That got me around the error from Point-Stat. (I'm
just
> now seeing your message that you weren't able to complete the ftp.
So
> that's the likely source of this problem).
>
> When I ran Point-Stat, I did not get the
> "Dictionary::lookup_string_array()" error you saw, but I have a
> suggestion. This is the config file that produced that error:
> /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConfig_nc
>
> In that config file, I'm guessing you defined the "fcst" and "obs"
> dictionaries separately. And I'll be that you have the
"message_type"
> setting in the "fcst" dictionary and not in the "obs"
> dictionary. It belongs in the "obs" dictionary since it specifying
> information about the point observations. Try moving "message_type"
into
> the "obs" dictionary and see if that error goes away.
>
> So to test things out, I ran the following command:
> METv4.1/bin/point_stat \
> WRFPRS_d01.all \
> gdas.42112.2011092800.nc \
> PointStatConfig_emt \
> -outdir out \
> -log run_ps.log \
> -v 4
>
> And like you, I see no VL1L2 lines in the output. This is due to a
rather
> unfortunate convention we chose a while back. In order to produce
VL1L2
> vector partial sums, the UGRD field must be immediately followed by
the
> VGRD at the same vertical level. That simplifies the logic so that
the
> code doesn't have to hunt through the config file to match up UGRD
and
> VGRD pairs. In your config file, UGRD is followed by VGRD but for 4
> different levels, as shown here:
> {
> name = "UGRD";
> level = [ "Z10", "P850", "P700", "P500" ];
> cat_thresh = [ >1.0 ];
> },
>
> {
> name = "VGRD";
> level = [ "Z10", "P850", "P700", "P500" ];
> cat_thresh = [ >1.0 ];
> },
>
> When the code expands this it sees: UGRD/Z10, UGRD/P850, UGRD/P700,
> UGRD/P500, VGRD/Z10, VGRD/P850, VGRD/P700, VGRD/P500 So the
convention is
> not met since UGRD is not followed by VGRD at the same vertical
level.
> When I remove the first 3 levels, leaving only "P500" and rerun
> Point-Stat, I do get VL1L2 partial sums in the output. I order to
get the
> desired behavior, you'd have to set up the config file like list:
> { name = "UGRD"; level = ["Z10"]; cat_thresh = [ >1.0 ]; },
> { name = "VGRD"; level = ["Z10"]; cat_thresh = [ >1.0 ]; },
> { name = "UGRD"; level = ["P850"]; cat_thresh = [ >1.0 ]; },
> { name = "VGRD"; level = ["P850"]; cat_thresh = [ >1.0 ]; },
> { name = "UGRD"; level = ["P700"]; cat_thresh = [ >1.0 ]; },
> { name = "VGRD"; level = ["P700"]; cat_thresh = [ >1.0 ]; },
> { name = "UGRD"; level = ["P500"]; cat_thresh = [ >1.0 ]; },
> { name = "VGRD"; level = ["P500"]; cat_thresh = [ >1.0 ]; },
>
> In this way, UGRD is immediately followed by VGRD at the same
vertical
> level. I realize that's more cumbersome, but it should solve your
> problem.
>
> Lastly, I want to mention something about how you've prepared your
data
> for Point-Stat. You've grouped all the forecast lead times into a
single
> GRIB file. When I run Point-Stat and verify 500 mb temperature, for
> example, I see the following log message:
> DEBUG 2: For TMP/P500 found 25 forecast levels and 0 climatology
> levels.
>
> Looking at the (truncated) GRIB file you sent, I see 25 records of
> temperature at 500 mb, for hourly forecasts from 25 to 36 hours:
> wgrib WRFPRS_d01.all | grep TMP | grep "kpds7=500"
>
> Point-Stat is not verifying them one-by-one. Instead it's just
using the
> first one it finds. If you'd like to organize your data in this
way,
> you'll need to tell Point-Stat which forecast lead time you'd like
to
> evaluate. You do this using the "lead_time" setting in the config
file.
> I see that you have "lead_time" listed in the config file you sent
but
> it's commented out. If your forecast data is organized in this way,
you
> should be setting "lead_time".
>
> Hope that helps clarify.
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu
>
> On 11/22/2013 12:46 PM, Tardif, Elliot M via RT wrote:
>>
>> Fri Nov 22 12:46:10 2013: Request 64405 was acted upon.
>> Transaction: Ticket created by elliot.tardif at ncdenr.gov
>> Queue: met_help
>> Subject: Issue with wind forecast verification
>> Owner: Nobody
>> Requestors: elliot.tardif at ncdenr.gov
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=64405
>> >
>>
>>
>> Good afternoon,
>>
>> I am running Point-stat for an annual WRF model run; the WRF-ARW
data is
>> being fed through UPP to get the forecast data into the proper
format,
>> then "copygb" is used to group the hourly forecast files together
into
>> one big file so I can look at daily verification data instead of
one
>> hour at a time. I am analyzing temperature, dewpoint, absolute &
>> relative humidity data, and I want to analyze wind data as well.
>> However, MET will not produce the partial vector sums for wind
(only
>> partial scalar sums), and I want to analyze both wind direction and
>> speed. I have attempted to work around this problem by running the
WRF
>> data through p_interp (see ticket #64317), to no avail as it now
gives
>> me the following error:
>>
>> *** Running Point-Stat on EPA WRF data *** DEBUG 1: Default Config
>> File:
>> /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConf
>> ig_default DEBUG 1: User Config File:
>> /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConf
>> ig_nc
>> ERROR :
>> ERROR : Dictionary::lookup_string_array() -> lookup failed for
name
>> "message_type"
>> ERROR :
>>
>> I would greatly appreciate any help on getting MET to produce
partial
>> vector sums for wind direction and wind speed verification
analysis,
>> either through running p_interp or UPP. I have sent some files via
ftp,
>> using the instructions given on your website, for your
consideration. I
>> will be happy to answer any questions.
>>
>> Thanks for your time and have a great weekend,
>>
>> Elliot Tardif, Meteorologist II
>> NC DENR, Division of Air Quality
>> Planning Section, Attainment Planning Branch
>> 1641 Mail Service Center
>> Raleigh, NC 27699-1641
>> Phone/Fax: 919-707-8483
>> Email: Elliot.Tardif at ncdenr.gov<mailto:Nick.Witcraft at ncdenr.gov>
>> Web : http://www.ncair.org<http://www.ncair.org/>
>>
>> Email correspondence to and from this address is subject to the
North
>> Carolina Public Records Law and may be disclosed to third parties
unless
>> the content is exempt by statue or other regulation.
>>
>
>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #64405] Issue with wind forecast verification
From: Tardif, Elliot M
Time: Tue Nov 26 15:49:06 2013
Good afternoon John,
After some re-working of my scripts using the advice you gave below, I
am able to get hourly MET data, and I will group the hourly output
together later either using Stat Analysis or in Excel, so I can get
the daily, monthly and annual verification values that I am seeking.
The "mpr" file showed that I was looking at verification across the
same timeframe for both forecast and observed data sets. I have
discontinued stitching together all of the hourly output files from
UPP using the copygb utility; instead, I am working with the smaller
hourly files from UPP, which is helping MET to move along very
quickly.
Thanks very much for your patience and assistance John, and have a
great Thanksgiving!
Best Regards,
Elliot Tardif, Meteorologist II
NC DENR, Division of Air Quality
Planning Section, Attainment Planning Branch
1641 Mail Service Center
Raleigh, NC 27699-1641
Phone/Fax: 919-707-8483
Email: Elliot.Tardif at ncdenr.gov
Web : http://www.ncair.org
Email correspondence to and from this address is subject to the North
Carolina Public Records Law and may be disclosed to third parties
unless the content is exempt by statue or other regulation.
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Monday, November 25, 2013 10:56 PM
To: Tardif, Elliot M
Subject: RE: [rt.rap.ucar.edu #64405] Issue with wind forecast
verification
Elliot,
Using the data you sent last week, I added the following to the Point-
Stat config file...
init_time = "20110927_12";
valid_time = "20110929_00";
lead_time = "36";
That results in a single GRIB record being found. For example, here's
some log output showing that it found a single record:
DEBUG 2: Reading data for TMP/P500.
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found range match for
VarInfo "TMP/P500" in GRIB record 8386 of GRIB file "WRFPRS_d01.all".
DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found 1 GRIB records
matching VarInfo "TMP/P500" in GRIB file "WRFPRS_d01.all".
DEBUG 2: For TMP/P500 found 1 forecast levels and 0 climatology
levels.
However, specifying all 3 of these settings is overkill. All you
really need to specify is "lead_time" since that what varies from
record to record. Just specifying the lead_time is sufficient:
lead_time = "36";
That results in a single GRIB record being found.
As for verifying all of the forecast hours in your GRIB file, you have
two options.
(1) You could set up the config file to explicitly list all the
forecast variables, levels, and lead times you'd like to evaluate.
But this would make for a very *LONG* config file. For example, for
500mb TMP, you'd
list:
{ name = "TMP"; level = "P500"; fcst_lead = "00"; },
{ name = "TMP"; level = "P500"; fcst_lead = "03"; },
{ name = "TMP"; level = "P500"; fcst_lead = "06"; },
... and so on for all lead times in your file!
Since you have a lot of variables/levels/lead times, that'd make a
really long config file.
(2) I think that the second option is easier. Just set the lead_time
using an environment variable like this:
lead_time = "${FCST_LEAD_TIME}";
Then call Point-Stat from a script that loops through the lead times
you'd like to evaluate. Before calling Point-Stat, set the
FCST_LEAD_TIME environment variable. So you'll be calling Point-Stat
once for each lead time and changing the "FCST_LEAD_TIME" environment
variable each time.
Now, when Point-Stat finds a GRIB record to be evaluated, it extracts
the valid time from that record. Then it uses the "obs_window"
setting to define a verifying time window. Here's that setting from
the data you
sent:
obs_window = {
beg = -600;
end = 600;
}
So Point-Stat will only use observations that fall within +/- 10
minutes (i.e. +/- 600 seconds) around the valid time of the forecast
being evaluated. That sounds like a pretty reasonable setting to me.
Hope that helps clarify.
Thanks,
John
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=64405 >
>
> Good afternoon John, I believe I have found a resolution to the
> problem you pointed out to me at the bottom of your reply, regarding
> the grouping of the data into one big file. Here is the adjustment
I
> made in my PointStatConfig file:
>
> fcst = {
> wind_thresh = [ NA ];
> message_type = [ "ADPSFC", "ADPUPA" ];
> init_time = "20111017_12";
> valid_time = "20111019_00";
> lead_time = "36";
>
> Output:
> DEBUG 1: Forecast File:
> /opt/storage/high-speed/EMT2/UPPVspace/postprd/WRFPRS_d01.all
> DEBUG 1: Climatology File: none
> DEBUG 1: Observation File:
> /opt/storage/high-speed/EMT2/2011MetData/gdas.42112.2011101900.nc
> DEBUG 1: Observation File:
> /opt/storage/high-speed/EMT2/2011MetData/gdas.42112.2011101906.nc
> DEBUG 1: Observation File:
> /opt/storage/high-speed/EMT2/2011MetData/gdas.42112.2011101912.nc
> DEBUG 1: Observation File:
> /opt/storage/high-speed/EMT2/2011MetData/gdas.42112.2011101918.nc
> DEBUG 1: Observation File:
> /opt/storage/high-speed/EMT2/2011MetData/gdas.42112.2011102000.nc
> DEBUG 2:
> DEBUG 2:
>
----------------------------------------------------------------------
> ----------
> DEBUG 2:
> DEBUG 2: Reading data for TMP/Z2.
> DEBUG 2: For TMP/Z2 found 1 forecast levels and 0 climatology
levels.
> DEBUG 2:
> DEBUG 2:
>
----------------------------------------------------------------------
> ----------
> DEBUG 2:
> DEBUG 2: Reading data for TMP/P850.
> DEBUG 2: For TMP/P850 found 1 forecast levels and 0 climatology
levels.
> DEBUG 2:
> DEBUG 2:
>
----------------------------------------------------------------------
> ----------
>
> However, resolving this problem has opened up a far larger problem
for me:
> I discovered that MET is only looking at the first hour's WRF data
> across all 24 hours of observation data at each given verification
> point (please see the file
> "point_stat_360000L_20111019_000000V_mpr.txt" that I have sent to
you
> via FTP). I want to compare hourly model data versus corresponding
> hourly observed data over the course of 24 hours (e.g., 3Z WRF
output
> vs. ~3Z obs, 9Z WRF output vs. ~9Z obs, etc.), not the same hour of
> forecast data against 24 hours of observed data. Is there a way to
do that in MET?
>
> Thanks again for your help,
>
> Elliot Tardif, Meteorologist II
> NC DENR, Division of Air Quality
> Planning Section, Attainment Planning Branch
> 1641 Mail Service Center
> Raleigh, NC 27699-1641
> Phone/Fax:Â 919-707-8483
> Email:Â Elliot.Tardif at ncdenr.gov
> Web : http://www.ncair.org
>
> Email correspondence to and from this address is subject to the
North
> Carolina Public Records Law and may be disclosed to third parties
> unless the content is exempt by statue or other regulation.
>
>
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Friday, November 22, 2013 4:07 PM
> To: Tardif, Elliot M
> Subject: Re: [rt.rap.ucar.edu #64405] Issue with wind forecast
> verification
>
> Elliot,
>
> Thanks for sending the detailed description of the problem and some
> sample data that you're using. I see that you're having trouble
> getting the
> VL1L2 vector partial sums from the Point-Stat tool.
>
> There may be a problem with the WRFPRS_d01.all data file you sent.
> When I try to run it through wgrib to inventory it, I get the
following error:
> error, could not read to end of record 8461
>
> And when I try to run it through Point-Stat, I get:
> GribFile::read() -> file read error ... requested 201498 bytes,
> got
> 123540
>
> Perhaps the file was truncated when you were writing it to our ftp
site.
> To get around the problem, I used wgrib to extract the first 8460
> records from that file. That got me around the error from Point-
Stat.
> (I'm just now seeing your message that you weren't able to complete
> the ftp. So that's the likely source of this problem).
>
> When I ran Point-Stat, I did not get the
> "Dictionary::lookup_string_array()" error you saw, but I have a
> suggestion. This is the config file that produced that error:
>
> /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConf
> ig_nc
>
> In that config file, I'm guessing you defined the "fcst" and "obs"
> dictionaries separately. And I'll be that you have the
"message_type"
> setting in the "fcst" dictionary and not in the "obs"
> dictionary. It belongs in the "obs" dictionary since it specifying
> information about the point observations. Try moving "message_type"
> into the "obs" dictionary and see if that error goes away.
>
> So to test things out, I ran the following command:
> METv4.1/bin/point_stat \
> WRFPRS_d01.all \
> gdas.42112.2011092800.nc \
> PointStatConfig_emt \
> -outdir out \
> -log run_ps.log \
> -v 4
>
> And like you, I see no VL1L2 lines in the output. This is due to a
> rather unfortunate convention we chose a while back. In order to
> produce VL1L2 vector partial sums, the UGRD field must be
immediately
> followed by the VGRD at the same vertical level. That simplifies
the
> logic so that the code doesn't have to hunt through the config file
to
> match up UGRD and VGRD pairs. In your config file, UGRD is followed
> by VGRD but for 4 different levels, as shown here:
> {
> name = "UGRD";
> level = [ "Z10", "P850", "P700", "P500" ];
> cat_thresh = [ >1.0 ];
> },
>
> {
> name = "VGRD";
> level = [ "Z10", "P850", "P700", "P500" ];
> cat_thresh = [ >1.0 ];
> },
>
> When the code expands this it sees: UGRD/Z10, UGRD/P850, UGRD/P700,
> UGRD/P500, VGRD/Z10, VGRD/P850, VGRD/P700, VGRD/P500 So the
convention
> is not met since UGRD is not followed by VGRD at the same vertical
level.
> When I remove the first 3 levels, leaving only "P500" and rerun
> Point-Stat, I do get VL1L2 partial sums in the output. I order to
get
> the desired behavior, you'd have to set up the config file like
list:
> { name = "UGRD"; level = ["Z10"]; cat_thresh = [ >1.0 ]; },
> { name = "VGRD"; level = ["Z10"]; cat_thresh = [ >1.0 ]; },
> { name = "UGRD"; level = ["P850"]; cat_thresh = [ >1.0 ]; },
> { name = "VGRD"; level = ["P850"]; cat_thresh = [ >1.0 ]; },
> { name = "UGRD"; level = ["P700"]; cat_thresh = [ >1.0 ]; },
> { name = "VGRD"; level = ["P700"]; cat_thresh = [ >1.0 ]; },
> { name = "UGRD"; level = ["P500"]; cat_thresh = [ >1.0 ]; },
> { name = "VGRD"; level = ["P500"]; cat_thresh = [ >1.0 ]; },
>
> In this way, UGRD is immediately followed by VGRD at the same
vertical
> level. I realize that's more cumbersome, but it should solve your
> problem.
>
> Lastly, I want to mention something about how you've prepared your
> data for Point-Stat. You've grouped all the forecast lead times
into
> a single GRIB file. When I run Point-Stat and verify 500 mb
> temperature, for example, I see the following log message:
> DEBUG 2: For TMP/P500 found 25 forecast levels and 0 climatology
> levels.
>
> Looking at the (truncated) GRIB file you sent, I see 25 records of
> temperature at 500 mb, for hourly forecasts from 25 to 36 hours:
> wgrib WRFPRS_d01.all | grep TMP | grep "kpds7=500"
>
> Point-Stat is not verifying them one-by-one. Instead it's just
using
> the first one it finds. If you'd like to organize your data in this
> way, you'll need to tell Point-Stat which forecast lead time you'd
> like to evaluate. You do this using the "lead_time" setting in the
config file.
> I see that you have "lead_time" listed in the config file you sent
but
> it's commented out. If your forecast data is organized in this way,
> you should be setting "lead_time".
>
> Hope that helps clarify.
>
> Thanks,
> John Halley Gotway
> met_help at ucar.edu
>
> On 11/22/2013 12:46 PM, Tardif, Elliot M via RT wrote:
>>
>> Fri Nov 22 12:46:10 2013: Request 64405 was acted upon.
>> Transaction: Ticket created by elliot.tardif at ncdenr.gov
>> Queue: met_help
>> Subject: Issue with wind forecast verification
>> Owner: Nobody
>> Requestors: elliot.tardif at ncdenr.gov
>> Status: new
>> Ticket <URL:
>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=64405
>> >
>>
>>
>> Good afternoon,
>>
>> I am running Point-stat for an annual WRF model run; the WRF-ARW
data
>> is being fed through UPP to get the forecast data into the proper
>> format, then "copygb" is used to group the hourly forecast files
>> together into one big file so I can look at daily verification data
>> instead of one hour at a time. I am analyzing temperature,
dewpoint,
>> absolute & relative humidity data, and I want to analyze wind data
as well.
>> However, MET will not produce the partial vector sums for wind
(only
>> partial scalar sums), and I want to analyze both wind direction and
>> speed. I have attempted to work around this problem by running the
>> WRF data through p_interp (see ticket #64317), to no avail as it
now
>> gives me the following error:
>>
>> *** Running Point-Stat on EPA WRF data *** DEBUG 1: Default Config
>> File:
>> /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatCon
>> f ig_default DEBUG 1: User Config File:
>> /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatCon
>> f
>> ig_nc
>> ERROR :
>> ERROR : Dictionary::lookup_string_array() -> lookup failed for
name
>> "message_type"
>> ERROR :
>>
>> I would greatly appreciate any help on getting MET to produce
partial
>> vector sums for wind direction and wind speed verification
analysis,
>> either through running p_interp or UPP. I have sent some files via
>> ftp, using the instructions given on your website, for your
>> consideration. I will be happy to answer any questions.
>>
>> Thanks for your time and have a great weekend,
>>
>> Elliot Tardif, Meteorologist II
>> NC DENR, Division of Air Quality
>> Planning Section, Attainment Planning Branch
>> 1641 Mail Service Center
>> Raleigh, NC 27699-1641
>> Phone/Fax: 919-707-8483
>> Email: Elliot.Tardif at ncdenr.gov<mailto:Nick.Witcraft at ncdenr.gov>
>> Web : http://www.ncair.org<http://www.ncair.org/>
>>
>> Email correspondence to and from this address is subject to the
North
>> Carolina Public Records Law and may be disclosed to third parties
>> unless the content is exempt by statue or other regulation.
>>
>
>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #64405] Issue with wind forecast verification
From: John Halley Gotway
Time: Wed Nov 27 14:55:48 2013
Elliot,
Great, glad you were able to figure it out. Happy Thanksgiving to you
as
well. Just let us know if you have any more questions or issues in
your
use of MET.
Thanks,
John
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=64405 >
>
> Good afternoon John,
>
> After some re-working of my scripts using the advice you gave below,
I am
> able to get hourly MET data, and I will group the hourly output
together
> later either using Stat Analysis or in Excel, so I can get the
daily,
> monthly and annual verification values that I am seeking. The "mpr"
file
> showed that I was looking at verification across the same timeframe
for
> both forecast and observed data sets. I have discontinued stitching
> together all of the hourly output files from UPP using the copygb
utility;
> instead, I am working with the smaller hourly files from UPP, which
is
> helping MET to move along very quickly.
>
> Thanks very much for your patience and assistance John, and have a
great
> Thanksgiving!
>
> Best Regards,
>
> Elliot Tardif, Meteorologist II
> NC DENR, Division of Air Quality
> Planning Section, Attainment Planning Branch
> 1641 Mail Service Center
> Raleigh, NC 27699-1641
> Phone/Fax:Â 919-707-8483
> Email:Â Elliot.Tardif at ncdenr.gov
> Web : http://www.ncair.org
>
> Email correspondence to and from this address is subject to the
North
> Carolina Public Records Law and may be disclosed to third parties
unless
> the content is exempt by statue or other regulation.
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Monday, November 25, 2013 10:56 PM
> To: Tardif, Elliot M
> Subject: RE: [rt.rap.ucar.edu #64405] Issue with wind forecast
> verification
>
> Elliot,
>
> Using the data you sent last week, I added the following to the
Point-Stat
> config file...
>
> init_time = "20110927_12";
> valid_time = "20110929_00";
> lead_time = "36";
>
> That results in a single GRIB record being found. For example,
here's
> some log output showing that it found a single record:
>
> DEBUG 2: Reading data for TMP/P500.
> DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found range match
for
> VarInfo "TMP/P500" in GRIB record 8386 of GRIB file
"WRFPRS_d01.all".
> DEBUG 3: MetGrib1DataFile::data_plane_array() -> Found 1 GRIB
records
> matching VarInfo "TMP/P500" in GRIB file "WRFPRS_d01.all".
> DEBUG 2: For TMP/P500 found 1 forecast levels and 0 climatology
levels.
>
> However, specifying all 3 of these settings is overkill. All you
really
> need to specify is "lead_time" since that what varies from record to
> record. Just specifying the lead_time is sufficient:
> lead_time = "36";
> That results in a single GRIB record being found.
>
> As for verifying all of the forecast hours in your GRIB file, you
have two
> options.
> (1) You could set up the config file to explicitly list all the
forecast
> variables, levels, and lead times you'd like to evaluate. But this
would
> make for a very *LONG* config file. For example, for 500mb TMP,
you'd
> list:
> { name = "TMP"; level = "P500"; fcst_lead = "00"; },
> { name = "TMP"; level = "P500"; fcst_lead = "03"; },
> { name = "TMP"; level = "P500"; fcst_lead = "06"; },
> ... and so on for all lead times in your file!
> Since you have a lot of variables/levels/lead times, that'd make a
really
> long config file.
>
> (2) I think that the second option is easier. Just set the
lead_time
> using an environment variable like this:
> lead_time = "${FCST_LEAD_TIME}";
> Then call Point-Stat from a script that loops through the lead times
you'd
> like to evaluate. Before calling Point-Stat, set the FCST_LEAD_TIME
> environment variable. So you'll be calling Point-Stat once for each
lead
> time and changing the "FCST_LEAD_TIME" environment variable each
time.
>
> Now, when Point-Stat finds a GRIB record to be evaluated, it
extracts the
> valid time from that record. Then it uses the "obs_window" setting
to
> define a verifying time window. Here's that setting from the data
you
> sent:
> obs_window = {
> beg = -600;
> end = 600;
> }
> So Point-Stat will only use observations that fall within +/- 10
minutes
> (i.e. +/- 600 seconds) around the valid time of the forecast being
> evaluated. That sounds like a pretty reasonable setting to me.
>
> Hope that helps clarify.
>
> Thanks,
> John
>
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=64405 >
>>
>> Good afternoon John, I believe I have found a resolution to the
>> problem you pointed out to me at the bottom of your reply,
regarding
>> the grouping of the data into one big file. Here is the adjustment
I
>> made in my PointStatConfig file:
>>
>> fcst = {
>> wind_thresh = [ NA ];
>> message_type = [ "ADPSFC", "ADPUPA" ];
>> init_time = "20111017_12";
>> valid_time = "20111019_00";
>> lead_time = "36";
>>
>> Output:
>> DEBUG 1: Forecast File:
>> /opt/storage/high-speed/EMT2/UPPVspace/postprd/WRFPRS_d01.all
>> DEBUG 1: Climatology File: none
>> DEBUG 1: Observation File:
>> /opt/storage/high-speed/EMT2/2011MetData/gdas.42112.2011101900.nc
>> DEBUG 1: Observation File:
>> /opt/storage/high-speed/EMT2/2011MetData/gdas.42112.2011101906.nc
>> DEBUG 1: Observation File:
>> /opt/storage/high-speed/EMT2/2011MetData/gdas.42112.2011101912.nc
>> DEBUG 1: Observation File:
>> /opt/storage/high-speed/EMT2/2011MetData/gdas.42112.2011101918.nc
>> DEBUG 1: Observation File:
>> /opt/storage/high-speed/EMT2/2011MetData/gdas.42112.2011102000.nc
>> DEBUG 2:
>> DEBUG 2:
>>
----------------------------------------------------------------------
>> ----------
>> DEBUG 2:
>> DEBUG 2: Reading data for TMP/Z2.
>> DEBUG 2: For TMP/Z2 found 1 forecast levels and 0 climatology
levels.
>> DEBUG 2:
>> DEBUG 2:
>>
----------------------------------------------------------------------
>> ----------
>> DEBUG 2:
>> DEBUG 2: Reading data for TMP/P850.
>> DEBUG 2: For TMP/P850 found 1 forecast levels and 0 climatology
levels.
>> DEBUG 2:
>> DEBUG 2:
>>
----------------------------------------------------------------------
>> ----------
>>
>> However, resolving this problem has opened up a far larger problem
for
>> me:
>> I discovered that MET is only looking at the first hour's WRF data
>> across all 24 hours of observation data at each given verification
>> point (please see the file
>> "point_stat_360000L_20111019_000000V_mpr.txt" that I have sent to
you
>> via FTP). I want to compare hourly model data versus corresponding
>> hourly observed data over the course of 24 hours (e.g., 3Z WRF
output
>> vs. ~3Z obs, 9Z WRF output vs. ~9Z obs, etc.), not the same hour of
>> forecast data against 24 hours of observed data. Is there a way to
do
>> that in MET?
>>
>> Thanks again for your help,
>>
>> Elliot Tardif, Meteorologist II
>> NC DENR, Division of Air Quality
>> Planning Section, Attainment Planning Branch
>> 1641 Mail Service Center
>> Raleigh, NC 27699-1641
>> Phone/Fax: 919-707-8483
>> Email: Elliot.Tardif at ncdenr.gov
>> Web : http://www.ncair.org
>>
>> Email correspondence to and from this address is subject to the
North
>> Carolina Public Records Law and may be disclosed to third parties
>> unless the content is exempt by statue or other regulation.
>>
>>
>>
>>
>> -----Original Message-----
>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> Sent: Friday, November 22, 2013 4:07 PM
>> To: Tardif, Elliot M
>> Subject: Re: [rt.rap.ucar.edu #64405] Issue with wind forecast
>> verification
>>
>> Elliot,
>>
>> Thanks for sending the detailed description of the problem and some
>> sample data that you're using. I see that you're having trouble
>> getting the
>> VL1L2 vector partial sums from the Point-Stat tool.
>>
>> There may be a problem with the WRFPRS_d01.all data file you sent.
>> When I try to run it through wgrib to inventory it, I get the
following
>> error:
>> error, could not read to end of record 8461
>>
>> And when I try to run it through Point-Stat, I get:
>> GribFile::read() -> file read error ... requested 201498 bytes,
>> got
>> 123540
>>
>> Perhaps the file was truncated when you were writing it to our ftp
site.
>> To get around the problem, I used wgrib to extract the first 8460
>> records from that file. That got me around the error from Point-
Stat.
>> (I'm just now seeing your message that you weren't able to complete
>> the ftp. So that's the likely source of this problem).
>>
>> When I ran Point-Stat, I did not get the
>> "Dictionary::lookup_string_array()" error you saw, but I have a
>> suggestion. This is the config file that produced that error:
>>
>> /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatConf
>> ig_nc
>>
>> In that config file, I'm guessing you defined the "fcst" and "obs"
>> dictionaries separately. And I'll be that you have the
"message_type"
>> setting in the "fcst" dictionary and not in the "obs"
>> dictionary. It belongs in the "obs" dictionary since it specifying
>> information about the point observations. Try moving
"message_type"
>> into the "obs" dictionary and see if that error goes away.
>>
>> So to test things out, I ran the following command:
>> METv4.1/bin/point_stat \
>> WRFPRS_d01.all \
>> gdas.42112.2011092800.nc \
>> PointStatConfig_emt \
>> -outdir out \
>> -log run_ps.log \
>> -v 4
>>
>> And like you, I see no VL1L2 lines in the output. This is due to a
>> rather unfortunate convention we chose a while back. In order to
>> produce VL1L2 vector partial sums, the UGRD field must be
immediately
>> followed by the VGRD at the same vertical level. That simplifies
the
>> logic so that the code doesn't have to hunt through the config file
to
>> match up UGRD and VGRD pairs. In your config file, UGRD is
followed
>> by VGRD but for 4 different levels, as shown here:
>> {
>> name = "UGRD";
>> level = [ "Z10", "P850", "P700", "P500" ];
>> cat_thresh = [ >1.0 ];
>> },
>>
>> {
>> name = "VGRD";
>> level = [ "Z10", "P850", "P700", "P500" ];
>> cat_thresh = [ >1.0 ];
>> },
>>
>> When the code expands this it sees: UGRD/Z10, UGRD/P850,
UGRD/P700,
>> UGRD/P500, VGRD/Z10, VGRD/P850, VGRD/P700, VGRD/P500 So the
convention
>> is not met since UGRD is not followed by VGRD at the same vertical
>> level.
>> When I remove the first 3 levels, leaving only "P500" and rerun
>> Point-Stat, I do get VL1L2 partial sums in the output. I order to
get
>> the desired behavior, you'd have to set up the config file like
list:
>> { name = "UGRD"; level = ["Z10"]; cat_thresh = [ >1.0 ]; },
>> { name = "VGRD"; level = ["Z10"]; cat_thresh = [ >1.0 ]; },
>> { name = "UGRD"; level = ["P850"]; cat_thresh = [ >1.0 ]; },
>> { name = "VGRD"; level = ["P850"]; cat_thresh = [ >1.0 ]; },
>> { name = "UGRD"; level = ["P700"]; cat_thresh = [ >1.0 ]; },
>> { name = "VGRD"; level = ["P700"]; cat_thresh = [ >1.0 ]; },
>> { name = "UGRD"; level = ["P500"]; cat_thresh = [ >1.0 ]; },
>> { name = "VGRD"; level = ["P500"]; cat_thresh = [ >1.0 ]; },
>>
>> In this way, UGRD is immediately followed by VGRD at the same
vertical
>> level. I realize that's more cumbersome, but it should solve your
>> problem.
>>
>> Lastly, I want to mention something about how you've prepared your
>> data for Point-Stat. You've grouped all the forecast lead times
into
>> a single GRIB file. When I run Point-Stat and verify 500 mb
>> temperature, for example, I see the following log message:
>> DEBUG 2: For TMP/P500 found 25 forecast levels and 0
climatology
>> levels.
>>
>> Looking at the (truncated) GRIB file you sent, I see 25 records of
>> temperature at 500 mb, for hourly forecasts from 25 to 36 hours:
>> wgrib WRFPRS_d01.all | grep TMP | grep "kpds7=500"
>>
>> Point-Stat is not verifying them one-by-one. Instead it's just
using
>> the first one it finds. If you'd like to organize your data in
this
>> way, you'll need to tell Point-Stat which forecast lead time you'd
>> like to evaluate. You do this using the "lead_time" setting in the
>> config file.
>> I see that you have "lead_time" listed in the config file you sent
but
>> it's commented out. If your forecast data is organized in this
way,
>> you should be setting "lead_time".
>>
>> Hope that helps clarify.
>>
>> Thanks,
>> John Halley Gotway
>> met_help at ucar.edu
>>
>> On 11/22/2013 12:46 PM, Tardif, Elliot M via RT wrote:
>>>
>>> Fri Nov 22 12:46:10 2013: Request 64405 was acted upon.
>>> Transaction: Ticket created by elliot.tardif at ncdenr.gov
>>> Queue: met_help
>>> Subject: Issue with wind forecast verification
>>> Owner: Nobody
>>> Requestors: elliot.tardif at ncdenr.gov
>>> Status: new
>>> Ticket <URL:
>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=64405
>>> >
>>>
>>>
>>> Good afternoon,
>>>
>>> I am running Point-stat for an annual WRF model run; the WRF-ARW
data
>>> is being fed through UPP to get the forecast data into the proper
>>> format, then "copygb" is used to group the hourly forecast files
>>> together into one big file so I can look at daily verification
data
>>> instead of one hour at a time. I am analyzing temperature,
dewpoint,
>>> absolute & relative humidity data, and I want to analyze wind data
as
>>> well.
>>> However, MET will not produce the partial vector sums for wind
(only
>>> partial scalar sums), and I want to analyze both wind direction
and
>>> speed. I have attempted to work around this problem by running
the
>>> WRF data through p_interp (see ticket #64317), to no avail as it
now
>>> gives me the following error:
>>>
>>> *** Running Point-Stat on EPA WRF data *** DEBUG 1: Default Config
>>> File:
>>> /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatCon
>>> f ig_default DEBUG 1: User Config File:
>>> /opt/storage/high-
speed/EMT2/METv4.1/METv4.1/data/config/PointStatCon
>>> f
>>> ig_nc
>>> ERROR :
>>> ERROR : Dictionary::lookup_string_array() -> lookup failed for
name
>>> "message_type"
>>> ERROR :
>>>
>>> I would greatly appreciate any help on getting MET to produce
partial
>>> vector sums for wind direction and wind speed verification
analysis,
>>> either through running p_interp or UPP. I have sent some files
via
>>> ftp, using the instructions given on your website, for your
>>> consideration. I will be happy to answer any questions.
>>>
>>> Thanks for your time and have a great weekend,
>>>
>>> Elliot Tardif, Meteorologist II
>>> NC DENR, Division of Air Quality
>>> Planning Section, Attainment Planning Branch
>>> 1641 Mail Service Center
>>> Raleigh, NC 27699-1641
>>> Phone/Fax: 919-707-8483
>>> Email: Elliot.Tardif at ncdenr.gov<mailto:Nick.Witcraft at ncdenr.gov>
>>> Web : http://www.ncair.org<http://www.ncair.org/>
>>>
>>> Email correspondence to and from this address is subject to the
North
>>> Carolina Public Records Law and may be disclosed to third parties
>>> unless the content is exempt by statue or other regulation.
>>>
>>
>>
>>
>
>
>
>
>
------------------------------------------------
More information about the Met_help
mailing list