[Met_help] [rt.rap.ucar.edu #97623] History for Point_stat log file details
John Halley Gotway via RT
met_help at ucar.edu
Fri Dec 4 22:27:06 MST 2020
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello,
Is there a way to print out individual stations that were rejected in the following categories?
>From the Point_stat log file:
718 DEBUG 3: Number of matched pairs = 1292
719 DEBUG 3: Observations processed = 19696
720 DEBUG 3: Rejected: SID exclusion = 0
721 DEBUG 3: Rejected: obs type = 16198
722 DEBUG 3: Rejected: valid time = 0
723 DEBUG 3: Rejected: bad obs value = 0
724 DEBUG 3: Rejected: off the grid = 355
725 DEBUG 3: Rejected: topography = 665
726 DEBUG 3: Rejected: level mismatch = 0
727 DEBUG 3: Rejected: quality marker = 0
728 DEBUG 3: Rejected: message type = 0
729 DEBUG 3: Rejected: masking region = 0
730 DEBUG 3: Rejected: bad fcst value = 1186
731 DEBUG 3: Rejected: duplicates = 0
732 DEBUG 2: Computing Continuous Statistics.
Point_stat already prints out stations that were rejected due to topography. But I would love to find out what stations are being rejected due to "bad fcst value" and off the grid.
Thanks,
Justin
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Point_stat log file details
From: John Halley Gotway
Time: Mon Nov 30 13:00:24 2020
Justin,
I took a look in the source code and see where MET prints out a
Debug(4)
log message about skipping points due to topography differences.
Here's
that line:
https://github.com/dtcenter/MET/blob/17e1c9740224bf84a8bd0e84b5d254ccc5981bb8/met/src/libcode/vx_statistics/pair_data_point.cc#L876
In that source code I see we're increment rejection reason counts for:
- station id on line 788
- observation variable name on line 796 and 801
- quality control flag on line 812
- valid time on line 820
- bad obs value on line 836
- off the grid on line 848
*- topography on line 870 and 885*
- level mismatch on line 896, 906, and 918
- message type on line 988
- masking region on line 998, 1006, and 1014
- bad climo values on line 1038 and 1066
- bad forecast values on line 1102
- duplicate observations on line 1116
Of all those checks, topography is the only one for which a detailed
debug
level 4 log message is currently being written.
Presumably, we could add debug level 4 log messages in all those
spots.
However, that would result in thousands and thousands of log messages.
Are
there specific spots in particular that would be useful without
overwhelming the user with thousands of log messages?
Thanks,
John
On Mon, Nov 30, 2020 at 9:31 AM George McCabe via RT
<met_help at ucar.edu>
wrote:
>
> Mon Nov 30 09:31:30 2020: Request 97623 was acted upon.
> Transaction: Given to johnhg (John Halley Gotway) by mccabe
> Queue: met_help
> Subject: Point_stat log file details
> Owner: johnhg
> Requestors: justin.tsu at nrlmry.navy.mil
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=97623 >
>
>
> This transaction appears to have no content
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #97623] Point_stat log file details
From: Tsu, Mr. Justin
Time: Mon Nov 30 13:06:52 2020
It would be nice to printout information for any of the
classifications that have the word "bad" in them. I find that term to
be fairly vague and would like to know more about what has made MET
deem a pair as bad. What I am doing is I currently have a list of
surface stations used by Verify (NRL's verification package) for a
particular DTG, tau and variable. This list is significantly larger
(by about 1800 rows) than the list output into MPR by MET for the same
run. I am trying to track where and why the stations were rejected in
MET and not in verify. Figured this was a good starting point
Justin
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Monday, November 30, 2020 12:00 PM
To: Tsu, Mr. Justin
Subject: Re: [rt.rap.ucar.edu #97623] Point_stat log file details
Justin,
I took a look in the source code and see where MET prints out a
Debug(4)
log message about skipping points due to topography differences.
Here's
that line:
https://github.com/dtcenter/MET/blob/17e1c9740224bf84a8bd0e84b5d254ccc5981bb8/met/src/libcode/vx_statistics/pair_data_point.cc#L876
In that source code I see we're increment rejection reason counts for:
- station id on line 788
- observation variable name on line 796 and 801
- quality control flag on line 812
- valid time on line 820
- bad obs value on line 836
- off the grid on line 848
*- topography on line 870 and 885*
- level mismatch on line 896, 906, and 918
- message type on line 988
- masking region on line 998, 1006, and 1014
- bad climo values on line 1038 and 1066
- bad forecast values on line 1102
- duplicate observations on line 1116
Of all those checks, topography is the only one for which a detailed
debug
level 4 log message is currently being written.
Presumably, we could add debug level 4 log messages in all those
spots.
However, that would result in thousands and thousands of log messages.
Are
there specific spots in particular that would be useful without
overwhelming the user with thousands of log messages?
Thanks,
John
On Mon, Nov 30, 2020 at 9:31 AM George McCabe via RT
<met_help at ucar.edu>
wrote:
>
> Mon Nov 30 09:31:30 2020: Request 97623 was acted upon.
> Transaction: Given to johnhg (John Halley Gotway) by mccabe
> Queue: met_help
> Subject: Point_stat log file details
> Owner: johnhg
> Requestors: justin.tsu at nrlmry.navy.mil
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=97623 >
>
>
> This transaction appears to have no content
>
------------------------------------------------
Subject: Point_stat log file details
From: John Halley Gotway
Time: Wed Dec 02 10:43:07 2020
Justin,
OK, I wrote this up as a GitHub issue:
https://github.com/dtcenter/MET/issues/1588
I'd recommend having detailed log messages for:
bad obs value, off the grid, topography (already present), bad fcst
value,
duplicates
But not for:
SID exclusion, obs type, valid time, level mismatch, quality marker,
message type, masking region
We are weighing useful log messages vs swamping the user with too many
messages. The latter reasons are easily investigated by
re-configuring/re-running Point-Stat. The former set cannot be easily
investigated in this way.
Does that sound right to you?
Thanks,
John
On Mon, Nov 30, 2020 at 1:07 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=97623 >
>
> It would be nice to printout information for any of the
classifications
> that have the word "bad" in them. I find that term to be fairly
vague and
> would like to know more about what has made MET deem a pair as bad.
What I
> am doing is I currently have a list of surface stations used by
Verify
> (NRL's verification package) for a particular DTG, tau and variable.
This
> list is significantly larger (by about 1800 rows) than the list
output into
> MPR by MET for the same run. I am trying to track where and why the
> stations were rejected in MET and not in verify. Figured this was a
good
> starting point
>
> Justin
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Monday, November 30, 2020 12:00 PM
> To: Tsu, Mr. Justin
> Subject: Re: [rt.rap.ucar.edu #97623] Point_stat log file details
>
> Justin,
>
> I took a look in the source code and see where MET prints out a
Debug(4)
> log message about skipping points due to topography differences.
Here's
> that line:
>
>
>
https://github.com/dtcenter/MET/blob/17e1c9740224bf84a8bd0e84b5d254ccc5981bb8/met/src/libcode/vx_statistics/pair_data_point.cc#L876
>
> In that source code I see we're increment rejection reason counts
for:
> - station id on line 788
> - observation variable name on line 796 and 801
> - quality control flag on line 812
> - valid time on line 820
> - bad obs value on line 836
> - off the grid on line 848
> *- topography on line 870 and 885*
> - level mismatch on line 896, 906, and 918
> - message type on line 988
> - masking region on line 998, 1006, and 1014
> - bad climo values on line 1038 and 1066
> - bad forecast values on line 1102
> - duplicate observations on line 1116
>
> Of all those checks, topography is the only one for which a detailed
debug
> level 4 log message is currently being written.
>
> Presumably, we could add debug level 4 log messages in all those
spots.
> However, that would result in thousands and thousands of log
messages. Are
> there specific spots in particular that would be useful without
> overwhelming the user with thousands of log messages?
>
> Thanks,
> John
>
>
> On Mon, Nov 30, 2020 at 9:31 AM George McCabe via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > Mon Nov 30 09:31:30 2020: Request 97623 was acted upon.
> > Transaction: Given to johnhg (John Halley Gotway) by mccabe
> > Queue: met_help
> > Subject: Point_stat log file details
> > Owner: johnhg
> > Requestors: justin.tsu at nrlmry.navy.mil
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=97623 >
> >
> >
> > This transaction appears to have no content
> >
>
>
>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #97623] Point_stat log file details
From: Tsu, Mr. Justin
Time: Wed Dec 02 11:47:36 2020
Sounds good to me. Thanks John
Justin
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Wednesday, December 2, 2020 9:43 AM
To: Tsu, Mr. Justin
Subject: Re: [rt.rap.ucar.edu #97623] Point_stat log file details
Justin,
OK, I wrote this up as a GitHub issue:
https://github.com/dtcenter/MET/issues/1588
I'd recommend having detailed log messages for:
bad obs value, off the grid, topography (already present), bad fcst
value,
duplicates
But not for:
SID exclusion, obs type, valid time, level mismatch, quality marker,
message type, masking region
We are weighing useful log messages vs swamping the user with too many
messages. The latter reasons are easily investigated by
re-configuring/re-running Point-Stat. The former set cannot be easily
investigated in this way.
Does that sound right to you?
Thanks,
John
On Mon, Nov 30, 2020 at 1:07 PM Tsu, Mr. Justin via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=97623 >
>
> It would be nice to printout information for any of the
classifications
> that have the word "bad" in them. I find that term to be fairly
vague and
> would like to know more about what has made MET deem a pair as bad.
What I
> am doing is I currently have a list of surface stations used by
Verify
> (NRL's verification package) for a particular DTG, tau and variable.
This
> list is significantly larger (by about 1800 rows) than the list
output into
> MPR by MET for the same run. I am trying to track where and why the
> stations were rejected in MET and not in verify. Figured this was a
good
> starting point
>
> Justin
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Monday, November 30, 2020 12:00 PM
> To: Tsu, Mr. Justin
> Subject: Re: [rt.rap.ucar.edu #97623] Point_stat log file details
>
> Justin,
>
> I took a look in the source code and see where MET prints out a
Debug(4)
> log message about skipping points due to topography differences.
Here's
> that line:
>
>
>
https://github.com/dtcenter/MET/blob/17e1c9740224bf84a8bd0e84b5d254ccc5981bb8/met/src/libcode/vx_statistics/pair_data_point.cc#L876
>
> In that source code I see we're increment rejection reason counts
for:
> - station id on line 788
> - observation variable name on line 796 and 801
> - quality control flag on line 812
> - valid time on line 820
> - bad obs value on line 836
> - off the grid on line 848
> *- topography on line 870 and 885*
> - level mismatch on line 896, 906, and 918
> - message type on line 988
> - masking region on line 998, 1006, and 1014
> - bad climo values on line 1038 and 1066
> - bad forecast values on line 1102
> - duplicate observations on line 1116
>
> Of all those checks, topography is the only one for which a detailed
debug
> level 4 log message is currently being written.
>
> Presumably, we could add debug level 4 log messages in all those
spots.
> However, that would result in thousands and thousands of log
messages. Are
> there specific spots in particular that would be useful without
> overwhelming the user with thousands of log messages?
>
> Thanks,
> John
>
>
> On Mon, Nov 30, 2020 at 9:31 AM George McCabe via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > Mon Nov 30 09:31:30 2020: Request 97623 was acted upon.
> > Transaction: Given to johnhg (John Halley Gotway) by mccabe
> > Queue: met_help
> > Subject: Point_stat log file details
> > Owner: johnhg
> > Requestors: justin.tsu at nrlmry.navy.mil
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=97623 >
> >
> >
> > This transaction appears to have no content
> >
>
>
>
>
------------------------------------------------
More information about the Met_help
mailing list