[Met_help] [rt.rap.ucar.edu #41818] History for ASCII2NC and Point-Analysis Tools for METv3.0
RAL HelpDesk {for John Halley Gotway}
met_help at ucar.edu
Thu Nov 18 10:30:35 MST 2010
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
MET team,
Couple of clarification questions for you, regarding the MET package:
1. When preparing the point observation data for the ASCII2NC tool, I
realize that the longitude of the observing station must be in degrees
East. Just to clarify - for example:
would 75 degrees West longitude need to be -285 degrees East longitude in
the file before using the ASCII2NC tool?
2. I know that METv3.0 currently allows for WRF-ARW users to utilize
netCDF output directly from the WRF-ARW model itself. The variables that
will be verified must be stated in the Point-Stat configuration file before
running. I noticed the syntax:
var_name(i,...,j,*.*)
My verification studies will be focusing on wind speed (2-D or 3-D),
temperature, and dew point. So would my forecast fields be defined in the
following way for surface verification (ignore the var_names as they will
likely be different):
fcst_field[] = [ "TT(0,*,*)", "DPT(0,*,*)", "WSP(0,*,*,*)" ]
or WSP(0,*,*) for 2-D
3. Would the PB2NC tool be able to handle METAR data for conversion to
netCDF format (to be used in Point-Stat)?
I may have some questions for you about the Stat-Analysis tool when I come
to that step. I appreciate all your help thus far.
Thanks,
James
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #41818] ASCII2NC and Point-Analysis Tools for METv3.0
From: John Halley Gotway
Time: Thu Oct 28 15:23:43 2010
James,
(1) Yes, we follow the convention of defining latitude as degrees
north and longitude as degrees east. To switch between degrees east
and west, the easiest thing to do is just multiply by -1. 75
degrees west is the same as -75 degrees east. Or you could add 360 to
that and use 285 degrees east. You should be able to use -75 or 285 -
they are equivalent.
(2) METv3.0 does NOT read the output of WRF-ARW directly. Instead it
reads the NetCDF output of the "pinterp" tool which can only be run on
WRF-ARW data. You do have the basic idea for the variable
naming convention correct in the config file. However, please note
that you can only use the '*' for two dimensions - the two which
define the 2D, x/y grid:
fcst_field[] = [ "TT(0,*,*)", "DPT(0,*,*)" ];
To verify a range of pressure levels, you specify it like this:
fcst_field[] = [ "WSP(0,5-8,*,*)" ];
Where the *'s are for the grid dimensions and the 5-8 specifies the
range of pressure levels you want to verify.
Also note that you'll need to specify the corresponding observations
to be used separately, and using the GRIB conventions. Something like
this:
fcst_field[] = [ "TT(0,*,*)", "DPT(0,*,*)" ];
obs_field[] = [ "TMP/Z0", "DPT/Z0" ];
Just give it a shot and let us know if you get stuck.
(3) The PB2NC tool can handle the METAR data that's included in the
PREPBUFR file you've input to the tool. If the METAR data is not in
the PREPBUFR file, PB2NC cannot handle it.
Hope that helps.
Thanks,
John
On 10/28/2010 02:55 PM, RAL HelpDesk {for James P Cipriani} wrote:
>
> Thu Oct 28 14:55:51 2010: Request 41818 was acted upon.
> Transaction: Ticket created by jpcipria at us.ibm.com
> Queue: met_help
> Subject: ASCII2NC and Point-Analysis Tools for METv3.0
> Owner: Nobody
> Requestors: jpcipria at us.ibm.com
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41818 >
>
>
>
>
> MET team,
>
> Couple of clarification questions for you, regarding the MET
package:
>
>
> 1. When preparing the point observation data for the ASCII2NC tool,
I
> realize that the longitude of the observing station must be in
degrees
> East. Just to clarify - for example:
>
> would 75 degrees West longitude need to be -285 degrees East
longitude in
> the file before using the ASCII2NC tool?
>
> 2. I know that METv3.0 currently allows for WRF-ARW users to
utilize
> netCDF output directly from the WRF-ARW model itself. The variables
that
> will be verified must be stated in the Point-Stat configuration file
before
> running. I noticed the syntax:
>
> var_name(i,...,j,*.*)
>
> My verification studies will be focusing on wind speed (2-D or 3-D),
> temperature, and dew point. So would my forecast fields be defined
in the
> following way for surface verification (ignore the var_names as they
will
> likely be different):
>
> fcst_field[] = [ "TT(0,*,*)", "DPT(0,*,*)", "WSP(0,*,*,*)" ]
>
> or WSP(0,*,*) for 2-D
>
> 3. Would the PB2NC tool be able to handle METAR data for conversion
to
> netCDF format (to be used in Point-Stat)?
>
>
> I may have some questions for you about the Stat-Analysis tool when
I come
> to that step. I appreciate all your help thus far.
>
> Thanks,
> James
------------------------------------------------
Subject: ASCII2NC and Point-Analysis Tools for METv3.0
From: James P Cipriani
Time: Fri Oct 29 06:53:28 2010
John,
Thanks for the input.
Quick follow-up questions:
1. For a station whose coordinates are already given in negative
degrees
East (say -1.03 degrees east), should I just keep this value negative
or
negate it to create a positive for degrees East (Keep in mind that I'm
using [-1]*[degrees West] + 360 for the west longitude stations)?
2. Let's say I'm only interested in surface wind speed in 2
dimensions
(x,y) - would I use something like:
fcst_field[] = [ "WSP(0,*,*)" ] ? And of course, this would be using
message type = "ADPSFC"
Thanks for the input and your help in these matters. This is my first
time
utilizing such software, but I must say that it is quite helpful for
our
verification work.
--James
From: "RAL HelpDesk {for John Halley Gotway}" <met_help at ucar.edu>
To: James P Cipriani/Watson/IBM at IBMUS
Date: 10/28/2010 05:24 PM
Subject: Re: [rt.rap.ucar.edu #41818] ASCII2NC and Point-Analysis
Tools
for METv3.0
James,
(1) Yes, we follow the convention of defining latitude as degrees
north and
longitude as degrees east. To switch between degrees east and west,
the
easiest thing to do is just multiply by -1. 75
degrees west is the same as -75 degrees east. Or you could add 360 to
that
and use 285 degrees east. You should be able to use -75 or 285 - they
are
equivalent.
(2) METv3.0 does NOT read the output of WRF-ARW directly. Instead it
reads
the NetCDF output of the "pinterp" tool which can only be run on WRF-
ARW
data. You do have the basic idea for the variable
naming convention correct in the config file. However, please note
that
you can only use the '*' for two dimensions - the two which define the
2D,
x/y grid:
fcst_field[] = [ "TT(0,*,*)", "DPT(0,*,*)" ];
To verify a range of pressure levels, you specify it like this:
fcst_field[] = [ "WSP(0,5-8,*,*)" ];
Where the *'s are for the grid dimensions and the 5-8 specifies the
range
of pressure levels you want to verify.
Also note that you'll need to specify the corresponding observations
to be
used separately, and using the GRIB conventions. Something like this:
fcst_field[] = [ "TT(0,*,*)", "DPT(0,*,*)" ];
obs_field[] = [ "TMP/Z0", "DPT/Z0" ];
Just give it a shot and let us know if you get stuck.
(3) The PB2NC tool can handle the METAR data that's included in the
PREPBUFR file you've input to the tool. If the METAR data is not in
the
PREPBUFR file, PB2NC cannot handle it.
Hope that helps.
Thanks,
John
On 10/28/2010 02:55 PM, RAL HelpDesk {for James P Cipriani} wrote:
>
> Thu Oct 28 14:55:51 2010: Request 41818 was acted upon.
> Transaction: Ticket created by jpcipria at us.ibm.com
> Queue: met_help
> Subject: ASCII2NC and Point-Analysis Tools for METv3.0
> Owner: Nobody
> Requestors: jpcipria at us.ibm.com
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41818 >
>
>
>
>
> MET team,
>
> Couple of clarification questions for you, regarding the MET
package:
>
>
> 1. When preparing the point observation data for the ASCII2NC tool,
I
> realize that the longitude of the observing station must be in
degrees
> East. Just to clarify - for example:
>
> would 75 degrees West longitude need to be -285 degrees East
longitude in
> the file before using the ASCII2NC tool?
>
> 2. I know that METv3.0 currently allows for WRF-ARW users to
utilize
> netCDF output directly from the WRF-ARW model itself. The variables
that
> will be verified must be stated in the Point-Stat configuration file
before
> running. I noticed the syntax:
>
> var_name(i,...,j,*.*)
>
> My verification studies will be focusing on wind speed (2-D or 3-D),
> temperature, and dew point. So would my forecast fields be defined
in
the
> following way for surface verification (ignore the var_names as they
will
> likely be different):
>
> fcst_field[] = [ "TT(0,*,*)", "DPT(0,*,*)", "WSP(0,*,*,*)" ]
>
> or WSP(0,*,*) for 2-D
>
> 3. Would the PB2NC tool be able to handle METAR data for conversion
to
> netCDF format (to be used in Point-Stat)?
>
>
> I may have some questions for you about the Stat-Analysis tool when
I
come
> to that step. I appreciate all your help thus far.
>
> Thanks,
> James
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #41818] ASCII2NC and Point-Analysis Tools for METv3.0
From: John Halley Gotway
Time: Fri Oct 29 12:50:52 2010
James,
(1) I'm getting a little confused here between degrees west and
degrees east. For MET, the longitudes should be given in degrees
east. It shouldn't matter if they're negative or positive degrees
east. I'd just pick a convention and use it - for example, you could
define them all in the range of (-180, 180]. The following pseudo-
code would do that. Assume that deg_west is your longitude in
degrees west:
deg_east = -1.0 * deg_west;
if(d < -180.0) deg_east = deg_east + 360
(2) It looks like you're interested in verifying 2-meter wind speed.
I don't believe the model actually outputs wind speed. Instead it
outputs U and V. I looked in some sample pinterp output, and I
do not see wind speed in there. And you can't use MET to verify
fields that don't exist in your pinterp output file.
However, if you were to use WPP to post-process your output (as I
mentioned in an earlier email), you'd have GRIB data. And MET
actually can read the U and V components and derive and verify wind
speed for you. Here's how you'd do it:
fcst_field[] = [ "WIND/Z2" ];
obs_field[] = []; // inherits the fcst_field settings by
default
message_type[] = [ "ADPSFC" ];
MET will look in the input GRIB file for a record of 2-meter wind
speed. If it finds one, it'll use it. If not, it'll look for U and V
at 2-meters. If those are defined relative the grid, it'll
rotate them to be relative to the earth. And then it'll derive wind
speed for you on the fly.
Now you'll need to make sure that you have wind speed available in
your observations as well. Since you're using ASCII observations,
you'll need to derive wind speed and put them into your file.
John
On 10/29/2010 06:53 AM, RAL HelpDesk {for James P Cipriani} wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41818 >
>
>
> John,
>
> Thanks for the input.
>
> Quick follow-up questions:
>
> 1. For a station whose coordinates are already given in negative
degrees
> East (say -1.03 degrees east), should I just keep this value
negative or
> negate it to create a positive for degrees East (Keep in mind that
I'm
> using [-1]*[degrees West] + 360 for the west longitude stations)?
>
> 2. Let's say I'm only interested in surface wind speed in 2
dimensions
> (x,y) - would I use something like:
>
> fcst_field[] = [ "WSP(0,*,*)" ] ? And of course, this would be
using
> message type = "ADPSFC"
>
> Thanks for the input and your help in these matters. This is my
first time
> utilizing such software, but I must say that it is quite helpful for
our
> verification work.
>
> --James
>
>
>
>
>
> From: "RAL HelpDesk {for John Halley Gotway}" <met_help at ucar.edu>
> To: James P Cipriani/Watson/IBM at IBMUS
> Date: 10/28/2010 05:24 PM
> Subject: Re: [rt.rap.ucar.edu #41818] ASCII2NC and Point-Analysis
Tools
> for METv3.0
>
>
>
> James,
>
> (1) Yes, we follow the convention of defining latitude as degrees
north and
> longitude as degrees east. To switch between degrees east and west,
the
> easiest thing to do is just multiply by -1. 75
> degrees west is the same as -75 degrees east. Or you could add 360
to that
> and use 285 degrees east. You should be able to use -75 or 285 -
they are
> equivalent.
>
> (2) METv3.0 does NOT read the output of WRF-ARW directly. Instead
it reads
> the NetCDF output of the "pinterp" tool which can only be run on
WRF-ARW
> data. You do have the basic idea for the variable
> naming convention correct in the config file. However, please note
that
> you can only use the '*' for two dimensions - the two which define
the 2D,
> x/y grid:
> fcst_field[] = [ "TT(0,*,*)", "DPT(0,*,*)" ];
>
> To verify a range of pressure levels, you specify it like this:
> fcst_field[] = [ "WSP(0,5-8,*,*)" ];
> Where the *'s are for the grid dimensions and the 5-8 specifies the
range
> of pressure levels you want to verify.
>
> Also note that you'll need to specify the corresponding observations
to be
> used separately, and using the GRIB conventions. Something like
this:
> fcst_field[] = [ "TT(0,*,*)", "DPT(0,*,*)" ];
> obs_field[] = [ "TMP/Z0", "DPT/Z0" ];
>
> Just give it a shot and let us know if you get stuck.
>
> (3) The PB2NC tool can handle the METAR data that's included in the
> PREPBUFR file you've input to the tool. If the METAR data is not in
the
> PREPBUFR file, PB2NC cannot handle it.
>
> Hope that helps.
>
> Thanks,
> John
>
> On 10/28/2010 02:55 PM, RAL HelpDesk {for James P Cipriani} wrote:
>>
>> Thu Oct 28 14:55:51 2010: Request 41818 was acted upon.
>> Transaction: Ticket created by jpcipria at us.ibm.com
>> Queue: met_help
>> Subject: ASCII2NC and Point-Analysis Tools for METv3.0
>> Owner: Nobody
>> Requestors: jpcipria at us.ibm.com
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41818 >
>>
>>
>>
>>
>> MET team,
>>
>> Couple of clarification questions for you, regarding the MET
package:
>>
>>
>> 1. When preparing the point observation data for the ASCII2NC
tool, I
>> realize that the longitude of the observing station must be in
degrees
>> East. Just to clarify - for example:
>>
>> would 75 degrees West longitude need to be -285 degrees East
longitude in
>> the file before using the ASCII2NC tool?
>>
>> 2. I know that METv3.0 currently allows for WRF-ARW users to
utilize
>> netCDF output directly from the WRF-ARW model itself. The
variables that
>> will be verified must be stated in the Point-Stat configuration
file
> before
>> running. I noticed the syntax:
>>
>> var_name(i,...,j,*.*)
>>
>> My verification studies will be focusing on wind speed (2-D or 3-
D),
>> temperature, and dew point. So would my forecast fields be defined
in
> the
>> following way for surface verification (ignore the var_names as
they will
>> likely be different):
>>
>> fcst_field[] = [ "TT(0,*,*)", "DPT(0,*,*)", "WSP(0,*,*,*)" ]
>>
>> or WSP(0,*,*) for 2-D
>>
>> 3. Would the PB2NC tool be able to handle METAR data for
conversion to
>> netCDF format (to be used in Point-Stat)?
>>
>>
>> I may have some questions for you about the Stat-Analysis tool when
I
> come
>> to that step. I appreciate all your help thus far.
>>
>> Thanks,
>> James
>
>
------------------------------------------------
Subject: ASCII2NC and Point-Analysis Tools for METv3.0
From: James P Cipriani
Time: Wed Nov 03 10:11:50 2010
Thanks.
1. I'm assuming then that MET will understand and correctly interpret
the
following as 2-meter temperature and 10-meter winds (with MET deriving
the
10-meter wind speed):
fcst_field[] = [ "TMP/Z2", "WIND/Z10" ];
obs_field[] = [];
message_type[] = [ "ADPSFC" ];
?
2. In terms of wind speed (which is derived from the U10 and V10
components), for continuous statistics (like multiplicative bias and
root
mean square error), would this require the declaration of the
individual
wind thresholds (fcst_wind_thresh) or would a single threshold suffice
(in
fcst_thresh)?
I'm sorry for so many questions - I am in the process of putting
everything
together, from reformatting the observation files, to running WPPV3,
to
running the actual MET package...
Thanks,
James
From: "RAL HelpDesk {for John Halley Gotway}" <met_help at ucar.edu>
To: James P Cipriani/Watson/IBM at IBMUS
Date: 10/29/2010 02:50 PM
Subject: Re: [rt.rap.ucar.edu #41818] ASCII2NC and Point-Analysis
Tools
for METv3.0
James,
(1) I'm getting a little confused here between degrees west and
degrees
east. For MET, the longitudes should be given in degrees east. It
shouldn't matter if they're negative or positive degrees
east. I'd just pick a convention and use it - for example, you could
define them all in the range of (-180, 180]. The following pseudo-
code
would do that. Assume that deg_west is your longitude in
degrees west:
deg_east = -1.0 * deg_west;
if(d < -180.0) deg_east = deg_east + 360
(2) It looks like you're interested in verifying 2-meter wind speed.
I
don't believe the model actually outputs wind speed. Instead it
outputs U
and V. I looked in some sample pinterp output, and I
do not see wind speed in there. And you can't use MET to verify
fields
that don't exist in your pinterp output file.
However, if you were to use WPP to post-process your output (as I
mentioned
in an earlier email), you'd have GRIB data. And MET actually can read
the
U and V components and derive and verify wind
speed for you. Here's how you'd do it:
fcst_field[] = [ "WIND/Z2" ];
obs_field[] = []; // inherits the fcst_field settings by
default
message_type[] = [ "ADPSFC" ];
MET will look in the input GRIB file for a record of 2-meter wind
speed.
If it finds one, it'll use it. If not, it'll look for U and V at 2-
meters.
If those are defined relative the grid, it'll
rotate them to be relative to the earth. And then it'll derive wind
speed
for you on the fly.
Now you'll need to make sure that you have wind speed available in
your
observations as well. Since you're using ASCII observations, you'll
need
to derive wind speed and put them into your file.
John
On 10/29/2010 06:53 AM, RAL HelpDesk {for James P Cipriani} wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41818 >
>
>
> John,
>
> Thanks for the input.
>
> Quick follow-up questions:
>
> 1. For a station whose coordinates are already given in negative
degrees
> East (say -1.03 degrees east), should I just keep this value
negative or
> negate it to create a positive for degrees East (Keep in mind that
I'm
> using [-1]*[degrees West] + 360 for the west longitude stations)?
>
> 2. Let's say I'm only interested in surface wind speed in 2
dimensions
> (x,y) - would I use something like:
>
> fcst_field[] = [ "WSP(0,*,*)" ] ? And of course, this would be
using
> message type = "ADPSFC"
>
> Thanks for the input and your help in these matters. This is my
first
time
> utilizing such software, but I must say that it is quite helpful for
our
> verification work.
>
> --James
>
>
>
>
>
> From: "RAL HelpDesk {for John Halley Gotway}"
<met_help at ucar.edu>
> To: James P Cipriani/Watson/IBM at IBMUS
> Date: 10/28/2010 05:24 PM
> Subject: Re: [rt.rap.ucar.edu #41818] ASCII2NC and Point-Analysis
Tools
> for METv3.0
>
>
>
> James,
>
> (1) Yes, we follow the convention of defining latitude as degrees
north
and
> longitude as degrees east. To switch between degrees east and west,
the
> easiest thing to do is just multiply by -1. 75
> degrees west is the same as -75 degrees east. Or you could add 360
to
that
> and use 285 degrees east. You should be able to use -75 or 285 -
they
are
> equivalent.
>
> (2) METv3.0 does NOT read the output of WRF-ARW directly. Instead
it
reads
> the NetCDF output of the "pinterp" tool which can only be run on
WRF-ARW
> data. You do have the basic idea for the variable
> naming convention correct in the config file. However, please note
that
> you can only use the '*' for two dimensions - the two which define
the
2D,
> x/y grid:
> fcst_field[] = [ "TT(0,*,*)", "DPT(0,*,*)" ];
>
> To verify a range of pressure levels, you specify it like this:
> fcst_field[] = [ "WSP(0,5-8,*,*)" ];
> Where the *'s are for the grid dimensions and the 5-8 specifies the
range
> of pressure levels you want to verify.
>
> Also note that you'll need to specify the corresponding observations
to
be
> used separately, and using the GRIB conventions. Something like
this:
> fcst_field[] = [ "TT(0,*,*)", "DPT(0,*,*)" ];
> obs_field[] = [ "TMP/Z0", "DPT/Z0" ];
>
> Just give it a shot and let us know if you get stuck.
>
> (3) The PB2NC tool can handle the METAR data that's included in the
> PREPBUFR file you've input to the tool. If the METAR data is not in
the
> PREPBUFR file, PB2NC cannot handle it.
>
> Hope that helps.
>
> Thanks,
> John
>
> On 10/28/2010 02:55 PM, RAL HelpDesk {for James P Cipriani} wrote:
>>
>> Thu Oct 28 14:55:51 2010: Request 41818 was acted upon.
>> Transaction: Ticket created by jpcipria at us.ibm.com
>> Queue: met_help
>> Subject: ASCII2NC and Point-Analysis Tools for METv3.0
>> Owner: Nobody
>> Requestors: jpcipria at us.ibm.com
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41818 >
>>
>>
>>
>>
>> MET team,
>>
>> Couple of clarification questions for you, regarding the MET
package:
>>
>>
>> 1. When preparing the point observation data for the ASCII2NC
tool, I
>> realize that the longitude of the observing station must be in
degrees
>> East. Just to clarify - for example:
>>
>> would 75 degrees West longitude need to be -285 degrees East
longitude
in
>> the file before using the ASCII2NC tool?
>>
>> 2. I know that METv3.0 currently allows for WRF-ARW users to
utilize
>> netCDF output directly from the WRF-ARW model itself. The
variables
that
>> will be verified must be stated in the Point-Stat configuration
file
> before
>> running. I noticed the syntax:
>>
>> var_name(i,...,j,*.*)
>>
>> My verification studies will be focusing on wind speed (2-D or 3-
D),
>> temperature, and dew point. So would my forecast fields be defined
in
> the
>> following way for surface verification (ignore the var_names as
they
will
>> likely be different):
>>
>> fcst_field[] = [ "TT(0,*,*)", "DPT(0,*,*)", "WSP(0,*,*,*)" ]
>>
>> or WSP(0,*,*) for 2-D
>>
>> 3. Would the PB2NC tool be able to handle METAR data for
conversion to
>> netCDF format (to be used in Point-Stat)?
>>
>>
>> I may have some questions for you about the Stat-Analysis tool when
I
> come
>> to that step. I appreciate all your help thus far.
>>
>> Thanks,
>> James
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #41818] ASCII2NC and Point-Analysis Tools for METv3.0
From: John Halley Gotway
Time: Wed Nov 03 10:37:38 2010
James,
Yes, your settings for "fcst_field", "obs_field", and "message_type"
look
fine. Issues may come up when you actually try to run it, but it's a
good
place to start.
Let me clarify a bit about what the threshold parameters do in the
configuration file:
(1) First, regarding the computation of continuous statistics - like
multiplicative bias and rmse. These are computed over ALL the points
in
your verification area. So if you're verifying over the "FULL"
domain,
the continuous statistics are computed using the matched pairs for ALL
the
grid points in your domain.
(2) The "fcst_thresh" settings are used to compute 2x2 contingency
tables.
The corresponding contingency table statistics are computed for each
of
these contingency tables. If you specify multiple thresholds here,
multiple 2x2 contingency tables are computed AND multi-category
contingency tables (3x3 or 4x4 and so on) if you request their output
in
the "output_flag" parameter.
(3) The "fcst_wind_thresh" parameter is NOT involved in this process
at
all. Read the comments in the config file for this one closely. It's
only used to filter the U/V pairs that are include in the VL1L2
partial
sums lines.
Perhaps you're actually interested in doing conditional verification,
and
answer questions like:
- How skillful is my wind speed forecast for speeds > 2 m/s?
- How skillful is my wind speed forecast for speeds > 5 m/s?
Point-Stat cannot answer this question directly, but there is a way to
get
at it. Here's the process I'd recommend:
- Run Point-Stat at each valid time and do your verification. In
addition, dump out the MPR (matched pair line type).
- Run a STAT-Analysis job to read in many of those MPR lines, filter
out
only the ones you want to use, and recompute statistics for that
subset of
data. For example, you could use STAT-Analysis to filter out only
those
pairs whose forecast and/or observation wind speeds meet some
threshold
criteria.
Clear as mud?
Thanks,
John
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41818 >
>
>
> Thanks.
>
> 1. I'm assuming then that MET will understand and correctly
interpret the
> following as 2-meter temperature and 10-meter winds (with MET
deriving the
> 10-meter wind speed):
>
> fcst_field[] = [ "TMP/Z2", "WIND/Z10" ];
> obs_field[] = [];
> message_type[] = [ "ADPSFC" ];
>
> ?
>
> 2. In terms of wind speed (which is derived from the U10 and V10
> components), for continuous statistics (like multiplicative bias and
root
> mean square error), would this require the declaration of the
individual
> wind thresholds (fcst_wind_thresh) or would a single threshold
suffice (in
> fcst_thresh)?
>
> I'm sorry for so many questions - I am in the process of putting
> everything
> together, from reformatting the observation files, to running WPPV3,
to
> running the actual MET package...
>
> Thanks,
> James
>
>
>
> From: "RAL HelpDesk {for John Halley Gotway}" <met_help at ucar.edu>
> To: James P Cipriani/Watson/IBM at IBMUS
> Date: 10/29/2010 02:50 PM
> Subject: Re: [rt.rap.ucar.edu #41818] ASCII2NC and Point-Analysis
Tools
> for METv3.0
>
>
>
> James,
>
> (1) I'm getting a little confused here between degrees west and
degrees
> east. For MET, the longitudes should be given in degrees east. It
> shouldn't matter if they're negative or positive degrees
> east. I'd just pick a convention and use it - for example, you
could
> define them all in the range of (-180, 180]. The following pseudo-
code
> would do that. Assume that deg_west is your longitude in
> degrees west:
>
> deg_east = -1.0 * deg_west;
> if(d < -180.0) deg_east = deg_east + 360
>
> (2) It looks like you're interested in verifying 2-meter wind speed.
I
> don't believe the model actually outputs wind speed. Instead it
outputs U
> and V. I looked in some sample pinterp output, and I
> do not see wind speed in there. And you can't use MET to verify
fields
> that don't exist in your pinterp output file.
>
> However, if you were to use WPP to post-process your output (as I
> mentioned
> in an earlier email), you'd have GRIB data. And MET actually can
read the
> U and V components and derive and verify wind
> speed for you. Here's how you'd do it:
>
> fcst_field[] = [ "WIND/Z2" ];
> obs_field[] = []; // inherits the fcst_field settings by
default
> message_type[] = [ "ADPSFC" ];
>
> MET will look in the input GRIB file for a record of 2-meter wind
speed.
> If it finds one, it'll use it. If not, it'll look for U and V at
> 2-meters.
> If those are defined relative the grid, it'll
> rotate them to be relative to the earth. And then it'll derive wind
speed
> for you on the fly.
>
> Now you'll need to make sure that you have wind speed available in
your
> observations as well. Since you're using ASCII observations, you'll
need
> to derive wind speed and put them into your file.
>
> John
>
>
> On 10/29/2010 06:53 AM, RAL HelpDesk {for James P Cipriani} wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41818 >
>>
>>
>> John,
>>
>> Thanks for the input.
>>
>> Quick follow-up questions:
>>
>> 1. For a station whose coordinates are already given in negative
degrees
>> East (say -1.03 degrees east), should I just keep this value
negative or
>> negate it to create a positive for degrees East (Keep in mind that
I'm
>> using [-1]*[degrees West] + 360 for the west longitude stations)?
>>
>> 2. Let's say I'm only interested in surface wind speed in 2
dimensions
>> (x,y) - would I use something like:
>>
>> fcst_field[] = [ "WSP(0,*,*)" ] ? And of course, this would be
using
>> message type = "ADPSFC"
>>
>> Thanks for the input and your help in these matters. This is my
first
> time
>> utilizing such software, but I must say that it is quite helpful
for our
>> verification work.
>>
>> --James
>>
>>
>>
>>
>>
>> From: "RAL HelpDesk {for John Halley Gotway}"
> <met_help at ucar.edu>
>> To: James P Cipriani/Watson/IBM at IBMUS
>> Date: 10/28/2010 05:24 PM
>> Subject: Re: [rt.rap.ucar.edu #41818] ASCII2NC and Point-Analysis
> Tools
>> for METv3.0
>>
>>
>>
>> James,
>>
>> (1) Yes, we follow the convention of defining latitude as degrees
north
> and
>> longitude as degrees east. To switch between degrees east and
west, the
>> easiest thing to do is just multiply by -1. 75
>> degrees west is the same as -75 degrees east. Or you could add 360
to
> that
>> and use 285 degrees east. You should be able to use -75 or 285 -
they
> are
>> equivalent.
>>
>> (2) METv3.0 does NOT read the output of WRF-ARW directly. Instead
it
> reads
>> the NetCDF output of the "pinterp" tool which can only be run on
WRF-ARW
>> data. You do have the basic idea for the variable
>> naming convention correct in the config file. However, please note
that
>> you can only use the '*' for two dimensions - the two which define
the
> 2D,
>> x/y grid:
>> fcst_field[] = [ "TT(0,*,*)", "DPT(0,*,*)" ];
>>
>> To verify a range of pressure levels, you specify it like this:
>> fcst_field[] = [ "WSP(0,5-8,*,*)" ];
>> Where the *'s are for the grid dimensions and the 5-8 specifies the
>> range
>> of pressure levels you want to verify.
>>
>> Also note that you'll need to specify the corresponding
observations to
> be
>> used separately, and using the GRIB conventions. Something like
this:
>> fcst_field[] = [ "TT(0,*,*)", "DPT(0,*,*)" ];
>> obs_field[] = [ "TMP/Z0", "DPT/Z0" ];
>>
>> Just give it a shot and let us know if you get stuck.
>>
>> (3) The PB2NC tool can handle the METAR data that's included in the
>> PREPBUFR file you've input to the tool. If the METAR data is not
in the
>> PREPBUFR file, PB2NC cannot handle it.
>>
>> Hope that helps.
>>
>> Thanks,
>> John
>>
>> On 10/28/2010 02:55 PM, RAL HelpDesk {for James P Cipriani} wrote:
>>>
>>> Thu Oct 28 14:55:51 2010: Request 41818 was acted upon.
>>> Transaction: Ticket created by jpcipria at us.ibm.com
>>> Queue: met_help
>>> Subject: ASCII2NC and Point-Analysis Tools for METv3.0
>>> Owner: Nobody
>>> Requestors: jpcipria at us.ibm.com
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41818 >
>>>
>>>
>>>
>>>
>>> MET team,
>>>
>>> Couple of clarification questions for you, regarding the MET
package:
>>>
>>>
>>> 1. When preparing the point observation data for the ASCII2NC
tool, I
>>> realize that the longitude of the observing station must be in
degrees
>>> East. Just to clarify - for example:
>>>
>>> would 75 degrees West longitude need to be -285 degrees East
longitude
> in
>>> the file before using the ASCII2NC tool?
>>>
>>> 2. I know that METv3.0 currently allows for WRF-ARW users to
utilize
>>> netCDF output directly from the WRF-ARW model itself. The
variables
> that
>>> will be verified must be stated in the Point-Stat configuration
file
>> before
>>> running. I noticed the syntax:
>>>
>>> var_name(i,...,j,*.*)
>>>
>>> My verification studies will be focusing on wind speed (2-D or 3-
D),
>>> temperature, and dew point. So would my forecast fields be
defined in
>> the
>>> following way for surface verification (ignore the var_names as
they
> will
>>> likely be different):
>>>
>>> fcst_field[] = [ "TT(0,*,*)", "DPT(0,*,*)", "WSP(0,*,*,*)" ]
>>>
>>> or WSP(0,*,*) for 2-D
>>>
>>> 3. Would the PB2NC tool be able to handle METAR data for
conversion to
>>> netCDF format (to be used in Point-Stat)?
>>>
>>>
>>> I may have some questions for you about the Stat-Analysis tool
when I
>> come
>>> to that step. I appreciate all your help thus far.
>>>
>>> Thanks,
>>> James
>>
>>
>
>
>
------------------------------------------------
More information about the Met_help
mailing list