[Met_help] [rt.rap.ucar.edu #41014] History for MPR Question
RAL HelpDesk {for John Halley Gotway}
met_help at ucar.edu
Mon Oct 11 15:54:49 MDT 2010
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi John,
I hope you are doing well!
A question for you - would you advise against outputting matched pair
data from the grid-stat tool? We are presently verifying TMP/RH/WINDS
at sfc, 850, 500, 250mb over nested domain. The reason I ask - we plan
on storing that matched pair data so that we can aggregate data
differently (using stat analysis) down the road... but don't want to be
storing ridiculous amts of data. Is there a different way to utilize
stat-analysis and grid stat together more efficiently?
Jackie
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #41014]
From: John Halley Gotway
Time: Tue Sep 21 10:43:46 2010
Jackie,
Grid-Stat actually does not dump out the MPR line to a STAT file for
the very reason you mention - the output would be ridiculously large.
Instead, Grid-Stat is able to create a NetCDF file
containing the same type of data as the MPR line: forecast values,
observation values, and difference field. If you've set the
"interp_pnts = 1" in the Grid-Stat config file, then these values are
really just the same as the input fields themselves. And currently,
STAT-Analysis is NOT set up to read those NetCDF matched pairs files.
While it would be a logical extension of STAT-Analysis, we
haven't had any user requests to do so.
So ultimately you'd like to be able to aggregate your Grid-Stat data
across multiple runs in time. One way you can do that is by
outputting the contingency table counts (CTC) and the partial sums
(SL1L2) for each Grid-Stat run. Then, you can use STAT-Analysis to
aggregate together multiple CTC lines and compute a CTS (contingency
table statistics) line. Or you can aggregate together multiple
SL1L2 lines and compute a CNT (continuous statistics) line.
The downside here is that you have to choose your thresholds of
interest (for CTC) and verification regions of interest (for SL1L2)
ahead of time. The analysis isn't as flexible as with using the MPR
output lines for Point-Stat. But that's the compromise you make to
avoid storing so much data.
Hope that helps clarify.
Thanks,
John
RAL HelpDesk {for John Halley Gotway} wrote:
> Tue Sep 21 10:33:19 2010: Request 41014 was acted upon.
> Transaction: Ticket created by johnhg
> Queue: met_help
> Subject: (No subject given)
> Owner: johnhg
> Requestors: jackie.miller at vaisala.com
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41014 >
>
>
> Hi John,
>
> I hope you are doing well!
>
> A question for you - would you advise against outputting matched
pair
> data from the grid-stat tool? We are presently verifying
TMP/RH/WINDS
> at sfc, 850, 500, 250mb over nested domain. The reason I ask - we
plan
> on storing that matched pair data so that we can aggregate data
> differently (using stat analysis) down the road... but don't want to
be
> storing ridiculous amts of data. Is there a different way to
utilize
> stat-analysis and grid stat together more efficiently?
>
> Jackie
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #41014]
From: jackie.miller
Time: Tue Sep 21 15:20:02 2010
Hi John,
This helps -- which variables can I output partial sums for?
Separate question - in the process of setting up point-stat, it took a
bit of effort to complete the pre-processing of the point data (adding
the necessary fields) for the ASCII2NC tool. I wonder if (e.g. for
CONUS model verification) you have any sort of pre-processing scripts
available for "standard" point verification sources like METARs? For
the private data we are currently using we did the pre-processing on
our
own, but I thought it might be worth asking if there were any scripts
floating around MET for more common point verification sources.
Jackie
Jackie Miller
Meteorologist
Vaisala Inc.
Phone +1 303 885 3251
Mobile +1 303 885 3251
www.vaisala.com
This electronic message contains a communication which is strictly
confidential and intended solely for the addressee(s). Any
non-addressee is prohibited from reading, disseminating, distributing,
or copying the communication contained herein. If you are in
possession
of the communication in error, please immediately notify the sender
via
an electronic response and destroy the original communication. Thank
you.
U.S. Export Restrictions & Disclaimer: Export of any technical
information contained in this email and/or its attachments is subject
to
the export control laws and regulations of the U.S. Government and may
require a valid license or written approval prior to export.
-----Original Message-----
From: RAL HelpDesk {for John Halley Gotway} [mailto:met_help at ucar.edu]
Sent: Tuesday, September 21, 2010 11:44 AM
To: Miller Jackie JCM
Subject: Re: [rt.rap.ucar.edu #41014]
Jackie,
Grid-Stat actually does not dump out the MPR line to a STAT file for
the
very reason you mention - the output would be ridiculously large.
Instead, Grid-Stat is able to create a NetCDF file
containing the same type of data as the MPR line: forecast values,
observation values, and difference field. If you've set the
"interp_pnts = 1" in the Grid-Stat config file, then these values are
really just the same as the input fields themselves. And currently,
STAT-Analysis is NOT set up to read those NetCDF matched pairs files.
While it would be a logical extension of STAT-Analysis, we
haven't had any user requests to do so.
So ultimately you'd like to be able to aggregate your Grid-Stat data
across multiple runs in time. One way you can do that is by
outputting
the contingency table counts (CTC) and the partial sums
(SL1L2) for each Grid-Stat run. Then, you can use STAT-Analysis to
aggregate together multiple CTC lines and compute a CTS (contingency
table statistics) line. Or you can aggregate together multiple
SL1L2 lines and compute a CNT (continuous statistics) line.
The downside here is that you have to choose your thresholds of
interest
(for CTC) and verification regions of interest (for SL1L2) ahead of
time. The analysis isn't as flexible as with using the MPR
output lines for Point-Stat. But that's the compromise you make to
avoid storing so much data.
Hope that helps clarify.
Thanks,
John
RAL HelpDesk {for John Halley Gotway} wrote:
> Tue Sep 21 10:33:19 2010: Request 41014 was acted upon.
> Transaction: Ticket created by johnhg
> Queue: met_help
> Subject: (No subject given)
> Owner: johnhg
> Requestors: jackie.miller at vaisala.com
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41014
>
>
>
> Hi John,
>
> I hope you are doing well!
>
> A question for you - would you advise against outputting matched
pair
> data from the grid-stat tool? We are presently verifying
TMP/RH/WINDS
> at sfc, 850, 500, 250mb over nested domain. The reason I ask - we
plan
> on storing that matched pair data so that we can aggregate data
> differently (using stat analysis) down the road... but don't want to
be
> storing ridiculous amts of data. Is there a different way to
utilize
> stat-analysis and grid stat together more efficiently?
>
> Jackie
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #41014]
From: John Halley Gotway
Time: Tue Sep 21 15:37:02 2010
Jackie,
The partial sums are contained in the SL1L2 (S for scalar) line type,
which can be output for all the fields (just turn it on in the
"output_flag" parameter). The only variant is for winds, where we
can output the VL1L2 (V for vector) partial sums line. Just turn it
on in the "output_flag". Then if you list out U and V in the
"fcst_field" at the same level, you'll see VL1L2 line in the MET
output.
For example,
fcst_field[] = [ "UGRD/Z2", "VGRD/Z2" ];
And turn on the VL1L2 lines in the output_flag, and you should see
VL1l2 lines in the ".stat" file output.
For your second question, the answer is no. We do not have a script
for converting common formats. In the short term, if we had such a
script, we could post it to the scripts section of the MET website:
http://www.dtcenter.org/met/users/downloads/analysis_scripts.php
In the long term, we could consider adding support for common ASCII
observation file formats, including METARs, directly to the ASCII2NC
tool. Is that something that you think would be useful?
Thanks,
John
RAL HelpDesk {for jackie.miller} wrote:
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41014 >
>
> Hi John,
>
> This helps -- which variables can I output partial sums for?
>
> Separate question - in the process of setting up point-stat, it took
a
> bit of effort to complete the pre-processing of the point data
(adding
> the necessary fields) for the ASCII2NC tool. I wonder if (e.g. for
> CONUS model verification) you have any sort of pre-processing
scripts
> available for "standard" point verification sources like METARs?
For
> the private data we are currently using we did the pre-processing on
our
> own, but I thought it might be worth asking if there were any
scripts
> floating around MET for more common point verification sources.
>
> Jackie
>
> Jackie Miller
> Meteorologist
> Vaisala Inc.
>
> Phone +1 303 885 3251
> Mobile +1 303 885 3251
> www.vaisala.com
>
> This electronic message contains a communication which is strictly
> confidential and intended solely for the addressee(s). Any
> non-addressee is prohibited from reading, disseminating,
distributing,
> or copying the communication contained herein. If you are in
possession
> of the communication in error, please immediately notify the sender
via
> an electronic response and destroy the original communication.
Thank
> you.
>
> U.S. Export Restrictions & Disclaimer: Export of any technical
> information contained in this email and/or its attachments is
subject to
> the export control laws and regulations of the U.S. Government and
may
> require a valid license or written approval prior to export.
> -----Original Message-----
> From: RAL HelpDesk {for John Halley Gotway}
[mailto:met_help at ucar.edu]
> Sent: Tuesday, September 21, 2010 11:44 AM
> To: Miller Jackie JCM
> Subject: Re: [rt.rap.ucar.edu #41014]
>
> Jackie,
>
> Grid-Stat actually does not dump out the MPR line to a STAT file for
the
> very reason you mention - the output would be ridiculously large.
> Instead, Grid-Stat is able to create a NetCDF file
> containing the same type of data as the MPR line: forecast values,
> observation values, and difference field. If you've set the
> "interp_pnts = 1" in the Grid-Stat config file, then these values
are
> really just the same as the input fields themselves. And currently,
> STAT-Analysis is NOT set up to read those NetCDF matched pairs
files.
> While it would be a logical extension of STAT-Analysis, we
> haven't had any user requests to do so.
>
> So ultimately you'd like to be able to aggregate your Grid-Stat data
> across multiple runs in time. One way you can do that is by
outputting
> the contingency table counts (CTC) and the partial sums
> (SL1L2) for each Grid-Stat run. Then, you can use STAT-Analysis to
> aggregate together multiple CTC lines and compute a CTS (contingency
> table statistics) line. Or you can aggregate together multiple
> SL1L2 lines and compute a CNT (continuous statistics) line.
>
> The downside here is that you have to choose your thresholds of
interest
> (for CTC) and verification regions of interest (for SL1L2) ahead of
> time. The analysis isn't as flexible as with using the MPR
> output lines for Point-Stat. But that's the compromise you make to
> avoid storing so much data.
>
> Hope that helps clarify.
>
> Thanks,
> John
>
> RAL HelpDesk {for John Halley Gotway} wrote:
>> Tue Sep 21 10:33:19 2010: Request 41014 was acted upon.
>> Transaction: Ticket created by johnhg
>> Queue: met_help
>> Subject: (No subject given)
>> Owner: johnhg
>> Requestors: jackie.miller at vaisala.com
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41014
>>
>>
>>
>> Hi John,
>>
>> I hope you are doing well!
>>
>> A question for you - would you advise against outputting matched
pair
>> data from the grid-stat tool? We are presently verifying
TMP/RH/WINDS
>> at sfc, 850, 500, 250mb over nested domain. The reason I ask - we
> plan
>> on storing that matched pair data so that we can aggregate data
>> differently (using stat analysis) down the road... but don't want
to
> be
>> storing ridiculous amts of data. Is there a different way to
utilize
>> stat-analysis and grid stat together more efficiently?
>>
>> Jackie
>
------------------------------------------------
More information about the Met_help
mailing list