[Met_help] [rt.rap.ucar.edu #83028] History for using point_stat to verify MSONET data
John Halley Gotway via RT
met_help at ucar.edu
Tue Jul 9 12:04:06 MDT 2019
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi, there,
I have run into some issues in trying to verify items like 2-m temperature
in point_stat vs. mesonet data. I noticed that no MSONET data for this
variable was present in the .stat file. In running point stat with the
verbosity set to 3, I noticed the following:
DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type MSONET, over
region G236, for interpolation method NEAREST(1), using 0 pairs.
DEBUG 3: Number of matched pairs = 0
DEBUG 3: Observations processed = 744234
DEBUG 3: Rejected: SID exclusion = 0
DEBUG 3: Rejected: GRIB code = 654463
DEBUG 3: Rejected: valid time = 0
DEBUG 3: Rejected: bad obs value = 0
DEBUG 3: Rejected: off the grid = 37
DEBUG 3: Rejected: level mismatch = 84847
DEBUG 3: Rejected: quality marker = 0
DEBUG 3: Rejected: message type = 4887
DEBUG 3: Rejected: masking region = 0
DEBUG 3: Rejected: bad fcst value = 0
DEBUG 3: Rejected: duplicates = 0
I am wondering - why no matched pairs? There should be a lot of mesonet
surface-level data to verify (VSDB usually has a very large ob count). We
don't get this problem with ADPSFC. There are MSONET .stat lines for
upper-air data, but for some reason not 2-m or 10-m data. Think we could
find out why?
Thanks!
Perry
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: using point_stat to verify MSONET data
From: John Halley Gotway
Time: Wed Nov 15 09:32:01 2017
Perry,
I suspect the source of this discrepancy is the logic for handling
message
types.
In Point-Stat, the APDSFC and SFCSHP (and ONLYSF as the union of
these)
message types are treated in a special way. Basically, the code
assumes
these observations occur at the surface... so we don't actually check
their
"level" value when verifying against forecasts as the surface (like 2-
m
temperature and 10-m winds).
Currently, this special "surface" logic is *not* applied to the MSONET
message type.
Should it be?
If so, the easiest way of fixing this would be to just add MSONET to
the
list of surface types (ADPSFC, SFCSHP, MSONET).
Perhaps a more robust option would be moving the list of surface
message
types to a config file. Then users could edit it when needed without
needing to make changes to the code.
John
On Wed, Nov 15, 2017 at 8:25 AM, perry.shafran at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> Wed Nov 15 08:25:08 2017: Request 83028 was acted upon.
> Transaction: Ticket created by perry.shafran at noaa.gov
> Queue: met_help
> Subject: using point_stat to verify MSONET data
> Owner: Nobody
> Requestors: perry.shafran at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=83028 >
>
>
> Hi, there,
>
> I have run into some issues in trying to verify items like 2-m
temperature
> in point_stat vs. mesonet data. I noticed that no MSONET data for
this
> variable was present in the .stat file. In running point stat with
the
> verbosity set to 3, I noticed the following:
>
> DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type
MSONET, over
> region G236, for interpolation method NEAREST(1), using 0 pairs.
> DEBUG 3: Number of matched pairs = 0
> DEBUG 3: Observations processed = 744234
> DEBUG 3: Rejected: SID exclusion = 0
> DEBUG 3: Rejected: GRIB code = 654463
> DEBUG 3: Rejected: valid time = 0
> DEBUG 3: Rejected: bad obs value = 0
> DEBUG 3: Rejected: off the grid = 37
> DEBUG 3: Rejected: level mismatch = 84847
> DEBUG 3: Rejected: quality marker = 0
> DEBUG 3: Rejected: message type = 4887
> DEBUG 3: Rejected: masking region = 0
> DEBUG 3: Rejected: bad fcst value = 0
> DEBUG 3: Rejected: duplicates = 0
>
> I am wondering - why no matched pairs? There should be a lot of
mesonet
> surface-level data to verify (VSDB usually has a very large ob
count). We
> don't get this problem with ADPSFC. There are MSONET .stat lines
for
> upper-air data, but for some reason not 2-m or 10-m data. Think we
could
> find out why?
>
> Thanks!
>
> Perry
>
>
------------------------------------------------
Subject: using point_stat to verify MSONET data
From: perry.shafran at noaa.gov
Time: Wed Nov 15 09:45:07 2017
Hi, John,
So currently, applying that surface logic is something that can be
done by
me, or is that something that you need to do in the MET code on your
end?
Thanks!
Perry
On Wed, Nov 15, 2017 at 11:32 AM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Perry,
>
> I suspect the source of this discrepancy is the logic for handling
message
> types.
>
> In Point-Stat, the APDSFC and SFCSHP (and ONLYSF as the union of
these)
> message types are treated in a special way. Basically, the code
assumes
> these observations occur at the surface... so we don't actually
check their
> "level" value when verifying against forecasts as the surface (like
2-m
> temperature and 10-m winds).
>
> Currently, this special "surface" logic is *not* applied to the
MSONET
> message type.
>
> Should it be?
>
> If so, the easiest way of fixing this would be to just add MSONET to
the
> list of surface types (ADPSFC, SFCSHP, MSONET).
>
> Perhaps a more robust option would be moving the list of surface
message
> types to a config file. Then users could edit it when needed
without
> needing to make changes to the code.
>
> John
>
> On Wed, Nov 15, 2017 at 8:25 AM, perry.shafran at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > Wed Nov 15 08:25:08 2017: Request 83028 was acted upon.
> > Transaction: Ticket created by perry.shafran at noaa.gov
> > Queue: met_help
> > Subject: using point_stat to verify MSONET data
> > Owner: Nobody
> > Requestors: perry.shafran at noaa.gov
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=83028 >
> >
> >
> > Hi, there,
> >
> > I have run into some issues in trying to verify items like 2-m
> temperature
> > in point_stat vs. mesonet data. I noticed that no MSONET data for
this
> > variable was present in the .stat file. In running point stat
with the
> > verbosity set to 3, I noticed the following:
> >
> > DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type
MSONET,
> over
> > region G236, for interpolation method NEAREST(1), using 0 pairs.
> > DEBUG 3: Number of matched pairs = 0
> > DEBUG 3: Observations processed = 744234
> > DEBUG 3: Rejected: SID exclusion = 0
> > DEBUG 3: Rejected: GRIB code = 654463
> > DEBUG 3: Rejected: valid time = 0
> > DEBUG 3: Rejected: bad obs value = 0
> > DEBUG 3: Rejected: off the grid = 37
> > DEBUG 3: Rejected: level mismatch = 84847
> > DEBUG 3: Rejected: quality marker = 0
> > DEBUG 3: Rejected: message type = 4887
> > DEBUG 3: Rejected: masking region = 0
> > DEBUG 3: Rejected: bad fcst value = 0
> > DEBUG 3: Rejected: duplicates = 0
> >
> > I am wondering - why no matched pairs? There should be a lot of
mesonet
> > surface-level data to verify (VSDB usually has a very large ob
count).
> We
> > don't get this problem with ADPSFC. There are MSONET .stat lines
for
> > upper-air data, but for some reason not 2-m or 10-m data. Think
we could
> > find out why?
> >
> > Thanks!
> >
> > Perry
> >
> >
>
>
------------------------------------------------
Subject: using point_stat to verify MSONET data
From: John Halley Gotway
Time: Wed Nov 15 09:59:08 2017
Perry,
It's done by the MET code...
In util_constants.h:
static const char onlysf_msg_typ_str[] = "ADPSFC SFCSHP";
And then in pair_data_point.cc:
// For vertical levels, check for a surface message type or if the
// observation height falls within the requested range.
else if(obs_info->level().type() == LevelType_Vert) {
if(strstr(onlysf_msg_typ_str, hdr_typ_str) == NULL &&
(obs_hgt < obs_info->level().lower() ||
obs_hgt > obs_info->level().upper())) {
rej_lvl++;
return;
}
}
In the logic above, if the message type of the current observation
shows up
in the "only_msg_typ_str", then we ** DO NOT ** reject it.
The quickest way to fix it would be defining:
static const char surface_msg_typ_list[] = "ADPSFC SFCSHP MSONET";
And then referencing this string in the code.
But a more robust option would be moving this to the configuration
file:
surface_message_types = [ "ADPSFC", "SFCSHP", "MSONET" ];
Then if someone were using ascii observations with a custom list of
message
types, they could modify the list in the config file to control the
matching logic.
Do you have a preference on the type of solution?
And does this logic need to be included in met-6.1?
Thanks,
John
On Wed, Nov 15, 2017 at 9:45 AM, perry.shafran at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=83028 >
>
> Hi, John,
>
> So currently, applying that surface logic is something that can be
done by
> me, or is that something that you need to do in the MET code on your
end?
>
> Thanks!
>
> Perry
>
> On Wed, Nov 15, 2017 at 11:32 AM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Perry,
> >
> > I suspect the source of this discrepancy is the logic for handling
> message
> > types.
> >
> > In Point-Stat, the APDSFC and SFCSHP (and ONLYSF as the union of
these)
> > message types are treated in a special way. Basically, the code
assumes
> > these observations occur at the surface... so we don't actually
check
> their
> > "level" value when verifying against forecasts as the surface
(like 2-m
> > temperature and 10-m winds).
> >
> > Currently, this special "surface" logic is *not* applied to the
MSONET
> > message type.
> >
> > Should it be?
> >
> > If so, the easiest way of fixing this would be to just add MSONET
to the
> > list of surface types (ADPSFC, SFCSHP, MSONET).
> >
> > Perhaps a more robust option would be moving the list of surface
message
> > types to a config file. Then users could edit it when needed
without
> > needing to make changes to the code.
> >
> > John
> >
> > On Wed, Nov 15, 2017 at 8:25 AM, perry.shafran at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > Wed Nov 15 08:25:08 2017: Request 83028 was acted upon.
> > > Transaction: Ticket created by perry.shafran at noaa.gov
> > > Queue: met_help
> > > Subject: using point_stat to verify MSONET data
> > > Owner: Nobody
> > > Requestors: perry.shafran at noaa.gov
> > > Status: new
> > > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=83028
> >
> > >
> > >
> > > Hi, there,
> > >
> > > I have run into some issues in trying to verify items like 2-m
> > temperature
> > > in point_stat vs. mesonet data. I noticed that no MSONET data
for this
> > > variable was present in the .stat file. In running point stat
with the
> > > verbosity set to 3, I noticed the following:
> > >
> > > DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type
MSONET,
> > over
> > > region G236, for interpolation method NEAREST(1), using 0 pairs.
> > > DEBUG 3: Number of matched pairs = 0
> > > DEBUG 3: Observations processed = 744234
> > > DEBUG 3: Rejected: SID exclusion = 0
> > > DEBUG 3: Rejected: GRIB code = 654463
> > > DEBUG 3: Rejected: valid time = 0
> > > DEBUG 3: Rejected: bad obs value = 0
> > > DEBUG 3: Rejected: off the grid = 37
> > > DEBUG 3: Rejected: level mismatch = 84847
> > > DEBUG 3: Rejected: quality marker = 0
> > > DEBUG 3: Rejected: message type = 4887
> > > DEBUG 3: Rejected: masking region = 0
> > > DEBUG 3: Rejected: bad fcst value = 0
> > > DEBUG 3: Rejected: duplicates = 0
> > >
> > > I am wondering - why no matched pairs? There should be a lot of
> mesonet
> > > surface-level data to verify (VSDB usually has a very large ob
count).
> > We
> > > don't get this problem with ADPSFC. There are MSONET .stat
lines for
> > > upper-air data, but for some reason not 2-m or 10-m data. Think
we
> could
> > > find out why?
> > >
> > > Thanks!
> > >
> > > Perry
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: using point_stat to verify MSONET data
From: perry.shafran at noaa.gov
Time: Wed Nov 15 10:10:00 2017
Hi, John,
I think the config file usage would be best.
As for when to make that change, it really sounded like Tara wanted to
fix
the code as it stands now for release at the end of this month, so
let's
not add new things to it. MET 6.2 is fine. I don't think anyone's
screaming to verify mesonet data right this minute.
Thanks!
Perry
On Wed, Nov 15, 2017 at 11:59 AM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Perry,
>
> It's done by the MET code...
>
> In util_constants.h:
>
> static const char onlysf_msg_typ_str[] = "ADPSFC SFCSHP";
>
> And then in pair_data_point.cc:
>
> // For vertical levels, check for a surface message type or if
the
> // observation height falls within the requested range.
> else if(obs_info->level().type() == LevelType_Vert) {
>
> if(strstr(onlysf_msg_typ_str, hdr_typ_str) == NULL &&
> (obs_hgt < obs_info->level().lower() ||
> obs_hgt > obs_info->level().upper())) {
> rej_lvl++;
> return;
> }
> }
>
> In the logic above, if the message type of the current observation
shows up
> in the "only_msg_typ_str", then we ** DO NOT ** reject it.
>
> The quickest way to fix it would be defining:
> static const char surface_msg_typ_list[] = "ADPSFC SFCSHP
MSONET";
> And then referencing this string in the code.
>
> But a more robust option would be moving this to the configuration
file:
> surface_message_types = [ "ADPSFC", "SFCSHP", "MSONET" ];
>
> Then if someone were using ascii observations with a custom list of
message
> types, they could modify the list in the config file to control the
> matching logic.
>
> Do you have a preference on the type of solution?
>
> And does this logic need to be included in met-6.1?
>
> Thanks,
> John
>
>
> On Wed, Nov 15, 2017 at 9:45 AM, perry.shafran at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=83028 >
> >
> > Hi, John,
> >
> > So currently, applying that surface logic is something that can be
done
> by
> > me, or is that something that you need to do in the MET code on
your end?
> >
> > Thanks!
> >
> > Perry
> >
> > On Wed, Nov 15, 2017 at 11:32 AM, John Halley Gotway via RT <
> > met_help at ucar.edu> wrote:
> >
> > > Perry,
> > >
> > > I suspect the source of this discrepancy is the logic for
handling
> > message
> > > types.
> > >
> > > In Point-Stat, the APDSFC and SFCSHP (and ONLYSF as the union of
these)
> > > message types are treated in a special way. Basically, the code
> assumes
> > > these observations occur at the surface... so we don't actually
check
> > their
> > > "level" value when verifying against forecasts as the surface
(like 2-m
> > > temperature and 10-m winds).
> > >
> > > Currently, this special "surface" logic is *not* applied to the
MSONET
> > > message type.
> > >
> > > Should it be?
> > >
> > > If so, the easiest way of fixing this would be to just add
MSONET to
> the
> > > list of surface types (ADPSFC, SFCSHP, MSONET).
> > >
> > > Perhaps a more robust option would be moving the list of surface
> message
> > > types to a config file. Then users could edit it when needed
without
> > > needing to make changes to the code.
> > >
> > > John
> > >
> > > On Wed, Nov 15, 2017 at 8:25 AM, perry.shafran at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > Wed Nov 15 08:25:08 2017: Request 83028 was acted upon.
> > > > Transaction: Ticket created by perry.shafran at noaa.gov
> > > > Queue: met_help
> > > > Subject: using point_stat to verify MSONET data
> > > > Owner: Nobody
> > > > Requestors: perry.shafran at noaa.gov
> > > > Status: new
> > > > Ticket <URL: https://rt.rap.ucar.edu/rt/
> Ticket/Display.html?id=83028
> > >
> > > >
> > > >
> > > > Hi, there,
> > > >
> > > > I have run into some issues in trying to verify items like 2-m
> > > temperature
> > > > in point_stat vs. mesonet data. I noticed that no MSONET data
for
> this
> > > > variable was present in the .stat file. In running point stat
with
> the
> > > > verbosity set to 3, I noticed the following:
> > > >
> > > > DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation type
> MSONET,
> > > over
> > > > region G236, for interpolation method NEAREST(1), using 0
pairs.
> > > > DEBUG 3: Number of matched pairs = 0
> > > > DEBUG 3: Observations processed = 744234
> > > > DEBUG 3: Rejected: SID exclusion = 0
> > > > DEBUG 3: Rejected: GRIB code = 654463
> > > > DEBUG 3: Rejected: valid time = 0
> > > > DEBUG 3: Rejected: bad obs value = 0
> > > > DEBUG 3: Rejected: off the grid = 37
> > > > DEBUG 3: Rejected: level mismatch = 84847
> > > > DEBUG 3: Rejected: quality marker = 0
> > > > DEBUG 3: Rejected: message type = 4887
> > > > DEBUG 3: Rejected: masking region = 0
> > > > DEBUG 3: Rejected: bad fcst value = 0
> > > > DEBUG 3: Rejected: duplicates = 0
> > > >
> > > > I am wondering - why no matched pairs? There should be a lot
of
> > mesonet
> > > > surface-level data to verify (VSDB usually has a very large ob
> count).
> > > We
> > > > don't get this problem with ADPSFC. There are MSONET .stat
lines for
> > > > upper-air data, but for some reason not 2-m or 10-m data.
Think we
> > could
> > > > find out why?
> > > >
> > > > Thanks!
> > > >
> > > > Perry
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: using point_stat to verify MSONET data
From: John Halley Gotway
Time: Wed Nov 15 10:43:18 2017
Perry,
OK, I created a development ticket to capture this request, and will
resolve this met-help ticket now.
Thanks,
John
On Wed, Nov 15, 2017 at 10:10 AM, perry.shafran at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=83028 >
>
> Hi, John,
>
> I think the config file usage would be best.
>
> As for when to make that change, it really sounded like Tara wanted
to fix
> the code as it stands now for release at the end of this month, so
let's
> not add new things to it. MET 6.2 is fine. I don't think anyone's
> screaming to verify mesonet data right this minute.
>
> Thanks!
>
> Perry
>
> On Wed, Nov 15, 2017 at 11:59 AM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Perry,
> >
> > It's done by the MET code...
> >
> > In util_constants.h:
> >
> > static const char onlysf_msg_typ_str[] = "ADPSFC SFCSHP";
> >
> > And then in pair_data_point.cc:
> >
> > // For vertical levels, check for a surface message type or if
the
> > // observation height falls within the requested range.
> > else if(obs_info->level().type() == LevelType_Vert) {
> >
> > if(strstr(onlysf_msg_typ_str, hdr_typ_str) == NULL &&
> > (obs_hgt < obs_info->level().lower() ||
> > obs_hgt > obs_info->level().upper())) {
> > rej_lvl++;
> > return;
> > }
> > }
> >
> > In the logic above, if the message type of the current observation
shows
> up
> > in the "only_msg_typ_str", then we ** DO NOT ** reject it.
> >
> > The quickest way to fix it would be defining:
> > static const char surface_msg_typ_list[] = "ADPSFC SFCSHP
MSONET";
> > And then referencing this string in the code.
> >
> > But a more robust option would be moving this to the configuration
file:
> > surface_message_types = [ "ADPSFC", "SFCSHP", "MSONET" ];
> >
> > Then if someone were using ascii observations with a custom list
of
> message
> > types, they could modify the list in the config file to control
the
> > matching logic.
> >
> > Do you have a preference on the type of solution?
> >
> > And does this logic need to be included in met-6.1?
> >
> > Thanks,
> > John
> >
> >
> > On Wed, Nov 15, 2017 at 9:45 AM, perry.shafran at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=83028 >
> > >
> > > Hi, John,
> > >
> > > So currently, applying that surface logic is something that can
be done
> > by
> > > me, or is that something that you need to do in the MET code on
your
> end?
> > >
> > > Thanks!
> > >
> > > Perry
> > >
> > > On Wed, Nov 15, 2017 at 11:32 AM, John Halley Gotway via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > > Perry,
> > > >
> > > > I suspect the source of this discrepancy is the logic for
handling
> > > message
> > > > types.
> > > >
> > > > In Point-Stat, the APDSFC and SFCSHP (and ONLYSF as the union
of
> these)
> > > > message types are treated in a special way. Basically, the
code
> > assumes
> > > > these observations occur at the surface... so we don't
actually check
> > > their
> > > > "level" value when verifying against forecasts as the surface
(like
> 2-m
> > > > temperature and 10-m winds).
> > > >
> > > > Currently, this special "surface" logic is *not* applied to
the
> MSONET
> > > > message type.
> > > >
> > > > Should it be?
> > > >
> > > > If so, the easiest way of fixing this would be to just add
MSONET to
> > the
> > > > list of surface types (ADPSFC, SFCSHP, MSONET).
> > > >
> > > > Perhaps a more robust option would be moving the list of
surface
> > message
> > > > types to a config file. Then users could edit it when needed
without
> > > > needing to make changes to the code.
> > > >
> > > > John
> > > >
> > > > On Wed, Nov 15, 2017 at 8:25 AM, perry.shafran at noaa.gov via RT
<
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > >
> > > > > Wed Nov 15 08:25:08 2017: Request 83028 was acted upon.
> > > > > Transaction: Ticket created by perry.shafran at noaa.gov
> > > > > Queue: met_help
> > > > > Subject: using point_stat to verify MSONET data
> > > > > Owner: Nobody
> > > > > Requestors: perry.shafran at noaa.gov
> > > > > Status: new
> > > > > Ticket <URL: https://rt.rap.ucar.edu/rt/
> > Ticket/Display.html?id=83028
> > > >
> > > > >
> > > > >
> > > > > Hi, there,
> > > > >
> > > > > I have run into some issues in trying to verify items like
2-m
> > > > temperature
> > > > > in point_stat vs. mesonet data. I noticed that no MSONET
data for
> > this
> > > > > variable was present in the .stat file. In running point
stat with
> > the
> > > > > verbosity set to 3, I noticed the following:
> > > > >
> > > > > DEBUG 2: Processing TMP/Z2 versus TMP/Z2, for observation
type
> > MSONET,
> > > > over
> > > > > region G236, for interpolation method NEAREST(1), using 0
pairs.
> > > > > DEBUG 3: Number of matched pairs = 0
> > > > > DEBUG 3: Observations processed = 744234
> > > > > DEBUG 3: Rejected: SID exclusion = 0
> > > > > DEBUG 3: Rejected: GRIB code = 654463
> > > > > DEBUG 3: Rejected: valid time = 0
> > > > > DEBUG 3: Rejected: bad obs value = 0
> > > > > DEBUG 3: Rejected: off the grid = 37
> > > > > DEBUG 3: Rejected: level mismatch = 84847
> > > > > DEBUG 3: Rejected: quality marker = 0
> > > > > DEBUG 3: Rejected: message type = 4887
> > > > > DEBUG 3: Rejected: masking region = 0
> > > > > DEBUG 3: Rejected: bad fcst value = 0
> > > > > DEBUG 3: Rejected: duplicates = 0
> > > > >
> > > > > I am wondering - why no matched pairs? There should be a
lot of
> > > mesonet
> > > > > surface-level data to verify (VSDB usually has a very large
ob
> > count).
> > > > We
> > > > > don't get this problem with ADPSFC. There are MSONET .stat
lines
> for
> > > > > upper-air data, but for some reason not 2-m or 10-m data.
Think we
> > > could
> > > > > find out why?
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Perry
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
More information about the Met_help
mailing list