[Met_help] [rt.rap.ucar.edu #86203] History for point_stat with dropsonde data
John Halley Gotway via RT
met_help at ucar.edu
Tue Jul 9 12:03:25 MDT 2019
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi,
I am trying to use point_stat to verify model output with dropsonde data.
For some reason I am getting: using 0 pairs with out any error.
Here is what I did:
Forecast grib files located:
/scratch4/BMC/fim/Keren.Rosado/MET/data/sample_fcst/2016092900/
gfs.t00z.pgrb2.0p25.f018
Observation:
/scratch4/BMC/fim/Keren.Rosado/MET/data/sample_obs/dropsonde/20160929A1/
g143345049.nc
I converted the ascii data to netcdf file using ascii2nc .
Configure file:
/scratch4/BMC/fim/Keren.Rosado/MET/tutorial_Matthew_GF/config/
PointStatConfig_tutorial
For the configure file I originally had it set-up P1000, P900, P850....P100
but trying to figuring out why there are 0 pairs, I set-up a particular
pressure level where I knew there were observations e.g. 858.1.
I am also using the mask option and I double check that there is dropsonde
data for the masked area.
I have a log file located: /scratch4/BMC/fim/Keren.Rosado/MET/mask/858.1.log
Is there a configuration option for point_stat to count as a pair a level
close enough ?
Thanks,
Keren
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: point_stat with dropsonde data
From: John Halley Gotway
Time: Mon Jul 16 13:13:36 2018
Keren,
I see that you have a question as to why you are getting 0 matched
pairs.
When running point_stat try increasing the verbosity logging level to
3
using the "-v 3" command line option. That'll dump out reason codes
for
why the observations were not used.
For example, I ran:
cd /scratch4/BMC/dtc/John.H.Gotway/MET/MET_Help/rosado_data_20180716
module use /contrib/modulefiles
module load met/6.0
point_stat gfs.t00z.pgrb2.0p25.f018 g143345049.nc
PointStatConfig_tutorial
-outdir out -v 3 -log run_ps.log
Looking at the output, you did get 1 matched pair for TMP and RH at
1000mb. Here's a sample of the log output from that run explaining
why you
got 1 matched pair:
DEBUG 2: Processing TMP/P1000 versus TMP/P1000, for observation type
ADPUPA, over region FULL, for interpolation method BILIN(4), using 1
pairs.
DEBUG 3: Number of matched pairs = 1
DEBUG 3: Observations processed = 2340
DEBUG 3: Rejected: SID exclusion = 0
DEBUG 3: Rejected: GRIB code = 1755
DEBUG 3: Rejected: valid time = 0
DEBUG 3: Rejected: bad obs value = 320
DEBUG 3: Rejected: off the grid = 4
DEBUG 3: Rejected: level mismatch = 260
DEBUG 3: Rejected: quality marker = 0
DEBUG 3: Rejected: message type = 0
DEBUG 3: Rejected: masking region = 0
DEBUG 3: Rejected: bad fcst value = 0
DEBUG 3: Rejected: duplicates = 0
But looking at your point observations, I see that there's only data
for a
single station named "N42RF". So perhaps having 1 matched pair is
exactly
what you'd expect for this data. If that's the case, there's no need
to
compute this over two different masking regions. Instead, just use
'grid =
["FULL"];'.
But perhaps you're wondering why you got 0 matched pairs for
temperature at
850? Looking closely at your data, I see that the pressure level of
the
temperature observations range from 856.1 to 1005. That's true of all
the
observation variables. You only have data in that pressure range.
FYI, here's how I figured that out...
# Load the R module
> module load R
# Run this Rscript to dump NetCDF point obs out to ascii
> Rscript /contrib/met/6.0/scripts/Rscripts/pntnc2ascii.R
g143345049.nc >
g143345049.txt
# Sort the unique pressure levels numerically and see the range of
values
> cat g143345049.txt | awk '{print $8}' | egrep -v NA | sort -nu
Thanks,
John
On Fri, Jul 13, 2018 at 3:04 PM Keren Rosado - NOAA Affiliate via RT <
met_help at ucar.edu> wrote:
>
> Fri Jul 13 15:04:18 2018: Request 86203 was acted upon.
> Transaction: Ticket created by keren.rosado at noaa.gov
> Queue: met_help
> Subject: point_stat with dropsonde data
> Owner: Nobody
> Requestors: keren.rosado at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=86203 >
>
>
> Hi,
>
> I am trying to use point_stat to verify model output with dropsonde
data.
> For some reason I am getting: using 0 pairs with out any error.
>
> Here is what I did:
> Forecast grib files located:
> /scratch4/BMC/fim/Keren.Rosado/MET/data/sample_fcst/2016092900/
> gfs.t00z.pgrb2.0p25.f018
>
> Observation:
>
/scratch4/BMC/fim/Keren.Rosado/MET/data/sample_obs/dropsonde/20160929A1/
> g143345049.nc
> I converted the ascii data to netcdf file using ascii2nc .
>
>
> Configure file:
> /scratch4/BMC/fim/Keren.Rosado/MET/tutorial_Matthew_GF/config/
> PointStatConfig_tutorial
>
> For the configure file I originally had it set-up P1000, P900,
P850....P100
> but trying to figuring out why there are 0 pairs, I set-up a
particular
> pressure level where I knew there were observations e.g. 858.1.
>
> I am also using the mask option and I double check that there is
dropsonde
> data for the masked area.
>
> I have a log file located:
> /scratch4/BMC/fim/Keren.Rosado/MET/mask/858.1.log
>
> Is there a configuration option for point_stat to count as a pair a
level
> close enough ?
>
>
> Thanks,
>
> Keren
>
>
------------------------------------------------
Subject: point_stat with dropsonde data
From: Keren Rosado - NOAA Affiliate
Time: Mon Jul 16 14:22:04 2018
Hi John,
I know that I only have data for thoes levels, that is why I those are
the
level in the configure file "P858.1", "P857.6", "P857.1", "P856.6",
"P856.1".
I still don't understand if the observations exist in thoes levels,
why I
don't get match pairs.
Thanks,
Keren
----
Keren Rosado, Ph.D.
NCAS-M Postdoctoral Fellow
NOAA ESRL
Office: (303) 497-5907
On Mon, Jul 16, 2018 at 1:13 PM, John Halley Gotway via RT <
met_help at ucar.edu> wrote:
> Keren,
>
> I see that you have a question as to why you are getting 0 matched
pairs.
> When running point_stat try increasing the verbosity logging level
to 3
> using the "-v 3" command line option. That'll dump out reason codes
for
> why the observations were not used.
>
> For example, I ran:
>
> cd /scratch4/BMC/dtc/John.H.Gotway/MET/MET_Help/rosado_data_20180716
> module use /contrib/modulefiles
> module load met/6.0
> point_stat gfs.t00z.pgrb2.0p25.f018 g143345049.nc
PointStatConfig_tutorial
> -outdir out -v 3 -log run_ps.log
>
> Looking at the output, you did get 1 matched pair for TMP and RH at
> 1000mb. Here's a sample of the log output from that run explaining
why you
> got 1 matched pair:
>
> DEBUG 2: Processing TMP/P1000 versus TMP/P1000, for observation type
> ADPUPA, over region FULL, for interpolation method BILIN(4), using 1
pairs.
> DEBUG 3: Number of matched pairs = 1
> DEBUG 3: Observations processed = 2340
> DEBUG 3: Rejected: SID exclusion = 0
> DEBUG 3: Rejected: GRIB code = 1755
> DEBUG 3: Rejected: valid time = 0
> DEBUG 3: Rejected: bad obs value = 320
> DEBUG 3: Rejected: off the grid = 4
> DEBUG 3: Rejected: level mismatch = 260
> DEBUG 3: Rejected: quality marker = 0
> DEBUG 3: Rejected: message type = 0
> DEBUG 3: Rejected: masking region = 0
> DEBUG 3: Rejected: bad fcst value = 0
> DEBUG 3: Rejected: duplicates = 0
>
> But looking at your point observations, I see that there's only data
for a
> single station named "N42RF". So perhaps having 1 matched pair is
exactly
> what you'd expect for this data. If that's the case, there's no
need to
> compute this over two different masking regions. Instead, just use
'grid =
> ["FULL"];'.
>
> But perhaps you're wondering why you got 0 matched pairs for
temperature at
> 850? Looking closely at your data, I see that the pressure level of
the
> temperature observations range from 856.1 to 1005. That's true of
all the
> observation variables. You only have data in that pressure range.
>
> FYI, here's how I figured that out...
> # Load the R module
> > module load R
> # Run this Rscript to dump NetCDF point obs out to ascii
> > Rscript /contrib/met/6.0/scripts/Rscripts/pntnc2ascii.R
g143345049.nc >
> g143345049.txt
> # Sort the unique pressure levels numerically and see the range of
values
> > cat g143345049.txt | awk '{print $8}' | egrep -v NA | sort -nu
>
> Thanks,
> John
>
>
> On Fri, Jul 13, 2018 at 3:04 PM Keren Rosado - NOAA Affiliate via RT
<
> met_help at ucar.edu> wrote:
>
> >
> > Fri Jul 13 15:04:18 2018: Request 86203 was acted upon.
> > Transaction: Ticket created by keren.rosado at noaa.gov
> > Queue: met_help
> > Subject: point_stat with dropsonde data
> > Owner: Nobody
> > Requestors: keren.rosado at noaa.gov
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=86203 >
> >
> >
> > Hi,
> >
> > I am trying to use point_stat to verify model output with
dropsonde data.
> > For some reason I am getting: using 0 pairs with out any error.
> >
> > Here is what I did:
> > Forecast grib files located:
> > /scratch4/BMC/fim/Keren.Rosado/MET/data/sample_fcst/2016092900/
> > gfs.t00z.pgrb2.0p25.f018
> >
> > Observation:
> >
/scratch4/BMC/fim/Keren.Rosado/MET/data/sample_obs/dropsonde/20160929A1/
> > g143345049.nc
> > I converted the ascii data to netcdf file using ascii2nc .
> >
> >
> > Configure file:
> > /scratch4/BMC/fim/Keren.Rosado/MET/tutorial_Matthew_GF/config/
> > PointStatConfig_tutorial
> >
> > For the configure file I originally had it set-up P1000, P900,
> P850....P100
> > but trying to figuring out why there are 0 pairs, I set-up a
particular
> > pressure level where I knew there were observations e.g. 858.1.
> >
> > I am also using the mask option and I double check that there is
> dropsonde
> > data for the masked area.
> >
> > I have a log file located:
> > /scratch4/BMC/fim/Keren.Rosado/MET/mask/858.1.log
> >
> > Is there a configuration option for point_stat to count as a pair
a level
> > close enough ?
> >
> >
> > Thanks,
> >
> > Keren
> >
> >
>
>
------------------------------------------------
Subject: point_stat with dropsonde data
From: Keren Rosado - NOAA Affiliate
Time: Mon Jul 16 14:37:53 2018
Hi John,
Now I see that the grib file is the problem. There is no level 858.1
is 850
or 860.
Is there a way that I can tell MET to interpolate to the nearest level
and
produce a match.
I have seen aircraft observations compared to model output using MET
before
and I guess the observations are not exactly the same level as
standard
model level.
Thanks,
Keren
----
Keren Rosado, Ph.D.
NCAS-M Postdoctoral Fellow
NOAA ESRL
Office: (303) 497-5907
On Mon, Jul 16, 2018 at 2:21 PM, Keren Rosado - NOAA Affiliate <
keren.rosado at noaa.gov> wrote:
> Hi John,
>
> I know that I only have data for thoes levels, that is why I those
are the
> level in the configure file "P858.1", "P857.6", "P857.1", "P856.6",
> "P856.1".
>
> I still don't understand if the observations exist in thoes levels,
why I
> don't get match pairs.
>
> Thanks,
>
> Keren
>
> ----
> Keren Rosado, Ph.D.
> NCAS-M Postdoctoral Fellow
> NOAA ESRL
> Office: (303) 497-5907
>
> On Mon, Jul 16, 2018 at 1:13 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
>> Keren,
>>
>> I see that you have a question as to why you are getting 0 matched
pairs.
>> When running point_stat try increasing the verbosity logging level
to 3
>> using the "-v 3" command line option. That'll dump out reason
codes for
>> why the observations were not used.
>>
>> For example, I ran:
>>
>> cd
/scratch4/BMC/dtc/John.H.Gotway/MET/MET_Help/rosado_data_20180716
>> module use /contrib/modulefiles
>> module load met/6.0
>> point_stat gfs.t00z.pgrb2.0p25.f018 g143345049.nc
>> PointStatConfig_tutorial
>> -outdir out -v 3 -log run_ps.log
>>
>> Looking at the output, you did get 1 matched pair for TMP and RH at
>> 1000mb. Here's a sample of the log output from that run explaining
why
>> you
>> got 1 matched pair:
>>
>> DEBUG 2: Processing TMP/P1000 versus TMP/P1000, for observation
type
>> ADPUPA, over region FULL, for interpolation method BILIN(4), using
1
>> pairs.
>> DEBUG 3: Number of matched pairs = 1
>> DEBUG 3: Observations processed = 2340
>> DEBUG 3: Rejected: SID exclusion = 0
>> DEBUG 3: Rejected: GRIB code = 1755
>> DEBUG 3: Rejected: valid time = 0
>> DEBUG 3: Rejected: bad obs value = 320
>> DEBUG 3: Rejected: off the grid = 4
>> DEBUG 3: Rejected: level mismatch = 260
>> DEBUG 3: Rejected: quality marker = 0
>> DEBUG 3: Rejected: message type = 0
>> DEBUG 3: Rejected: masking region = 0
>> DEBUG 3: Rejected: bad fcst value = 0
>> DEBUG 3: Rejected: duplicates = 0
>>
>> But looking at your point observations, I see that there's only
data for a
>> single station named "N42RF". So perhaps having 1 matched pair is
exactly
>> what you'd expect for this data. If that's the case, there's no
need to
>> compute this over two different masking regions. Instead, just use
'grid
>> =
>> ["FULL"];'.
>>
>> But perhaps you're wondering why you got 0 matched pairs for
temperature
>> at
>> 850? Looking closely at your data, I see that the pressure level
of the
>> temperature observations range from 856.1 to 1005. That's true of
all the
>> observation variables. You only have data in that pressure range.
>>
>> FYI, here's how I figured that out...
>> # Load the R module
>> > module load R
>> # Run this Rscript to dump NetCDF point obs out to ascii
>> > Rscript /contrib/met/6.0/scripts/Rscripts/pntnc2ascii.R
g143345049.nc >
>> g143345049.txt
>> # Sort the unique pressure levels numerically and see the range of
values
>> > cat g143345049.txt | awk '{print $8}' | egrep -v NA | sort -nu
>>
>> Thanks,
>> John
>>
>>
>> On Fri, Jul 13, 2018 at 3:04 PM Keren Rosado - NOAA Affiliate via
RT <
>> met_help at ucar.edu> wrote:
>>
>> >
>> > Fri Jul 13 15:04:18 2018: Request 86203 was acted upon.
>> > Transaction: Ticket created by keren.rosado at noaa.gov
>> > Queue: met_help
>> > Subject: point_stat with dropsonde data
>> > Owner: Nobody
>> > Requestors: keren.rosado at noaa.gov
>> > Status: new
>> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=86203 >
>> >
>> >
>> > Hi,
>> >
>> > I am trying to use point_stat to verify model output with
dropsonde
>> data.
>> > For some reason I am getting: using 0 pairs with out any error.
>> >
>> > Here is what I did:
>> > Forecast grib files located:
>> > /scratch4/BMC/fim/Keren.Rosado/MET/data/sample_fcst/2016092900/
>> > gfs.t00z.pgrb2.0p25.f018
>> >
>> > Observation:
>> > /scratch4/BMC/fim/Keren.Rosado/MET/data/sample_obs/dropsonde
>> /20160929A1/
>> > g143345049.nc
>> > I converted the ascii data to netcdf file using ascii2nc .
>> >
>> >
>> > Configure file:
>> > /scratch4/BMC/fim/Keren.Rosado/MET/tutorial_Matthew_GF/config/
>> > PointStatConfig_tutorial
>> >
>> > For the configure file I originally had it set-up P1000, P900,
>> P850....P100
>> > but trying to figuring out why there are 0 pairs, I set-up a
particular
>> > pressure level where I knew there were observations e.g. 858.1.
>> >
>> > I am also using the mask option and I double check that there is
>> dropsonde
>> > data for the masked area.
>> >
>> > I have a log file located:
>> > /scratch4/BMC/fim/Keren.Rosado/MET/mask/858.1.log
>> >
>> > Is there a configuration option for point_stat to count as a pair
a
>> level
>> > close enough ?
>> >
>> >
>> > Thanks,
>> >
>> > Keren
>> >
>> >
>>
>>
>
------------------------------------------------
Subject: point_stat with dropsonde data
From: John Halley Gotway
Time: Mon Jul 16 14:41:49 2018
Keren,
Sorry, I didn't notice those details.
Looking at your observations, you actually do not have any obs at
850.1...
instead, they are at 858.099975585938. I rounded it to 858.1 in my
email,
but MET does not. When checking for equality between 2 floating point
numbers, MET checks to see if they're the same out to 10 decimal
places.
This is a case of pesky floating point equality issues.
So you're verifying on multiple, very specific levels. Instead of
doing
that, you could verify in *layers*... like this in the config file...
fcst = {
wind_thresh = [ NA ];
message_type = [ "ADPUPA" ];
level = [ "P1000-850" ];
cat_thresh = [ >0.0 ];
field = [
{ name = "TMP"; },
{ name = "RH"; },
{ name = "UGRD"; },
{ name = "VGRD"; }
];
}
obs = fcst;
That includes all the observations falling between 850 and 1000mb into
the
same verification task. Here's some log messages you'd see about
verifying
temperature in this way:
DEBUG 2: For TMP/P1000-850 found 6 forecast levels and 0 climatology
levels.
DEBUG 2: Processing TMP/P1000-850 versus TMP/P1000-850, for
observation
type ADPUPA, over region FULL, for interpolation method BILIN(4),
using 253
pairs.
DEBUG 3: Number of matched pairs = 253
Your model data has temperature at 850, 900, 925, 950, 975, and 1000.
MET
reads them all. For each point observation it uses the model values
"above" and "below" and interpolates to the observation pressure
level,
linear in the log of pressure.
Make sense?
When specifying the forecast and observation fields, you can specify
each
as a single level or as a range of levels. For example, you could
verify
your 850 forecast using obs between 845 and 855. But unless there's a
reason not do, I'd suggest defining both as layers.
Thanks,
John
On Mon, Jul 16, 2018 at 2:22 PM Keren Rosado - NOAA Affiliate via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=86203 >
>
> Hi John,
>
> I know that I only have data for thoes levels, that is why I those
are the
> level in the configure file "P858.1", "P857.6", "P857.1", "P856.6",
> "P856.1".
>
> I still don't understand if the observations exist in thoes levels,
why I
> don't get match pairs.
>
> Thanks,
>
> Keren
>
> ----
> Keren Rosado, Ph.D.
> NCAS-M Postdoctoral Fellow
> NOAA ESRL
> Office: (303) 497-5907
>
> On Mon, Jul 16, 2018 at 1:13 PM, John Halley Gotway via RT <
> met_help at ucar.edu> wrote:
>
> > Keren,
> >
> > I see that you have a question as to why you are getting 0 matched
pairs.
> > When running point_stat try increasing the verbosity logging level
to 3
> > using the "-v 3" command line option. That'll dump out reason
codes for
> > why the observations were not used.
> >
> > For example, I ran:
> >
> > cd
/scratch4/BMC/dtc/John.H.Gotway/MET/MET_Help/rosado_data_20180716
> > module use /contrib/modulefiles
> > module load met/6.0
> > point_stat gfs.t00z.pgrb2.0p25.f018 g143345049.nc
> PointStatConfig_tutorial
> > -outdir out -v 3 -log run_ps.log
> >
> > Looking at the output, you did get 1 matched pair for TMP and RH
at
> > 1000mb. Here's a sample of the log output from that run
explaining why
> you
> > got 1 matched pair:
> >
> > DEBUG 2: Processing TMP/P1000 versus TMP/P1000, for observation
type
> > ADPUPA, over region FULL, for interpolation method BILIN(4), using
1
> pairs.
> > DEBUG 3: Number of matched pairs = 1
> > DEBUG 3: Observations processed = 2340
> > DEBUG 3: Rejected: SID exclusion = 0
> > DEBUG 3: Rejected: GRIB code = 1755
> > DEBUG 3: Rejected: valid time = 0
> > DEBUG 3: Rejected: bad obs value = 320
> > DEBUG 3: Rejected: off the grid = 4
> > DEBUG 3: Rejected: level mismatch = 260
> > DEBUG 3: Rejected: quality marker = 0
> > DEBUG 3: Rejected: message type = 0
> > DEBUG 3: Rejected: masking region = 0
> > DEBUG 3: Rejected: bad fcst value = 0
> > DEBUG 3: Rejected: duplicates = 0
> >
> > But looking at your point observations, I see that there's only
data for
> a
> > single station named "N42RF". So perhaps having 1 matched pair is
> exactly
> > what you'd expect for this data. If that's the case, there's no
need to
> > compute this over two different masking regions. Instead, just
use
> 'grid =
> > ["FULL"];'.
> >
> > But perhaps you're wondering why you got 0 matched pairs for
temperature
> at
> > 850? Looking closely at your data, I see that the pressure level
of the
> > temperature observations range from 856.1 to 1005. That's true of
all
> the
> > observation variables. You only have data in that pressure range.
> >
> > FYI, here's how I figured that out...
> > # Load the R module
> > > module load R
> > # Run this Rscript to dump NetCDF point obs out to ascii
> > > Rscript /contrib/met/6.0/scripts/Rscripts/pntnc2ascii.R
g143345049.nc
> >
> > g143345049.txt
> > # Sort the unique pressure levels numerically and see the range of
values
> > > cat g143345049.txt | awk '{print $8}' | egrep -v NA | sort -nu
> >
> > Thanks,
> > John
> >
> >
> > On Fri, Jul 13, 2018 at 3:04 PM Keren Rosado - NOAA Affiliate via
RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > Fri Jul 13 15:04:18 2018: Request 86203 was acted upon.
> > > Transaction: Ticket created by keren.rosado at noaa.gov
> > > Queue: met_help
> > > Subject: point_stat with dropsonde data
> > > Owner: Nobody
> > > Requestors: keren.rosado at noaa.gov
> > > Status: new
> > > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=86203
> >
> > >
> > >
> > > Hi,
> > >
> > > I am trying to use point_stat to verify model output with
dropsonde
> data.
> > > For some reason I am getting: using 0 pairs with out any error.
> > >
> > > Here is what I did:
> > > Forecast grib files located:
> > > /scratch4/BMC/fim/Keren.Rosado/MET/data/sample_fcst/2016092900/
> > > gfs.t00z.pgrb2.0p25.f018
> > >
> > > Observation:
> > >
>
/scratch4/BMC/fim/Keren.Rosado/MET/data/sample_obs/dropsonde/20160929A1/
> > > g143345049.nc
> > > I converted the ascii data to netcdf file using ascii2nc .
> > >
> > >
> > > Configure file:
> > > /scratch4/BMC/fim/Keren.Rosado/MET/tutorial_Matthew_GF/config/
> > > PointStatConfig_tutorial
> > >
> > > For the configure file I originally had it set-up P1000, P900,
> > P850....P100
> > > but trying to figuring out why there are 0 pairs, I set-up a
particular
> > > pressure level where I knew there were observations e.g. 858.1.
> > >
> > > I am also using the mask option and I double check that there is
> > dropsonde
> > > data for the masked area.
> > >
> > > I have a log file located:
> > > /scratch4/BMC/fim/Keren.Rosado/MET/mask/858.1.log
> > >
> > > Is there a configuration option for point_stat to count as a
pair a
> level
> > > close enough ?
> > >
> > >
> > > Thanks,
> > >
> > > Keren
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: point_stat with dropsonde data
From: John Halley Gotway
Time: Mon Jul 16 14:45:04 2018
Also, you obs contain wind speed and direction, not U and V. So
change
UGRD/VGRD to WIND. Unfortunately though, MET does not verify wind
direction direction in Point-Stat:
field = [
{ name = "TMP"; },
{ name = "RH"; },
{ name = "WIND"; }
];
John
On Mon, Jul 16, 2018 at 2:41 PM John Halley Gotway <johnhg at ucar.edu>
wrote:
> Keren,
>
> Sorry, I didn't notice those details.
>
> Looking at your observations, you actually do not have any obs at
850.1...
> instead, they are at 858.099975585938. I rounded it to 858.1 in my
email,
> but MET does not. When checking for equality between 2 floating
point
> numbers, MET checks to see if they're the same out to 10 decimal
places.
> This is a case of pesky floating point equality issues.
>
> So you're verifying on multiple, very specific levels. Instead of
doing
> that, you could verify in *layers*... like this in the config
file...
>
> fcst = {
> wind_thresh = [ NA ];
> message_type = [ "ADPUPA" ];
> level = [ "P1000-850" ];
> cat_thresh = [ >0.0 ];
> field = [
> { name = "TMP"; },
> { name = "RH"; },
> { name = "UGRD"; },
> { name = "VGRD"; }
> ];
> }
> obs = fcst;
>
> That includes all the observations falling between 850 and 1000mb
into the
> same verification task. Here's some log messages you'd see about
verifying
> temperature in this way:
>
> DEBUG 2: For TMP/P1000-850 found 6 forecast levels and 0 climatology
> levels.
> DEBUG 2: Processing TMP/P1000-850 versus TMP/P1000-850, for
observation
> type ADPUPA, over region FULL, for interpolation method BILIN(4),
using 253
> pairs.
> DEBUG 3: Number of matched pairs = 253
>
> Your model data has temperature at 850, 900, 925, 950, 975, and
1000. MET
> reads them all. For each point observation it uses the model values
> "above" and "below" and interpolates to the observation pressure
level,
> linear in the log of pressure.
>
> Make sense?
>
> When specifying the forecast and observation fields, you can specify
each
> as a single level or as a range of levels. For example, you could
verify
> your 850 forecast using obs between 845 and 855. But unless there's
a
> reason not do, I'd suggest defining both as layers.
>
> Thanks,
> John
>
>
>
>
>
> On Mon, Jul 16, 2018 at 2:22 PM Keren Rosado - NOAA Affiliate via RT
<
> met_help at ucar.edu> wrote:
>
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=86203 >
>>
>> Hi John,
>>
>> I know that I only have data for thoes levels, that is why I those
are the
>> level in the configure file "P858.1", "P857.6", "P857.1", "P856.6",
>> "P856.1".
>>
>> I still don't understand if the observations exist in thoes levels,
why I
>> don't get match pairs.
>>
>> Thanks,
>>
>> Keren
>>
>> ----
>> Keren Rosado, Ph.D.
>> NCAS-M Postdoctoral Fellow
>> NOAA ESRL
>> Office: (303) 497-5907
>>
>> On Mon, Jul 16, 2018 at 1:13 PM, John Halley Gotway via RT <
>> met_help at ucar.edu> wrote:
>>
>> > Keren,
>> >
>> > I see that you have a question as to why you are getting 0
matched
>> pairs.
>> > When running point_stat try increasing the verbosity logging
level to 3
>> > using the "-v 3" command line option. That'll dump out reason
codes for
>> > why the observations were not used.
>> >
>> > For example, I ran:
>> >
>> > cd
/scratch4/BMC/dtc/John.H.Gotway/MET/MET_Help/rosado_data_20180716
>> > module use /contrib/modulefiles
>> > module load met/6.0
>> > point_stat gfs.t00z.pgrb2.0p25.f018 g143345049.nc
>> PointStatConfig_tutorial
>> > -outdir out -v 3 -log run_ps.log
>> >
>> > Looking at the output, you did get 1 matched pair for TMP and RH
at
>> > 1000mb. Here's a sample of the log output from that run
explaining why
>> you
>> > got 1 matched pair:
>> >
>> > DEBUG 2: Processing TMP/P1000 versus TMP/P1000, for observation
type
>> > ADPUPA, over region FULL, for interpolation method BILIN(4),
using 1
>> pairs.
>> > DEBUG 3: Number of matched pairs = 1
>> > DEBUG 3: Observations processed = 2340
>> > DEBUG 3: Rejected: SID exclusion = 0
>> > DEBUG 3: Rejected: GRIB code = 1755
>> > DEBUG 3: Rejected: valid time = 0
>> > DEBUG 3: Rejected: bad obs value = 320
>> > DEBUG 3: Rejected: off the grid = 4
>> > DEBUG 3: Rejected: level mismatch = 260
>> > DEBUG 3: Rejected: quality marker = 0
>> > DEBUG 3: Rejected: message type = 0
>> > DEBUG 3: Rejected: masking region = 0
>> > DEBUG 3: Rejected: bad fcst value = 0
>> > DEBUG 3: Rejected: duplicates = 0
>> >
>> > But looking at your point observations, I see that there's only
data
>> for a
>> > single station named "N42RF". So perhaps having 1 matched pair
is
>> exactly
>> > what you'd expect for this data. If that's the case, there's no
need to
>> > compute this over two different masking regions. Instead, just
use
>> 'grid =
>> > ["FULL"];'.
>> >
>> > But perhaps you're wondering why you got 0 matched pairs for
>> temperature at
>> > 850? Looking closely at your data, I see that the pressure level
of the
>> > temperature observations range from 856.1 to 1005. That's true
of all
>> the
>> > observation variables. You only have data in that pressure
range.
>> >
>> > FYI, here's how I figured that out...
>> > # Load the R module
>> > > module load R
>> > # Run this Rscript to dump NetCDF point obs out to ascii
>> > > Rscript /contrib/met/6.0/scripts/Rscripts/pntnc2ascii.R
g143345049.nc
>> >
>> > g143345049.txt
>> > # Sort the unique pressure levels numerically and see the range
of
>> values
>> > > cat g143345049.txt | awk '{print $8}' | egrep -v NA | sort -nu
>> >
>> > Thanks,
>> > John
>> >
>> >
>> > On Fri, Jul 13, 2018 at 3:04 PM Keren Rosado - NOAA Affiliate via
RT <
>> > met_help at ucar.edu> wrote:
>> >
>> > >
>> > > Fri Jul 13 15:04:18 2018: Request 86203 was acted upon.
>> > > Transaction: Ticket created by keren.rosado at noaa.gov
>> > > Queue: met_help
>> > > Subject: point_stat with dropsonde data
>> > > Owner: Nobody
>> > > Requestors: keren.rosado at noaa.gov
>> > > Status: new
>> > > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=86203
>> >
>> > >
>> > >
>> > > Hi,
>> > >
>> > > I am trying to use point_stat to verify model output with
dropsonde
>> data.
>> > > For some reason I am getting: using 0 pairs with out any error.
>> > >
>> > > Here is what I did:
>> > > Forecast grib files located:
>> > > /scratch4/BMC/fim/Keren.Rosado/MET/data/sample_fcst/2016092900/
>> > > gfs.t00z.pgrb2.0p25.f018
>> > >
>> > > Observation:
>> > >
>>
/scratch4/BMC/fim/Keren.Rosado/MET/data/sample_obs/dropsonde/20160929A1/
>> > > g143345049.nc
>> > > I converted the ascii data to netcdf file using ascii2nc .
>> > >
>> > >
>> > > Configure file:
>> > > /scratch4/BMC/fim/Keren.Rosado/MET/tutorial_Matthew_GF/config/
>> > > PointStatConfig_tutorial
>> > >
>> > > For the configure file I originally had it set-up P1000, P900,
>> > P850....P100
>> > > but trying to figuring out why there are 0 pairs, I set-up a
>> particular
>> > > pressure level where I knew there were observations e.g. 858.1.
>> > >
>> > > I am also using the mask option and I double check that there
is
>> > dropsonde
>> > > data for the masked area.
>> > >
>> > > I have a log file located:
>> > > /scratch4/BMC/fim/Keren.Rosado/MET/mask/858.1.log
>> > >
>> > > Is there a configuration option for point_stat to count as a
pair a
>> level
>> > > close enough ?
>> > >
>> > >
>> > > Thanks,
>> > >
>> > > Keren
>> > >
>> > >
>> >
>> >
>>
>>
------------------------------------------------
More information about the Met_help
mailing list