[Met_help] [rt.rap.ucar.edu #95970] History for Wind direction unsemble verifcaion
John Halley Gotway via RT
met_help at ucar.edu
Thu Oct 1 14:35:24 MDT 2020
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello,
I am working on ensemble wind direction verification using the "gefs"
model. I noticed that MET could handle wind direction using "grid_stat" and
"aggregate_stat", but this is not for ensemble. The gefs model only has
UGRD and VGRD (no direction) and my observation has WIND SPEED and WIND
DIRECTION. Of course I can get WIND DIRECTION for model data (or UGRD and
VGRD for observation). But I think it will not be the right way if I just
use ensemble_stat and grid_stat by treating "WIND DIRECTION" as others like
TEMP. because the degree issue from WIND DIrection (e.g: 0 degree is close
to 350 degree. )
So any suggestions to do wind direction ensemble verification using MET?
How the problem (like 0 vs. 350 degree) is resolved in the
"aggregate_stat"?
Thank you very much.
Binyu
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Wind direction unsemble verifcaion
From: John Halley Gotway
Time: Tue Jul 21 14:07:43 2020
Binyu,
Let me address wind speed first (WIND). When processing GRIB 1 or 2
files,
when you request wind speed in a MET config file, MET will first try
to
find a record of WIND directly in that file. If not present, it will
automatically try to find the corresponding UGRD and VGRD records. And
it'll automatically derive wind speed on the fly.
In regards to wind direction (WDIR), the MET tools do not verify it
directly. In fact, if you request it, you'll see an error message
stating
that.
When running point_stat and grid_stat, you can compute the VCNT
(vector
continuous statistics) line type. And the vector partial sums (VL1L2
line
type) is also useful. But those require the comparison of U/V
components.
And it sounds like you only have wind speed and direction in the
observations. So that's a limitation.
For ensemble_stat, you could verify wind speed by requesting WIND in
the
config file.
John
On Tue, Jul 21, 2020 at 12:15 PM binyu.wang at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> Tue Jul 21 12:15:18 2020: Request 95970 was acted upon.
> Transaction: Ticket created by binyu.wang at noaa.gov
> Queue: met_help
> Subject: Wind direction unsemble verifcaion
> Owner: Nobody
> Requestors: binyu.wang at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
>
>
> Hello,
>
> I am working on ensemble wind direction verification using the
"gefs"
> model. I noticed that MET could handle wind direction using
"grid_stat" and
> "aggregate_stat", but this is not for ensemble. The gefs model only
has
> UGRD and VGRD (no direction) and my observation has WIND SPEED and
WIND
> DIRECTION. Of course I can get WIND DIRECTION for model data (or
UGRD and
> VGRD for observation). But I think it will not be the right way if I
just
> use ensemble_stat and grid_stat by treating "WIND DIRECTION" as
others like
> TEMP. because the degree issue from WIND DIrection (e.g: 0 degree is
close
> to 350 degree. )
>
> So any suggestions to do wind direction ensemble verification using
MET?
> How the problem (like 0 vs. 350 degree) is resolved in the
> "aggregate_stat"?
>
> Thank you very much.
> Binyu
>
>
------------------------------------------------
Subject: Wind direction unsemble verifcaion
From: binyu.wang at noaa.gov
Time: Tue Jul 21 15:21:21 2020
John,
Although my original Obs. data has no UGRD/VGRD, I did derive them
using
WIND and WDIR (the original input is ascII file, so I used ascIInc and
grid2point to convert them to *nc file, which has
UGRD/VGRD/WIND/WDIR). So
it is not a problem for me.
"For ensemble_stat, you could verify wind speed by requesting WIND in
the
config file." But WIND only tells the magnitude, not the direction,
right?
So how does the MET deal with the degree for WDIR? If WDIR=355degree
from
MODEL, and WDIR=0 from OBS, will MET treat them as a big difference or
small difference? I know how to do the ensemble verification for
UGRD/VGRD,
but my main interest is WDIR. I want to know if I could treat WDIR as
UGRD/VGRD using ensemble_stat and grid_stat.
Thank you.
Binyu
On Tue, Jul 21, 2020 at 4:07 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binyu,
>
> Let me address wind speed first (WIND). When processing GRIB 1 or 2
files,
> when you request wind speed in a MET config file, MET will first try
to
> find a record of WIND directly in that file. If not present, it will
> automatically try to find the corresponding UGRD and VGRD records.
And
> it'll automatically derive wind speed on the fly.
>
> In regards to wind direction (WDIR), the MET tools do not verify it
> directly. In fact, if you request it, you'll see an error message
stating
> that.
>
> When running point_stat and grid_stat, you can compute the VCNT
(vector
> continuous statistics) line type. And the vector partial sums (VL1L2
line
> type) is also useful. But those require the comparison of U/V
components.
> And it sounds like you only have wind speed and direction in the
> observations. So that's a limitation.
>
> For ensemble_stat, you could verify wind speed by requesting WIND in
the
> config file.
>
> John
>
> On Tue, Jul 21, 2020 at 12:15 PM binyu.wang at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > Tue Jul 21 12:15:18 2020: Request 95970 was acted upon.
> > Transaction: Ticket created by binyu.wang at noaa.gov
> > Queue: met_help
> > Subject: Wind direction unsemble verifcaion
> > Owner: Nobody
> > Requestors: binyu.wang at noaa.gov
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> >
> >
> > Hello,
> >
> > I am working on ensemble wind direction verification using the
"gefs"
> > model. I noticed that MET could handle wind direction using
"grid_stat"
> and
> > "aggregate_stat", but this is not for ensemble. The gefs model
only has
> > UGRD and VGRD (no direction) and my observation has WIND SPEED and
WIND
> > DIRECTION. Of course I can get WIND DIRECTION for model data (or
UGRD
> and
> > VGRD for observation). But I think it will not be the right way if
I just
> > use ensemble_stat and grid_stat by treating "WIND DIRECTION" as
others
> like
> > TEMP. because the degree issue from WIND DIrection (e.g: 0 degree
is
> close
> > to 350 degree. )
> >
> > So any suggestions to do wind direction ensemble verification
using MET?
> > How the problem (like 0 vs. 350 degree) is resolved in the
> > "aggregate_stat"?
> >
> > Thank you very much.
> > Binyu
> >
> >
>
>
------------------------------------------------
Subject: Wind direction unsemble verifcaion
From: John Halley Gotway
Time: Tue Jul 21 16:39:52 2020
Binyu,
MET does not evaluate wind direction directly for the reason that you
mention. Since it's a "circular" variable, it does not lend itself
well to
traditional statistics, like RMSE. If you try evaluating wind
direction
directly, you'll get this error message:
ERROR : PointStatVxOpt::process_config() -> wind direction may not be
verified using point_stat.
With U/V pairs, you can run point_stat to evaluate those vectors and
write
the VL1L2 partial sums and VCNT statistics. I'd recommend running
point_stat to evaluate the ensemble mean using the VL1L2 and VCNT line
types. Those VCNT statistic are described in the MET User's Guide.
John
On Tue, Jul 21, 2020 at 3:22 PM binyu.wang at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
>
> John,
>
> Although my original Obs. data has no UGRD/VGRD, I did derive them
using
> WIND and WDIR (the original input is ascII file, so I used ascIInc
and
> grid2point to convert them to *nc file, which has
UGRD/VGRD/WIND/WDIR). So
> it is not a problem for me.
>
> "For ensemble_stat, you could verify wind speed by requesting WIND
in the
> config file." But WIND only tells the magnitude, not the direction,
right?
>
> So how does the MET deal with the degree for WDIR? If
WDIR=355degree from
> MODEL, and WDIR=0 from OBS, will MET treat them as a big difference
or
> small difference? I know how to do the ensemble verification for
UGRD/VGRD,
> but my main interest is WDIR. I want to know if I could treat WDIR
as
> UGRD/VGRD using ensemble_stat and grid_stat.
>
> Thank you.
> Binyu
>
>
>
> On Tue, Jul 21, 2020 at 4:07 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Binyu,
> >
> > Let me address wind speed first (WIND). When processing GRIB 1 or
2
> files,
> > when you request wind speed in a MET config file, MET will first
try to
> > find a record of WIND directly in that file. If not present, it
will
> > automatically try to find the corresponding UGRD and VGRD records.
And
> > it'll automatically derive wind speed on the fly.
> >
> > In regards to wind direction (WDIR), the MET tools do not verify
it
> > directly. In fact, if you request it, you'll see an error message
stating
> > that.
> >
> > When running point_stat and grid_stat, you can compute the VCNT
(vector
> > continuous statistics) line type. And the vector partial sums
(VL1L2 line
> > type) is also useful. But those require the comparison of U/V
components.
> > And it sounds like you only have wind speed and direction in the
> > observations. So that's a limitation.
> >
> > For ensemble_stat, you could verify wind speed by requesting WIND
in the
> > config file.
> >
> > John
> >
> > On Tue, Jul 21, 2020 at 12:15 PM binyu.wang at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > Tue Jul 21 12:15:18 2020: Request 95970 was acted upon.
> > > Transaction: Ticket created by binyu.wang at noaa.gov
> > > Queue: met_help
> > > Subject: Wind direction unsemble verifcaion
> > > Owner: Nobody
> > > Requestors: binyu.wang at noaa.gov
> > > Status: new
> > > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> >
> > >
> > >
> > > Hello,
> > >
> > > I am working on ensemble wind direction verification using the
"gefs"
> > > model. I noticed that MET could handle wind direction using
"grid_stat"
> > and
> > > "aggregate_stat", but this is not for ensemble. The gefs model
only has
> > > UGRD and VGRD (no direction) and my observation has WIND SPEED
and WIND
> > > DIRECTION. Of course I can get WIND DIRECTION for model data
(or UGRD
> > and
> > > VGRD for observation). But I think it will not be the right way
if I
> just
> > > use ensemble_stat and grid_stat by treating "WIND DIRECTION" as
others
> > like
> > > TEMP. because the degree issue from WIND DIrection (e.g: 0
degree is
> > close
> > > to 350 degree. )
> > >
> > > So any suggestions to do wind direction ensemble verification
using
> MET?
> > > How the problem (like 0 vs. 350 degree) is resolved in the
> > > "aggregate_stat"?
> > >
> > > Thank you very much.
> > > Binyu
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Wind direction unsemble verifcaion
From: binyu.wang at noaa.gov
Time: Thu Jul 23 16:49:50 2020
Thank you, John.
Based on what you said I can not evaluate wind direction directly, so
there
is no need for me to get WDIR based on UGRD and VGRD from the GEFS
model
output. I need to do the WDIR verification because my ensemble model
output (which is based on GEFS wind profile) predicted that the ash
went
northward, while the satellite observance shows the ash went southward
over
one volcano eruption. So I want to identify if there is a problem for
WDIR
prediction over the volcano area.
Following your suggestion, I used point_stat for UGRD/VGRD, however,
the
output is empty (no matching pair). But I am sure there are matching
pairs
for UGRD/VGRD because I have no problem to get non-empty stat. output
using
"ensemble_stat" and "grid_stat" for UGRD/VGRD. Below is my script:
(and my
obs. is abstained using ascii2nc)
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/ush/
verf_g2g_gec_Reventador.sh
Thank you.
Binyu
On Tue, Jul 21, 2020 at 6:47 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binyu,
>
> MET does not evaluate wind direction directly for the reason that
you
> mention. Since it's a "circular" variable, it does not lend itself
well to
> traditional statistics, like RMSE. If you try evaluating wind
direction
> directly, you'll get this error message:
>
> ERROR : PointStatVxOpt::process_config() -> wind direction may not
be
> verified using point_stat.
>
> With U/V pairs, you can run point_stat to evaluate those vectors and
write
> the VL1L2 partial sums and VCNT statistics. I'd recommend running
> point_stat to evaluate the ensemble mean using the VL1L2 and VCNT
line
> types. Those VCNT statistic are described in the MET User's Guide.
>
> John
>
> On Tue, Jul 21, 2020 at 3:22 PM binyu.wang at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> >
> > John,
> >
> > Although my original Obs. data has no UGRD/VGRD, I did derive them
using
> > WIND and WDIR (the original input is ascII file, so I used ascIInc
and
> > grid2point to convert them to *nc file, which has
UGRD/VGRD/WIND/WDIR).
> So
> > it is not a problem for me.
> >
> > "For ensemble_stat, you could verify wind speed by requesting WIND
in the
> > config file." But WIND only tells the magnitude, not the
direction,
> right?
> >
> > So how does the MET deal with the degree for WDIR? If
WDIR=355degree
> from
> > MODEL, and WDIR=0 from OBS, will MET treat them as a big
difference or
> > small difference? I know how to do the ensemble verification for
> UGRD/VGRD,
> > but my main interest is WDIR. I want to know if I could treat WDIR
as
> > UGRD/VGRD using ensemble_stat and grid_stat.
> >
> > Thank you.
> > Binyu
> >
> >
> >
> > On Tue, Jul 21, 2020 at 4:07 PM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > Binyu,
> > >
> > > Let me address wind speed first (WIND). When processing GRIB 1
or 2
> > files,
> > > when you request wind speed in a MET config file, MET will first
try to
> > > find a record of WIND directly in that file. If not present, it
will
> > > automatically try to find the corresponding UGRD and VGRD
records. And
> > > it'll automatically derive wind speed on the fly.
> > >
> > > In regards to wind direction (WDIR), the MET tools do not verify
it
> > > directly. In fact, if you request it, you'll see an error
message
> stating
> > > that.
> > >
> > > When running point_stat and grid_stat, you can compute the VCNT
(vector
> > > continuous statistics) line type. And the vector partial sums
(VL1L2
> line
> > > type) is also useful. But those require the comparison of U/V
> components.
> > > And it sounds like you only have wind speed and direction in the
> > > observations. So that's a limitation.
> > >
> > > For ensemble_stat, you could verify wind speed by requesting
WIND in
> the
> > > config file.
> > >
> > > John
> > >
> > > On Tue, Jul 21, 2020 at 12:15 PM binyu.wang at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > Tue Jul 21 12:15:18 2020: Request 95970 was acted upon.
> > > > Transaction: Ticket created by binyu.wang at noaa.gov
> > > > Queue: met_help
> > > > Subject: Wind direction unsemble verifcaion
> > > > Owner: Nobody
> > > > Requestors: binyu.wang at noaa.gov
> > > > Status: new
> > > > Ticket <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > >
> > > >
> > > >
> > > > Hello,
> > > >
> > > > I am working on ensemble wind direction verification using the
"gefs"
> > > > model. I noticed that MET could handle wind direction using
> "grid_stat"
> > > and
> > > > "aggregate_stat", but this is not for ensemble. The gefs model
only
> has
> > > > UGRD and VGRD (no direction) and my observation has WIND SPEED
and
> WIND
> > > > DIRECTION. Of course I can get WIND DIRECTION for model data
(or
> UGRD
> > > and
> > > > VGRD for observation). But I think it will not be the right
way if I
> > just
> > > > use ensemble_stat and grid_stat by treating "WIND DIRECTION"
as
> others
> > > like
> > > > TEMP. because the degree issue from WIND DIrection (e.g: 0
degree is
> > > close
> > > > to 350 degree. )
> > > >
> > > > So any suggestions to do wind direction ensemble verification
using
> > MET?
> > > > How the problem (like 0 vs. 350 degree) is resolved in the
> > > > "aggregate_stat"?
> > > >
> > > > Thank you very much.
> > > > Binyu
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Wind direction unsemble verifcaion
From: John Halley Gotway
Time: Thu Jul 23 17:24:02 2020
Binyu,
I logged onto Mars, took a look at your shell script, and ran these
commands:
*module use
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/modulefilesmodule
load met/9.0.2*
*mkdir -p out/point_stat*
*point_stat
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/EMC_HYSPLIT/inout/ptmp/com/gefs/prod/gefs.20200201/00/pgrb2ap5/gec00.t00z.pgrb2a.0p50.f012
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met_temp/asc2nc_SKTQ_SKBO_20200201.nc
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/parm/PointStatConfig
-log run_pt.log -outdir out/point_stat -v 3*
But this finds 0 matched pairs and the log messages indicates that
it's a
level mismatch:
DEBUG 2: Processing UGRD/P250 versus UGRD/P250, for observation type
ADPUPA, over region FULL, for interpolation method NEAREST(1), using 0
matched pairs.
DEBUG 3: Number of matched pairs = 0
DEBUG 3: Observations processed = 340
...
DEBUG 3: Rejected: level mismatch = 85
So let's check the obs that are in the file
asc2nc_SKTQ_SKBO_20200201.nc. I
copied that file to my local machine and ran this Rscript to dump it
back
out to an easier to read ascii format:
Rscript met/scripts/Rscripts/pntnc2ascii.R
asc2nc_SKTQ_SKBO_20200201.nc >
asc2nc_SKTQ_SKBO_20200201.txt
That file contains 85 instances of UGRD, but the level values range
from
2546 to 22562. None of them have a level value of exactly 250. And
that's
why you're getting 0 matches. Looks to me like there's 2 issues:
(1) The units of pressure differ between the fcst and obs.
(2) No obs exactly match 250mb.
You can handle both issues in the Point-Stat config file. Just specify
separate levels for the fcst and obs dictionaries.
fcst = { field = [ { name="UGRD"; level="P250"; } ]; }
obs = { field = [ { name="UGRD"; level="P20000-30000"; } ]; }
That'll match any obs of UGRD with a pressure value between 20000 and
30000
to the forecast for P250.
Make sense?
John
On Thu, Jul 23, 2020 at 4:50 PM binyu.wang at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
>
> Thank you, John.
>
> Based on what you said I can not evaluate wind direction directly,
so there
> is no need for me to get WDIR based on UGRD and VGRD from the GEFS
model
> output. I need to do the WDIR verification because my ensemble
model
> output (which is based on GEFS wind profile) predicted that the ash
went
> northward, while the satellite observance shows the ash went
southward over
> one volcano eruption. So I want to identify if there is a problem
for WDIR
> prediction over the volcano area.
>
> Following your suggestion, I used point_stat for UGRD/VGRD, however,
the
> output is empty (no matching pair). But I am sure there are matching
pairs
> for UGRD/VGRD because I have no problem to get non-empty stat.
output using
> "ensemble_stat" and "grid_stat" for UGRD/VGRD. Below is my script:
(and my
> obs. is abstained using ascii2nc)
>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/ush/
> verf_g2g_gec_Reventador.sh
>
> Thank you.
> Binyu
>
> On Tue, Jul 21, 2020 at 6:47 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Binyu,
> >
> > MET does not evaluate wind direction directly for the reason that
you
> > mention. Since it's a "circular" variable, it does not lend itself
well
> to
> > traditional statistics, like RMSE. If you try evaluating wind
direction
> > directly, you'll get this error message:
> >
> > ERROR : PointStatVxOpt::process_config() -> wind direction may
not be
> > verified using point_stat.
> >
> > With U/V pairs, you can run point_stat to evaluate those vectors
and
> write
> > the VL1L2 partial sums and VCNT statistics. I'd recommend running
> > point_stat to evaluate the ensemble mean using the VL1L2 and VCNT
line
> > types. Those VCNT statistic are described in the MET User's Guide.
> >
> > John
> >
> > On Tue, Jul 21, 2020 at 3:22 PM binyu.wang at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> > >
> > > John,
> > >
> > > Although my original Obs. data has no UGRD/VGRD, I did derive
them
> using
> > > WIND and WDIR (the original input is ascII file, so I used
ascIInc and
> > > grid2point to convert them to *nc file, which has
UGRD/VGRD/WIND/WDIR).
> > So
> > > it is not a problem for me.
> > >
> > > "For ensemble_stat, you could verify wind speed by requesting
WIND in
> the
> > > config file." But WIND only tells the magnitude, not the
direction,
> > right?
> > >
> > > So how does the MET deal with the degree for WDIR? If
WDIR=355degree
> > from
> > > MODEL, and WDIR=0 from OBS, will MET treat them as a big
difference or
> > > small difference? I know how to do the ensemble verification for
> > UGRD/VGRD,
> > > but my main interest is WDIR. I want to know if I could treat
WDIR as
> > > UGRD/VGRD using ensemble_stat and grid_stat.
> > >
> > > Thank you.
> > > Binyu
> > >
> > >
> > >
> > > On Tue, Jul 21, 2020 at 4:07 PM John Halley Gotway via RT <
> > > met_help at ucar.edu>
> > > wrote:
> > >
> > > > Binyu,
> > > >
> > > > Let me address wind speed first (WIND). When processing GRIB 1
or 2
> > > files,
> > > > when you request wind speed in a MET config file, MET will
first try
> to
> > > > find a record of WIND directly in that file. If not present,
it will
> > > > automatically try to find the corresponding UGRD and VGRD
records.
> And
> > > > it'll automatically derive wind speed on the fly.
> > > >
> > > > In regards to wind direction (WDIR), the MET tools do not
verify it
> > > > directly. In fact, if you request it, you'll see an error
message
> > stating
> > > > that.
> > > >
> > > > When running point_stat and grid_stat, you can compute the
VCNT
> (vector
> > > > continuous statistics) line type. And the vector partial sums
(VL1L2
> > line
> > > > type) is also useful. But those require the comparison of U/V
> > components.
> > > > And it sounds like you only have wind speed and direction in
the
> > > > observations. So that's a limitation.
> > > >
> > > > For ensemble_stat, you could verify wind speed by requesting
WIND in
> > the
> > > > config file.
> > > >
> > > > John
> > > >
> > > > On Tue, Jul 21, 2020 at 12:15 PM binyu.wang at noaa.gov via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > >
> > > > > Tue Jul 21 12:15:18 2020: Request 95970 was acted upon.
> > > > > Transaction: Ticket created by binyu.wang at noaa.gov
> > > > > Queue: met_help
> > > > > Subject: Wind direction unsemble verifcaion
> > > > > Owner: Nobody
> > > > > Requestors: binyu.wang at noaa.gov
> > > > > Status: new
> > > > > Ticket <URL:
> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > > >
> > > > >
> > > > >
> > > > > Hello,
> > > > >
> > > > > I am working on ensemble wind direction verification using
the
> "gefs"
> > > > > model. I noticed that MET could handle wind direction using
> > "grid_stat"
> > > > and
> > > > > "aggregate_stat", but this is not for ensemble. The gefs
model only
> > has
> > > > > UGRD and VGRD (no direction) and my observation has WIND
SPEED and
> > WIND
> > > > > DIRECTION. Of course I can get WIND DIRECTION for model
data (or
> > UGRD
> > > > and
> > > > > VGRD for observation). But I think it will not be the right
way if
> I
> > > just
> > > > > use ensemble_stat and grid_stat by treating "WIND DIRECTION"
as
> > others
> > > > like
> > > > > TEMP. because the degree issue from WIND DIrection (e.g: 0
degree
> is
> > > > close
> > > > > to 350 degree. )
> > > > >
> > > > > So any suggestions to do wind direction ensemble
verification using
> > > MET?
> > > > > How the problem (like 0 vs. 350 degree) is resolved in the
> > > > > "aggregate_stat"?
> > > > >
> > > > > Thank you very much.
> > > > > Binyu
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Wind direction unsemble verifcaion
From: binyu.wang at noaa.gov
Time: Thu Jul 23 21:39:40 2020
John, thank you for your help.
I tried to add the pressure level to the *nc created from ascII2nc and
run
point_stat again. It now has 1 matched pair. But when I try to load
the
*stat file to METViewer, I got some very strange error (please see the
log
file below):
%cd /gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/METviewer_AWS/g2g
%run_g2g_met_verf_wdir.sh > log
Is this error from METViwer only or there is something wrong with my
scripts/inputs?
My point_stat script is still under:
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/ush/
verf_g2g_gec_Reventador.sh
There is another question about adding the pressure to the file:
should I
just give the real value to the 8th column instead of "N/A"? Or do I
also
need to add "pressure level" as one other variable to the file ( like
"TEMP" or "UGRD" etc)? Or either one will work? I did both in my
files, but
I am not sure which one is correct.
Best.
Binyu
On Thu, Jul 23, 2020 at 7:24 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binyu,
>
> I logged onto Mars, took a look at your shell script, and ran these
> commands:
>
>
>
> *module use
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/modulefilesmodule
> load met/9.0.2*
> *mkdir -p out/point_stat*
>
> *point_stat
>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/EMC_HYSPLIT/inout/ptmp/com/gefs/prod/gefs.20200201/00/pgrb2ap5/gec00.t00z.pgrb2a.0p50.f012
>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met_temp/asc2nc_SKTQ_SKBO_20200201.nc
>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/parm/PointStatConfig
> -log run_pt.log -outdir out/point_stat -v 3*
>
> But this finds 0 matched pairs and the log messages indicates that
it's a
> level mismatch:
>
> DEBUG 2: Processing UGRD/P250 versus UGRD/P250, for observation type
> ADPUPA, over region FULL, for interpolation method NEAREST(1), using
0
> matched pairs.
> DEBUG 3: Number of matched pairs = 0
> DEBUG 3: Observations processed = 340
> ...
> DEBUG 3: Rejected: level mismatch = 85
>
> So let's check the obs that are in the file
asc2nc_SKTQ_SKBO_20200201.nc. I
> copied that file to my local machine and ran this Rscript to dump it
back
> out to an easier to read ascii format:
>
> Rscript met/scripts/Rscripts/pntnc2ascii.R
asc2nc_SKTQ_SKBO_20200201.nc >
> asc2nc_SKTQ_SKBO_20200201.txt
>
> That file contains 85 instances of UGRD, but the level values range
from
> 2546 to 22562. None of them have a level value of exactly 250. And
that's
> why you're getting 0 matches. Looks to me like there's 2 issues:
>
> (1) The units of pressure differ between the fcst and obs.
> (2) No obs exactly match 250mb.
>
> You can handle both issues in the Point-Stat config file. Just
specify
> separate levels for the fcst and obs dictionaries.
>
> fcst = { field = [ { name="UGRD"; level="P250"; } ]; }
> obs = { field = [ { name="UGRD"; level="P20000-30000"; } ]; }
>
> That'll match any obs of UGRD with a pressure value between 20000
and 30000
> to the forecast for P250.
>
> Make sense?
>
> John
>
> On Thu, Jul 23, 2020 at 4:50 PM binyu.wang at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> >
> > Thank you, John.
> >
> > Based on what you said I can not evaluate wind direction directly,
so
> there
> > is no need for me to get WDIR based on UGRD and VGRD from the GEFS
model
> > output. I need to do the WDIR verification because my ensemble
model
> > output (which is based on GEFS wind profile) predicted that the
ash went
> > northward, while the satellite observance shows the ash went
southward
> over
> > one volcano eruption. So I want to identify if there is a problem
for
> WDIR
> > prediction over the volcano area.
> >
> > Following your suggestion, I used point_stat for UGRD/VGRD,
however, the
> > output is empty (no matching pair). But I am sure there are
matching
> pairs
> > for UGRD/VGRD because I have no problem to get non-empty stat.
output
> using
> > "ensemble_stat" and "grid_stat" for UGRD/VGRD. Below is my script:
(and
> my
> > obs. is abstained using ascii2nc)
> >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/ush/
> > verf_g2g_gec_Reventador.sh
> >
> > Thank you.
> > Binyu
> >
> > On Tue, Jul 21, 2020 at 6:47 PM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > Binyu,
> > >
> > > MET does not evaluate wind direction directly for the reason
that you
> > > mention. Since it's a "circular" variable, it does not lend
itself well
> > to
> > > traditional statistics, like RMSE. If you try evaluating wind
direction
> > > directly, you'll get this error message:
> > >
> > > ERROR : PointStatVxOpt::process_config() -> wind direction may
not be
> > > verified using point_stat.
> > >
> > > With U/V pairs, you can run point_stat to evaluate those vectors
and
> > write
> > > the VL1L2 partial sums and VCNT statistics. I'd recommend
running
> > > point_stat to evaluate the ensemble mean using the VL1L2 and
VCNT line
> > > types. Those VCNT statistic are described in the MET User's
Guide.
> > >
> > > John
> > >
> > > On Tue, Jul 21, 2020 at 3:22 PM binyu.wang at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
>
> > > >
> > > > John,
> > > >
> > > > Although my original Obs. data has no UGRD/VGRD, I did derive
them
> > using
> > > > WIND and WDIR (the original input is ascII file, so I used
ascIInc
> and
> > > > grid2point to convert them to *nc file, which has
> UGRD/VGRD/WIND/WDIR).
> > > So
> > > > it is not a problem for me.
> > > >
> > > > "For ensemble_stat, you could verify wind speed by requesting
WIND in
> > the
> > > > config file." But WIND only tells the magnitude, not the
direction,
> > > right?
> > > >
> > > > So how does the MET deal with the degree for WDIR? If
WDIR=355degree
> > > from
> > > > MODEL, and WDIR=0 from OBS, will MET treat them as a big
difference
> or
> > > > small difference? I know how to do the ensemble verification
for
> > > UGRD/VGRD,
> > > > but my main interest is WDIR. I want to know if I could treat
WDIR as
> > > > UGRD/VGRD using ensemble_stat and grid_stat.
> > > >
> > > > Thank you.
> > > > Binyu
> > > >
> > > >
> > > >
> > > > On Tue, Jul 21, 2020 at 4:07 PM John Halley Gotway via RT <
> > > > met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > > Binyu,
> > > > >
> > > > > Let me address wind speed first (WIND). When processing GRIB
1 or 2
> > > > files,
> > > > > when you request wind speed in a MET config file, MET will
first
> try
> > to
> > > > > find a record of WIND directly in that file. If not present,
it
> will
> > > > > automatically try to find the corresponding UGRD and VGRD
records.
> > And
> > > > > it'll automatically derive wind speed on the fly.
> > > > >
> > > > > In regards to wind direction (WDIR), the MET tools do not
verify it
> > > > > directly. In fact, if you request it, you'll see an error
message
> > > stating
> > > > > that.
> > > > >
> > > > > When running point_stat and grid_stat, you can compute the
VCNT
> > (vector
> > > > > continuous statistics) line type. And the vector partial
sums
> (VL1L2
> > > line
> > > > > type) is also useful. But those require the comparison of
U/V
> > > components.
> > > > > And it sounds like you only have wind speed and direction in
the
> > > > > observations. So that's a limitation.
> > > > >
> > > > > For ensemble_stat, you could verify wind speed by requesting
WIND
> in
> > > the
> > > > > config file.
> > > > >
> > > > > John
> > > > >
> > > > > On Tue, Jul 21, 2020 at 12:15 PM binyu.wang at noaa.gov via RT
<
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > > >
> > > > > > Tue Jul 21 12:15:18 2020: Request 95970 was acted upon.
> > > > > > Transaction: Ticket created by binyu.wang at noaa.gov
> > > > > > Queue: met_help
> > > > > > Subject: Wind direction unsemble verifcaion
> > > > > > Owner: Nobody
> > > > > > Requestors: binyu.wang at noaa.gov
> > > > > > Status: new
> > > > > > Ticket <URL:
> > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > > > >
> > > > > >
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I am working on ensemble wind direction verification using
the
> > "gefs"
> > > > > > model. I noticed that MET could handle wind direction
using
> > > "grid_stat"
> > > > > and
> > > > > > "aggregate_stat", but this is not for ensemble. The gefs
model
> only
> > > has
> > > > > > UGRD and VGRD (no direction) and my observation has WIND
SPEED
> and
> > > WIND
> > > > > > DIRECTION. Of course I can get WIND DIRECTION for model
data (or
> > > UGRD
> > > > > and
> > > > > > VGRD for observation). But I think it will not be the
right way
> if
> > I
> > > > just
> > > > > > use ensemble_stat and grid_stat by treating "WIND
DIRECTION" as
> > > others
> > > > > like
> > > > > > TEMP. because the degree issue from WIND DIrection (e.g: 0
degree
> > is
> > > > > close
> > > > > > to 350 degree. )
> > > > > >
> > > > > > So any suggestions to do wind direction ensemble
verification
> using
> > > > MET?
> > > > > > How the problem (like 0 vs. 350 degree) is resolved in the
> > > > > > "aggregate_stat"?
> > > > > >
> > > > > > Thank you very much.
> > > > > > Binyu
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Wind direction unsemble verifcaion
From: binyu.wang at noaa.gov
Time: Thu Jul 23 22:11:57 2020
John,
Your email reminds me of another thing that I want to confirm:
Using the same ascII2nc output file ( the one you just saw:
asc2nc_SKTQ_SKBO_20200201.nc) as input, I used point2grid to get a new
output (
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met/
regrid_SKTQ_SKBO_t12z.20200201.nc).
The new output has a pressure level like P250. From the MET
documentation:
"point2grid input_filename to_grid output_filename", the input is
re-grided based on "to_grid" file. How the input got "pressure level"?
I
guess in MET, the same relationship between height and pressure in
"to_grid" is assigned to the input? I.e: over one site in the
"to_grid"
file, the pressure level 250mb is corresponding to 10000m , MET
treats the
same relationship to input, so the site with height 10000m is
assigned 250mb as pressure level. Am I correct?
Thank you.
Binyu
On Thu, Jul 23, 2020 at 7:24 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binyu,
>
> I logged onto Mars, took a look at your shell script, and ran these
> commands:
>
>
>
> *module use
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/modulefilesmodule
> load met/9.0.2*
> *mkdir -p out/point_stat*
>
> *point_stat
>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/EMC_HYSPLIT/inout/ptmp/com/gefs/prod/gefs.20200201/00/pgrb2ap5/gec00.t00z.pgrb2a.0p50.f012
>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met_temp/asc2nc_SKTQ_SKBO_20200201.nc
>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/parm/PointStatConfig
> -log run_pt.log -outdir out/point_stat -v 3*
>
> But this finds 0 matched pairs and the log messages indicates that
it's a
> level mismatch:
>
> DEBUG 2: Processing UGRD/P250 versus UGRD/P250, for observation type
> ADPUPA, over region FULL, for interpolation method NEAREST(1), using
0
> matched pairs.
> DEBUG 3: Number of matched pairs = 0
> DEBUG 3: Observations processed = 340
> ...
> DEBUG 3: Rejected: level mismatch = 85
>
> So let's check the obs that are in the file
asc2nc_SKTQ_SKBO_20200201.nc. I
> copied that file to my local machine and ran this Rscript to dump it
back
> out to an easier to read ascii format:
>
> Rscript met/scripts/Rscripts/pntnc2ascii.R
asc2nc_SKTQ_SKBO_20200201.nc >
> asc2nc_SKTQ_SKBO_20200201.txt
>
> That file contains 85 instances of UGRD, but the level values range
from
> 2546 to 22562. None of them have a level value of exactly 250. And
that's
> why you're getting 0 matches. Looks to me like there's 2 issues:
>
> (1) The units of pressure differ between the fcst and obs.
> (2) No obs exactly match 250mb.
>
> You can handle both issues in the Point-Stat config file. Just
specify
> separate levels for the fcst and obs dictionaries.
>
> fcst = { field = [ { name="UGRD"; level="P250"; } ]; }
> obs = { field = [ { name="UGRD"; level="P20000-30000"; } ]; }
>
> That'll match any obs of UGRD with a pressure value between 20000
and 30000
> to the forecast for P250.
>
> Make sense?
>
> John
>
> On Thu, Jul 23, 2020 at 4:50 PM binyu.wang at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> >
> > Thank you, John.
> >
> > Based on what you said I can not evaluate wind direction directly,
so
> there
> > is no need for me to get WDIR based on UGRD and VGRD from the GEFS
model
> > output. I need to do the WDIR verification because my ensemble
model
> > output (which is based on GEFS wind profile) predicted that the
ash went
> > northward, while the satellite observance shows the ash went
southward
> over
> > one volcano eruption. So I want to identify if there is a problem
for
> WDIR
> > prediction over the volcano area.
> >
> > Following your suggestion, I used point_stat for UGRD/VGRD,
however, the
> > output is empty (no matching pair). But I am sure there are
matching
> pairs
> > for UGRD/VGRD because I have no problem to get non-empty stat.
output
> using
> > "ensemble_stat" and "grid_stat" for UGRD/VGRD. Below is my script:
(and
> my
> > obs. is abstained using ascii2nc)
> >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/ush/
> > verf_g2g_gec_Reventador.sh
> >
> > Thank you.
> > Binyu
> >
> > On Tue, Jul 21, 2020 at 6:47 PM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > Binyu,
> > >
> > > MET does not evaluate wind direction directly for the reason
that you
> > > mention. Since it's a "circular" variable, it does not lend
itself well
> > to
> > > traditional statistics, like RMSE. If you try evaluating wind
direction
> > > directly, you'll get this error message:
> > >
> > > ERROR : PointStatVxOpt::process_config() -> wind direction may
not be
> > > verified using point_stat.
> > >
> > > With U/V pairs, you can run point_stat to evaluate those vectors
and
> > write
> > > the VL1L2 partial sums and VCNT statistics. I'd recommend
running
> > > point_stat to evaluate the ensemble mean using the VL1L2 and
VCNT line
> > > types. Those VCNT statistic are described in the MET User's
Guide.
> > >
> > > John
> > >
> > > On Tue, Jul 21, 2020 at 3:22 PM binyu.wang at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
>
> > > >
> > > > John,
> > > >
> > > > Although my original Obs. data has no UGRD/VGRD, I did derive
them
> > using
> > > > WIND and WDIR (the original input is ascII file, so I used
ascIInc
> and
> > > > grid2point to convert them to *nc file, which has
> UGRD/VGRD/WIND/WDIR).
> > > So
> > > > it is not a problem for me.
> > > >
> > > > "For ensemble_stat, you could verify wind speed by requesting
WIND in
> > the
> > > > config file." But WIND only tells the magnitude, not the
direction,
> > > right?
> > > >
> > > > So how does the MET deal with the degree for WDIR? If
WDIR=355degree
> > > from
> > > > MODEL, and WDIR=0 from OBS, will MET treat them as a big
difference
> or
> > > > small difference? I know how to do the ensemble verification
for
> > > UGRD/VGRD,
> > > > but my main interest is WDIR. I want to know if I could treat
WDIR as
> > > > UGRD/VGRD using ensemble_stat and grid_stat.
> > > >
> > > > Thank you.
> > > > Binyu
> > > >
> > > >
> > > >
> > > > On Tue, Jul 21, 2020 at 4:07 PM John Halley Gotway via RT <
> > > > met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > > Binyu,
> > > > >
> > > > > Let me address wind speed first (WIND). When processing GRIB
1 or 2
> > > > files,
> > > > > when you request wind speed in a MET config file, MET will
first
> try
> > to
> > > > > find a record of WIND directly in that file. If not present,
it
> will
> > > > > automatically try to find the corresponding UGRD and VGRD
records.
> > And
> > > > > it'll automatically derive wind speed on the fly.
> > > > >
> > > > > In regards to wind direction (WDIR), the MET tools do not
verify it
> > > > > directly. In fact, if you request it, you'll see an error
message
> > > stating
> > > > > that.
> > > > >
> > > > > When running point_stat and grid_stat, you can compute the
VCNT
> > (vector
> > > > > continuous statistics) line type. And the vector partial
sums
> (VL1L2
> > > line
> > > > > type) is also useful. But those require the comparison of
U/V
> > > components.
> > > > > And it sounds like you only have wind speed and direction in
the
> > > > > observations. So that's a limitation.
> > > > >
> > > > > For ensemble_stat, you could verify wind speed by requesting
WIND
> in
> > > the
> > > > > config file.
> > > > >
> > > > > John
> > > > >
> > > > > On Tue, Jul 21, 2020 at 12:15 PM binyu.wang at noaa.gov via RT
<
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > > >
> > > > > > Tue Jul 21 12:15:18 2020: Request 95970 was acted upon.
> > > > > > Transaction: Ticket created by binyu.wang at noaa.gov
> > > > > > Queue: met_help
> > > > > > Subject: Wind direction unsemble verifcaion
> > > > > > Owner: Nobody
> > > > > > Requestors: binyu.wang at noaa.gov
> > > > > > Status: new
> > > > > > Ticket <URL:
> > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > > > >
> > > > > >
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I am working on ensemble wind direction verification using
the
> > "gefs"
> > > > > > model. I noticed that MET could handle wind direction
using
> > > "grid_stat"
> > > > > and
> > > > > > "aggregate_stat", but this is not for ensemble. The gefs
model
> only
> > > has
> > > > > > UGRD and VGRD (no direction) and my observation has WIND
SPEED
> and
> > > WIND
> > > > > > DIRECTION. Of course I can get WIND DIRECTION for model
data (or
> > > UGRD
> > > > > and
> > > > > > VGRD for observation). But I think it will not be the
right way
> if
> > I
> > > > just
> > > > > > use ensemble_stat and grid_stat by treating "WIND
DIRECTION" as
> > > others
> > > > > like
> > > > > > TEMP. because the degree issue from WIND DIrection (e.g: 0
degree
> > is
> > > > > close
> > > > > > to 350 degree. )
> > > > > >
> > > > > > So any suggestions to do wind direction ensemble
verification
> using
> > > > MET?
> > > > > > How the problem (like 0 vs. 350 degree) is resolved in the
> > > > > > "aggregate_stat"?
> > > > > >
> > > > > > Thank you very much.
> > > > > > Binyu
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Wind direction unsemble verifcaion
From: John Halley Gotway
Time: Fri Jul 31 14:08:51 2020
Hi Binyu,
I realize that I never responded on this ticket. But I did respond to
your
other question today. Is this still an open issue or were you able to
figure it out?
Thanks,
John
On Thu, Jul 23, 2020 at 10:12 PM binyu.wang at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
>
> John,
>
> Your email reminds me of another thing that I want to confirm:
>
> Using the same ascII2nc output file ( the one you just saw:
> asc2nc_SKTQ_SKBO_20200201.nc) as input, I used point2grid to get a
new
> output (
>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met/
> regrid_SKTQ_SKBO_t12z.20200201.nc).
> The new output has a pressure level like P250. From the MET
documentation:
> "point2grid input_filename to_grid output_filename", the input is
> re-grided based on "to_grid" file. How the input got "pressure
level"? I
> guess in MET, the same relationship between height and pressure in
> "to_grid" is assigned to the input? I.e: over one site in the
"to_grid"
> file, the pressure level 250mb is corresponding to 10000m , MET
treats the
> same relationship to input, so the site with height 10000m is
> assigned 250mb as pressure level. Am I correct?
>
> Thank you.
> Binyu
>
>
>
> On Thu, Jul 23, 2020 at 7:24 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Binyu,
> >
> > I logged onto Mars, took a look at your shell script, and ran
these
> > commands:
> >
> >
> >
> > *module use
> >
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/modulefilesmodule
> > load met/9.0.2*
> > *mkdir -p out/point_stat*
> >
> > *point_stat
> >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/EMC_HYSPLIT/inout/ptmp/com/gefs/prod/gefs.20200201/00/pgrb2ap5/gec00.t00z.pgrb2a.0p50.f012
> >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met_temp/asc2nc_SKTQ_SKBO_20200201.nc
> >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/parm/PointStatConfig
> > -log run_pt.log -outdir out/point_stat -v 3*
> >
> > But this finds 0 matched pairs and the log messages indicates that
it's a
> > level mismatch:
> >
> > DEBUG 2: Processing UGRD/P250 versus UGRD/P250, for observation
type
> > ADPUPA, over region FULL, for interpolation method NEAREST(1),
using 0
> > matched pairs.
> > DEBUG 3: Number of matched pairs = 0
> > DEBUG 3: Observations processed = 340
> > ...
> > DEBUG 3: Rejected: level mismatch = 85
> >
> > So let's check the obs that are in the file
> asc2nc_SKTQ_SKBO_20200201.nc. I
> > copied that file to my local machine and ran this Rscript to dump
it back
> > out to an easier to read ascii format:
> >
> > Rscript met/scripts/Rscripts/pntnc2ascii.R
asc2nc_SKTQ_SKBO_20200201.nc >
> > asc2nc_SKTQ_SKBO_20200201.txt
> >
> > That file contains 85 instances of UGRD, but the level values
range from
> > 2546 to 22562. None of them have a level value of exactly 250. And
that's
> > why you're getting 0 matches. Looks to me like there's 2 issues:
> >
> > (1) The units of pressure differ between the fcst and obs.
> > (2) No obs exactly match 250mb.
> >
> > You can handle both issues in the Point-Stat config file. Just
specify
> > separate levels for the fcst and obs dictionaries.
> >
> > fcst = { field = [ { name="UGRD"; level="P250"; } ]; }
> > obs = { field = [ { name="UGRD"; level="P20000-30000"; } ]; }
> >
> > That'll match any obs of UGRD with a pressure value between 20000
and
> 30000
> > to the forecast for P250.
> >
> > Make sense?
> >
> > John
> >
> > On Thu, Jul 23, 2020 at 4:50 PM binyu.wang at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> > >
> > > Thank you, John.
> > >
> > > Based on what you said I can not evaluate wind direction
directly, so
> > there
> > > is no need for me to get WDIR based on UGRD and VGRD from the
GEFS
> model
> > > output. I need to do the WDIR verification because my ensemble
model
> > > output (which is based on GEFS wind profile) predicted that the
ash
> went
> > > northward, while the satellite observance shows the ash went
southward
> > over
> > > one volcano eruption. So I want to identify if there is a
problem for
> > WDIR
> > > prediction over the volcano area.
> > >
> > > Following your suggestion, I used point_stat for UGRD/VGRD,
however,
> the
> > > output is empty (no matching pair). But I am sure there are
matching
> > pairs
> > > for UGRD/VGRD because I have no problem to get non-empty stat.
output
> > using
> > > "ensemble_stat" and "grid_stat" for UGRD/VGRD. Below is my
script: (and
> > my
> > > obs. is abstained using ascii2nc)
> > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/ush/
> > > verf_g2g_gec_Reventador.sh
> > >
> > > Thank you.
> > > Binyu
> > >
> > > On Tue, Jul 21, 2020 at 6:47 PM John Halley Gotway via RT <
> > > met_help at ucar.edu>
> > > wrote:
> > >
> > > > Binyu,
> > > >
> > > > MET does not evaluate wind direction directly for the reason
that you
> > > > mention. Since it's a "circular" variable, it does not lend
itself
> well
> > > to
> > > > traditional statistics, like RMSE. If you try evaluating wind
> direction
> > > > directly, you'll get this error message:
> > > >
> > > > ERROR : PointStatVxOpt::process_config() -> wind direction
may not
> be
> > > > verified using point_stat.
> > > >
> > > > With U/V pairs, you can run point_stat to evaluate those
vectors and
> > > write
> > > > the VL1L2 partial sums and VCNT statistics. I'd recommend
running
> > > > point_stat to evaluate the ensemble mean using the VL1L2 and
VCNT
> line
> > > > types. Those VCNT statistic are described in the MET User's
Guide.
> > > >
> > > > John
> > > >
> > > > On Tue, Jul 21, 2020 at 3:22 PM binyu.wang at noaa.gov via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> > > > >
> > > > > John,
> > > > >
> > > > > Although my original Obs. data has no UGRD/VGRD, I did
derive them
> > > using
> > > > > WIND and WDIR (the original input is ascII file, so I used
ascIInc
> > and
> > > > > grid2point to convert them to *nc file, which has
> > UGRD/VGRD/WIND/WDIR).
> > > > So
> > > > > it is not a problem for me.
> > > > >
> > > > > "For ensemble_stat, you could verify wind speed by
requesting WIND
> in
> > > the
> > > > > config file." But WIND only tells the magnitude, not the
> direction,
> > > > right?
> > > > >
> > > > > So how does the MET deal with the degree for WDIR? If
> WDIR=355degree
> > > > from
> > > > > MODEL, and WDIR=0 from OBS, will MET treat them as a big
difference
> > or
> > > > > small difference? I know how to do the ensemble verification
for
> > > > UGRD/VGRD,
> > > > > but my main interest is WDIR. I want to know if I could
treat WDIR
> as
> > > > > UGRD/VGRD using ensemble_stat and grid_stat.
> > > > >
> > > > > Thank you.
> > > > > Binyu
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Jul 21, 2020 at 4:07 PM John Halley Gotway via RT <
> > > > > met_help at ucar.edu>
> > > > > wrote:
> > > > >
> > > > > > Binyu,
> > > > > >
> > > > > > Let me address wind speed first (WIND). When processing
GRIB 1
> or 2
> > > > > files,
> > > > > > when you request wind speed in a MET config file, MET will
first
> > try
> > > to
> > > > > > find a record of WIND directly in that file. If not
present, it
> > will
> > > > > > automatically try to find the corresponding UGRD and VGRD
> records.
> > > And
> > > > > > it'll automatically derive wind speed on the fly.
> > > > > >
> > > > > > In regards to wind direction (WDIR), the MET tools do not
verify
> it
> > > > > > directly. In fact, if you request it, you'll see an error
message
> > > > stating
> > > > > > that.
> > > > > >
> > > > > > When running point_stat and grid_stat, you can compute the
VCNT
> > > (vector
> > > > > > continuous statistics) line type. And the vector partial
sums
> > (VL1L2
> > > > line
> > > > > > type) is also useful. But those require the comparison of
U/V
> > > > components.
> > > > > > And it sounds like you only have wind speed and direction
in the
> > > > > > observations. So that's a limitation.
> > > > > >
> > > > > > For ensemble_stat, you could verify wind speed by
requesting WIND
> > in
> > > > the
> > > > > > config file.
> > > > > >
> > > > > > John
> > > > > >
> > > > > > On Tue, Jul 21, 2020 at 12:15 PM binyu.wang at noaa.gov via
RT <
> > > > > > met_help at ucar.edu> wrote:
> > > > > >
> > > > > > >
> > > > > > > Tue Jul 21 12:15:18 2020: Request 95970 was acted upon.
> > > > > > > Transaction: Ticket created by binyu.wang at noaa.gov
> > > > > > > Queue: met_help
> > > > > > > Subject: Wind direction unsemble verifcaion
> > > > > > > Owner: Nobody
> > > > > > > Requestors: binyu.wang at noaa.gov
> > > > > > > Status: new
> > > > > > > Ticket <URL:
> > > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > I am working on ensemble wind direction verification
using the
> > > "gefs"
> > > > > > > model. I noticed that MET could handle wind direction
using
> > > > "grid_stat"
> > > > > > and
> > > > > > > "aggregate_stat", but this is not for ensemble. The gefs
model
> > only
> > > > has
> > > > > > > UGRD and VGRD (no direction) and my observation has WIND
SPEED
> > and
> > > > WIND
> > > > > > > DIRECTION. Of course I can get WIND DIRECTION for model
data
> (or
> > > > UGRD
> > > > > > and
> > > > > > > VGRD for observation). But I think it will not be the
right way
> > if
> > > I
> > > > > just
> > > > > > > use ensemble_stat and grid_stat by treating "WIND
DIRECTION" as
> > > > others
> > > > > > like
> > > > > > > TEMP. because the degree issue from WIND DIrection (e.g:
0
> degree
> > > is
> > > > > > close
> > > > > > > to 350 degree. )
> > > > > > >
> > > > > > > So any suggestions to do wind direction ensemble
verification
> > using
> > > > > MET?
> > > > > > > How the problem (like 0 vs. 350 degree) is resolved in
the
> > > > > > > "aggregate_stat"?
> > > > > > >
> > > > > > > Thank you very much.
> > > > > > > Binyu
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Wind direction unsemble verifcaion
From: binyu.wang at noaa.gov
Time: Fri Jul 31 15:09:32 2020
No,actually they are different questions. I do still need confirmation
for
my guess in the previous email. Thank you.
On Fri, Jul 31, 2020 at 4:09 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Hi Binyu,
>
> I realize that I never responded on this ticket. But I did respond
to your
> other question today. Is this still an open issue or were you able
to
> figure it out?
>
> Thanks,
> John
>
> On Thu, Jul 23, 2020 at 10:12 PM binyu.wang at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> >
> > John,
> >
> > Your email reminds me of another thing that I want to confirm:
> >
> > Using the same ascII2nc output file ( the one you just saw:
> > asc2nc_SKTQ_SKBO_20200201.nc) as input, I used point2grid to get a
new
> > output (
> >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met/
> > regrid_SKTQ_SKBO_t12z.20200201.nc).
> > The new output has a pressure level like P250. From the MET
> documentation:
> > "point2grid input_filename to_grid output_filename", the input is
> > re-grided based on "to_grid" file. How the input got "pressure
level"? I
> > guess in MET, the same relationship between height and pressure in
> > "to_grid" is assigned to the input? I.e: over one site in the
"to_grid"
> > file, the pressure level 250mb is corresponding to 10000m , MET
treats
> the
> > same relationship to input, so the site with height 10000m is
> > assigned 250mb as pressure level. Am I correct?
> >
> > Thank you.
> > Binyu
> >
> >
> >
> > On Thu, Jul 23, 2020 at 7:24 PM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > Binyu,
> > >
> > > I logged onto Mars, took a look at your shell script, and ran
these
> > > commands:
> > >
> > >
> > >
> > > *module use
> > >
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/modulefilesmodule
> > > load met/9.0.2*
> > > *mkdir -p out/point_stat*
> > >
> > > *point_stat
> > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/EMC_HYSPLIT/inout/ptmp/com/gefs/prod/gefs.20200201/00/pgrb2ap5/gec00.t00z.pgrb2a.0p50.f012
> > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met_temp/asc2nc_SKTQ_SKBO_20200201.nc
> > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/parm/PointStatConfig
> > > -log run_pt.log -outdir out/point_stat -v 3*
> > >
> > > But this finds 0 matched pairs and the log messages indicates
that
> it's a
> > > level mismatch:
> > >
> > > DEBUG 2: Processing UGRD/P250 versus UGRD/P250, for observation
type
> > > ADPUPA, over region FULL, for interpolation method NEAREST(1),
using 0
> > > matched pairs.
> > > DEBUG 3: Number of matched pairs = 0
> > > DEBUG 3: Observations processed = 340
> > > ...
> > > DEBUG 3: Rejected: level mismatch = 85
> > >
> > > So let's check the obs that are in the file
> > asc2nc_SKTQ_SKBO_20200201.nc. I
> > > copied that file to my local machine and ran this Rscript to
dump it
> back
> > > out to an easier to read ascii format:
> > >
> > > Rscript met/scripts/Rscripts/pntnc2ascii.R
> asc2nc_SKTQ_SKBO_20200201.nc >
> > > asc2nc_SKTQ_SKBO_20200201.txt
> > >
> > > That file contains 85 instances of UGRD, but the level values
range
> from
> > > 2546 to 22562. None of them have a level value of exactly 250.
And
> that's
> > > why you're getting 0 matches. Looks to me like there's 2 issues:
> > >
> > > (1) The units of pressure differ between the fcst and obs.
> > > (2) No obs exactly match 250mb.
> > >
> > > You can handle both issues in the Point-Stat config file. Just
specify
> > > separate levels for the fcst and obs dictionaries.
> > >
> > > fcst = { field = [ { name="UGRD"; level="P250"; } ]; }
> > > obs = { field = [ { name="UGRD"; level="P20000-30000"; } ]; }
> > >
> > > That'll match any obs of UGRD with a pressure value between
20000 and
> > 30000
> > > to the forecast for P250.
> > >
> > > Make sense?
> > >
> > > John
> > >
> > > On Thu, Jul 23, 2020 at 4:50 PM binyu.wang at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
>
> > > >
> > > > Thank you, John.
> > > >
> > > > Based on what you said I can not evaluate wind direction
directly, so
> > > there
> > > > is no need for me to get WDIR based on UGRD and VGRD from the
GEFS
> > model
> > > > output. I need to do the WDIR verification because my
ensemble model
> > > > output (which is based on GEFS wind profile) predicted that
the ash
> > went
> > > > northward, while the satellite observance shows the ash went
> southward
> > > over
> > > > one volcano eruption. So I want to identify if there is a
problem for
> > > WDIR
> > > > prediction over the volcano area.
> > > >
> > > > Following your suggestion, I used point_stat for UGRD/VGRD,
however,
> > the
> > > > output is empty (no matching pair). But I am sure there are
matching
> > > pairs
> > > > for UGRD/VGRD because I have no problem to get non-empty stat.
output
> > > using
> > > > "ensemble_stat" and "grid_stat" for UGRD/VGRD. Below is my
script:
> (and
> > > my
> > > > obs. is abstained using ascii2nc)
> > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/ush/
> > > > verf_g2g_gec_Reventador.sh
> > > >
> > > > Thank you.
> > > > Binyu
> > > >
> > > > On Tue, Jul 21, 2020 at 6:47 PM John Halley Gotway via RT <
> > > > met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > > Binyu,
> > > > >
> > > > > MET does not evaluate wind direction directly for the reason
that
> you
> > > > > mention. Since it's a "circular" variable, it does not lend
itself
> > well
> > > > to
> > > > > traditional statistics, like RMSE. If you try evaluating
wind
> > direction
> > > > > directly, you'll get this error message:
> > > > >
> > > > > ERROR : PointStatVxOpt::process_config() -> wind direction
may not
> > be
> > > > > verified using point_stat.
> > > > >
> > > > > With U/V pairs, you can run point_stat to evaluate those
vectors
> and
> > > > write
> > > > > the VL1L2 partial sums and VCNT statistics. I'd recommend
running
> > > > > point_stat to evaluate the ensemble mean using the VL1L2 and
VCNT
> > line
> > > > > types. Those VCNT statistic are described in the MET User's
Guide.
> > > > >
> > > > > John
> > > > >
> > > > > On Tue, Jul 21, 2020 at 3:22 PM binyu.wang at noaa.gov via RT <
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > > >
> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> > > > > >
> > > > > > John,
> > > > > >
> > > > > > Although my original Obs. data has no UGRD/VGRD, I did
derive
> them
> > > > using
> > > > > > WIND and WDIR (the original input is ascII file, so I used
> ascIInc
> > > and
> > > > > > grid2point to convert them to *nc file, which has
> > > UGRD/VGRD/WIND/WDIR).
> > > > > So
> > > > > > it is not a problem for me.
> > > > > >
> > > > > > "For ensemble_stat, you could verify wind speed by
requesting
> WIND
> > in
> > > > the
> > > > > > config file." But WIND only tells the magnitude, not the
> > direction,
> > > > > right?
> > > > > >
> > > > > > So how does the MET deal with the degree for WDIR? If
> > WDIR=355degree
> > > > > from
> > > > > > MODEL, and WDIR=0 from OBS, will MET treat them as a big
> difference
> > > or
> > > > > > small difference? I know how to do the ensemble
verification for
> > > > > UGRD/VGRD,
> > > > > > but my main interest is WDIR. I want to know if I could
treat
> WDIR
> > as
> > > > > > UGRD/VGRD using ensemble_stat and grid_stat.
> > > > > >
> > > > > > Thank you.
> > > > > > Binyu
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Jul 21, 2020 at 4:07 PM John Halley Gotway via RT
<
> > > > > > met_help at ucar.edu>
> > > > > > wrote:
> > > > > >
> > > > > > > Binyu,
> > > > > > >
> > > > > > > Let me address wind speed first (WIND). When processing
GRIB 1
> > or 2
> > > > > > files,
> > > > > > > when you request wind speed in a MET config file, MET
will
> first
> > > try
> > > > to
> > > > > > > find a record of WIND directly in that file. If not
present, it
> > > will
> > > > > > > automatically try to find the corresponding UGRD and
VGRD
> > records.
> > > > And
> > > > > > > it'll automatically derive wind speed on the fly.
> > > > > > >
> > > > > > > In regards to wind direction (WDIR), the MET tools do
not
> verify
> > it
> > > > > > > directly. In fact, if you request it, you'll see an
error
> message
> > > > > stating
> > > > > > > that.
> > > > > > >
> > > > > > > When running point_stat and grid_stat, you can compute
the VCNT
> > > > (vector
> > > > > > > continuous statistics) line type. And the vector partial
sums
> > > (VL1L2
> > > > > line
> > > > > > > type) is also useful. But those require the comparison
of U/V
> > > > > components.
> > > > > > > And it sounds like you only have wind speed and
direction in
> the
> > > > > > > observations. So that's a limitation.
> > > > > > >
> > > > > > > For ensemble_stat, you could verify wind speed by
requesting
> WIND
> > > in
> > > > > the
> > > > > > > config file.
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > On Tue, Jul 21, 2020 at 12:15 PM binyu.wang at noaa.gov via
RT <
> > > > > > > met_help at ucar.edu> wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > Tue Jul 21 12:15:18 2020: Request 95970 was acted
upon.
> > > > > > > > Transaction: Ticket created by binyu.wang at noaa.gov
> > > > > > > > Queue: met_help
> > > > > > > > Subject: Wind direction unsemble verifcaion
> > > > > > > > Owner: Nobody
> > > > > > > > Requestors: binyu.wang at noaa.gov
> > > > > > > > Status: new
> > > > > > > > Ticket <URL:
> > > > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > I am working on ensemble wind direction verification
using
> the
> > > > "gefs"
> > > > > > > > model. I noticed that MET could handle wind direction
using
> > > > > "grid_stat"
> > > > > > > and
> > > > > > > > "aggregate_stat", but this is not for ensemble. The
gefs
> model
> > > only
> > > > > has
> > > > > > > > UGRD and VGRD (no direction) and my observation has
WIND
> SPEED
> > > and
> > > > > WIND
> > > > > > > > DIRECTION. Of course I can get WIND DIRECTION for
model data
> > (or
> > > > > UGRD
> > > > > > > and
> > > > > > > > VGRD for observation). But I think it will not be the
right
> way
> > > if
> > > > I
> > > > > > just
> > > > > > > > use ensemble_stat and grid_stat by treating "WIND
DIRECTION"
> as
> > > > > others
> > > > > > > like
> > > > > > > > TEMP. because the degree issue from WIND DIrection
(e.g: 0
> > degree
> > > > is
> > > > > > > close
> > > > > > > > to 350 degree. )
> > > > > > > >
> > > > > > > > So any suggestions to do wind direction ensemble
verification
> > > using
> > > > > > MET?
> > > > > > > > How the problem (like 0 vs. 350 degree) is resolved in
the
> > > > > > > > "aggregate_stat"?
> > > > > > > >
> > > > > > > > Thank you very much.
> > > > > > > > Binyu
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Wind direction unsemble verifcaion
From: John Halley Gotway
Time: Fri Jul 31 16:47:16 2020
Binyu,
Back to this question... sorry for the delay.
No MET is not, in general, converting between pressure and height
levels.
When running Point-Stat, you generally compare forecasts at pressure
levels
to observations at pressure levels... and forecasts at height levels
to
observations at height levels.
But you are asking about running the point2grid tool. I logged on to
wcoss
and took a look at:
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventad
or/Sounding/2020/SKTQ_SKBO/UWYO_obs_met/
regrid_SKTQ_SKBO_t12z.20200201.nc
<http://regrid_sktq_skbo_t12z.20200201.nc/>
I looked at the variables named "UGRD_cnt" and "UGRD". I see missing
data
everywhere other than a single grid point.
I ran the following plot_data_plane commands to visualize this data
and
have attached the result:
plot_data_plane regrid_SKTQ_SKBO_t12z.20200201.nc UGRD.ps
'name="UGRD";
level="(*,*)";'
plot_data_plane regrid_SKTQ_SKBO_t12z.20200201.nc UGRD_cnt.ps
'name="UGRD_cnt"; level="(*,*)";'
There's a single pink dot in northern south america which isn't even
really
visible in the attached plots.
This doesn't look to me like a very good use of the point2grid tool.
It's
generally intended to read a dense set of point observations and put
them
onto a grid.
John
[image: UGRD.png]
[image: UGRD_cnt.png]
John
On Fri, Jul 31, 2020 at 3:10 PM binyu.wang at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
>
> No,actually they are different questions. I do still need
confirmation for
> my guess in the previous email. Thank you.
>
>
> On Fri, Jul 31, 2020 at 4:09 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Hi Binyu,
> >
> > I realize that I never responded on this ticket. But I did respond
to
> your
> > other question today. Is this still an open issue or were you able
to
> > figure it out?
> >
> > Thanks,
> > John
> >
> > On Thu, Jul 23, 2020 at 10:12 PM binyu.wang at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> > >
> > > John,
> > >
> > > Your email reminds me of another thing that I want to confirm:
> > >
> > > Using the same ascII2nc output file ( the one you just saw:
> > > asc2nc_SKTQ_SKBO_20200201.nc) as input, I used point2grid to get
a new
> > > output (
> > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met/
> > > regrid_SKTQ_SKBO_t12z.20200201.nc).
> > > The new output has a pressure level like P250. From the MET
> > documentation:
> > > "point2grid input_filename to_grid output_filename", the input
is
> > > re-grided based on "to_grid" file. How the input got "pressure
level"?
> I
> > > guess in MET, the same relationship between height and pressure
in
> > > "to_grid" is assigned to the input? I.e: over one site in the
"to_grid"
> > > file, the pressure level 250mb is corresponding to 10000m , MET
treats
> > the
> > > same relationship to input, so the site with height 10000m is
> > > assigned 250mb as pressure level. Am I correct?
> > >
> > > Thank you.
> > > Binyu
> > >
> > >
> > >
> > > On Thu, Jul 23, 2020 at 7:24 PM John Halley Gotway via RT <
> > > met_help at ucar.edu>
> > > wrote:
> > >
> > > > Binyu,
> > > >
> > > > I logged onto Mars, took a look at your shell script, and ran
these
> > > > commands:
> > > >
> > > >
> > > >
> > > > *module use
> > > >
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/modulefilesmodule
> > > > load met/9.0.2*
> > > > *mkdir -p out/point_stat*
> > > >
> > > > *point_stat
> > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/EMC_HYSPLIT/inout/ptmp/com/gefs/prod/gefs.20200201/00/pgrb2ap5/gec00.t00z.pgrb2a.0p50.f012
> > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met_temp/asc2nc_SKTQ_SKBO_20200201.nc
> > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/parm/PointStatConfig
> > > > -log run_pt.log -outdir out/point_stat -v 3*
> > > >
> > > > But this finds 0 matched pairs and the log messages indicates
that
> > it's a
> > > > level mismatch:
> > > >
> > > > DEBUG 2: Processing UGRD/P250 versus UGRD/P250, for
observation type
> > > > ADPUPA, over region FULL, for interpolation method NEAREST(1),
using
> 0
> > > > matched pairs.
> > > > DEBUG 3: Number of matched pairs = 0
> > > > DEBUG 3: Observations processed = 340
> > > > ...
> > > > DEBUG 3: Rejected: level mismatch = 85
> > > >
> > > > So let's check the obs that are in the file
> > > asc2nc_SKTQ_SKBO_20200201.nc. I
> > > > copied that file to my local machine and ran this Rscript to
dump it
> > back
> > > > out to an easier to read ascii format:
> > > >
> > > > Rscript met/scripts/Rscripts/pntnc2ascii.R
> > asc2nc_SKTQ_SKBO_20200201.nc >
> > > > asc2nc_SKTQ_SKBO_20200201.txt
> > > >
> > > > That file contains 85 instances of UGRD, but the level values
range
> > from
> > > > 2546 to 22562. None of them have a level value of exactly 250.
And
> > that's
> > > > why you're getting 0 matches. Looks to me like there's 2
issues:
> > > >
> > > > (1) The units of pressure differ between the fcst and obs.
> > > > (2) No obs exactly match 250mb.
> > > >
> > > > You can handle both issues in the Point-Stat config file. Just
> specify
> > > > separate levels for the fcst and obs dictionaries.
> > > >
> > > > fcst = { field = [ { name="UGRD"; level="P250"; } ]; }
> > > > obs = { field = [ { name="UGRD"; level="P20000-30000"; } ]; }
> > > >
> > > > That'll match any obs of UGRD with a pressure value between
20000 and
> > > 30000
> > > > to the forecast for P250.
> > > >
> > > > Make sense?
> > > >
> > > > John
> > > >
> > > > On Thu, Jul 23, 2020 at 4:50 PM binyu.wang at noaa.gov via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> > > > >
> > > > > Thank you, John.
> > > > >
> > > > > Based on what you said I can not evaluate wind direction
directly,
> so
> > > > there
> > > > > is no need for me to get WDIR based on UGRD and VGRD from
the GEFS
> > > model
> > > > > output. I need to do the WDIR verification because my
ensemble
> model
> > > > > output (which is based on GEFS wind profile) predicted that
the ash
> > > went
> > > > > northward, while the satellite observance shows the ash went
> > southward
> > > > over
> > > > > one volcano eruption. So I want to identify if there is a
problem
> for
> > > > WDIR
> > > > > prediction over the volcano area.
> > > > >
> > > > > Following your suggestion, I used point_stat for UGRD/VGRD,
> however,
> > > the
> > > > > output is empty (no matching pair). But I am sure there are
> matching
> > > > pairs
> > > > > for UGRD/VGRD because I have no problem to get non-empty
stat.
> output
> > > > using
> > > > > "ensemble_stat" and "grid_stat" for UGRD/VGRD. Below is my
script:
> > (and
> > > > my
> > > > > obs. is abstained using ascii2nc)
> > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/ush/
> > > > > verf_g2g_gec_Reventador.sh
> > > > >
> > > > > Thank you.
> > > > > Binyu
> > > > >
> > > > > On Tue, Jul 21, 2020 at 6:47 PM John Halley Gotway via RT <
> > > > > met_help at ucar.edu>
> > > > > wrote:
> > > > >
> > > > > > Binyu,
> > > > > >
> > > > > > MET does not evaluate wind direction directly for the
reason that
> > you
> > > > > > mention. Since it's a "circular" variable, it does not
lend
> itself
> > > well
> > > > > to
> > > > > > traditional statistics, like RMSE. If you try evaluating
wind
> > > direction
> > > > > > directly, you'll get this error message:
> > > > > >
> > > > > > ERROR : PointStatVxOpt::process_config() -> wind
direction may
> not
> > > be
> > > > > > verified using point_stat.
> > > > > >
> > > > > > With U/V pairs, you can run point_stat to evaluate those
vectors
> > and
> > > > > write
> > > > > > the VL1L2 partial sums and VCNT statistics. I'd recommend
running
> > > > > > point_stat to evaluate the ensemble mean using the VL1L2
and VCNT
> > > line
> > > > > > types. Those VCNT statistic are described in the MET
User's
> Guide.
> > > > > >
> > > > > > John
> > > > > >
> > > > > > On Tue, Jul 21, 2020 at 3:22 PM binyu.wang at noaa.gov via RT
<
> > > > > > met_help at ucar.edu> wrote:
> > > > > >
> > > > > > >
> > > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> >
> > > > > > >
> > > > > > > John,
> > > > > > >
> > > > > > > Although my original Obs. data has no UGRD/VGRD, I did
derive
> > them
> > > > > using
> > > > > > > WIND and WDIR (the original input is ascII file, so I
used
> > ascIInc
> > > > and
> > > > > > > grid2point to convert them to *nc file, which has
> > > > UGRD/VGRD/WIND/WDIR).
> > > > > > So
> > > > > > > it is not a problem for me.
> > > > > > >
> > > > > > > "For ensemble_stat, you could verify wind speed by
requesting
> > WIND
> > > in
> > > > > the
> > > > > > > config file." But WIND only tells the magnitude, not
the
> > > direction,
> > > > > > right?
> > > > > > >
> > > > > > > So how does the MET deal with the degree for WDIR? If
> > > WDIR=355degree
> > > > > > from
> > > > > > > MODEL, and WDIR=0 from OBS, will MET treat them as a big
> > difference
> > > > or
> > > > > > > small difference? I know how to do the ensemble
verification
> for
> > > > > > UGRD/VGRD,
> > > > > > > but my main interest is WDIR. I want to know if I could
treat
> > WDIR
> > > as
> > > > > > > UGRD/VGRD using ensemble_stat and grid_stat.
> > > > > > >
> > > > > > > Thank you.
> > > > > > > Binyu
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Jul 21, 2020 at 4:07 PM John Halley Gotway via
RT <
> > > > > > > met_help at ucar.edu>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Binyu,
> > > > > > > >
> > > > > > > > Let me address wind speed first (WIND). When
processing GRIB
> 1
> > > or 2
> > > > > > > files,
> > > > > > > > when you request wind speed in a MET config file, MET
will
> > first
> > > > try
> > > > > to
> > > > > > > > find a record of WIND directly in that file. If not
present,
> it
> > > > will
> > > > > > > > automatically try to find the corresponding UGRD and
VGRD
> > > records.
> > > > > And
> > > > > > > > it'll automatically derive wind speed on the fly.
> > > > > > > >
> > > > > > > > In regards to wind direction (WDIR), the MET tools do
not
> > verify
> > > it
> > > > > > > > directly. In fact, if you request it, you'll see an
error
> > message
> > > > > > stating
> > > > > > > > that.
> > > > > > > >
> > > > > > > > When running point_stat and grid_stat, you can compute
the
> VCNT
> > > > > (vector
> > > > > > > > continuous statistics) line type. And the vector
partial sums
> > > > (VL1L2
> > > > > > line
> > > > > > > > type) is also useful. But those require the comparison
of U/V
> > > > > > components.
> > > > > > > > And it sounds like you only have wind speed and
direction in
> > the
> > > > > > > > observations. So that's a limitation.
> > > > > > > >
> > > > > > > > For ensemble_stat, you could verify wind speed by
requesting
> > WIND
> > > > in
> > > > > > the
> > > > > > > > config file.
> > > > > > > >
> > > > > > > > John
> > > > > > > >
> > > > > > > > On Tue, Jul 21, 2020 at 12:15 PM binyu.wang at noaa.gov
via RT
> <
> > > > > > > > met_help at ucar.edu> wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Tue Jul 21 12:15:18 2020: Request 95970 was acted
upon.
> > > > > > > > > Transaction: Ticket created by binyu.wang at noaa.gov
> > > > > > > > > Queue: met_help
> > > > > > > > > Subject: Wind direction unsemble verifcaion
> > > > > > > > > Owner: Nobody
> > > > > > > > > Requestors: binyu.wang at noaa.gov
> > > > > > > > > Status: new
> > > > > > > > > Ticket <URL:
> > > > > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hello,
> > > > > > > > >
> > > > > > > > > I am working on ensemble wind direction verification
using
> > the
> > > > > "gefs"
> > > > > > > > > model. I noticed that MET could handle wind
direction using
> > > > > > "grid_stat"
> > > > > > > > and
> > > > > > > > > "aggregate_stat", but this is not for ensemble. The
gefs
> > model
> > > > only
> > > > > > has
> > > > > > > > > UGRD and VGRD (no direction) and my observation has
WIND
> > SPEED
> > > > and
> > > > > > WIND
> > > > > > > > > DIRECTION. Of course I can get WIND DIRECTION for
model
> data
> > > (or
> > > > > > UGRD
> > > > > > > > and
> > > > > > > > > VGRD for observation). But I think it will not be
the right
> > way
> > > > if
> > > > > I
> > > > > > > just
> > > > > > > > > use ensemble_stat and grid_stat by treating "WIND
> DIRECTION"
> > as
> > > > > > others
> > > > > > > > like
> > > > > > > > > TEMP. because the degree issue from WIND DIrection
(e.g: 0
> > > degree
> > > > > is
> > > > > > > > close
> > > > > > > > > to 350 degree. )
> > > > > > > > >
> > > > > > > > > So any suggestions to do wind direction ensemble
> verification
> > > > using
> > > > > > > MET?
> > > > > > > > > How the problem (like 0 vs. 350 degree) is resolved
in the
> > > > > > > > > "aggregate_stat"?
> > > > > > > > >
> > > > > > > > > Thank you very much.
> > > > > > > > > Binyu
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Wind direction unsemble verifcaion
From: binyu.wang at noaa.gov
Time: Fri Jul 31 17:49:32 2020
Yes, you are right. I have very few sites. So you don't recommend
using
point_stat to do the verification?
Binyy
On Fri, Jul 31, 2020 at 6:47 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binyu,
>
> Back to this question... sorry for the delay.
>
> No MET is not, in general, converting between pressure and height
levels.
> When running Point-Stat, you generally compare forecasts at pressure
levels
> to observations at pressure levels... and forecasts at height levels
to
> observations at height levels.
>
> But you are asking about running the point2grid tool. I logged on to
wcoss
> and took a look at:
> /gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventad
> or/Sounding/2020/SKTQ_SKBO/UWYO_obs_met/
> regrid_SKTQ_SKBO_t12z.20200201.nc
> <http://regrid_sktq_skbo_t12z.20200201.nc/>
>
> I looked at the variables named "UGRD_cnt" and "UGRD". I see missing
data
> everywhere other than a single grid point.
> I ran the following plot_data_plane commands to visualize this data
and
> have attached the result:
>
> plot_data_plane regrid_SKTQ_SKBO_t12z.20200201.nc UGRD.ps
'name="UGRD";
> level="(*,*)";'
> plot_data_plane regrid_SKTQ_SKBO_t12z.20200201.nc UGRD_cnt.ps
> 'name="UGRD_cnt"; level="(*,*)";'
>
> There's a single pink dot in northern south america which isn't even
really
> visible in the attached plots.
>
> This doesn't look to me like a very good use of the point2grid tool.
It's
> generally intended to read a dense set of point observations and put
them
> onto a grid.
>
> John
> [image: UGRD.png]
> [image: UGRD_cnt.png]
>
> John
>
> On Fri, Jul 31, 2020 at 3:10 PM binyu.wang at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> >
> > No,actually they are different questions. I do still need
confirmation
> for
> > my guess in the previous email. Thank you.
> >
> >
> > On Fri, Jul 31, 2020 at 4:09 PM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > Hi Binyu,
> > >
> > > I realize that I never responded on this ticket. But I did
respond to
> > your
> > > other question today. Is this still an open issue or were you
able to
> > > figure it out?
> > >
> > > Thanks,
> > > John
> > >
> > > On Thu, Jul 23, 2020 at 10:12 PM binyu.wang at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
>
> > > >
> > > > John,
> > > >
> > > > Your email reminds me of another thing that I want to confirm:
> > > >
> > > > Using the same ascII2nc output file ( the one you just saw:
> > > > asc2nc_SKTQ_SKBO_20200201.nc) as input, I used point2grid to
get a
> new
> > > > output (
> > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met/
> > > > regrid_SKTQ_SKBO_t12z.20200201.nc).
> > > > The new output has a pressure level like P250. From the MET
> > > documentation:
> > > > "point2grid input_filename to_grid output_filename", the input
is
> > > > re-grided based on "to_grid" file. How the input got "pressure
> level"?
> > I
> > > > guess in MET, the same relationship between height and
pressure in
> > > > "to_grid" is assigned to the input? I.e: over one site in the
> "to_grid"
> > > > file, the pressure level 250mb is corresponding to 10000m ,
MET
> treats
> > > the
> > > > same relationship to input, so the site with height 10000m is
> > > > assigned 250mb as pressure level. Am I correct?
> > > >
> > > > Thank you.
> > > > Binyu
> > > >
> > > >
> > > >
> > > > On Thu, Jul 23, 2020 at 7:24 PM John Halley Gotway via RT <
> > > > met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > > Binyu,
> > > > >
> > > > > I logged onto Mars, took a look at your shell script, and
ran these
> > > > > commands:
> > > > >
> > > > >
> > > > >
> > > > > *module use
> > > > >
> >
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/modulefilesmodule
> > > > > load met/9.0.2*
> > > > > *mkdir -p out/point_stat*
> > > > >
> > > > > *point_stat
> > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/EMC_HYSPLIT/inout/ptmp/com/gefs/prod/gefs.20200201/00/pgrb2ap5/gec00.t00z.pgrb2a.0p50.f012
> > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met_temp/asc2nc_SKTQ_SKBO_20200201.nc
> > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/parm/PointStatConfig
> > > > > -log run_pt.log -outdir out/point_stat -v 3*
> > > > >
> > > > > But this finds 0 matched pairs and the log messages
indicates that
> > > it's a
> > > > > level mismatch:
> > > > >
> > > > > DEBUG 2: Processing UGRD/P250 versus UGRD/P250, for
observation
> type
> > > > > ADPUPA, over region FULL, for interpolation method
NEAREST(1),
> using
> > 0
> > > > > matched pairs.
> > > > > DEBUG 3: Number of matched pairs = 0
> > > > > DEBUG 3: Observations processed = 340
> > > > > ...
> > > > > DEBUG 3: Rejected: level mismatch = 85
> > > > >
> > > > > So let's check the obs that are in the file
> > > > asc2nc_SKTQ_SKBO_20200201.nc. I
> > > > > copied that file to my local machine and ran this Rscript to
dump
> it
> > > back
> > > > > out to an easier to read ascii format:
> > > > >
> > > > > Rscript met/scripts/Rscripts/pntnc2ascii.R
> > > asc2nc_SKTQ_SKBO_20200201.nc >
> > > > > asc2nc_SKTQ_SKBO_20200201.txt
> > > > >
> > > > > That file contains 85 instances of UGRD, but the level
values range
> > > from
> > > > > 2546 to 22562. None of them have a level value of exactly
250. And
> > > that's
> > > > > why you're getting 0 matches. Looks to me like there's 2
issues:
> > > > >
> > > > > (1) The units of pressure differ between the fcst and obs.
> > > > > (2) No obs exactly match 250mb.
> > > > >
> > > > > You can handle both issues in the Point-Stat config file.
Just
> > specify
> > > > > separate levels for the fcst and obs dictionaries.
> > > > >
> > > > > fcst = { field = [ { name="UGRD"; level="P250"; } ]; }
> > > > > obs = { field = [ { name="UGRD"; level="P20000-30000"; } ];
}
> > > > >
> > > > > That'll match any obs of UGRD with a pressure value between
20000
> and
> > > > 30000
> > > > > to the forecast for P250.
> > > > >
> > > > > Make sense?
> > > > >
> > > > > John
> > > > >
> > > > > On Thu, Jul 23, 2020 at 4:50 PM binyu.wang at noaa.gov via RT <
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > > >
> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> > > > > >
> > > > > > Thank you, John.
> > > > > >
> > > > > > Based on what you said I can not evaluate wind direction
> directly,
> > so
> > > > > there
> > > > > > is no need for me to get WDIR based on UGRD and VGRD from
the
> GEFS
> > > > model
> > > > > > output. I need to do the WDIR verification because my
ensemble
> > model
> > > > > > output (which is based on GEFS wind profile) predicted
that the
> ash
> > > > went
> > > > > > northward, while the satellite observance shows the ash
went
> > > southward
> > > > > over
> > > > > > one volcano eruption. So I want to identify if there is a
problem
> > for
> > > > > WDIR
> > > > > > prediction over the volcano area.
> > > > > >
> > > > > > Following your suggestion, I used point_stat for
UGRD/VGRD,
> > however,
> > > > the
> > > > > > output is empty (no matching pair). But I am sure there
are
> > matching
> > > > > pairs
> > > > > > for UGRD/VGRD because I have no problem to get non-empty
stat.
> > output
> > > > > using
> > > > > > "ensemble_stat" and "grid_stat" for UGRD/VGRD. Below is my
> script:
> > > (and
> > > > > my
> > > > > > obs. is abstained using ascii2nc)
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/ush/
> > > > > > verf_g2g_gec_Reventador.sh
> > > > > >
> > > > > > Thank you.
> > > > > > Binyu
> > > > > >
> > > > > > On Tue, Jul 21, 2020 at 6:47 PM John Halley Gotway via RT
<
> > > > > > met_help at ucar.edu>
> > > > > > wrote:
> > > > > >
> > > > > > > Binyu,
> > > > > > >
> > > > > > > MET does not evaluate wind direction directly for the
reason
> that
> > > you
> > > > > > > mention. Since it's a "circular" variable, it does not
lend
> > itself
> > > > well
> > > > > > to
> > > > > > > traditional statistics, like RMSE. If you try evaluating
wind
> > > > direction
> > > > > > > directly, you'll get this error message:
> > > > > > >
> > > > > > > ERROR : PointStatVxOpt::process_config() -> wind
direction may
> > not
> > > > be
> > > > > > > verified using point_stat.
> > > > > > >
> > > > > > > With U/V pairs, you can run point_stat to evaluate those
> vectors
> > > and
> > > > > > write
> > > > > > > the VL1L2 partial sums and VCNT statistics. I'd
recommend
> running
> > > > > > > point_stat to evaluate the ensemble mean using the VL1L2
and
> VCNT
> > > > line
> > > > > > > types. Those VCNT statistic are described in the MET
User's
> > Guide.
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > On Tue, Jul 21, 2020 at 3:22 PM binyu.wang at noaa.gov via
RT <
> > > > > > > met_help at ucar.edu> wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > >
> > > > > > > >
> > > > > > > > John,
> > > > > > > >
> > > > > > > > Although my original Obs. data has no UGRD/VGRD, I did
derive
> > > them
> > > > > > using
> > > > > > > > WIND and WDIR (the original input is ascII file, so I
used
> > > ascIInc
> > > > > and
> > > > > > > > grid2point to convert them to *nc file, which has
> > > > > UGRD/VGRD/WIND/WDIR).
> > > > > > > So
> > > > > > > > it is not a problem for me.
> > > > > > > >
> > > > > > > > "For ensemble_stat, you could verify wind speed by
requesting
> > > WIND
> > > > in
> > > > > > the
> > > > > > > > config file." But WIND only tells the magnitude, not
the
> > > > direction,
> > > > > > > right?
> > > > > > > >
> > > > > > > > So how does the MET deal with the degree for WDIR? If
> > > > WDIR=355degree
> > > > > > > from
> > > > > > > > MODEL, and WDIR=0 from OBS, will MET treat them as a
big
> > > difference
> > > > > or
> > > > > > > > small difference? I know how to do the ensemble
verification
> > for
> > > > > > > UGRD/VGRD,
> > > > > > > > but my main interest is WDIR. I want to know if I
could treat
> > > WDIR
> > > > as
> > > > > > > > UGRD/VGRD using ensemble_stat and grid_stat.
> > > > > > > >
> > > > > > > > Thank you.
> > > > > > > > Binyu
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Jul 21, 2020 at 4:07 PM John Halley Gotway via
RT <
> > > > > > > > met_help at ucar.edu>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Binyu,
> > > > > > > > >
> > > > > > > > > Let me address wind speed first (WIND). When
processing
> GRIB
> > 1
> > > > or 2
> > > > > > > > files,
> > > > > > > > > when you request wind speed in a MET config file,
MET will
> > > first
> > > > > try
> > > > > > to
> > > > > > > > > find a record of WIND directly in that file. If not
> present,
> > it
> > > > > will
> > > > > > > > > automatically try to find the corresponding UGRD and
VGRD
> > > > records.
> > > > > > And
> > > > > > > > > it'll automatically derive wind speed on the fly.
> > > > > > > > >
> > > > > > > > > In regards to wind direction (WDIR), the MET tools
do not
> > > verify
> > > > it
> > > > > > > > > directly. In fact, if you request it, you'll see an
error
> > > message
> > > > > > > stating
> > > > > > > > > that.
> > > > > > > > >
> > > > > > > > > When running point_stat and grid_stat, you can
compute the
> > VCNT
> > > > > > (vector
> > > > > > > > > continuous statistics) line type. And the vector
partial
> sums
> > > > > (VL1L2
> > > > > > > line
> > > > > > > > > type) is also useful. But those require the
comparison of
> U/V
> > > > > > > components.
> > > > > > > > > And it sounds like you only have wind speed and
direction
> in
> > > the
> > > > > > > > > observations. So that's a limitation.
> > > > > > > > >
> > > > > > > > > For ensemble_stat, you could verify wind speed by
> requesting
> > > WIND
> > > > > in
> > > > > > > the
> > > > > > > > > config file.
> > > > > > > > >
> > > > > > > > > John
> > > > > > > > >
> > > > > > > > > On Tue, Jul 21, 2020 at 12:15 PM binyu.wang at noaa.gov
via
> RT
> > <
> > > > > > > > > met_help at ucar.edu> wrote:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Tue Jul 21 12:15:18 2020: Request 95970 was acted
upon.
> > > > > > > > > > Transaction: Ticket created by binyu.wang at noaa.gov
> > > > > > > > > > Queue: met_help
> > > > > > > > > > Subject: Wind direction unsemble verifcaion
> > > > > > > > > > Owner: Nobody
> > > > > > > > > > Requestors: binyu.wang at noaa.gov
> > > > > > > > > > Status: new
> > > > > > > > > > Ticket <URL:
> > > > > > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Hello,
> > > > > > > > > >
> > > > > > > > > > I am working on ensemble wind direction
verification
> using
> > > the
> > > > > > "gefs"
> > > > > > > > > > model. I noticed that MET could handle wind
direction
> using
> > > > > > > "grid_stat"
> > > > > > > > > and
> > > > > > > > > > "aggregate_stat", but this is not for ensemble.
The gefs
> > > model
> > > > > only
> > > > > > > has
> > > > > > > > > > UGRD and VGRD (no direction) and my observation
has WIND
> > > SPEED
> > > > > and
> > > > > > > WIND
> > > > > > > > > > DIRECTION. Of course I can get WIND DIRECTION for
model
> > data
> > > > (or
> > > > > > > UGRD
> > > > > > > > > and
> > > > > > > > > > VGRD for observation). But I think it will not be
the
> right
> > > way
> > > > > if
> > > > > > I
> > > > > > > > just
> > > > > > > > > > use ensemble_stat and grid_stat by treating "WIND
> > DIRECTION"
> > > as
> > > > > > > others
> > > > > > > > > like
> > > > > > > > > > TEMP. because the degree issue from WIND DIrection
(e.g:
> 0
> > > > degree
> > > > > > is
> > > > > > > > > close
> > > > > > > > > > to 350 degree. )
> > > > > > > > > >
> > > > > > > > > > So any suggestions to do wind direction ensemble
> > verification
> > > > > using
> > > > > > > > MET?
> > > > > > > > > > How the problem (like 0 vs. 350 degree) is
resolved in
> the
> > > > > > > > > > "aggregate_stat"?
> > > > > > > > > >
> > > > > > > > > > Thank you very much.
> > > > > > > > > > Binyu
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Wind direction unsemble verifcaion
From: John Halley Gotway
Time: Tue Aug 11 16:19:17 2020
Binyu,
Sorry for the long delay in responding on this issue. I was scrambling
to
get the met-9.1 release out the door.
No, I definitely do recommend running the Point-Stat tool to do point
verification. Point-Stat interpolates gridded forecast data to those
point
observation locations, constructs matched fcst/obs pairs, and derives
statistics from them. That's exactly the right process.
The issue is that you were running the Point2Grid tool, and I
definitely do
not recommend that for such sparse data. Point2Grid is useful for
placing a
dense set of point data onto a regular grid to support grid-to-grid
comparison (i.e. prior to running Grid-Stat, MODE, or Series-
Analysis).
Thanks,
John Halley Gotway
On Fri, Jul 31, 2020 at 5:50 PM binyu.wang at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
>
> Yes, you are right. I have very few sites. So you don't recommend
using
> point_stat to do the verification?
>
> Binyy
>
> On Fri, Jul 31, 2020 at 6:47 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Binyu,
> >
> > Back to this question... sorry for the delay.
> >
> > No MET is not, in general, converting between pressure and height
levels.
> > When running Point-Stat, you generally compare forecasts at
pressure
> levels
> > to observations at pressure levels... and forecasts at height
levels to
> > observations at height levels.
> >
> > But you are asking about running the point2grid tool. I logged on
to
> wcoss
> > and took a look at:
> > /gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventad
> > or/Sounding/2020/SKTQ_SKBO/UWYO_obs_met/
> > regrid_SKTQ_SKBO_t12z.20200201.nc
> > <http://regrid_sktq_skbo_t12z.20200201.nc/>
> >
> > I looked at the variables named "UGRD_cnt" and "UGRD". I see
missing data
> > everywhere other than a single grid point.
> > I ran the following plot_data_plane commands to visualize this
data and
> > have attached the result:
> >
> > plot_data_plane regrid_SKTQ_SKBO_t12z.20200201.nc UGRD.ps
'name="UGRD";
> > level="(*,*)";'
> > plot_data_plane regrid_SKTQ_SKBO_t12z.20200201.nc UGRD_cnt.ps
> > 'name="UGRD_cnt"; level="(*,*)";'
> >
> > There's a single pink dot in northern south america which isn't
even
> really
> > visible in the attached plots.
> >
> > This doesn't look to me like a very good use of the point2grid
tool. It's
> > generally intended to read a dense set of point observations and
put them
> > onto a grid.
> >
> > John
> > [image: UGRD.png]
> > [image: UGRD_cnt.png]
> >
> > John
> >
> > On Fri, Jul 31, 2020 at 3:10 PM binyu.wang at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> > >
> > > No,actually they are different questions. I do still need
confirmation
> > for
> > > my guess in the previous email. Thank you.
> > >
> > >
> > > On Fri, Jul 31, 2020 at 4:09 PM John Halley Gotway via RT <
> > > met_help at ucar.edu>
> > > wrote:
> > >
> > > > Hi Binyu,
> > > >
> > > > I realize that I never responded on this ticket. But I did
respond to
> > > your
> > > > other question today. Is this still an open issue or were you
able to
> > > > figure it out?
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > > On Thu, Jul 23, 2020 at 10:12 PM binyu.wang at noaa.gov via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> > > > >
> > > > > John,
> > > > >
> > > > > Your email reminds me of another thing that I want to
confirm:
> > > > >
> > > > > Using the same ascII2nc output file ( the one you just saw:
> > > > > asc2nc_SKTQ_SKBO_20200201.nc) as input, I used point2grid to
get a
> > new
> > > > > output (
> > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met/
> > > > > regrid_SKTQ_SKBO_t12z.20200201.nc).
> > > > > The new output has a pressure level like P250. From the MET
> > > > documentation:
> > > > > "point2grid input_filename to_grid output_filename", the
input is
> > > > > re-grided based on "to_grid" file. How the input got
"pressure
> > level"?
> > > I
> > > > > guess in MET, the same relationship between height and
pressure in
> > > > > "to_grid" is assigned to the input? I.e: over one site in
the
> > "to_grid"
> > > > > file, the pressure level 250mb is corresponding to 10000m ,
MET
> > treats
> > > > the
> > > > > same relationship to input, so the site with height 10000m
is
> > > > > assigned 250mb as pressure level. Am I correct?
> > > > >
> > > > > Thank you.
> > > > > Binyu
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Jul 23, 2020 at 7:24 PM John Halley Gotway via RT <
> > > > > met_help at ucar.edu>
> > > > > wrote:
> > > > >
> > > > > > Binyu,
> > > > > >
> > > > > > I logged onto Mars, took a look at your shell script, and
ran
> these
> > > > > > commands:
> > > > > >
> > > > > >
> > > > > >
> > > > > > *module use
> > > > > >
> > >
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/modulefilesmodule
> > > > > > load met/9.0.2*
> > > > > > *mkdir -p out/point_stat*
> > > > > >
> > > > > > *point_stat
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/EMC_HYSPLIT/inout/ptmp/com/gefs/prod/gefs.20200201/00/pgrb2ap5/gec00.t00z.pgrb2a.0p50.f012
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met_temp/asc2nc_SKTQ_SKBO_20200201.nc
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/parm/PointStatConfig
> > > > > > -log run_pt.log -outdir out/point_stat -v 3*
> > > > > >
> > > > > > But this finds 0 matched pairs and the log messages
indicates
> that
> > > > it's a
> > > > > > level mismatch:
> > > > > >
> > > > > > DEBUG 2: Processing UGRD/P250 versus UGRD/P250, for
observation
> > type
> > > > > > ADPUPA, over region FULL, for interpolation method
NEAREST(1),
> > using
> > > 0
> > > > > > matched pairs.
> > > > > > DEBUG 3: Number of matched pairs = 0
> > > > > > DEBUG 3: Observations processed = 340
> > > > > > ...
> > > > > > DEBUG 3: Rejected: level mismatch = 85
> > > > > >
> > > > > > So let's check the obs that are in the file
> > > > > asc2nc_SKTQ_SKBO_20200201.nc. I
> > > > > > copied that file to my local machine and ran this Rscript
to dump
> > it
> > > > back
> > > > > > out to an easier to read ascii format:
> > > > > >
> > > > > > Rscript met/scripts/Rscripts/pntnc2ascii.R
> > > > asc2nc_SKTQ_SKBO_20200201.nc >
> > > > > > asc2nc_SKTQ_SKBO_20200201.txt
> > > > > >
> > > > > > That file contains 85 instances of UGRD, but the level
values
> range
> > > > from
> > > > > > 2546 to 22562. None of them have a level value of exactly
250.
> And
> > > > that's
> > > > > > why you're getting 0 matches. Looks to me like there's 2
issues:
> > > > > >
> > > > > > (1) The units of pressure differ between the fcst and obs.
> > > > > > (2) No obs exactly match 250mb.
> > > > > >
> > > > > > You can handle both issues in the Point-Stat config file.
Just
> > > specify
> > > > > > separate levels for the fcst and obs dictionaries.
> > > > > >
> > > > > > fcst = { field = [ { name="UGRD"; level="P250"; } ]; }
> > > > > > obs = { field = [ { name="UGRD"; level="P20000-30000"; }
]; }
> > > > > >
> > > > > > That'll match any obs of UGRD with a pressure value
between 20000
> > and
> > > > > 30000
> > > > > > to the forecast for P250.
> > > > > >
> > > > > > Make sense?
> > > > > >
> > > > > > John
> > > > > >
> > > > > > On Thu, Jul 23, 2020 at 4:50 PM binyu.wang at noaa.gov via RT
<
> > > > > > met_help at ucar.edu> wrote:
> > > > > >
> > > > > > >
> > > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> >
> > > > > > >
> > > > > > > Thank you, John.
> > > > > > >
> > > > > > > Based on what you said I can not evaluate wind direction
> > directly,
> > > so
> > > > > > there
> > > > > > > is no need for me to get WDIR based on UGRD and VGRD
from the
> > GEFS
> > > > > model
> > > > > > > output. I need to do the WDIR verification because my
ensemble
> > > model
> > > > > > > output (which is based on GEFS wind profile) predicted
that the
> > ash
> > > > > went
> > > > > > > northward, while the satellite observance shows the ash
went
> > > > southward
> > > > > > over
> > > > > > > one volcano eruption. So I want to identify if there is
a
> problem
> > > for
> > > > > > WDIR
> > > > > > > prediction over the volcano area.
> > > > > > >
> > > > > > > Following your suggestion, I used point_stat for
UGRD/VGRD,
> > > however,
> > > > > the
> > > > > > > output is empty (no matching pair). But I am sure there
are
> > > matching
> > > > > > pairs
> > > > > > > for UGRD/VGRD because I have no problem to get non-empty
stat.
> > > output
> > > > > > using
> > > > > > > "ensemble_stat" and "grid_stat" for UGRD/VGRD. Below is
my
> > script:
> > > > (and
> > > > > > my
> > > > > > > obs. is abstained using ascii2nc)
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/ush/
> > > > > > > verf_g2g_gec_Reventador.sh
> > > > > > >
> > > > > > > Thank you.
> > > > > > > Binyu
> > > > > > >
> > > > > > > On Tue, Jul 21, 2020 at 6:47 PM John Halley Gotway via
RT <
> > > > > > > met_help at ucar.edu>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Binyu,
> > > > > > > >
> > > > > > > > MET does not evaluate wind direction directly for the
reason
> > that
> > > > you
> > > > > > > > mention. Since it's a "circular" variable, it does not
lend
> > > itself
> > > > > well
> > > > > > > to
> > > > > > > > traditional statistics, like RMSE. If you try
evaluating wind
> > > > > direction
> > > > > > > > directly, you'll get this error message:
> > > > > > > >
> > > > > > > > ERROR : PointStatVxOpt::process_config() -> wind
direction
> may
> > > not
> > > > > be
> > > > > > > > verified using point_stat.
> > > > > > > >
> > > > > > > > With U/V pairs, you can run point_stat to evaluate
those
> > vectors
> > > > and
> > > > > > > write
> > > > > > > > the VL1L2 partial sums and VCNT statistics. I'd
recommend
> > running
> > > > > > > > point_stat to evaluate the ensemble mean using the
VL1L2 and
> > VCNT
> > > > > line
> > > > > > > > types. Those VCNT statistic are described in the MET
User's
> > > Guide.
> > > > > > > >
> > > > > > > > John
> > > > > > > >
> > > > > > > > On Tue, Jul 21, 2020 at 3:22 PM binyu.wang at noaa.gov
via RT <
> > > > > > > > met_help at ucar.edu> wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > <URL:
> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > > >
> > > > > > > > >
> > > > > > > > > John,
> > > > > > > > >
> > > > > > > > > Although my original Obs. data has no UGRD/VGRD, I
did
> derive
> > > > them
> > > > > > > using
> > > > > > > > > WIND and WDIR (the original input is ascII file, so
I used
> > > > ascIInc
> > > > > > and
> > > > > > > > > grid2point to convert them to *nc file, which has
> > > > > > UGRD/VGRD/WIND/WDIR).
> > > > > > > > So
> > > > > > > > > it is not a problem for me.
> > > > > > > > >
> > > > > > > > > "For ensemble_stat, you could verify wind speed by
> requesting
> > > > WIND
> > > > > in
> > > > > > > the
> > > > > > > > > config file." But WIND only tells the magnitude,
not the
> > > > > direction,
> > > > > > > > right?
> > > > > > > > >
> > > > > > > > > So how does the MET deal with the degree for WDIR?
If
> > > > > WDIR=355degree
> > > > > > > > from
> > > > > > > > > MODEL, and WDIR=0 from OBS, will MET treat them as a
big
> > > > difference
> > > > > > or
> > > > > > > > > small difference? I know how to do the ensemble
> verification
> > > for
> > > > > > > > UGRD/VGRD,
> > > > > > > > > but my main interest is WDIR. I want to know if I
could
> treat
> > > > WDIR
> > > > > as
> > > > > > > > > UGRD/VGRD using ensemble_stat and grid_stat.
> > > > > > > > >
> > > > > > > > > Thank you.
> > > > > > > > > Binyu
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Jul 21, 2020 at 4:07 PM John Halley Gotway
via RT <
> > > > > > > > > met_help at ucar.edu>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Binyu,
> > > > > > > > > >
> > > > > > > > > > Let me address wind speed first (WIND). When
processing
> > GRIB
> > > 1
> > > > > or 2
> > > > > > > > > files,
> > > > > > > > > > when you request wind speed in a MET config file,
MET
> will
> > > > first
> > > > > > try
> > > > > > > to
> > > > > > > > > > find a record of WIND directly in that file. If
not
> > present,
> > > it
> > > > > > will
> > > > > > > > > > automatically try to find the corresponding UGRD
and VGRD
> > > > > records.
> > > > > > > And
> > > > > > > > > > it'll automatically derive wind speed on the fly.
> > > > > > > > > >
> > > > > > > > > > In regards to wind direction (WDIR), the MET tools
do not
> > > > verify
> > > > > it
> > > > > > > > > > directly. In fact, if you request it, you'll see
an error
> > > > message
> > > > > > > > stating
> > > > > > > > > > that.
> > > > > > > > > >
> > > > > > > > > > When running point_stat and grid_stat, you can
compute
> the
> > > VCNT
> > > > > > > (vector
> > > > > > > > > > continuous statistics) line type. And the vector
partial
> > sums
> > > > > > (VL1L2
> > > > > > > > line
> > > > > > > > > > type) is also useful. But those require the
comparison of
> > U/V
> > > > > > > > components.
> > > > > > > > > > And it sounds like you only have wind speed and
direction
> > in
> > > > the
> > > > > > > > > > observations. So that's a limitation.
> > > > > > > > > >
> > > > > > > > > > For ensemble_stat, you could verify wind speed by
> > requesting
> > > > WIND
> > > > > > in
> > > > > > > > the
> > > > > > > > > > config file.
> > > > > > > > > >
> > > > > > > > > > John
> > > > > > > > > >
> > > > > > > > > > On Tue, Jul 21, 2020 at 12:15 PM
binyu.wang at noaa.gov via
> > RT
> > > <
> > > > > > > > > > met_help at ucar.edu> wrote:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Tue Jul 21 12:15:18 2020: Request 95970 was
acted upon.
> > > > > > > > > > > Transaction: Ticket created by
binyu.wang at noaa.gov
> > > > > > > > > > > Queue: met_help
> > > > > > > > > > > Subject: Wind direction unsemble verifcaion
> > > > > > > > > > > Owner: Nobody
> > > > > > > > > > > Requestors: binyu.wang at noaa.gov
> > > > > > > > > > > Status: new
> > > > > > > > > > > Ticket <URL:
> > > > > > > >
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Hello,
> > > > > > > > > > >
> > > > > > > > > > > I am working on ensemble wind direction
verification
> > using
> > > > the
> > > > > > > "gefs"
> > > > > > > > > > > model. I noticed that MET could handle wind
direction
> > using
> > > > > > > > "grid_stat"
> > > > > > > > > > and
> > > > > > > > > > > "aggregate_stat", but this is not for ensemble.
The
> gefs
> > > > model
> > > > > > only
> > > > > > > > has
> > > > > > > > > > > UGRD and VGRD (no direction) and my observation
has
> WIND
> > > > SPEED
> > > > > > and
> > > > > > > > WIND
> > > > > > > > > > > DIRECTION. Of course I can get WIND DIRECTION
for
> model
> > > data
> > > > > (or
> > > > > > > > UGRD
> > > > > > > > > > and
> > > > > > > > > > > VGRD for observation). But I think it will not
be the
> > right
> > > > way
> > > > > > if
> > > > > > > I
> > > > > > > > > just
> > > > > > > > > > > use ensemble_stat and grid_stat by treating
"WIND
> > > DIRECTION"
> > > > as
> > > > > > > > others
> > > > > > > > > > like
> > > > > > > > > > > TEMP. because the degree issue from WIND
DIrection
> (e.g:
> > 0
> > > > > degree
> > > > > > > is
> > > > > > > > > > close
> > > > > > > > > > > to 350 degree. )
> > > > > > > > > > >
> > > > > > > > > > > So any suggestions to do wind direction ensemble
> > > verification
> > > > > > using
> > > > > > > > > MET?
> > > > > > > > > > > How the problem (like 0 vs. 350 degree) is
resolved in
> > the
> > > > > > > > > > > "aggregate_stat"?
> > > > > > > > > > >
> > > > > > > > > > > Thank you very much.
> > > > > > > > > > > Binyu
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Wind direction unsemble verifcaion
From: binyu.wang at noaa.gov
Time: Tue Aug 11 21:15:51 2020
That makes sense. Thank you for clarifying!
Binyu
On Tue, Aug 11, 2020 at 6:19 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binyu,
>
> Sorry for the long delay in responding on this issue. I was
scrambling to
> get the met-9.1 release out the door.
>
> No, I definitely do recommend running the Point-Stat tool to do
point
> verification. Point-Stat interpolates gridded forecast data to those
point
> observation locations, constructs matched fcst/obs pairs, and
derives
> statistics from them. That's exactly the right process.
>
> The issue is that you were running the Point2Grid tool, and I
definitely do
> not recommend that for such sparse data. Point2Grid is useful for
placing a
> dense set of point data onto a regular grid to support grid-to-grid
> comparison (i.e. prior to running Grid-Stat, MODE, or Series-
Analysis).
>
> Thanks,
> John Halley Gotway
>
> On Fri, Jul 31, 2020 at 5:50 PM binyu.wang at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> >
> > Yes, you are right. I have very few sites. So you don't recommend
using
> > point_stat to do the verification?
> >
> > Binyy
> >
> > On Fri, Jul 31, 2020 at 6:47 PM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > Binyu,
> > >
> > > Back to this question... sorry for the delay.
> > >
> > > No MET is not, in general, converting between pressure and
height
> levels.
> > > When running Point-Stat, you generally compare forecasts at
pressure
> > levels
> > > to observations at pressure levels... and forecasts at height
levels to
> > > observations at height levels.
> > >
> > > But you are asking about running the point2grid tool. I logged
on to
> > wcoss
> > > and took a look at:
> > > /gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventad
> > > or/Sounding/2020/SKTQ_SKBO/UWYO_obs_met/
> > > regrid_SKTQ_SKBO_t12z.20200201.nc
> > > <http://regrid_sktq_skbo_t12z.20200201.nc/>
> > >
> > > I looked at the variables named "UGRD_cnt" and "UGRD". I see
missing
> data
> > > everywhere other than a single grid point.
> > > I ran the following plot_data_plane commands to visualize this
data and
> > > have attached the result:
> > >
> > > plot_data_plane regrid_SKTQ_SKBO_t12z.20200201.nc UGRD.ps
> 'name="UGRD";
> > > level="(*,*)";'
> > > plot_data_plane regrid_SKTQ_SKBO_t12z.20200201.nc UGRD_cnt.ps
> > > 'name="UGRD_cnt"; level="(*,*)";'
> > >
> > > There's a single pink dot in northern south america which isn't
even
> > really
> > > visible in the attached plots.
> > >
> > > This doesn't look to me like a very good use of the point2grid
tool.
> It's
> > > generally intended to read a dense set of point observations and
put
> them
> > > onto a grid.
> > >
> > > John
> > > [image: UGRD.png]
> > > [image: UGRD_cnt.png]
> > >
> > > John
> > >
> > > On Fri, Jul 31, 2020 at 3:10 PM binyu.wang at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
>
> > > >
> > > > No,actually they are different questions. I do still need
> confirmation
> > > for
> > > > my guess in the previous email. Thank you.
> > > >
> > > >
> > > > On Fri, Jul 31, 2020 at 4:09 PM John Halley Gotway via RT <
> > > > met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > > Hi Binyu,
> > > > >
> > > > > I realize that I never responded on this ticket. But I did
respond
> to
> > > > your
> > > > > other question today. Is this still an open issue or were
you able
> to
> > > > > figure it out?
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > > On Thu, Jul 23, 2020 at 10:12 PM binyu.wang at noaa.gov via RT
<
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > > >
> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> > > > > >
> > > > > > John,
> > > > > >
> > > > > > Your email reminds me of another thing that I want to
confirm:
> > > > > >
> > > > > > Using the same ascII2nc output file ( the one you just
saw:
> > > > > > asc2nc_SKTQ_SKBO_20200201.nc) as input, I used point2grid
to get
> a
> > > new
> > > > > > output (
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met/
> > > > > > regrid_SKTQ_SKBO_t12z.20200201.nc).
> > > > > > The new output has a pressure level like P250. From the
MET
> > > > > documentation:
> > > > > > "point2grid input_filename to_grid output_filename", the
input is
> > > > > > re-grided based on "to_grid" file. How the input got
"pressure
> > > level"?
> > > > I
> > > > > > guess in MET, the same relationship between height and
pressure
> in
> > > > > > "to_grid" is assigned to the input? I.e: over one site in
the
> > > "to_grid"
> > > > > > file, the pressure level 250mb is corresponding to 10000m
, MET
> > > treats
> > > > > the
> > > > > > same relationship to input, so the site with height 10000m
is
> > > > > > assigned 250mb as pressure level. Am I correct?
> > > > > >
> > > > > > Thank you.
> > > > > > Binyu
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Jul 23, 2020 at 7:24 PM John Halley Gotway via RT
<
> > > > > > met_help at ucar.edu>
> > > > > > wrote:
> > > > > >
> > > > > > > Binyu,
> > > > > > >
> > > > > > > I logged onto Mars, took a look at your shell script,
and ran
> > these
> > > > > > > commands:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > *module use
> > > > > > >
> > > >
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/modulefilesmodule
> > > > > > > load met/9.0.2*
> > > > > > > *mkdir -p out/point_stat*
> > > > > > >
> > > > > > > *point_stat
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/EMC_HYSPLIT/inout/ptmp/com/gefs/prod/gefs.20200201/00/pgrb2ap5/gec00.t00z.pgrb2a.0p50.f012
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met_temp/asc2nc_SKTQ_SKBO_20200201.nc
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/parm/PointStatConfig
> > > > > > > -log run_pt.log -outdir out/point_stat -v 3*
> > > > > > >
> > > > > > > But this finds 0 matched pairs and the log messages
indicates
> > that
> > > > > it's a
> > > > > > > level mismatch:
> > > > > > >
> > > > > > > DEBUG 2: Processing UGRD/P250 versus UGRD/P250, for
observation
> > > type
> > > > > > > ADPUPA, over region FULL, for interpolation method
NEAREST(1),
> > > using
> > > > 0
> > > > > > > matched pairs.
> > > > > > > DEBUG 3: Number of matched pairs = 0
> > > > > > > DEBUG 3: Observations processed = 340
> > > > > > > ...
> > > > > > > DEBUG 3: Rejected: level mismatch = 85
> > > > > > >
> > > > > > > So let's check the obs that are in the file
> > > > > > asc2nc_SKTQ_SKBO_20200201.nc. I
> > > > > > > copied that file to my local machine and ran this
Rscript to
> dump
> > > it
> > > > > back
> > > > > > > out to an easier to read ascii format:
> > > > > > >
> > > > > > > Rscript met/scripts/Rscripts/pntnc2ascii.R
> > > > > asc2nc_SKTQ_SKBO_20200201.nc >
> > > > > > > asc2nc_SKTQ_SKBO_20200201.txt
> > > > > > >
> > > > > > > That file contains 85 instances of UGRD, but the level
values
> > range
> > > > > from
> > > > > > > 2546 to 22562. None of them have a level value of
exactly 250.
> > And
> > > > > that's
> > > > > > > why you're getting 0 matches. Looks to me like there's 2
> issues:
> > > > > > >
> > > > > > > (1) The units of pressure differ between the fcst and
obs.
> > > > > > > (2) No obs exactly match 250mb.
> > > > > > >
> > > > > > > You can handle both issues in the Point-Stat config
file. Just
> > > > specify
> > > > > > > separate levels for the fcst and obs dictionaries.
> > > > > > >
> > > > > > > fcst = { field = [ { name="UGRD"; level="P250"; } ]; }
> > > > > > > obs = { field = [ { name="UGRD"; level="P20000-30000"; }
]; }
> > > > > > >
> > > > > > > That'll match any obs of UGRD with a pressure value
between
> 20000
> > > and
> > > > > > 30000
> > > > > > > to the forecast for P250.
> > > > > > >
> > > > > > > Make sense?
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > On Thu, Jul 23, 2020 at 4:50 PM binyu.wang at noaa.gov via
RT <
> > > > > > > met_help at ucar.edu> wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > >
> > > > > > > >
> > > > > > > > Thank you, John.
> > > > > > > >
> > > > > > > > Based on what you said I can not evaluate wind
direction
> > > directly,
> > > > so
> > > > > > > there
> > > > > > > > is no need for me to get WDIR based on UGRD and VGRD
from the
> > > GEFS
> > > > > > model
> > > > > > > > output. I need to do the WDIR verification because my
> ensemble
> > > > model
> > > > > > > > output (which is based on GEFS wind profile) predicted
that
> the
> > > ash
> > > > > > went
> > > > > > > > northward, while the satellite observance shows the
ash went
> > > > > southward
> > > > > > > over
> > > > > > > > one volcano eruption. So I want to identify if there
is a
> > problem
> > > > for
> > > > > > > WDIR
> > > > > > > > prediction over the volcano area.
> > > > > > > >
> > > > > > > > Following your suggestion, I used point_stat for
UGRD/VGRD,
> > > > however,
> > > > > > the
> > > > > > > > output is empty (no matching pair). But I am sure
there are
> > > > matching
> > > > > > > pairs
> > > > > > > > for UGRD/VGRD because I have no problem to get non-
empty
> stat.
> > > > output
> > > > > > > using
> > > > > > > > "ensemble_stat" and "grid_stat" for UGRD/VGRD. Below
is my
> > > script:
> > > > > (and
> > > > > > > my
> > > > > > > > obs. is abstained using ascii2nc)
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/ush/
> > > > > > > > verf_g2g_gec_Reventador.sh
> > > > > > > >
> > > > > > > > Thank you.
> > > > > > > > Binyu
> > > > > > > >
> > > > > > > > On Tue, Jul 21, 2020 at 6:47 PM John Halley Gotway via
RT <
> > > > > > > > met_help at ucar.edu>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Binyu,
> > > > > > > > >
> > > > > > > > > MET does not evaluate wind direction directly for
the
> reason
> > > that
> > > > > you
> > > > > > > > > mention. Since it's a "circular" variable, it does
not lend
> > > > itself
> > > > > > well
> > > > > > > > to
> > > > > > > > > traditional statistics, like RMSE. If you try
evaluating
> wind
> > > > > > direction
> > > > > > > > > directly, you'll get this error message:
> > > > > > > > >
> > > > > > > > > ERROR : PointStatVxOpt::process_config() -> wind
direction
> > may
> > > > not
> > > > > > be
> > > > > > > > > verified using point_stat.
> > > > > > > > >
> > > > > > > > > With U/V pairs, you can run point_stat to evaluate
those
> > > vectors
> > > > > and
> > > > > > > > write
> > > > > > > > > the VL1L2 partial sums and VCNT statistics. I'd
recommend
> > > running
> > > > > > > > > point_stat to evaluate the ensemble mean using the
VL1L2
> and
> > > VCNT
> > > > > > line
> > > > > > > > > types. Those VCNT statistic are described in the MET
User's
> > > > Guide.
> > > > > > > > >
> > > > > > > > > John
> > > > > > > > >
> > > > > > > > > On Tue, Jul 21, 2020 at 3:22 PM binyu.wang at noaa.gov
via
> RT <
> > > > > > > > > met_help at ucar.edu> wrote:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > <URL:
> > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > > > >
> > > > > > > > > >
> > > > > > > > > > John,
> > > > > > > > > >
> > > > > > > > > > Although my original Obs. data has no UGRD/VGRD, I
did
> > derive
> > > > > them
> > > > > > > > using
> > > > > > > > > > WIND and WDIR (the original input is ascII file,
so I
> used
> > > > > ascIInc
> > > > > > > and
> > > > > > > > > > grid2point to convert them to *nc file, which has
> > > > > > > UGRD/VGRD/WIND/WDIR).
> > > > > > > > > So
> > > > > > > > > > it is not a problem for me.
> > > > > > > > > >
> > > > > > > > > > "For ensemble_stat, you could verify wind speed by
> > requesting
> > > > > WIND
> > > > > > in
> > > > > > > > the
> > > > > > > > > > config file." But WIND only tells the magnitude,
not the
> > > > > > direction,
> > > > > > > > > right?
> > > > > > > > > >
> > > > > > > > > > So how does the MET deal with the degree for WDIR?
If
> > > > > > WDIR=355degree
> > > > > > > > > from
> > > > > > > > > > MODEL, and WDIR=0 from OBS, will MET treat them as
a big
> > > > > difference
> > > > > > > or
> > > > > > > > > > small difference? I know how to do the ensemble
> > verification
> > > > for
> > > > > > > > > UGRD/VGRD,
> > > > > > > > > > but my main interest is WDIR. I want to know if I
could
> > treat
> > > > > WDIR
> > > > > > as
> > > > > > > > > > UGRD/VGRD using ensemble_stat and grid_stat.
> > > > > > > > > >
> > > > > > > > > > Thank you.
> > > > > > > > > > Binyu
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, Jul 21, 2020 at 4:07 PM John Halley Gotway
via
> RT <
> > > > > > > > > > met_help at ucar.edu>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Binyu,
> > > > > > > > > > >
> > > > > > > > > > > Let me address wind speed first (WIND). When
processing
> > > GRIB
> > > > 1
> > > > > > or 2
> > > > > > > > > > files,
> > > > > > > > > > > when you request wind speed in a MET config
file, MET
> > will
> > > > > first
> > > > > > > try
> > > > > > > > to
> > > > > > > > > > > find a record of WIND directly in that file. If
not
> > > present,
> > > > it
> > > > > > > will
> > > > > > > > > > > automatically try to find the corresponding UGRD
and
> VGRD
> > > > > > records.
> > > > > > > > And
> > > > > > > > > > > it'll automatically derive wind speed on the
fly.
> > > > > > > > > > >
> > > > > > > > > > > In regards to wind direction (WDIR), the MET
tools do
> not
> > > > > verify
> > > > > > it
> > > > > > > > > > > directly. In fact, if you request it, you'll see
an
> error
> > > > > message
> > > > > > > > > stating
> > > > > > > > > > > that.
> > > > > > > > > > >
> > > > > > > > > > > When running point_stat and grid_stat, you can
compute
> > the
> > > > VCNT
> > > > > > > > (vector
> > > > > > > > > > > continuous statistics) line type. And the vector
> partial
> > > sums
> > > > > > > (VL1L2
> > > > > > > > > line
> > > > > > > > > > > type) is also useful. But those require the
comparison
> of
> > > U/V
> > > > > > > > > components.
> > > > > > > > > > > And it sounds like you only have wind speed and
> direction
> > > in
> > > > > the
> > > > > > > > > > > observations. So that's a limitation.
> > > > > > > > > > >
> > > > > > > > > > > For ensemble_stat, you could verify wind speed
by
> > > requesting
> > > > > WIND
> > > > > > > in
> > > > > > > > > the
> > > > > > > > > > > config file.
> > > > > > > > > > >
> > > > > > > > > > > John
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Jul 21, 2020 at 12:15 PM
binyu.wang at noaa.gov
> via
> > > RT
> > > > <
> > > > > > > > > > > met_help at ucar.edu> wrote:
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Tue Jul 21 12:15:18 2020: Request 95970 was
acted
> upon.
> > > > > > > > > > > > Transaction: Ticket created by
binyu.wang at noaa.gov
> > > > > > > > > > > > Queue: met_help
> > > > > > > > > > > > Subject: Wind direction unsemble
verifcaion
> > > > > > > > > > > > Owner: Nobody
> > > > > > > > > > > > Requestors: binyu.wang at noaa.gov
> > > > > > > > > > > > Status: new
> > > > > > > > > > > > Ticket <URL:
> > > > > > > > >
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Hello,
> > > > > > > > > > > >
> > > > > > > > > > > > I am working on ensemble wind direction
verification
> > > using
> > > > > the
> > > > > > > > "gefs"
> > > > > > > > > > > > model. I noticed that MET could handle wind
direction
> > > using
> > > > > > > > > "grid_stat"
> > > > > > > > > > > and
> > > > > > > > > > > > "aggregate_stat", but this is not for
ensemble. The
> > gefs
> > > > > model
> > > > > > > only
> > > > > > > > > has
> > > > > > > > > > > > UGRD and VGRD (no direction) and my
observation has
> > WIND
> > > > > SPEED
> > > > > > > and
> > > > > > > > > WIND
> > > > > > > > > > > > DIRECTION. Of course I can get WIND DIRECTION
for
> > model
> > > > data
> > > > > > (or
> > > > > > > > > UGRD
> > > > > > > > > > > and
> > > > > > > > > > > > VGRD for observation). But I think it will not
be the
> > > right
> > > > > way
> > > > > > > if
> > > > > > > > I
> > > > > > > > > > just
> > > > > > > > > > > > use ensemble_stat and grid_stat by treating
"WIND
> > > > DIRECTION"
> > > > > as
> > > > > > > > > others
> > > > > > > > > > > like
> > > > > > > > > > > > TEMP. because the degree issue from WIND
DIrection
> > (e.g:
> > > 0
> > > > > > degree
> > > > > > > > is
> > > > > > > > > > > close
> > > > > > > > > > > > to 350 degree. )
> > > > > > > > > > > >
> > > > > > > > > > > > So any suggestions to do wind direction
ensemble
> > > > verification
> > > > > > > using
> > > > > > > > > > MET?
> > > > > > > > > > > > How the problem (like 0 vs. 350 degree) is
resolved
> in
> > > the
> > > > > > > > > > > > "aggregate_stat"?
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you very much.
> > > > > > > > > > > > Binyu
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Wind direction unsemble verifcaion
From: binyu.wang at noaa.gov
Time: Thu Aug 13 18:12:47 2020
Hello John,
So we don't need multiple sites to use "point_stat", we can use this
utility even with one or two sites only, right? Speaking of "dense set
of
point data '' for Point2Grid, how dense is a good number? Like in a
grid of
0.1*0.1deg, are 10 sites enough? Thank you.
Binyu
Point-Sta
On Tue, Aug 11, 2020 at 6:19 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binyu,
>
> Sorry for the long delay in responding on this issue. I was
scrambling to
> get the met-9.1 release out the door.
>
> No, I definitely do recommend running the Point-Stat tool to do
point
> verification. Point-Stat interpolates gridded forecast data to those
point
> observation locations, constructs matched fcst/obs pairs, and
derives
> statistics from them. That's exactly the right process.
>
> The issue is that you were running the Point2Grid tool, and I
definitely do
> not recommend that for such sparse data. Point2Grid is useful for
placing a
> dense set of point data onto a regular grid to support grid-to-grid
> comparison (i.e. prior to running Grid-Stat, MODE, or Series-
Analysis).
>
> Thanks,
> John Halley Gotway
>
> On Fri, Jul 31, 2020 at 5:50 PM binyu.wang at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> >
> > Yes, you are right. I have very few sites. So you don't recommend
using
> > point_stat to do the verification?
> >
> > Binyy
> >
> > On Fri, Jul 31, 2020 at 6:47 PM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > Binyu,
> > >
> > > Back to this question... sorry for the delay.
> > >
> > > No MET is not, in general, converting between pressure and
height
> levels.
> > > When running Point-Stat, you generally compare forecasts at
pressure
> > levels
> > > to observations at pressure levels... and forecasts at height
levels to
> > > observations at height levels.
> > >
> > > But you are asking about running the point2grid tool. I logged
on to
> > wcoss
> > > and took a look at:
> > > /gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventad
> > > or/Sounding/2020/SKTQ_SKBO/UWYO_obs_met/
> > > regrid_SKTQ_SKBO_t12z.20200201.nc
> > > <http://regrid_sktq_skbo_t12z.20200201.nc/>
> > >
> > > I looked at the variables named "UGRD_cnt" and "UGRD". I see
missing
> data
> > > everywhere other than a single grid point.
> > > I ran the following plot_data_plane commands to visualize this
data and
> > > have attached the result:
> > >
> > > plot_data_plane regrid_SKTQ_SKBO_t12z.20200201.nc UGRD.ps
> 'name="UGRD";
> > > level="(*,*)";'
> > > plot_data_plane regrid_SKTQ_SKBO_t12z.20200201.nc UGRD_cnt.ps
> > > 'name="UGRD_cnt"; level="(*,*)";'
> > >
> > > There's a single pink dot in northern south america which isn't
even
> > really
> > > visible in the attached plots.
> > >
> > > This doesn't look to me like a very good use of the point2grid
tool.
> It's
> > > generally intended to read a dense set of point observations and
put
> them
> > > onto a grid.
> > >
> > > John
> > > [image: UGRD.png]
> > > [image: UGRD_cnt.png]
> > >
> > > John
> > >
> > > On Fri, Jul 31, 2020 at 3:10 PM binyu.wang at noaa.gov via RT <
> > > met_help at ucar.edu> wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
>
> > > >
> > > > No,actually they are different questions. I do still need
> confirmation
> > > for
> > > > my guess in the previous email. Thank you.
> > > >
> > > >
> > > > On Fri, Jul 31, 2020 at 4:09 PM John Halley Gotway via RT <
> > > > met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > > Hi Binyu,
> > > > >
> > > > > I realize that I never responded on this ticket. But I did
respond
> to
> > > > your
> > > > > other question today. Is this still an open issue or were
you able
> to
> > > > > figure it out?
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > > On Thu, Jul 23, 2020 at 10:12 PM binyu.wang at noaa.gov via RT
<
> > > > > met_help at ucar.edu> wrote:
> > > > >
> > > > > >
> > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> > > > > >
> > > > > > John,
> > > > > >
> > > > > > Your email reminds me of another thing that I want to
confirm:
> > > > > >
> > > > > > Using the same ascII2nc output file ( the one you just
saw:
> > > > > > asc2nc_SKTQ_SKBO_20200201.nc) as input, I used point2grid
to get
> a
> > > new
> > > > > > output (
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met/
> > > > > > regrid_SKTQ_SKBO_t12z.20200201.nc).
> > > > > > The new output has a pressure level like P250. From the
MET
> > > > > documentation:
> > > > > > "point2grid input_filename to_grid output_filename", the
input is
> > > > > > re-grided based on "to_grid" file. How the input got
"pressure
> > > level"?
> > > > I
> > > > > > guess in MET, the same relationship between height and
pressure
> in
> > > > > > "to_grid" is assigned to the input? I.e: over one site in
the
> > > "to_grid"
> > > > > > file, the pressure level 250mb is corresponding to 10000m
, MET
> > > treats
> > > > > the
> > > > > > same relationship to input, so the site with height 10000m
is
> > > > > > assigned 250mb as pressure level. Am I correct?
> > > > > >
> > > > > > Thank you.
> > > > > > Binyu
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Jul 23, 2020 at 7:24 PM John Halley Gotway via RT
<
> > > > > > met_help at ucar.edu>
> > > > > > wrote:
> > > > > >
> > > > > > > Binyu,
> > > > > > >
> > > > > > > I logged onto Mars, took a look at your shell script,
and ran
> > these
> > > > > > > commands:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > *module use
> > > > > > >
> > > >
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/modulefilesmodule
> > > > > > > load met/9.0.2*
> > > > > > > *mkdir -p out/point_stat*
> > > > > > >
> > > > > > > *point_stat
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/EMC_HYSPLIT/inout/ptmp/com/gefs/prod/gefs.20200201/00/pgrb2ap5/gec00.t00z.pgrb2a.0p50.f012
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met_temp/asc2nc_SKTQ_SKBO_20200201.nc
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/parm/PointStatConfig
> > > > > > > -log run_pt.log -outdir out/point_stat -v 3*
> > > > > > >
> > > > > > > But this finds 0 matched pairs and the log messages
indicates
> > that
> > > > > it's a
> > > > > > > level mismatch:
> > > > > > >
> > > > > > > DEBUG 2: Processing UGRD/P250 versus UGRD/P250, for
observation
> > > type
> > > > > > > ADPUPA, over region FULL, for interpolation method
NEAREST(1),
> > > using
> > > > 0
> > > > > > > matched pairs.
> > > > > > > DEBUG 3: Number of matched pairs = 0
> > > > > > > DEBUG 3: Observations processed = 340
> > > > > > > ...
> > > > > > > DEBUG 3: Rejected: level mismatch = 85
> > > > > > >
> > > > > > > So let's check the obs that are in the file
> > > > > > asc2nc_SKTQ_SKBO_20200201.nc. I
> > > > > > > copied that file to my local machine and ran this
Rscript to
> dump
> > > it
> > > > > back
> > > > > > > out to an easier to read ascii format:
> > > > > > >
> > > > > > > Rscript met/scripts/Rscripts/pntnc2ascii.R
> > > > > asc2nc_SKTQ_SKBO_20200201.nc >
> > > > > > > asc2nc_SKTQ_SKBO_20200201.txt
> > > > > > >
> > > > > > > That file contains 85 instances of UGRD, but the level
values
> > range
> > > > > from
> > > > > > > 2546 to 22562. None of them have a level value of
exactly 250.
> > And
> > > > > that's
> > > > > > > why you're getting 0 matches. Looks to me like there's 2
> issues:
> > > > > > >
> > > > > > > (1) The units of pressure differ between the fcst and
obs.
> > > > > > > (2) No obs exactly match 250mb.
> > > > > > >
> > > > > > > You can handle both issues in the Point-Stat config
file. Just
> > > > specify
> > > > > > > separate levels for the fcst and obs dictionaries.
> > > > > > >
> > > > > > > fcst = { field = [ { name="UGRD"; level="P250"; } ]; }
> > > > > > > obs = { field = [ { name="UGRD"; level="P20000-30000"; }
]; }
> > > > > > >
> > > > > > > That'll match any obs of UGRD with a pressure value
between
> 20000
> > > and
> > > > > > 30000
> > > > > > > to the forecast for P250.
> > > > > > >
> > > > > > > Make sense?
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > On Thu, Jul 23, 2020 at 4:50 PM binyu.wang at noaa.gov via
RT <
> > > > > > > met_help at ucar.edu> wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > >
> > > > > > > >
> > > > > > > > Thank you, John.
> > > > > > > >
> > > > > > > > Based on what you said I can not evaluate wind
direction
> > > directly,
> > > > so
> > > > > > > there
> > > > > > > > is no need for me to get WDIR based on UGRD and VGRD
from the
> > > GEFS
> > > > > > model
> > > > > > > > output. I need to do the WDIR verification because my
> ensemble
> > > > model
> > > > > > > > output (which is based on GEFS wind profile) predicted
that
> the
> > > ash
> > > > > > went
> > > > > > > > northward, while the satellite observance shows the
ash went
> > > > > southward
> > > > > > > over
> > > > > > > > one volcano eruption. So I want to identify if there
is a
> > problem
> > > > for
> > > > > > > WDIR
> > > > > > > > prediction over the volcano area.
> > > > > > > >
> > > > > > > > Following your suggestion, I used point_stat for
UGRD/VGRD,
> > > > however,
> > > > > > the
> > > > > > > > output is empty (no matching pair). But I am sure
there are
> > > > matching
> > > > > > > pairs
> > > > > > > > for UGRD/VGRD because I have no problem to get non-
empty
> stat.
> > > > output
> > > > > > > using
> > > > > > > > "ensemble_stat" and "grid_stat" for UGRD/VGRD. Below
is my
> > > script:
> > > > > (and
> > > > > > > my
> > > > > > > > obs. is abstained using ascii2nc)
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/ush/
> > > > > > > > verf_g2g_gec_Reventador.sh
> > > > > > > >
> > > > > > > > Thank you.
> > > > > > > > Binyu
> > > > > > > >
> > > > > > > > On Tue, Jul 21, 2020 at 6:47 PM John Halley Gotway via
RT <
> > > > > > > > met_help at ucar.edu>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Binyu,
> > > > > > > > >
> > > > > > > > > MET does not evaluate wind direction directly for
the
> reason
> > > that
> > > > > you
> > > > > > > > > mention. Since it's a "circular" variable, it does
not lend
> > > > itself
> > > > > > well
> > > > > > > > to
> > > > > > > > > traditional statistics, like RMSE. If you try
evaluating
> wind
> > > > > > direction
> > > > > > > > > directly, you'll get this error message:
> > > > > > > > >
> > > > > > > > > ERROR : PointStatVxOpt::process_config() -> wind
direction
> > may
> > > > not
> > > > > > be
> > > > > > > > > verified using point_stat.
> > > > > > > > >
> > > > > > > > > With U/V pairs, you can run point_stat to evaluate
those
> > > vectors
> > > > > and
> > > > > > > > write
> > > > > > > > > the VL1L2 partial sums and VCNT statistics. I'd
recommend
> > > running
> > > > > > > > > point_stat to evaluate the ensemble mean using the
VL1L2
> and
> > > VCNT
> > > > > > line
> > > > > > > > > types. Those VCNT statistic are described in the MET
User's
> > > > Guide.
> > > > > > > > >
> > > > > > > > > John
> > > > > > > > >
> > > > > > > > > On Tue, Jul 21, 2020 at 3:22 PM binyu.wang at noaa.gov
via
> RT <
> > > > > > > > > met_help at ucar.edu> wrote:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > <URL:
> > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > > > >
> > > > > > > > > >
> > > > > > > > > > John,
> > > > > > > > > >
> > > > > > > > > > Although my original Obs. data has no UGRD/VGRD, I
did
> > derive
> > > > > them
> > > > > > > > using
> > > > > > > > > > WIND and WDIR (the original input is ascII file,
so I
> used
> > > > > ascIInc
> > > > > > > and
> > > > > > > > > > grid2point to convert them to *nc file, which has
> > > > > > > UGRD/VGRD/WIND/WDIR).
> > > > > > > > > So
> > > > > > > > > > it is not a problem for me.
> > > > > > > > > >
> > > > > > > > > > "For ensemble_stat, you could verify wind speed by
> > requesting
> > > > > WIND
> > > > > > in
> > > > > > > > the
> > > > > > > > > > config file." But WIND only tells the magnitude,
not the
> > > > > > direction,
> > > > > > > > > right?
> > > > > > > > > >
> > > > > > > > > > So how does the MET deal with the degree for WDIR?
If
> > > > > > WDIR=355degree
> > > > > > > > > from
> > > > > > > > > > MODEL, and WDIR=0 from OBS, will MET treat them as
a big
> > > > > difference
> > > > > > > or
> > > > > > > > > > small difference? I know how to do the ensemble
> > verification
> > > > for
> > > > > > > > > UGRD/VGRD,
> > > > > > > > > > but my main interest is WDIR. I want to know if I
could
> > treat
> > > > > WDIR
> > > > > > as
> > > > > > > > > > UGRD/VGRD using ensemble_stat and grid_stat.
> > > > > > > > > >
> > > > > > > > > > Thank you.
> > > > > > > > > > Binyu
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, Jul 21, 2020 at 4:07 PM John Halley Gotway
via
> RT <
> > > > > > > > > > met_help at ucar.edu>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Binyu,
> > > > > > > > > > >
> > > > > > > > > > > Let me address wind speed first (WIND). When
processing
> > > GRIB
> > > > 1
> > > > > > or 2
> > > > > > > > > > files,
> > > > > > > > > > > when you request wind speed in a MET config
file, MET
> > will
> > > > > first
> > > > > > > try
> > > > > > > > to
> > > > > > > > > > > find a record of WIND directly in that file. If
not
> > > present,
> > > > it
> > > > > > > will
> > > > > > > > > > > automatically try to find the corresponding UGRD
and
> VGRD
> > > > > > records.
> > > > > > > > And
> > > > > > > > > > > it'll automatically derive wind speed on the
fly.
> > > > > > > > > > >
> > > > > > > > > > > In regards to wind direction (WDIR), the MET
tools do
> not
> > > > > verify
> > > > > > it
> > > > > > > > > > > directly. In fact, if you request it, you'll see
an
> error
> > > > > message
> > > > > > > > > stating
> > > > > > > > > > > that.
> > > > > > > > > > >
> > > > > > > > > > > When running point_stat and grid_stat, you can
compute
> > the
> > > > VCNT
> > > > > > > > (vector
> > > > > > > > > > > continuous statistics) line type. And the vector
> partial
> > > sums
> > > > > > > (VL1L2
> > > > > > > > > line
> > > > > > > > > > > type) is also useful. But those require the
comparison
> of
> > > U/V
> > > > > > > > > components.
> > > > > > > > > > > And it sounds like you only have wind speed and
> direction
> > > in
> > > > > the
> > > > > > > > > > > observations. So that's a limitation.
> > > > > > > > > > >
> > > > > > > > > > > For ensemble_stat, you could verify wind speed
by
> > > requesting
> > > > > WIND
> > > > > > > in
> > > > > > > > > the
> > > > > > > > > > > config file.
> > > > > > > > > > >
> > > > > > > > > > > John
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Jul 21, 2020 at 12:15 PM
binyu.wang at noaa.gov
> via
> > > RT
> > > > <
> > > > > > > > > > > met_help at ucar.edu> wrote:
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Tue Jul 21 12:15:18 2020: Request 95970 was
acted
> upon.
> > > > > > > > > > > > Transaction: Ticket created by
binyu.wang at noaa.gov
> > > > > > > > > > > > Queue: met_help
> > > > > > > > > > > > Subject: Wind direction unsemble
verifcaion
> > > > > > > > > > > > Owner: Nobody
> > > > > > > > > > > > Requestors: binyu.wang at noaa.gov
> > > > > > > > > > > > Status: new
> > > > > > > > > > > > Ticket <URL:
> > > > > > > > >
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Hello,
> > > > > > > > > > > >
> > > > > > > > > > > > I am working on ensemble wind direction
verification
> > > using
> > > > > the
> > > > > > > > "gefs"
> > > > > > > > > > > > model. I noticed that MET could handle wind
direction
> > > using
> > > > > > > > > "grid_stat"
> > > > > > > > > > > and
> > > > > > > > > > > > "aggregate_stat", but this is not for
ensemble. The
> > gefs
> > > > > model
> > > > > > > only
> > > > > > > > > has
> > > > > > > > > > > > UGRD and VGRD (no direction) and my
observation has
> > WIND
> > > > > SPEED
> > > > > > > and
> > > > > > > > > WIND
> > > > > > > > > > > > DIRECTION. Of course I can get WIND DIRECTION
for
> > model
> > > > data
> > > > > > (or
> > > > > > > > > UGRD
> > > > > > > > > > > and
> > > > > > > > > > > > VGRD for observation). But I think it will not
be the
> > > right
> > > > > way
> > > > > > > if
> > > > > > > > I
> > > > > > > > > > just
> > > > > > > > > > > > use ensemble_stat and grid_stat by treating
"WIND
> > > > DIRECTION"
> > > > > as
> > > > > > > > > others
> > > > > > > > > > > like
> > > > > > > > > > > > TEMP. because the degree issue from WIND
DIrection
> > (e.g:
> > > 0
> > > > > > degree
> > > > > > > > is
> > > > > > > > > > > close
> > > > > > > > > > > > to 350 degree. )
> > > > > > > > > > > >
> > > > > > > > > > > > So any suggestions to do wind direction
ensemble
> > > > verification
> > > > > > > using
> > > > > > > > > > MET?
> > > > > > > > > > > > How the problem (like 0 vs. 350 degree) is
resolved
> in
> > > the
> > > > > > > > > > > > "aggregate_stat"?
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you very much.
> > > > > > > > > > > > Binyu
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Wind direction unsemble verifcaion
From: John Halley Gotway
Time: Mon Aug 17 09:57:42 2020
Binyu,
Yes, that's correct. You can run Point-Stat with as few sites as you'd
like. For each observation, it'll interpolate the gridded forecast
data to
that observation lat/lon location and create a matched pair, and those
pairs can be written to the output MPR line type (if requested in the
config file). Point-Stat also computes statistics by grouping multiple
matched pairs together over user-defined spatial areas (defined in the
"mask" dictionary). However, statistics derived from just a handful of
matched pairs are not very meaningful.
So let's say you have 3 observing locations, you could try this
approach...
(1) Run Point-Stat once for each model output time but configure it to
ONLY
write out the MPR line type.
(2) After you've run Point-Stat many times and have lots of matched
pairs,
run the STAT-Analysis tool to read those MPR lines and derive
statistics
from them over some temporal aggregation period. For example,
statistics
computed over 1 month of data would likely be more meaningful that 3
pairs
from a single time step. And you could even compute stats separately
for
each station using the "-by" command line option for STAT-Analysis.
As for how much data is need to run Point2Grid well, there's no hard
and
fast rule. But more qualitatively, when you look at a plot of the
point
data, if the data "looks gridded" or you see some spatial structure
there,
then it might be a good approach.
Thanks,
John
On Thu, Aug 13, 2020 at 6:13 PM binyu.wang at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
>
> Hello John,
>
> So we don't need multiple sites to use "point_stat", we can use this
> utility even with one or two sites only, right? Speaking of "dense
set of
> point data '' for Point2Grid, how dense is a good number? Like in a
grid of
> 0.1*0.1deg, are 10 sites enough? Thank you.
>
> Binyu
>
> Point-Sta
>
> On Tue, Aug 11, 2020 at 6:19 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Binyu,
> >
> > Sorry for the long delay in responding on this issue. I was
scrambling to
> > get the met-9.1 release out the door.
> >
> > No, I definitely do recommend running the Point-Stat tool to do
point
> > verification. Point-Stat interpolates gridded forecast data to
those
> point
> > observation locations, constructs matched fcst/obs pairs, and
derives
> > statistics from them. That's exactly the right process.
> >
> > The issue is that you were running the Point2Grid tool, and I
definitely
> do
> > not recommend that for such sparse data. Point2Grid is useful for
> placing a
> > dense set of point data onto a regular grid to support grid-to-
grid
> > comparison (i.e. prior to running Grid-Stat, MODE, or Series-
Analysis).
> >
> > Thanks,
> > John Halley Gotway
> >
> > On Fri, Jul 31, 2020 at 5:50 PM binyu.wang at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> > >
> > > Yes, you are right. I have very few sites. So you don't
recommend using
> > > point_stat to do the verification?
> > >
> > > Binyy
> > >
> > > On Fri, Jul 31, 2020 at 6:47 PM John Halley Gotway via RT <
> > > met_help at ucar.edu>
> > > wrote:
> > >
> > > > Binyu,
> > > >
> > > > Back to this question... sorry for the delay.
> > > >
> > > > No MET is not, in general, converting between pressure and
height
> > levels.
> > > > When running Point-Stat, you generally compare forecasts at
pressure
> > > levels
> > > > to observations at pressure levels... and forecasts at height
levels
> to
> > > > observations at height levels.
> > > >
> > > > But you are asking about running the point2grid tool. I logged
on to
> > > wcoss
> > > > and took a look at:
> > > > /gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventad
> > > > or/Sounding/2020/SKTQ_SKBO/UWYO_obs_met/
> > > > regrid_SKTQ_SKBO_t12z.20200201.nc
> > > > <http://regrid_sktq_skbo_t12z.20200201.nc/>
> > > >
> > > > I looked at the variables named "UGRD_cnt" and "UGRD". I see
missing
> > data
> > > > everywhere other than a single grid point.
> > > > I ran the following plot_data_plane commands to visualize this
data
> and
> > > > have attached the result:
> > > >
> > > > plot_data_plane regrid_SKTQ_SKBO_t12z.20200201.nc UGRD.ps
> > 'name="UGRD";
> > > > level="(*,*)";'
> > > > plot_data_plane regrid_SKTQ_SKBO_t12z.20200201.nc UGRD_cnt.ps
> > > > 'name="UGRD_cnt"; level="(*,*)";'
> > > >
> > > > There's a single pink dot in northern south america which
isn't even
> > > really
> > > > visible in the attached plots.
> > > >
> > > > This doesn't look to me like a very good use of the point2grid
tool.
> > It's
> > > > generally intended to read a dense set of point observations
and put
> > them
> > > > onto a grid.
> > > >
> > > > John
> > > > [image: UGRD.png]
> > > > [image: UGRD_cnt.png]
> > > >
> > > > John
> > > >
> > > > On Fri, Jul 31, 2020 at 3:10 PM binyu.wang at noaa.gov via RT <
> > > > met_help at ucar.edu> wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970 >
> > > > >
> > > > > No,actually they are different questions. I do still need
> > confirmation
> > > > for
> > > > > my guess in the previous email. Thank you.
> > > > >
> > > > >
> > > > > On Fri, Jul 31, 2020 at 4:09 PM John Halley Gotway via RT <
> > > > > met_help at ucar.edu>
> > > > > wrote:
> > > > >
> > > > > > Hi Binyu,
> > > > > >
> > > > > > I realize that I never responded on this ticket. But I did
> respond
> > to
> > > > > your
> > > > > > other question today. Is this still an open issue or were
you
> able
> > to
> > > > > > figure it out?
> > > > > >
> > > > > > Thanks,
> > > > > > John
> > > > > >
> > > > > > On Thu, Jul 23, 2020 at 10:12 PM binyu.wang at noaa.gov via
RT <
> > > > > > met_help at ucar.edu> wrote:
> > > > > >
> > > > > > >
> > > > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> >
> > > > > > >
> > > > > > > John,
> > > > > > >
> > > > > > > Your email reminds me of another thing that I want to
confirm:
> > > > > > >
> > > > > > > Using the same ascII2nc output file ( the one you just
saw:
> > > > > > > asc2nc_SKTQ_SKBO_20200201.nc) as input, I used
point2grid to
> get
> > a
> > > > new
> > > > > > > output (
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met/
> > > > > > > regrid_SKTQ_SKBO_t12z.20200201.nc).
> > > > > > > The new output has a pressure level like P250. From the
MET
> > > > > > documentation:
> > > > > > > "point2grid input_filename to_grid output_filename", the
input
> is
> > > > > > > re-grided based on "to_grid" file. How the input got
"pressure
> > > > level"?
> > > > > I
> > > > > > > guess in MET, the same relationship between height and
pressure
> > in
> > > > > > > "to_grid" is assigned to the input? I.e: over one site
in the
> > > > "to_grid"
> > > > > > > file, the pressure level 250mb is corresponding to
10000m ,
> MET
> > > > treats
> > > > > > the
> > > > > > > same relationship to input, so the site with height
10000m is
> > > > > > > assigned 250mb as pressure level. Am I correct?
> > > > > > >
> > > > > > > Thank you.
> > > > > > > Binyu
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Jul 23, 2020 at 7:24 PM John Halley Gotway via
RT <
> > > > > > > met_help at ucar.edu>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Binyu,
> > > > > > > >
> > > > > > > > I logged onto Mars, took a look at your shell script,
and ran
> > > these
> > > > > > > > commands:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > *module use
> > > > > > > >
> > > > >
> >
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/modulefilesmodule
> > > > > > > > load met/9.0.2*
> > > > > > > > *mkdir -p out/point_stat*
> > > > > > > >
> > > > > > > > *point_stat
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/EMC_HYSPLIT/inout/ptmp/com/gefs/prod/gefs.20200201/00/pgrb2ap5/gec00.t00z.pgrb2a.0p50.f012
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Obs/Reventador/Sounding/2020/SKTQ_SKBO/UWYO_obs_met_temp/asc2nc_SKTQ_SKBO_20200201.nc
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/parm/PointStatConfig
> > > > > > > > -log run_pt.log -outdir out/point_stat -v 3*
> > > > > > > >
> > > > > > > > But this finds 0 matched pairs and the log messages
indicates
> > > that
> > > > > > it's a
> > > > > > > > level mismatch:
> > > > > > > >
> > > > > > > > DEBUG 2: Processing UGRD/P250 versus UGRD/P250, for
> observation
> > > > type
> > > > > > > > ADPUPA, over region FULL, for interpolation method
> NEAREST(1),
> > > > using
> > > > > 0
> > > > > > > > matched pairs.
> > > > > > > > DEBUG 3: Number of matched pairs = 0
> > > > > > > > DEBUG 3: Observations processed = 340
> > > > > > > > ...
> > > > > > > > DEBUG 3: Rejected: level mismatch = 85
> > > > > > > >
> > > > > > > > So let's check the obs that are in the file
> > > > > > > asc2nc_SKTQ_SKBO_20200201.nc. I
> > > > > > > > copied that file to my local machine and ran this
Rscript to
> > dump
> > > > it
> > > > > > back
> > > > > > > > out to an easier to read ascii format:
> > > > > > > >
> > > > > > > > Rscript met/scripts/Rscripts/pntnc2ascii.R
> > > > > > asc2nc_SKTQ_SKBO_20200201.nc >
> > > > > > > > asc2nc_SKTQ_SKBO_20200201.txt
> > > > > > > >
> > > > > > > > That file contains 85 instances of UGRD, but the level
values
> > > range
> > > > > > from
> > > > > > > > 2546 to 22562. None of them have a level value of
exactly
> 250.
> > > And
> > > > > > that's
> > > > > > > > why you're getting 0 matches. Looks to me like there's
2
> > issues:
> > > > > > > >
> > > > > > > > (1) The units of pressure differ between the fcst and
obs.
> > > > > > > > (2) No obs exactly match 250mb.
> > > > > > > >
> > > > > > > > You can handle both issues in the Point-Stat config
file.
> Just
> > > > > specify
> > > > > > > > separate levels for the fcst and obs dictionaries.
> > > > > > > >
> > > > > > > > fcst = { field = [ { name="UGRD"; level="P250"; } ]; }
> > > > > > > > obs = { field = [ { name="UGRD"; level="P20000-30000";
} ]; }
> > > > > > > >
> > > > > > > > That'll match any obs of UGRD with a pressure value
between
> > 20000
> > > > and
> > > > > > > 30000
> > > > > > > > to the forecast for P250.
> > > > > > > >
> > > > > > > > Make sense?
> > > > > > > >
> > > > > > > > John
> > > > > > > >
> > > > > > > > On Thu, Jul 23, 2020 at 4:50 PM binyu.wang at noaa.gov
via RT <
> > > > > > > > met_help at ucar.edu> wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > <URL:
> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > > >
> > > > > > > > >
> > > > > > > > > Thank you, John.
> > > > > > > > >
> > > > > > > > > Based on what you said I can not evaluate wind
direction
> > > > directly,
> > > > > so
> > > > > > > > there
> > > > > > > > > is no need for me to get WDIR based on UGRD and VGRD
from
> the
> > > > GEFS
> > > > > > > model
> > > > > > > > > output. I need to do the WDIR verification because
my
> > ensemble
> > > > > model
> > > > > > > > > output (which is based on GEFS wind profile)
predicted that
> > the
> > > > ash
> > > > > > > went
> > > > > > > > > northward, while the satellite observance shows the
ash
> went
> > > > > > southward
> > > > > > > > over
> > > > > > > > > one volcano eruption. So I want to identify if there
is a
> > > problem
> > > > > for
> > > > > > > > WDIR
> > > > > > > > > prediction over the volcano area.
> > > > > > > > >
> > > > > > > > > Following your suggestion, I used point_stat for
UGRD/VGRD,
> > > > > however,
> > > > > > > the
> > > > > > > > > output is empty (no matching pair). But I am sure
there are
> > > > > matching
> > > > > > > > pairs
> > > > > > > > > for UGRD/VGRD because I have no problem to get non-
empty
> > stat.
> > > > > output
> > > > > > > > using
> > > > > > > > > "ensemble_stat" and "grid_stat" for UGRD/VGRD. Below
is my
> > > > script:
> > > > > > (and
> > > > > > > > my
> > > > > > > > > obs. is abstained using ascii2nc)
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_gec/ush/
> > > > > > > > > verf_g2g_gec_Reventador.sh
> > > > > > > > >
> > > > > > > > > Thank you.
> > > > > > > > > Binyu
> > > > > > > > >
> > > > > > > > > On Tue, Jul 21, 2020 at 6:47 PM John Halley Gotway
via RT <
> > > > > > > > > met_help at ucar.edu>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Binyu,
> > > > > > > > > >
> > > > > > > > > > MET does not evaluate wind direction directly for
the
> > reason
> > > > that
> > > > > > you
> > > > > > > > > > mention. Since it's a "circular" variable, it does
not
> lend
> > > > > itself
> > > > > > > well
> > > > > > > > > to
> > > > > > > > > > traditional statistics, like RMSE. If you try
evaluating
> > wind
> > > > > > > direction
> > > > > > > > > > directly, you'll get this error message:
> > > > > > > > > >
> > > > > > > > > > ERROR : PointStatVxOpt::process_config() -> wind
> direction
> > > may
> > > > > not
> > > > > > > be
> > > > > > > > > > verified using point_stat.
> > > > > > > > > >
> > > > > > > > > > With U/V pairs, you can run point_stat to evaluate
those
> > > > vectors
> > > > > > and
> > > > > > > > > write
> > > > > > > > > > the VL1L2 partial sums and VCNT statistics. I'd
recommend
> > > > running
> > > > > > > > > > point_stat to evaluate the ensemble mean using the
VL1L2
> > and
> > > > VCNT
> > > > > > > line
> > > > > > > > > > types. Those VCNT statistic are described in the
MET
> User's
> > > > > Guide.
> > > > > > > > > >
> > > > > > > > > > John
> > > > > > > > > >
> > > > > > > > > > On Tue, Jul 21, 2020 at 3:22 PM
binyu.wang at noaa.gov via
> > RT <
> > > > > > > > > > met_help at ucar.edu> wrote:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > <URL:
> > > > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > > > > >
> > > > > > > > > > >
> > > > > > > > > > > John,
> > > > > > > > > > >
> > > > > > > > > > > Although my original Obs. data has no UGRD/VGRD,
I did
> > > derive
> > > > > > them
> > > > > > > > > using
> > > > > > > > > > > WIND and WDIR (the original input is ascII file,
so I
> > used
> > > > > > ascIInc
> > > > > > > > and
> > > > > > > > > > > grid2point to convert them to *nc file, which
has
> > > > > > > > UGRD/VGRD/WIND/WDIR).
> > > > > > > > > > So
> > > > > > > > > > > it is not a problem for me.
> > > > > > > > > > >
> > > > > > > > > > > "For ensemble_stat, you could verify wind speed
by
> > > requesting
> > > > > > WIND
> > > > > > > in
> > > > > > > > > the
> > > > > > > > > > > config file." But WIND only tells the
magnitude, not
> the
> > > > > > > direction,
> > > > > > > > > > right?
> > > > > > > > > > >
> > > > > > > > > > > So how does the MET deal with the degree for
WDIR? If
> > > > > > > WDIR=355degree
> > > > > > > > > > from
> > > > > > > > > > > MODEL, and WDIR=0 from OBS, will MET treat them
as a
> big
> > > > > > difference
> > > > > > > > or
> > > > > > > > > > > small difference? I know how to do the ensemble
> > > verification
> > > > > for
> > > > > > > > > > UGRD/VGRD,
> > > > > > > > > > > but my main interest is WDIR. I want to know if
I could
> > > treat
> > > > > > WDIR
> > > > > > > as
> > > > > > > > > > > UGRD/VGRD using ensemble_stat and grid_stat.
> > > > > > > > > > >
> > > > > > > > > > > Thank you.
> > > > > > > > > > > Binyu
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Jul 21, 2020 at 4:07 PM John Halley
Gotway via
> > RT <
> > > > > > > > > > > met_help at ucar.edu>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Binyu,
> > > > > > > > > > > >
> > > > > > > > > > > > Let me address wind speed first (WIND). When
> processing
> > > > GRIB
> > > > > 1
> > > > > > > or 2
> > > > > > > > > > > files,
> > > > > > > > > > > > when you request wind speed in a MET config
file, MET
> > > will
> > > > > > first
> > > > > > > > try
> > > > > > > > > to
> > > > > > > > > > > > find a record of WIND directly in that file.
If not
> > > > present,
> > > > > it
> > > > > > > > will
> > > > > > > > > > > > automatically try to find the corresponding
UGRD and
> > VGRD
> > > > > > > records.
> > > > > > > > > And
> > > > > > > > > > > > it'll automatically derive wind speed on the
fly.
> > > > > > > > > > > >
> > > > > > > > > > > > In regards to wind direction (WDIR), the MET
tools do
> > not
> > > > > > verify
> > > > > > > it
> > > > > > > > > > > > directly. In fact, if you request it, you'll
see an
> > error
> > > > > > message
> > > > > > > > > > stating
> > > > > > > > > > > > that.
> > > > > > > > > > > >
> > > > > > > > > > > > When running point_stat and grid_stat, you can
> compute
> > > the
> > > > > VCNT
> > > > > > > > > (vector
> > > > > > > > > > > > continuous statistics) line type. And the
vector
> > partial
> > > > sums
> > > > > > > > (VL1L2
> > > > > > > > > > line
> > > > > > > > > > > > type) is also useful. But those require the
> comparison
> > of
> > > > U/V
> > > > > > > > > > components.
> > > > > > > > > > > > And it sounds like you only have wind speed
and
> > direction
> > > > in
> > > > > > the
> > > > > > > > > > > > observations. So that's a limitation.
> > > > > > > > > > > >
> > > > > > > > > > > > For ensemble_stat, you could verify wind speed
by
> > > > requesting
> > > > > > WIND
> > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > > > config file.
> > > > > > > > > > > >
> > > > > > > > > > > > John
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Jul 21, 2020 at 12:15 PM
binyu.wang at noaa.gov
> > via
> > > > RT
> > > > > <
> > > > > > > > > > > > met_help at ucar.edu> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Tue Jul 21 12:15:18 2020: Request 95970 was
acted
> > upon.
> > > > > > > > > > > > > Transaction: Ticket created by
binyu.wang at noaa.gov
> > > > > > > > > > > > > Queue: met_help
> > > > > > > > > > > > > Subject: Wind direction unsemble
verifcaion
> > > > > > > > > > > > > Owner: Nobody
> > > > > > > > > > > > > Requestors: binyu.wang at noaa.gov
> > > > > > > > > > > > > Status: new
> > > > > > > > > > > > > Ticket <URL:
> > > > > > > > > >
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95970
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hello,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I am working on ensemble wind direction
> verification
> > > > using
> > > > > > the
> > > > > > > > > "gefs"
> > > > > > > > > > > > > model. I noticed that MET could handle wind
> direction
> > > > using
> > > > > > > > > > "grid_stat"
> > > > > > > > > > > > and
> > > > > > > > > > > > > "aggregate_stat", but this is not for
ensemble. The
> > > gefs
> > > > > > model
> > > > > > > > only
> > > > > > > > > > has
> > > > > > > > > > > > > UGRD and VGRD (no direction) and my
observation has
> > > WIND
> > > > > > SPEED
> > > > > > > > and
> > > > > > > > > > WIND
> > > > > > > > > > > > > DIRECTION. Of course I can get WIND
DIRECTION for
> > > model
> > > > > data
> > > > > > > (or
> > > > > > > > > > UGRD
> > > > > > > > > > > > and
> > > > > > > > > > > > > VGRD for observation). But I think it will
not be
> the
> > > > right
> > > > > > way
> > > > > > > > if
> > > > > > > > > I
> > > > > > > > > > > just
> > > > > > > > > > > > > use ensemble_stat and grid_stat by treating
"WIND
> > > > > DIRECTION"
> > > > > > as
> > > > > > > > > > others
> > > > > > > > > > > > like
> > > > > > > > > > > > > TEMP. because the degree issue from WIND
DIrection
> > > (e.g:
> > > > 0
> > > > > > > degree
> > > > > > > > > is
> > > > > > > > > > > > close
> > > > > > > > > > > > > to 350 degree. )
> > > > > > > > > > > > >
> > > > > > > > > > > > > So any suggestions to do wind direction
ensemble
> > > > > verification
> > > > > > > > using
> > > > > > > > > > > MET?
> > > > > > > > > > > > > How the problem (like 0 vs. 350 degree) is
resolved
> > in
> > > > the
> > > > > > > > > > > > > "aggregate_stat"?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thank you very much.
> > > > > > > > > > > > > Binyu
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
More information about the Met_help
mailing list