[Met_help] [rt.rap.ucar.edu #95208] History for Error with using PYTHON_NUMPY in config file
David Fillmore via RT
met_help at ucar.edu
Tue Oct 13 11:00:45 MDT 2020
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello,
MET helpers, I tried to use PYTHON_NUMPY in my config file for
"ensemble_stat",
cd /gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/ush
[Binyu.Wang at v71a3 ush]$ ./verf_g2g_kasat.sh
---
ERROR :
ERROR : VarInfo::set_magic() -> embedded whitespace found in the nstr
"/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Scripts/read_Kasatochi_NC.py
$OBSV_FILE ASH_MASS_LOADING" or lstr "(*,*)".
ERROR :
my config is:
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/parm/verf_g2g_ens_stat_regn_config_kasat
Any suggestions? Thank you.
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Error with using PYTHON_NUMPY in config file
From: David Fillmore
Time: Fri May 08 15:42:14 2020
Hi Julie -
Are you able to look at this additional PYTHON_NUMPY issue from Binyu
on
WCOSS?
thanks,
David
On Fri, May 8, 2020 at 3:34 PM binyu.wang at noaa.gov via RT
<met_help at ucar.edu>
wrote:
>
> Fri May 08 15:34:30 2020: Request 95208 was acted upon.
> Transaction: Ticket created by binyu.wang at noaa.gov
> Queue: met_help
> Subject: Error with using PYTHON_NUMPY in config file
> Owner: Nobody
> Requestors: binyu.wang at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95208 >
>
>
> Hello,
> MET helpers, I tried to use PYTHON_NUMPY in my config file for
> "ensemble_stat",
>
> cd
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/ush
> [Binyu.Wang at v71a3 ush]$ ./verf_g2g_kasat.sh
> ---
> ERROR :
> ERROR : VarInfo::set_magic() -> embedded whitespace found in the
nstr
>
>
"/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Scripts/read_Kasatochi_NC.py
> $OBSV_FILE ASH_MASS_LOADING" or lstr "(*,*)".
> ERROR :
>
> my config is:
>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/parm/verf_g2g_ens_stat_regn_config_kasat
>
> Any suggestions? Thank you.
>
>
------------------------------------------------
Subject: Error with using PYTHON_NUMPY in config file
From: John Halley Gotway
Time: Mon May 11 13:19:05 2020
Hi Binyu,
I'll log onto WCOSS and take a look at this issue. I do realize you
have a
few outstanding questions via met-help. So I'll try to work through
them
today.
John
On Fri, May 8, 2020 at 3:34 PM binyu.wang at noaa.gov via RT
<met_help at ucar.edu>
wrote:
>
> Fri May 08 15:34:30 2020: Request 95208 was acted upon.
> Transaction: Ticket created by binyu.wang at noaa.gov
> Queue: met_help
> Subject: Error with using PYTHON_NUMPY in config file
> Owner: Nobody
> Requestors: binyu.wang at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95208 >
>
>
> Hello,
> MET helpers, I tried to use PYTHON_NUMPY in my config file for
> "ensemble_stat",
>
> cd
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/ush
> [Binyu.Wang at v71a3 ush]$ ./verf_g2g_kasat.sh
> ---
> ERROR :
> ERROR : VarInfo::set_magic() -> embedded whitespace found in the
nstr
>
>
"/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Scripts/read_Kasatochi_NC.py
> $OBSV_FILE ASH_MASS_LOADING" or lstr "(*,*)".
> ERROR :
>
> my config is:
>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/parm/verf_g2g_ens_stat_regn_config_kasat
>
> Any suggestions? Thank you.
>
>
------------------------------------------------
Subject: Error with using PYTHON_NUMPY in config file
From: binyu.wang at noaa.gov
Time: Mon May 11 13:51:03 2020
Hello John,
Thank you for your help. To save your time, let me make more clear on
my
new questions. Actually I have a bunch now after spending more time on
this. Although I did get something but I am not sure it is correct or
not:
1. I changed my script and config files. Here is my new script:
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/ush/verf_g2g_kasat.sh2
Are "ensemble_stat " and "grid_stat " statements correct?
Please also look at the two configures files
"verf_g2g_ens_stat_regn_config_kasat" and
"verf_g2g_grid_stat_regn_config_kasat"
2. Inside of "verf_g2g_ens_stat_regn_config_kasa", what is the
relationship
of "field" included in "fcst" with that in "ens"? Which one refers to
the
real forecast? It seems the one in "fcst" is not used at all because
even
if I change the name "VAFTD" under "fcst" to a new name, there is no
difference.
e.g: my obs is "ASH_MASS_LOADING", my forecast is "VAFTD", I want to
use a
new name "ASH" in the MET_viewer, how to do that?
3 This question is related to the second one: to using "convert",
where to
use it? Under the "field" of "fcst" or "ens"? Here is the unit
relationship
of obs and forecast:
obs=1.636*10^18*(forecast)
4. I noticed I got a warning as below while the script is running,
what
does that mean?
.WARNING: GridStatVxOpt::process_config() -> "nc_pairs_var_str"
((nul)) is
deprecated and replaced by
"nc_pairs_var_suffix".
Sorry to ask so many questions. I can not find a similar use of
"PYTHON_NUMPY" from tutorial, so if you could confirm my script and
config
are correct, that will be very very helpful. Let me know if anything
is not
clear.
Binyu
On Mon, May 11, 2020 at 3:19 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Hi Binyu,
>
> I'll log onto WCOSS and take a look at this issue. I do realize you
have a
> few outstanding questions via met-help. So I'll try to work through
them
> today.
>
> John
>
> On Fri, May 8, 2020 at 3:34 PM binyu.wang at noaa.gov via RT <
> met_help at ucar.edu>
> wrote:
>
> >
> > Fri May 08 15:34:30 2020: Request 95208 was acted upon.
> > Transaction: Ticket created by binyu.wang at noaa.gov
> > Queue: met_help
> > Subject: Error with using PYTHON_NUMPY in config file
> > Owner: Nobody
> > Requestors: binyu.wang at noaa.gov
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95208 >
> >
> >
> > Hello,
> > MET helpers, I tried to use PYTHON_NUMPY in my config file for
> > "ensemble_stat",
> >
> > cd
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/ush
> > [Binyu.Wang at v71a3 ush]$ ./verf_g2g_kasat.sh
> > ---
> > ERROR :
> > ERROR : VarInfo::set_magic() -> embedded whitespace found in the
nstr
> >
> >
>
"/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/Scripts/read_Kasatochi_NC.py
> > $OBSV_FILE ASH_MASS_LOADING" or lstr "(*,*)".
> > ERROR :
> >
> > my config is:
> >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/parm/verf_g2g_ens_stat_regn_config_kasat
> >
> > Any suggestions? Thank you.
> >
> >
>
>
------------------------------------------------
Subject: Error with using PYTHON_NUMPY in config file
From: John Halley Gotway
Time: Mon May 11 17:15:55 2020
Binyu,
I provided answers inline below.
Thanks,
John
On Mon, May 11, 2020 at 1:51 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=95208 >
>
> Hello John,
>
> Thank you for your help. To save your time, let me make more clear
on my
> new questions. Actually I have a bunch now after spending more time
on
> this. Although I did get something but I am not sure it is correct
or not:
>
> 1. I changed my script and config files. Here is my new script:
>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/ush/verf_g2g_kasat.sh2
> Are "ensemble_stat " and "grid_stat " statements correct?
>
>
I'm working on Venus in
/u/John.H.Gotway/MET/MET_Help/wang_data_20200511
Running your script in there reveals lots of warnings like this:
*WARNING: MetGrib2DataFile::data_plane() -> Using the first of 60
matching
records for "VAFTD/L20000-0":*
This means that ensemble-stat found multiple matching records in the
input
files. Why? Each one of your GRIB2 model files contains output for 60
different forecast hours. You need to loop over them and process them
separately.
I would recommend setting up a METplus use case to handle this time
looping. But to demonstrate an example, I updated your ensemble-stat
config file to reference lead_time = "${LEAD_HR}"; and I updated your
run
script to set that variable as 11 hours.
And I also updated the Grid-Stat config file to solve this warning
message:
*WARNING: GridStatVxOpt::process_config() -> "nc_pairs_var_str"
((nul)) is
deprecated and replaced by "nc_pairs_var_suffix".*
The logs of my running can be seen in:
/u/John.H.Gotway/MET/MET_Help/wang_data_20200511/run_es.log and
run_gs.log
Please also look at the two configures files
> "verf_g2g_ens_stat_regn_config_kasat" and
> "verf_g2g_grid_stat_regn_config_kasat"
>
> 2. Inside of "verf_g2g_ens_stat_regn_config_kasa", what is the
relationship
> of "field" included in "fcst" with that in "ens"? Which one refers
to the
> real forecast? It seems the one in "fcst" is not used at all
because even
> if I change the name "VAFTD" under "fcst" to a new name, there is no
> difference.
> e.g: my obs is "ASH_MASS_LOADING", my forecast is "VAFTD", I want to
use a
> new name "ASH" in the MET_viewer, how to do that?
>
In the Ensemble-Stat config file, the "ens" dictionary defines the
fields
for which you want to derive ensemble mean and probability fields that
are
written to the output NetCDF file. The "fcst" dictionary defines the
fields for which you want to compute ensemble statistics. If those
are the
same, you could set "fcst = ens;". Those are not necessarily the same
list
of fields. In your case they are.
> 3 This question is related to the second one: to using "convert",
where to
> use it? Under the "field" of "fcst" or "ens"? Here is the unit
relationship
> of obs and forecast:
> obs=1.636*10^18*(forecast)
>
Both spots. Anytime you data that needs to be converted, you need to
specify the formula for converting it.
>
> 4. I noticed I got a warning as below while the script is running,
what
> does that mean?
> .WARNING: GridStatVxOpt::process_config() -> "nc_pairs_var_str"
((nul)) is
> deprecated and replaced by
"nc_pairs_var_suffix".
>
>
See answer to 1.
> Sorry to ask so many questions. I can not find a similar use of
> "PYTHON_NUMPY" from tutorial, so if you could confirm my script and
config
> are correct, that will be very very helpful. Let me know if anything
is not
> clear.
>
> Binyu
>
I understand what you're doing. I would recommend writing output to
different directories using the "-outdir" command line option. And
you
really need to loop over the 60 forecast hours and call ensemble-stat
and
grid-stat separately for each. You could do that manually with a
shell
script, like you're doing now. But it's going to be difficult to find
the
observation file that is "closest" in time to the forecast valid time.
Instead, METplus already includes logic to handle that.
So I'd recommend using METplus instead of your shell script. While
it's a
big learning curve, it will hopefully make things easier in the long
run.
Thanks,
John
------------------------------------------------
Subject: Error with using PYTHON_NUMPY in config file
From: binyu.wang at noaa.gov
Time: Mon May 11 20:14:08 2020
Hello John,
Thank you for spending so much time wring out this.
1. There is one thing I forgot to mention: for the satellite obs.
data,
there is ONLY one time ( 20080808 13:40 ) at which the observations
are available in the file. By saying that, should I change the
"lead_time =
"9"? Because the forecasting data (it contains 60- one hourly average
data)
starts at 4:00? We can use "lead_time" to specify the starting time,
is
there a way to specify the ending time? If so then we don't need to
worry
about the 60 different forecast hours. Am I right?
2. For the question about "ens" and "fcst" in the Ensemble-stat
config
file, is "fcst" a must to get "ens"? I mean do we must define "fcst"
to get
"ens"? If they are not the same, what will be the use of the field?
Can
you give me an example that they are not the same?
3. If I want to have a different name (not in obs./fcst) in the final
output "grid_stat_Kasatochi_090000L_20080808_130000V.stat", what
should I
do with the Ensemble-stat config file or Grid-stat config file?
4. What is the use of "reference" inside of "verf_g2g_kasat.sh2"? It
seems
some scripts in the example have it, but some don't.
Thank you very much for your help.
Binyu
On Mon, May 11, 2020 at 7:16 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binyu,
>
> I provided answers inline below.
>
> Thanks,
> John
>
> On Mon, May 11, 2020 at 1:51 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=95208 >
> >
> > Hello John,
> >
> > Thank you for your help. To save your time, let me make more clear
on my
> > new questions. Actually I have a bunch now after spending more
time on
> > this. Although I did get something but I am not sure it is correct
or
> not:
> >
> > 1. I changed my script and config files. Here is my new script:
> >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/ush/verf_g2g_kasat.sh2
> > Are "ensemble_stat " and "grid_stat " statements correct?
> >
> >
> I'm working on Venus in
/u/John.H.Gotway/MET/MET_Help/wang_data_20200511
> Running your script in there reveals lots of warnings like this:
>
> *WARNING: MetGrib2DataFile::data_plane() -> Using the first of 60
matching
> records for "VAFTD/L20000-0":*
>
> This means that ensemble-stat found multiple matching records in the
input
> files. Why? Each one of your GRIB2 model files contains output for
60
> different forecast hours. You need to loop over them and process
them
> separately.
>
> I would recommend setting up a METplus use case to handle this time
> looping. But to demonstrate an example, I updated your ensemble-
stat
> config file to reference lead_time = "${LEAD_HR}"; and I updated
your run
> script to set that variable as 11 hours.
>
> And I also updated the Grid-Stat config file to solve this warning
message:
>
> *WARNING: GridStatVxOpt::process_config() -> "nc_pairs_var_str"
((nul)) is
> deprecated and replaced by "nc_pairs_var_suffix".*
>
> The logs of my running can be seen in:
> /u/John.H.Gotway/MET/MET_Help/wang_data_20200511/run_es.log and
run_gs.log
>
> Please also look at the two configures files
> > "verf_g2g_ens_stat_regn_config_kasat" and
> > "verf_g2g_grid_stat_regn_config_kasat"
> >
> > 2. Inside of "verf_g2g_ens_stat_regn_config_kasa", what is the
> relationship
> > of "field" included in "fcst" with that in "ens"? Which one
refers to
> the
> > real forecast? It seems the one in "fcst" is not used at all
because
> even
> > if I change the name "VAFTD" under "fcst" to a new name, there is
no
> > difference.
> > e.g: my obs is "ASH_MASS_LOADING", my forecast is "VAFTD", I want
to use
> a
> > new name "ASH" in the MET_viewer, how to do that?
> >
>
> In the Ensemble-Stat config file, the "ens" dictionary defines the
fields
> for which you want to derive ensemble mean and probability fields
that are
> written to the output NetCDF file. The "fcst" dictionary defines
the
> fields for which you want to compute ensemble statistics. If those
are the
> same, you could set "fcst = ens;". Those are not necessarily the
same list
> of fields. In your case they are.
>
>
> > 3 This question is related to the second one: to using "convert",
where
> to
> > use it? Under the "field" of "fcst" or "ens"? Here is the unit
> relationship
> > of obs and forecast:
> > obs=1.636*10^18*(forecast)
> >
>
> Both spots. Anytime you data that needs to be converted, you need
to
> specify the formula for converting it.
>
>
> >
> > 4. I noticed I got a warning as below while the script is running,
what
> > does that mean?
> > .WARNING: GridStatVxOpt::process_config() -> "nc_pairs_var_str"
((nul))
> is
> > deprecated and replaced by
"nc_pairs_var_suffix".
> >
> >
> See answer to 1.
>
>
> > Sorry to ask so many questions. I can not find a similar use of
> > "PYTHON_NUMPY" from tutorial, so if you could confirm my script
and
> config
> > are correct, that will be very very helpful. Let me know if
anything is
> not
> > clear.
> >
> > Binyu
> >
>
> I understand what you're doing. I would recommend writing output to
> different directories using the "-outdir" command line option. And
you
> really need to loop over the 60 forecast hours and call ensemble-
stat and
> grid-stat separately for each. You could do that manually with a
shell
> script, like you're doing now. But it's going to be difficult to
find the
> observation file that is "closest" in time to the forecast valid
time.
> Instead, METplus already includes logic to handle that.
>
> So I'd recommend using METplus instead of your shell script. While
it's a
> big learning curve, it will hopefully make things easier in the long
run.
>
> Thanks,
> John
>
>
------------------------------------------------
Subject: Error with using PYTHON_NUMPY in config file
From: binyu.wang at noaa.gov
Time: Tue May 19 15:14:36 2020
Hello John,
I have another question about "clim_mean" in the config file. I am not
sure
how to use it. Why do we have to use that for "ensemble_stat" and
"grid_stat"? What is the relationship of "clim_mean" with "fcst" and
"obs"? In my script setup, should I set that to "fcst" or "obs" or
leave it
blank?
Thank you.
Binyu
On Mon, May 11, 2020 at 7:16 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binyu,
>
> I provided answers inline below.
>
> Thanks,
> John
>
> On Mon, May 11, 2020 at 1:51 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=95208 >
> >
> > Hello John,
> >
> > Thank you for your help. To save your time, let me make more clear
on my
> > new questions. Actually I have a bunch now after spending more
time on
> > this. Although I did get something but I am not sure it is correct
or
> not:
> >
> > 1. I changed my script and config files. Here is my new script:
> >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/ush/verf_g2g_kasat.sh2
> > Are "ensemble_stat " and "grid_stat " statements correct?
> >
> >
> I'm working on Venus in
/u/John.H.Gotway/MET/MET_Help/wang_data_20200511
> Running your script in there reveals lots of warnings like this:
>
> *WARNING: MetGrib2DataFile::data_plane() -> Using the first of 60
matching
> records for "VAFTD/L20000-0":*
>
> This means that ensemble-stat found multiple matching records in the
input
> files. Why? Each one of your GRIB2 model files contains output for
60
> different forecast hours. You need to loop over them and process
them
> separately.
>
> I would recommend setting up a METplus use case to handle this time
> looping. But to demonstrate an example, I updated your ensemble-
stat
> config file to reference lead_time = "${LEAD_HR}"; and I updated
your run
> script to set that variable as 11 hours.
>
> And I also updated the Grid-Stat config file to solve this warning
message:
>
> *WARNING: GridStatVxOpt::process_config() -> "nc_pairs_var_str"
((nul)) is
> deprecated and replaced by "nc_pairs_var_suffix".*
>
> The logs of my running can be seen in:
> /u/John.H.Gotway/MET/MET_Help/wang_data_20200511/run_es.log and
run_gs.log
>
> Please also look at the two configures files
> > "verf_g2g_ens_stat_regn_config_kasat" and
> > "verf_g2g_grid_stat_regn_config_kasat"
> >
> > 2. Inside of "verf_g2g_ens_stat_regn_config_kasa", what is the
> relationship
> > of "field" included in "fcst" with that in "ens"? Which one
refers to
> the
> > real forecast? It seems the one in "fcst" is not used at all
because
> even
> > if I change the name "VAFTD" under "fcst" to a new name, there is
no
> > difference.
> > e.g: my obs is "ASH_MASS_LOADING", my forecast is "VAFTD", I want
to use
> a
> > new name "ASH" in the MET_viewer, how to do that?
> >
>
> In the Ensemble-Stat config file, the "ens" dictionary defines the
fields
> for which you want to derive ensemble mean and probability fields
that are
> written to the output NetCDF file. The "fcst" dictionary defines
the
> fields for which you want to compute ensemble statistics. If those
are the
> same, you could set "fcst = ens;". Those are not necessarily the
same list
> of fields. In your case they are.
>
>
> > 3 This question is related to the second one: to using "convert",
where
> to
> > use it? Under the "field" of "fcst" or "ens"? Here is the unit
> relationship
> > of obs and forecast:
> > obs=1.636*10^18*(forecast)
> >
>
> Both spots. Anytime you data that needs to be converted, you need
to
> specify the formula for converting it.
>
>
> >
> > 4. I noticed I got a warning as below while the script is running,
what
> > does that mean?
> > .WARNING: GridStatVxOpt::process_config() -> "nc_pairs_var_str"
((nul))
> is
> > deprecated and replaced by
"nc_pairs_var_suffix".
> >
> >
> See answer to 1.
>
>
> > Sorry to ask so many questions. I can not find a similar use of
> > "PYTHON_NUMPY" from tutorial, so if you could confirm my script
and
> config
> > are correct, that will be very very helpful. Let me know if
anything is
> not
> > clear.
> >
> > Binyu
> >
>
> I understand what you're doing. I would recommend writing output to
> different directories using the "-outdir" command line option. And
you
> really need to loop over the 60 forecast hours and call ensemble-
stat and
> grid-stat separately for each. You could do that manually with a
shell
> script, like you're doing now. But it's going to be difficult to
find the
> observation file that is "closest" in time to the forecast valid
time.
> Instead, METplus already includes logic to handle that.
>
> So I'd recommend using METplus instead of your shell script. While
it's a
> big learning curve, it will hopefully make things easier in the long
run.
>
> Thanks,
> John
>
>
------------------------------------------------
Subject: Error with using PYTHON_NUMPY in config file
From: John Halley Gotway
Time: Thu May 21 13:54:24 2020
Binyu,
Yes, you can leave the climo_mean fields blank in Grid-Stat and
Ensemble-Stat if you do not need to compare against climatology data.
When
provided, the climatological mean data is used to compute scalar-
anomaly
and vector-anomaly partial sums (SAL1L2 and VAL1L2) line types and
statistics. The most common statistics computed using the climo mean
is the
anomaly correlation. In addition, the tools can also read
climatological
standard deviation data. With the mean and spread, we assume a normal
distribution of the climatology data and from this distribution we can
apply sort the data into climatologically-based bins or define
thresholds
relative to climatology. For example, ">CDP75" defines a threshold of
being
greater than the 75th percentile of the climatology at a given point.
Since
the climo mean and standard deviation change for each point, so too
would
the actual 75-th percentile of that distribution.
Hope this helps clarify.
John
On Tue, May 19, 2020 at 3:14 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=95208 >
>
> Hello John,
>
> I have another question about "clim_mean" in the config file. I am
not sure
> how to use it. Why do we have to use that for "ensemble_stat" and
> "grid_stat"? What is the relationship of "clim_mean" with "fcst"
and
> "obs"? In my script setup, should I set that to "fcst" or "obs" or
leave it
> blank?
>
> Thank you.
> Binyu
>
>
> On Mon, May 11, 2020 at 7:16 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Binyu,
> >
> > I provided answers inline below.
> >
> > Thanks,
> > John
> >
> > On Mon, May 11, 2020 at 1:51 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=95208 >
> > >
> > > Hello John,
> > >
> > > Thank you for your help. To save your time, let me make more
clear on
> my
> > > new questions. Actually I have a bunch now after spending more
time on
> > > this. Although I did get something but I am not sure it is
correct or
> > not:
> > >
> > > 1. I changed my script and config files. Here is my new script:
> > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/ush/verf_g2g_kasat.sh2
> > > Are "ensemble_stat " and "grid_stat " statements correct?
> > >
> > >
> > I'm working on Venus in
/u/John.H.Gotway/MET/MET_Help/wang_data_20200511
> > Running your script in there reveals lots of warnings like this:
> >
> > *WARNING: MetGrib2DataFile::data_plane() -> Using the first of 60
> matching
> > records for "VAFTD/L20000-0":*
> >
> > This means that ensemble-stat found multiple matching records in
the
> input
> > files. Why? Each one of your GRIB2 model files contains output
for 60
> > different forecast hours. You need to loop over them and process
them
> > separately.
> >
> > I would recommend setting up a METplus use case to handle this
time
> > looping. But to demonstrate an example, I updated your ensemble-
stat
> > config file to reference lead_time = "${LEAD_HR}"; and I updated
your run
> > script to set that variable as 11 hours.
> >
> > And I also updated the Grid-Stat config file to solve this warning
> message:
> >
> > *WARNING: GridStatVxOpt::process_config() -> "nc_pairs_var_str"
((nul))
> is
> > deprecated and replaced by "nc_pairs_var_suffix".*
> >
> > The logs of my running can be seen in:
> > /u/John.H.Gotway/MET/MET_Help/wang_data_20200511/run_es.log and
> run_gs.log
> >
> > Please also look at the two configures files
> > > "verf_g2g_ens_stat_regn_config_kasat" and
> > > "verf_g2g_grid_stat_regn_config_kasat"
> > >
> > > 2. Inside of "verf_g2g_ens_stat_regn_config_kasa", what is the
> > relationship
> > > of "field" included in "fcst" with that in "ens"? Which one
refers to
> > the
> > > real forecast? It seems the one in "fcst" is not used at all
because
> > even
> > > if I change the name "VAFTD" under "fcst" to a new name, there
is no
> > > difference.
> > > e.g: my obs is "ASH_MASS_LOADING", my forecast is "VAFTD", I
want to
> use
> > a
> > > new name "ASH" in the MET_viewer, how to do that?
> > >
> >
> > In the Ensemble-Stat config file, the "ens" dictionary defines the
fields
> > for which you want to derive ensemble mean and probability fields
that
> are
> > written to the output NetCDF file. The "fcst" dictionary defines
the
> > fields for which you want to compute ensemble statistics. If
those are
> the
> > same, you could set "fcst = ens;". Those are not necessarily the
same
> list
> > of fields. In your case they are.
> >
> >
> > > 3 This question is related to the second one: to using
"convert", where
> > to
> > > use it? Under the "field" of "fcst" or "ens"? Here is the unit
> > relationship
> > > of obs and forecast:
> > > obs=1.636*10^18*(forecast)
> > >
> >
> > Both spots. Anytime you data that needs to be converted, you need
to
> > specify the formula for converting it.
> >
> >
> > >
> > > 4. I noticed I got a warning as below while the script is
running, what
> > > does that mean?
> > > .WARNING: GridStatVxOpt::process_config() -> "nc_pairs_var_str"
((nul))
> > is
> > > deprecated and replaced by
> "nc_pairs_var_suffix".
> > >
> > >
> > See answer to 1.
> >
> >
> > > Sorry to ask so many questions. I can not find a similar use of
> > > "PYTHON_NUMPY" from tutorial, so if you could confirm my script
and
> > config
> > > are correct, that will be very very helpful. Let me know if
anything is
> > not
> > > clear.
> > >
> > > Binyu
> > >
> >
> > I understand what you're doing. I would recommend writing output
to
> > different directories using the "-outdir" command line option.
And you
> > really need to loop over the 60 forecast hours and call ensemble-
stat and
> > grid-stat separately for each. You could do that manually with a
shell
> > script, like you're doing now. But it's going to be difficult to
find
> the
> > observation file that is "closest" in time to the forecast valid
time.
> > Instead, METplus already includes logic to handle that.
> >
> > So I'd recommend using METplus instead of your shell script.
While it's
> a
> > big learning curve, it will hopefully make things easier in the
long run.
> >
> > Thanks,
> > John
> >
> >
>
>
------------------------------------------------
Subject: Error with using PYTHON_NUMPY in config file
From: John Halley Gotway
Time: Thu May 21 14:04:10 2020
Binyu,
On to your other questions:
1. There is one thing I forgot to mention: for the satellite obs.
data,
there is ONLY one time ( 20080808 13:40 ) at which the observations
are available in the file. By saying that, should I change the
"lead_time =
"9"? Because the forecasting data (it contains 60- one hourly average
data)
starts at 4:00? We can use "lead_time" to specify the starting time,
is
there a way to specify the ending time? If so then we don't need to
worry
about the 60 different forecast hours. Am I right?
> The MET tools, like Grid-Stat and Ensemble-Stat, are intended to
process
a single timestep of data in each call. Specifying lead_time = 9 is a
way
to extract a single timestep of data.
2. For the question about "ens" and "fcst" in the Ensemble-stat
config
file, is "fcst" a must to get "ens"? I mean do we must define "fcst"
to get
"ens"? If they are not the same, what will be the use of the field?
Can
you give me an example that they are not the same?
> The "ens" dictionary controls what fields are summarized into the
NetCDF
output file. For example, fields for which you can to compute an
ensemble
mean or probability forecast should be listed in "ens".
The "fcst" and "obs" dictionaries control the fields for which
verification
statistics should be computed. For example, those are the field for
which
you want to compute ranked histograms and ensemble spread/skill
information.
3. If I want to have a different name (not in obs./fcst) in the final
output "grid_stat_Kasatochi_090000L_20080808_130000V.stat", what
should I
do with the Ensemble-stat config file or Grid-stat config file?
> Grid-Stat and Ensemble-Stat choose their own output names. You can
configure them by specifying the "output_prefix" entry in the MET
config
file. However there is no way to entirely override them. The only way
to
change it would be to manually rename them via a script after the tool
is
finished running.
4. What is the use of "reference" inside of "verf_g2g_kasat.sh2"? It
seems
some scripts in the example have it, but some don't.
> I tried to log on today to see what you're referring to, but WCOSS
is
down.
John
On Thu, May 21, 2020 at 1:54 PM John Halley Gotway <johnhg at ucar.edu>
wrote:
> Binyu,
>
> Yes, you can leave the climo_mean fields blank in Grid-Stat and
> Ensemble-Stat if you do not need to compare against climatology
data. When
> provided, the climatological mean data is used to compute scalar-
anomaly
> and vector-anomaly partial sums (SAL1L2 and VAL1L2) line types and
> statistics. The most common statistics computed using the climo mean
is the
> anomaly correlation. In addition, the tools can also read
climatological
> standard deviation data. With the mean and spread, we assume a
normal
> distribution of the climatology data and from this distribution we
can
> apply sort the data into climatologically-based bins or define
thresholds
> relative to climatology. For example, ">CDP75" defines a threshold
of being
> greater than the 75th percentile of the climatology at a given
point. Since
> the climo mean and standard deviation change for each point, so too
would
> the actual 75-th percentile of that distribution.
>
> Hope this helps clarify.
>
> John
>
> On Tue, May 19, 2020 at 3:14 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=95208 >
>>
>> Hello John,
>>
>> I have another question about "clim_mean" in the config file. I am
not
>> sure
>> how to use it. Why do we have to use that for "ensemble_stat" and
>> "grid_stat"? What is the relationship of "clim_mean" with "fcst"
and
>> "obs"? In my script setup, should I set that to "fcst" or "obs" or
leave
>> it
>> blank?
>>
>> Thank you.
>> Binyu
>>
>>
>> On Mon, May 11, 2020 at 7:16 PM John Halley Gotway via RT <
>> met_help at ucar.edu>
>> wrote:
>>
>> > Binyu,
>> >
>> > I provided answers inline below.
>> >
>> > Thanks,
>> > John
>> >
>> > On Mon, May 11, 2020 at 1:51 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=95208 >
>> > >
>> > > Hello John,
>> > >
>> > > Thank you for your help. To save your time, let me make more
clear
>> on my
>> > > new questions. Actually I have a bunch now after spending more
time on
>> > > this. Although I did get something but I am not sure it is
correct or
>> > not:
>> > >
>> > > 1. I changed my script and config files. Here is my new script:
>> > >
>> > >
>> >
>>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/ush/verf_g2g_kasat.sh2
>> > > Are "ensemble_stat " and "grid_stat " statements correct?
>> > >
>> > >
>> > I'm working on Venus in
/u/John.H.Gotway/MET/MET_Help/wang_data_20200511
>> > Running your script in there reveals lots of warnings like this:
>> >
>> > *WARNING: MetGrib2DataFile::data_plane() -> Using the first of 60
>> matching
>> > records for "VAFTD/L20000-0":*
>> >
>> > This means that ensemble-stat found multiple matching records in
the
>> input
>> > files. Why? Each one of your GRIB2 model files contains output
for 60
>> > different forecast hours. You need to loop over them and process
them
>> > separately.
>> >
>> > I would recommend setting up a METplus use case to handle this
time
>> > looping. But to demonstrate an example, I updated your ensemble-
stat
>> > config file to reference lead_time = "${LEAD_HR}"; and I updated
your
>> run
>> > script to set that variable as 11 hours.
>> >
>> > And I also updated the Grid-Stat config file to solve this
warning
>> message:
>> >
>> > *WARNING: GridStatVxOpt::process_config() -> "nc_pairs_var_str"
((nul))
>> is
>> > deprecated and replaced by "nc_pairs_var_suffix".*
>> >
>> > The logs of my running can be seen in:
>> > /u/John.H.Gotway/MET/MET_Help/wang_data_20200511/run_es.log and
>> run_gs.log
>> >
>> > Please also look at the two configures files
>> > > "verf_g2g_ens_stat_regn_config_kasat" and
>> > > "verf_g2g_grid_stat_regn_config_kasat"
>> > >
>> > > 2. Inside of "verf_g2g_ens_stat_regn_config_kasa", what is the
>> > relationship
>> > > of "field" included in "fcst" with that in "ens"? Which one
refers to
>> > the
>> > > real forecast? It seems the one in "fcst" is not used at all
because
>> > even
>> > > if I change the name "VAFTD" under "fcst" to a new name, there
is no
>> > > difference.
>> > > e.g: my obs is "ASH_MASS_LOADING", my forecast is "VAFTD", I
want to
>> use
>> > a
>> > > new name "ASH" in the MET_viewer, how to do that?
>> > >
>> >
>> > In the Ensemble-Stat config file, the "ens" dictionary defines
the
>> fields
>> > for which you want to derive ensemble mean and probability fields
that
>> are
>> > written to the output NetCDF file. The "fcst" dictionary defines
the
>> > fields for which you want to compute ensemble statistics. If
those are
>> the
>> > same, you could set "fcst = ens;". Those are not necessarily the
same
>> list
>> > of fields. In your case they are.
>> >
>> >
>> > > 3 This question is related to the second one: to using
"convert",
>> where
>> > to
>> > > use it? Under the "field" of "fcst" or "ens"? Here is the unit
>> > relationship
>> > > of obs and forecast:
>> > > obs=1.636*10^18*(forecast)
>> > >
>> >
>> > Both spots. Anytime you data that needs to be converted, you
need to
>> > specify the formula for converting it.
>> >
>> >
>> > >
>> > > 4. I noticed I got a warning as below while the script is
running,
>> what
>> > > does that mean?
>> > > .WARNING: GridStatVxOpt::process_config() -> "nc_pairs_var_str"
>> ((nul))
>> > is
>> > > deprecated and replaced by
>> "nc_pairs_var_suffix".
>> > >
>> > >
>> > See answer to 1.
>> >
>> >
>> > > Sorry to ask so many questions. I can not find a similar use
of
>> > > "PYTHON_NUMPY" from tutorial, so if you could confirm my script
and
>> > config
>> > > are correct, that will be very very helpful. Let me know if
anything
>> is
>> > not
>> > > clear.
>> > >
>> > > Binyu
>> > >
>> >
>> > I understand what you're doing. I would recommend writing output
to
>> > different directories using the "-outdir" command line option.
And you
>> > really need to loop over the 60 forecast hours and call ensemble-
stat
>> and
>> > grid-stat separately for each. You could do that manually with a
shell
>> > script, like you're doing now. But it's going to be difficult to
find
>> the
>> > observation file that is "closest" in time to the forecast valid
time.
>> > Instead, METplus already includes logic to handle that.
>> >
>> > So I'd recommend using METplus instead of your shell script.
While
>> it's a
>> > big learning curve, it will hopefully make things easier in the
long
>> run.
>> >
>> > Thanks,
>> > John
>> >
>> >
>>
>>
------------------------------------------------
Subject: Error with using PYTHON_NUMPY in config file
From: binyu.wang at noaa.gov
Time: Fri May 22 10:21:26 2020
1. There is one thing I forgot to mention: for the satellite obs.
data,
there is ONLY one time ( 20080808 13:40 ) at which the observations
are available in the file. By saying that, should I change the
"lead_time =
"9"? Because the forecasting data (it contains 60- one hourly average
data)
starts at 4:00? We can use "lead_time" to specify the starting time,
is
there a way to specify the ending time? If so then we don't need to
worry
about the 60 different forecast hours. Am I right?
> The MET tools, like Grid-Stat and Ensemble-Stat, are intended to
process
a single timestep of data in each call. Specifying lead_time = 9 is a
way
to extract a single timestep of data.
-----------------------------------------------------------
John, " process a single timestep of data in each call " means
"Ensemble-stat" ONLY process a single timestep and then stop
automatically?
Or it starts from the "lead_time" and continue from there until it
finish
all the following timestep? If it continues to process all the
following
timestep, is there a function like "end_time" if we only want to
process
the first few timestep (NOT all of them)?
Thank you.
On Thu, May 21, 2020 at 4:04 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binyu,
>
> On to your other questions:
>
> 1. There is one thing I forgot to mention: for the satellite obs.
data,
> there is ONLY one time ( 20080808 13:40 ) at which the observations
> are available in the file. By saying that, should I change the
"lead_time =
> "9"? Because the forecasting data (it contains 60- one hourly
average data)
> starts at 4:00? We can use "lead_time" to specify the starting
time, is
> there a way to specify the ending time? If so then we don't need to
worry
> about the 60 different forecast hours. Am I right?
>
> > The MET tools, like Grid-Stat and Ensemble-Stat, are intended to
process
> a single timestep of data in each call. Specifying lead_time = 9 is
a way
> to extract a single timestep of data.
>
> 2. For the question about "ens" and "fcst" in the Ensemble-stat
config
> file, is "fcst" a must to get "ens"? I mean do we must define "fcst"
to get
> "ens"? If they are not the same, what will be the use of the field?
Can
> you give me an example that they are not the same?
>
> > The "ens" dictionary controls what fields are summarized into the
NetCDF
> output file. For example, fields for which you can to compute an
ensemble
> mean or probability forecast should be listed in "ens".
> The "fcst" and "obs" dictionaries control the fields for which
verification
> statistics should be computed. For example, those are the field for
which
> you want to compute ranked histograms and ensemble spread/skill
> information.
>
> 3. If I want to have a different name (not in obs./fcst) in the
final
> output "grid_stat_Kasatochi_090000L_20080808_130000V.stat", what
should I
> do with the Ensemble-stat config file or Grid-stat config file?
>
> > Grid-Stat and Ensemble-Stat choose their own output names. You
can
> configure them by specifying the "output_prefix" entry in the MET
config
> file. However there is no way to entirely override them. The only
way to
> change it would be to manually rename them via a script after the
tool is
> finished running.
>
> 4. What is the use of "reference" inside of "verf_g2g_kasat.sh2"? It
seems
> some scripts in the example have it, but some don't.
>
> > I tried to log on today to see what you're referring to, but WCOSS
is
> down.
>
> John
>
> On Thu, May 21, 2020 at 1:54 PM John Halley Gotway <johnhg at ucar.edu>
> wrote:
>
> > Binyu,
> >
> > Yes, you can leave the climo_mean fields blank in Grid-Stat and
> > Ensemble-Stat if you do not need to compare against climatology
data.
> When
> > provided, the climatological mean data is used to compute scalar-
anomaly
> > and vector-anomaly partial sums (SAL1L2 and VAL1L2) line types and
> > statistics. The most common statistics computed using the climo
mean is
> the
> > anomaly correlation. In addition, the tools can also read
climatological
> > standard deviation data. With the mean and spread, we assume a
normal
> > distribution of the climatology data and from this distribution we
can
> > apply sort the data into climatologically-based bins or define
thresholds
> > relative to climatology. For example, ">CDP75" defines a threshold
of
> being
> > greater than the 75th percentile of the climatology at a given
point.
> Since
> > the climo mean and standard deviation change for each point, so
too would
> > the actual 75-th percentile of that distribution.
> >
> > Hope this helps clarify.
> >
> > John
> >
> > On Tue, May 19, 2020 at 3:14 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=95208 >
> >>
> >> Hello John,
> >>
> >> I have another question about "clim_mean" in the config file. I
am not
> >> sure
> >> how to use it. Why do we have to use that for "ensemble_stat" and
> >> "grid_stat"? What is the relationship of "clim_mean" with "fcst"
and
> >> "obs"? In my script setup, should I set that to "fcst" or "obs"
or leave
> >> it
> >> blank?
> >>
> >> Thank you.
> >> Binyu
> >>
> >>
> >> On Mon, May 11, 2020 at 7:16 PM John Halley Gotway via RT <
> >> met_help at ucar.edu>
> >> wrote:
> >>
> >> > Binyu,
> >> >
> >> > I provided answers inline below.
> >> >
> >> > Thanks,
> >> > John
> >> >
> >> > On Mon, May 11, 2020 at 1:51 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=95208
>
> >> > >
> >> > > Hello John,
> >> > >
> >> > > Thank you for your help. To save your time, let me make more
clear
> >> on my
> >> > > new questions. Actually I have a bunch now after spending
more time
> on
> >> > > this. Although I did get something but I am not sure it is
correct
> or
> >> > not:
> >> > >
> >> > > 1. I changed my script and config files. Here is my new
script:
> >> > >
> >> > >
> >> >
> >>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/ush/verf_g2g_kasat.sh2
> >> > > Are "ensemble_stat " and "grid_stat " statements correct?
> >> > >
> >> > >
> >> > I'm working on Venus in
> /u/John.H.Gotway/MET/MET_Help/wang_data_20200511
> >> > Running your script in there reveals lots of warnings like
this:
> >> >
> >> > *WARNING: MetGrib2DataFile::data_plane() -> Using the first of
60
> >> matching
> >> > records for "VAFTD/L20000-0":*
> >> >
> >> > This means that ensemble-stat found multiple matching records
in the
> >> input
> >> > files. Why? Each one of your GRIB2 model files contains output
for 60
> >> > different forecast hours. You need to loop over them and
process them
> >> > separately.
> >> >
> >> > I would recommend setting up a METplus use case to handle this
time
> >> > looping. But to demonstrate an example, I updated your
ensemble-stat
> >> > config file to reference lead_time = "${LEAD_HR}"; and I
updated your
> >> run
> >> > script to set that variable as 11 hours.
> >> >
> >> > And I also updated the Grid-Stat config file to solve this
warning
> >> message:
> >> >
> >> > *WARNING: GridStatVxOpt::process_config() -> "nc_pairs_var_str"
> ((nul))
> >> is
> >> > deprecated and replaced by "nc_pairs_var_suffix".*
> >> >
> >> > The logs of my running can be seen in:
> >> > /u/John.H.Gotway/MET/MET_Help/wang_data_20200511/run_es.log and
> >> run_gs.log
> >> >
> >> > Please also look at the two configures files
> >> > > "verf_g2g_ens_stat_regn_config_kasat" and
> >> > > "verf_g2g_grid_stat_regn_config_kasat"
> >> > >
> >> > > 2. Inside of "verf_g2g_ens_stat_regn_config_kasa", what is
the
> >> > relationship
> >> > > of "field" included in "fcst" with that in "ens"? Which one
refers
> to
> >> > the
> >> > > real forecast? It seems the one in "fcst" is not used at all
> because
> >> > even
> >> > > if I change the name "VAFTD" under "fcst" to a new name,
there is no
> >> > > difference.
> >> > > e.g: my obs is "ASH_MASS_LOADING", my forecast is "VAFTD", I
want to
> >> use
> >> > a
> >> > > new name "ASH" in the MET_viewer, how to do that?
> >> > >
> >> >
> >> > In the Ensemble-Stat config file, the "ens" dictionary defines
the
> >> fields
> >> > for which you want to derive ensemble mean and probability
fields that
> >> are
> >> > written to the output NetCDF file. The "fcst" dictionary
defines the
> >> > fields for which you want to compute ensemble statistics. If
those
> are
> >> the
> >> > same, you could set "fcst = ens;". Those are not necessarily
the same
> >> list
> >> > of fields. In your case they are.
> >> >
> >> >
> >> > > 3 This question is related to the second one: to using
"convert",
> >> where
> >> > to
> >> > > use it? Under the "field" of "fcst" or "ens"? Here is the
unit
> >> > relationship
> >> > > of obs and forecast:
> >> > > obs=1.636*10^18*(forecast)
> >> > >
> >> >
> >> > Both spots. Anytime you data that needs to be converted, you
need to
> >> > specify the formula for converting it.
> >> >
> >> >
> >> > >
> >> > > 4. I noticed I got a warning as below while the script is
running,
> >> what
> >> > > does that mean?
> >> > > .WARNING: GridStatVxOpt::process_config() ->
"nc_pairs_var_str"
> >> ((nul))
> >> > is
> >> > > deprecated and replaced by
> >> "nc_pairs_var_suffix".
> >> > >
> >> > >
> >> > See answer to 1.
> >> >
> >> >
> >> > > Sorry to ask so many questions. I can not find a similar use
of
> >> > > "PYTHON_NUMPY" from tutorial, so if you could confirm my
script and
> >> > config
> >> > > are correct, that will be very very helpful. Let me know if
anything
> >> is
> >> > not
> >> > > clear.
> >> > >
> >> > > Binyu
> >> > >
> >> >
> >> > I understand what you're doing. I would recommend writing
output to
> >> > different directories using the "-outdir" command line option.
And
> you
> >> > really need to loop over the 60 forecast hours and call
ensemble-stat
> >> and
> >> > grid-stat separately for each. You could do that manually with
a
> shell
> >> > script, like you're doing now. But it's going to be difficult
to find
> >> the
> >> > observation file that is "closest" in time to the forecast
valid time.
> >> > Instead, METplus already includes logic to handle that.
> >> >
> >> > So I'd recommend using METplus instead of your shell script.
While
> >> it's a
> >> > big learning curve, it will hopefully make things easier in the
long
> >> run.
> >> >
> >> > Thanks,
> >> > John
> >> >
> >> >
> >>
> >>
>
>
------------------------------------------------
Subject: Error with using PYTHON_NUMPY in config file
From: binyu.wang at noaa.gov
Time: Wed May 27 14:33:28 2020
Hello John,
Thank you for helping me to create the grid_stat files. But I had
problems
using those to make plots using METviewer. I attached the Rely plot to
this
email.
Looking back at the "run_gs.log" file in your directory "
/u/John.H.Gotway/
MET/MET_Help/wang_data_20200511/ run_gs.log", there are some warning
like
"Forecast and observation valid times do not match 20080808_150000 !=
20080808_152000", will this be a problem? "20080808_152000" comes
from
" :Last_time = "2008221-152000" in the satellite file, this is NOT
the
real time when the ash data is detected (the only time that ash is
detected
is "2008221-134000"). If the warning is not an issue, why does it
seem
there is ONLY one pair on the "reply" plot while there are more than
360
matching pairs based on the log file.
Another thing, you suggest me to use Metplus, I heard METplus can not
handle ensemble at this moment, am I right?
Thank you.
Binyu
On Mon, May 11, 2020 at 7:16 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binyu,
>
> I provided answers inline below.
>
> Thanks,
> John
>
> On Mon, May 11, 2020 at 1:51 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=95208 >
> >
> > Hello John,
> >
> > Thank you for your help. To save your time, let me make more clear
on my
> > new questions. Actually I have a bunch now after spending more
time on
> > this. Although I did get something but I am not sure it is correct
or
> not:
> >
> > 1. I changed my script and config files. Here is my new script:
> >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/ush/verf_g2g_kasat.sh2
> > Are "ensemble_stat " and "grid_stat " statements correct?
> >
> >
> I'm working on Venus in
/u/John.H.Gotway/MET/MET_Help/wang_data_20200511
> Running your script in there reveals lots of warnings like this:
>
> *WARNING: MetGrib2DataFile::data_plane() -> Using the first of 60
matching
> records for "VAFTD/L20000-0":*
>
> This means that ensemble-stat found multiple matching records in the
input
> files. Why? Each one of your GRIB2 model files contains output for
60
> different forecast hours. You need to loop over them and process
them
> separately.
>
> I would recommend setting up a METplus use case to handle this time
> looping. But to demonstrate an example, I updated your ensemble-
stat
> config file to reference lead_time = "${LEAD_HR}"; and I updated
your run
> script to set that variable as 11 hours.
>
> And I also updated the Grid-Stat config file to solve this warning
message:
>
> *WARNING: GridStatVxOpt::process_config() -> "nc_pairs_var_str"
((nul)) is
> deprecated and replaced by "nc_pairs_var_suffix".*
>
> The logs of my running can be seen in:
> /u/John.H.Gotway/MET/MET_Help/wang_data_20200511/run_es.log and
run_gs.log
>
> Please also look at the two configures files
> > "verf_g2g_ens_stat_regn_config_kasat" and
> > "verf_g2g_grid_stat_regn_config_kasat"
> >
> > 2. Inside of "verf_g2g_ens_stat_regn_config_kasa", what is the
> relationship
> > of "field" included in "fcst" with that in "ens"? Which one
refers to
> the
> > real forecast? It seems the one in "fcst" is not used at all
because
> even
> > if I change the name "VAFTD" under "fcst" to a new name, there is
no
> > difference.
> > e.g: my obs is "ASH_MASS_LOADING", my forecast is "VAFTD", I want
to use
> a
> > new name "ASH" in the MET_viewer, how to do that?
> >
>
> In the Ensemble-Stat config file, the "ens" dictionary defines the
fields
> for which you want to derive ensemble mean and probability fields
that are
> written to the output NetCDF file. The "fcst" dictionary defines
the
> fields for which you want to compute ensemble statistics. If those
are the
> same, you could set "fcst = ens;". Those are not necessarily the
same list
> of fields. In your case they are.
>
>
> > 3 This question is related to the second one: to using "convert",
where
> to
> > use it? Under the "field" of "fcst" or "ens"? Here is the unit
> relationship
> > of obs and forecast:
> > obs=1.636*10^18*(forecast)
> >
>
> Both spots. Anytime you data that needs to be converted, you need
to
> specify the formula for converting it.
>
>
> >
> > 4. I noticed I got a warning as below while the script is running,
what
> > does that mean?
> > .WARNING: GridStatVxOpt::process_config() -> "nc_pairs_var_str"
((nul))
> is
> > deprecated and replaced by
"nc_pairs_var_suffix".
> >
> >
> See answer to 1.
>
>
> > Sorry to ask so many questions. I can not find a similar use of
> > "PYTHON_NUMPY" from tutorial, so if you could confirm my script
and
> config
> > are correct, that will be very very helpful. Let me know if
anything is
> not
> > clear.
> >
> > Binyu
> >
>
> I understand what you're doing. I would recommend writing output to
> different directories using the "-outdir" command line option. And
you
> really need to loop over the 60 forecast hours and call ensemble-
stat and
> grid-stat separately for each. You could do that manually with a
shell
> script, like you're doing now. But it's going to be difficult to
find the
> observation file that is "closest" in time to the forecast valid
time.
> Instead, METplus already includes logic to handle that.
>
> So I'd recommend using METplus instead of your shell script. While
it's a
> big learning curve, it will hopefully make things easier in the long
run.
>
> Thanks,
> John
>
>
------------------------------------------------
Subject: Error with using PYTHON_NUMPY in config file
From: John Halley Gotway
Time: Fri May 29 16:59:01 2020
Binyu,
OK, I'm looking again in
/u/John.H.Gotway/MET/MET_Help/wang_data_20200511
The script (verf_g2g_kasat.sh2) runs Ensemble-Stat to compute a
probability
forecasts from 5 input ensemble members. You configured ensemble-stat
to
define probabilities for:
float VAFTD_L20000-0_ENS_FREQ_le0.5(lat, lon) ;
float VAFTD_L20000-0_ENS_FREQ_gt0.5.and.le1(lat, lon) ;
float VAFTD_L20000-0_ENS_FREQ_gt1.and.le2(lat, lon) ;
float VAFTD_L20000-0_ENS_FREQ_gt2.and.le3(lat, lon) ;
float VAFTD_L20000-0_ENS_FREQ_gt3.and.ge5(lat, lon) ;
float VAFTD_L20000-0_ENS_FREQ_gt5.and.le8(lat, lon) ;
float VAFTD_L20000-0_ENS_FREQ_gt8.and.le10(lat, lon) ;
float VAFTD_L20000-0_ENS_FREQ_gt10(lat, lon) ;
These are rather odd probabilities. For example, the probability of
precipitation is defined by applying a simple threshold of "precip >
0".
In your case, you've defined probabilities of being within these bins.
If
those probabilities are meaningful to you, great. If not, consider
redefining them.
But we verify those probabilities by running Grid-Stat. As you note,
there
are 360 matched pairs. We verify these by populating a 10x2
probabilistic
contingency tables and write those counts out to the PCT line type.
But if
you look closely, all of those 360 matched pairs fall within the first
of
the 10 bins:
grep PCT
out/grid_stat/grid_stat_Kasatochi_090000L_20080808_130000V.stat
So that means the forecast probability values were always between 0
and
0.1. Since you only have 5 input ensemble members, the only possible
probability values are 0, 0.2, 0.4, 0.6, 0.8, and 1.0. So all the
forecast
probability values are 0.
And when you finally get to the point of plotting data in METviewer,
you're
only seeing a dot for a probability value of 0.05. METviewer is
plotting
the mid-point of the first bin (0.05 is the mid-point of the 0 to 0.1
bin). You only get a dot there because that's the only bin where you
have
non-zero data.
I'd recommend taking a step back to make sure that your forecast data
and
observation data overlap in time and space. I ran MET's
plot_data_plane on
the output from ensemble-stat and see that all of the probability
values
are 0 (see attached):
*plot_data_plane
out/ensemble_stat/ensemble_stat_volc_20080808_150000V_ens.nc
ens_VAFTD_prob.ps 'name="VAFTD_L20000-0_ENS_FREQ_gt0.5.and.le1";
level="(*,*)";'*
So step back and plot data from one of the input ensemble members for
ensemble-stat (see attached):
*plot_data_plane
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3/cgrib2.001
cgrib2.001_VAFTD.ps <http://cgrib2.001_VAFTD.ps> 'name="VAFTD"; level
=
"L0-20000"; convert\(x\)=1.636*10^18*\(x\); lead_time="12";'*
If you look at the crazy range of values shown in the colorbar, you
can see
why the event never occurs... and so you always have 0 probabilities!
I'm guessing that conversion function you're using is causing the
problem.
So I reran plot_data_plane without it (see attached):
*plot_data_plane
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3/cgrib2.001
cgrib2.001_VAFTD_no_convert.ps <http://cgrib2.001_VAFTD_no_convert.ps>
'name="VAFTD"; level = "L0-20000"; lead_time="12";'*
The values of -13 to -99 seem like a more reasonable range.
I'd recommend working on your convert function to put the forecast and
observation data into the same units.
John
On Wed, May 27, 2020 at 2:34 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=95208 >
>
> Hello John,
>
> Thank you for helping me to create the grid_stat files. But I had
problems
> using those to make plots using METviewer. I attached the Rely plot
to this
> email.
>
> Looking back at the "run_gs.log" file in your directory "
/u/John.H.Gotway/
> MET/MET_Help/wang_data_20200511/ run_gs.log", there are some warning
like
> "Forecast and observation valid times do not match 20080808_150000
!=
> 20080808_152000", will this be a problem? "20080808_152000" comes
from
> " :Last_time = "2008221-152000" in the satellite file, this is NOT
the
> real time when the ash data is detected (the only time that ash is
detected
> is "2008221-134000"). If the warning is not an issue, why does it
seem
> there is ONLY one pair on the "reply" plot while there are more than
360
> matching pairs based on the log file.
>
> Another thing, you suggest me to use Metplus, I heard METplus can
not
> handle ensemble at this moment, am I right?
>
> Thank you.
> Binyu
>
>
>
> On Mon, May 11, 2020 at 7:16 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Binyu,
> >
> > I provided answers inline below.
> >
> > Thanks,
> > John
> >
> > On Mon, May 11, 2020 at 1:51 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=95208 >
> > >
> > > Hello John,
> > >
> > > Thank you for your help. To save your time, let me make more
clear on
> my
> > > new questions. Actually I have a bunch now after spending more
time on
> > > this. Although I did get something but I am not sure it is
correct or
> > not:
> > >
> > > 1. I changed my script and config files. Here is my new script:
> > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/ush/verf_g2g_kasat.sh2
> > > Are "ensemble_stat " and "grid_stat " statements correct?
> > >
> > >
> > I'm working on Venus in
/u/John.H.Gotway/MET/MET_Help/wang_data_20200511
> > Running your script in there reveals lots of warnings like this:
> >
> > *WARNING: MetGrib2DataFile::data_plane() -> Using the first of 60
> matching
> > records for "VAFTD/L20000-0":*
> >
> > This means that ensemble-stat found multiple matching records in
the
> input
> > files. Why? Each one of your GRIB2 model files contains output
for 60
> > different forecast hours. You need to loop over them and process
them
> > separately.
> >
> > I would recommend setting up a METplus use case to handle this
time
> > looping. But to demonstrate an example, I updated your ensemble-
stat
> > config file to reference lead_time = "${LEAD_HR}"; and I updated
your run
> > script to set that variable as 11 hours.
> >
> > And I also updated the Grid-Stat config file to solve this warning
> message:
> >
> > *WARNING: GridStatVxOpt::process_config() -> "nc_pairs_var_str"
((nul))
> is
> > deprecated and replaced by "nc_pairs_var_suffix".*
> >
> > The logs of my running can be seen in:
> > /u/John.H.Gotway/MET/MET_Help/wang_data_20200511/run_es.log and
> run_gs.log
> >
> > Please also look at the two configures files
> > > "verf_g2g_ens_stat_regn_config_kasat" and
> > > "verf_g2g_grid_stat_regn_config_kasat"
> > >
> > > 2. Inside of "verf_g2g_ens_stat_regn_config_kasa", what is the
> > relationship
> > > of "field" included in "fcst" with that in "ens"? Which one
refers to
> > the
> > > real forecast? It seems the one in "fcst" is not used at all
because
> > even
> > > if I change the name "VAFTD" under "fcst" to a new name, there
is no
> > > difference.
> > > e.g: my obs is "ASH_MASS_LOADING", my forecast is "VAFTD", I
want to
> use
> > a
> > > new name "ASH" in the MET_viewer, how to do that?
> > >
> >
> > In the Ensemble-Stat config file, the "ens" dictionary defines the
fields
> > for which you want to derive ensemble mean and probability fields
that
> are
> > written to the output NetCDF file. The "fcst" dictionary defines
the
> > fields for which you want to compute ensemble statistics. If
those are
> the
> > same, you could set "fcst = ens;". Those are not necessarily the
same
> list
> > of fields. In your case they are.
> >
> >
> > > 3 This question is related to the second one: to using
"convert", where
> > to
> > > use it? Under the "field" of "fcst" or "ens"? Here is the unit
> > relationship
> > > of obs and forecast:
> > > obs=1.636*10^18*(forecast)
> > >
> >
> > Both spots. Anytime you data that needs to be converted, you need
to
> > specify the formula for converting it.
> >
> >
> > >
> > > 4. I noticed I got a warning as below while the script is
running, what
> > > does that mean?
> > > .WARNING: GridStatVxOpt::process_config() -> "nc_pairs_var_str"
((nul))
> > is
> > > deprecated and replaced by
> "nc_pairs_var_suffix".
> > >
> > >
> > See answer to 1.
> >
> >
> > > Sorry to ask so many questions. I can not find a similar use of
> > > "PYTHON_NUMPY" from tutorial, so if you could confirm my script
and
> > config
> > > are correct, that will be very very helpful. Let me know if
anything is
> > not
> > > clear.
> > >
> > > Binyu
> > >
> >
> > I understand what you're doing. I would recommend writing output
to
> > different directories using the "-outdir" command line option.
And you
> > really need to loop over the 60 forecast hours and call ensemble-
stat and
> > grid-stat separately for each. You could do that manually with a
shell
> > script, like you're doing now. But it's going to be difficult to
find
> the
> > observation file that is "closest" in time to the forecast valid
time.
> > Instead, METplus already includes logic to handle that.
> >
> > So I'd recommend using METplus instead of your shell script.
While it's
> a
> > big learning curve, it will hopefully make things easier in the
long run.
> >
> > Thanks,
> > John
> >
> >
>
>
------------------------------------------------
Subject: Error with using PYTHON_NUMPY in config file
From: binyu.wang at noaa.gov
Time: Thu Jun 04 10:28:08 2020
John,
Based on your suggestion, I did figure out the problem: my forecast
data
used in the MET is already processed (LOGx), so I need to add (10^(x))
into
the convert formula. (Old: 1.636*10^17*(x);
New:1.636*10^17*(10^(x));The
plots look reasonable after I made the change. Thank you for your
suggestion.
At the same time, I do get another question: do I also need to add the
same
formula converter for "climo_mean" as below or it is not necessary?
climo_mean = fcst;
climo_mean = {
file_name = "${REFERENCE}";
* convert(x) = 1.636*10^17*(10^(x));*
time_interp_method = DW_MEAN;
match_day = FALSE;
time_step = 1;
}
Thank you.
Binyu
On Fri, May 29, 2020 at 6:59 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binyu,
>
> OK, I'm looking again in
/u/John.H.Gotway/MET/MET_Help/wang_data_20200511
>
> The script (verf_g2g_kasat.sh2) runs Ensemble-Stat to compute a
probability
> forecasts from 5 input ensemble members. You configured ensemble-
stat to
> define probabilities for:
>
> float VAFTD_L20000-0_ENS_FREQ_le0.5(lat, lon) ;
> float VAFTD_L20000-0_ENS_FREQ_gt0.5.and.le1(lat, lon) ;
> float VAFTD_L20000-0_ENS_FREQ_gt1.and.le2(lat, lon) ;
> float VAFTD_L20000-0_ENS_FREQ_gt2.and.le3(lat, lon) ;
> float VAFTD_L20000-0_ENS_FREQ_gt3.and.ge5(lat, lon) ;
> float VAFTD_L20000-0_ENS_FREQ_gt5.and.le8(lat, lon) ;
> float VAFTD_L20000-0_ENS_FREQ_gt8.and.le10(lat, lon) ;
> float VAFTD_L20000-0_ENS_FREQ_gt10(lat, lon) ;
>
> These are rather odd probabilities. For example, the probability of
> precipitation is defined by applying a simple threshold of "precip >
0".
> In your case, you've defined probabilities of being within these
bins. If
> those probabilities are meaningful to you, great. If not, consider
> redefining them.
>
> But we verify those probabilities by running Grid-Stat. As you note,
there
> are 360 matched pairs. We verify these by populating a 10x2
probabilistic
> contingency tables and write those counts out to the PCT line type.
But if
> you look closely, all of those 360 matched pairs fall within the
first of
> the 10 bins:
>
> grep PCT
out/grid_stat/grid_stat_Kasatochi_090000L_20080808_130000V.stat
>
> So that means the forecast probability values were always between 0
and
> 0.1. Since you only have 5 input ensemble members, the only possible
> probability values are 0, 0.2, 0.4, 0.6, 0.8, and 1.0. So all the
forecast
> probability values are 0.
>
> And when you finally get to the point of plotting data in METviewer,
you're
> only seeing a dot for a probability value of 0.05. METviewer is
plotting
> the mid-point of the first bin (0.05 is the mid-point of the 0 to
0.1
> bin). You only get a dot there because that's the only bin where
you have
> non-zero data.
>
> I'd recommend taking a step back to make sure that your forecast
data and
> observation data overlap in time and space. I ran MET's
plot_data_plane on
> the output from ensemble-stat and see that all of the probability
values
> are 0 (see attached):
>
> *plot_data_plane
> out/ensemble_stat/ensemble_stat_volc_20080808_150000V_ens.nc
> ens_VAFTD_prob.ps 'name="VAFTD_L20000-0_ENS_FREQ_gt0.5.and.le1";
> level="(*,*)";'*
>
> So step back and plot data from one of the input ensemble members
for
> ensemble-stat (see attached):
>
> *plot_data_plane
>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3/cgrib2.001
> cgrib2.001_VAFTD.ps <http://cgrib2.001_VAFTD.ps> 'name="VAFTD";
level =
> "L0-20000"; convert\(x\)=1.636*10^18*\(x\); lead_time="12";'*
>
> If you look at the crazy range of values shown in the colorbar, you
can see
> why the event never occurs... and so you always have 0
probabilities!
>
> I'm guessing that conversion function you're using is causing the
problem.
> So I reran plot_data_plane without it (see attached):
>
> *plot_data_plane
>
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3/cgrib2.001
> cgrib2.001_VAFTD_no_convert.ps
<http://cgrib2.001_VAFTD_no_convert.ps>
> 'name="VAFTD"; level = "L0-20000"; lead_time="12";'*
>
> The values of -13 to -99 seem like a more reasonable range.
>
> I'd recommend working on your convert function to put the forecast
and
> observation data into the same units.
>
> John
>
>
> On Wed, May 27, 2020 at 2:34 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=95208 >
> >
> > Hello John,
> >
> > Thank you for helping me to create the grid_stat files. But I had
> problems
> > using those to make plots using METviewer. I attached the Rely
plot to
> this
> > email.
> >
> > Looking back at the "run_gs.log" file in your directory "
> /u/John.H.Gotway/
> > MET/MET_Help/wang_data_20200511/ run_gs.log", there are some
warning like
> > "Forecast and observation valid times do not match 20080808_150000
!=
> > 20080808_152000", will this be a problem? "20080808_152000"
comes from
> > " :Last_time = "2008221-152000" in the satellite file, this is
NOT the
> > real time when the ash data is detected (the only time that ash is
> detected
> > is "2008221-134000"). If the warning is not an issue, why does it
seem
> > there is ONLY one pair on the "reply" plot while there are more
than 360
> > matching pairs based on the log file.
> >
> > Another thing, you suggest me to use Metplus, I heard METplus can
not
> > handle ensemble at this moment, am I right?
> >
> > Thank you.
> > Binyu
> >
> >
> >
> > On Mon, May 11, 2020 at 7:16 PM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > Binyu,
> > >
> > > I provided answers inline below.
> > >
> > > Thanks,
> > > John
> > >
> > > On Mon, May 11, 2020 at 1:51 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=95208
>
> > > >
> > > > Hello John,
> > > >
> > > > Thank you for your help. To save your time, let me make more
clear on
> > my
> > > > new questions. Actually I have a bunch now after spending more
time
> on
> > > > this. Although I did get something but I am not sure it is
correct or
> > > not:
> > > >
> > > > 1. I changed my script and config files. Here is my new
script:
> > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/ush/verf_g2g_kasat.sh2
> > > > Are "ensemble_stat " and "grid_stat " statements correct?
> > > >
> > > >
> > > I'm working on Venus in
> /u/John.H.Gotway/MET/MET_Help/wang_data_20200511
> > > Running your script in there reveals lots of warnings like this:
> > >
> > > *WARNING: MetGrib2DataFile::data_plane() -> Using the first of
60
> > matching
> > > records for "VAFTD/L20000-0":*
> > >
> > > This means that ensemble-stat found multiple matching records in
the
> > input
> > > files. Why? Each one of your GRIB2 model files contains output
for 60
> > > different forecast hours. You need to loop over them and
process them
> > > separately.
> > >
> > > I would recommend setting up a METplus use case to handle this
time
> > > looping. But to demonstrate an example, I updated your
ensemble-stat
> > > config file to reference lead_time = "${LEAD_HR}"; and I updated
your
> run
> > > script to set that variable as 11 hours.
> > >
> > > And I also updated the Grid-Stat config file to solve this
warning
> > message:
> > >
> > > *WARNING: GridStatVxOpt::process_config() -> "nc_pairs_var_str"
((nul))
> > is
> > > deprecated and replaced by "nc_pairs_var_suffix".*
> > >
> > > The logs of my running can be seen in:
> > > /u/John.H.Gotway/MET/MET_Help/wang_data_20200511/run_es.log and
> > run_gs.log
> > >
> > > Please also look at the two configures files
> > > > "verf_g2g_ens_stat_regn_config_kasat" and
> > > > "verf_g2g_grid_stat_regn_config_kasat"
> > > >
> > > > 2. Inside of "verf_g2g_ens_stat_regn_config_kasa", what is the
> > > relationship
> > > > of "field" included in "fcst" with that in "ens"? Which one
refers
> to
> > > the
> > > > real forecast? It seems the one in "fcst" is not used at all
because
> > > even
> > > > if I change the name "VAFTD" under "fcst" to a new name, there
is no
> > > > difference.
> > > > e.g: my obs is "ASH_MASS_LOADING", my forecast is "VAFTD", I
want to
> > use
> > > a
> > > > new name "ASH" in the MET_viewer, how to do that?
> > > >
> > >
> > > In the Ensemble-Stat config file, the "ens" dictionary defines
the
> fields
> > > for which you want to derive ensemble mean and probability
fields that
> > are
> > > written to the output NetCDF file. The "fcst" dictionary
defines the
> > > fields for which you want to compute ensemble statistics. If
those are
> > the
> > > same, you could set "fcst = ens;". Those are not necessarily the
same
> > list
> > > of fields. In your case they are.
> > >
> > >
> > > > 3 This question is related to the second one: to using
"convert",
> where
> > > to
> > > > use it? Under the "field" of "fcst" or "ens"? Here is the unit
> > > relationship
> > > > of obs and forecast:
> > > > obs=1.636*10^18*(forecast)
> > > >
> > >
> > > Both spots. Anytime you data that needs to be converted, you
need to
> > > specify the formula for converting it.
> > >
> > >
> > > >
> > > > 4. I noticed I got a warning as below while the script is
running,
> what
> > > > does that mean?
> > > > .WARNING: GridStatVxOpt::process_config() ->
"nc_pairs_var_str"
> ((nul))
> > > is
> > > > deprecated and replaced by
> > "nc_pairs_var_suffix".
> > > >
> > > >
> > > See answer to 1.
> > >
> > >
> > > > Sorry to ask so many questions. I can not find a similar use
of
> > > > "PYTHON_NUMPY" from tutorial, so if you could confirm my
script and
> > > config
> > > > are correct, that will be very very helpful. Let me know if
anything
> is
> > > not
> > > > clear.
> > > >
> > > > Binyu
> > > >
> > >
> > > I understand what you're doing. I would recommend writing output
to
> > > different directories using the "-outdir" command line option.
And you
> > > really need to loop over the 60 forecast hours and call
ensemble-stat
> and
> > > grid-stat separately for each. You could do that manually with
a shell
> > > script, like you're doing now. But it's going to be difficult
to find
> > the
> > > observation file that is "closest" in time to the forecast valid
time.
> > > Instead, METplus already includes logic to handle that.
> > >
> > > So I'd recommend using METplus instead of your shell script.
While
> it's
> > a
> > > big learning curve, it will hopefully make things easier in the
long
> run.
> > >
> > > Thanks,
> > > John
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Error with using PYTHON_NUMPY in config file
From: John Halley Gotway
Time: Thu Jun 04 10:40:23 2020
Binyu,
If the same conversion function needs to be applied to the climo data,
then
yes, it needs to be specified there as well. The forecast data is read
and
processed separately from the climo mean data.
John
On Thu, Jun 4, 2020 at 10:28 AM binyu.wang at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95208 >
>
> John,
>
> Based on your suggestion, I did figure out the problem: my forecast
data
> used in the MET is already processed (LOGx), so I need to add
(10^(x)) into
> the convert formula. (Old: 1.636*10^17*(x);
New:1.636*10^17*(10^(x));The
> plots look reasonable after I made the change. Thank you for your
> suggestion.
>
> At the same time, I do get another question: do I also need to add
the same
> formula converter for "climo_mean" as below or it is not necessary?
>
>
> climo_mean = fcst;
> climo_mean = {
> file_name = "${REFERENCE}";
> * convert(x) = 1.636*10^17*(10^(x));*
> time_interp_method = DW_MEAN;
> match_day = FALSE;
> time_step = 1;
> }
>
> Thank you.
> Binyu
>
>
> On Fri, May 29, 2020 at 6:59 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Binyu,
> >
> > OK, I'm looking again in
/u/John.H.Gotway/MET/MET_Help/wang_data_20200511
> >
> > The script (verf_g2g_kasat.sh2) runs Ensemble-Stat to compute a
> probability
> > forecasts from 5 input ensemble members. You configured ensemble-
stat to
> > define probabilities for:
> >
> > float VAFTD_L20000-0_ENS_FREQ_le0.5(lat, lon) ;
> > float VAFTD_L20000-0_ENS_FREQ_gt0.5.and.le1(lat, lon) ;
> > float VAFTD_L20000-0_ENS_FREQ_gt1.and.le2(lat, lon) ;
> > float VAFTD_L20000-0_ENS_FREQ_gt2.and.le3(lat, lon) ;
> > float VAFTD_L20000-0_ENS_FREQ_gt3.and.ge5(lat, lon) ;
> > float VAFTD_L20000-0_ENS_FREQ_gt5.and.le8(lat, lon) ;
> > float VAFTD_L20000-0_ENS_FREQ_gt8.and.le10(lat, lon) ;
> > float VAFTD_L20000-0_ENS_FREQ_gt10(lat, lon) ;
> >
> > These are rather odd probabilities. For example, the probability
of
> > precipitation is defined by applying a simple threshold of "precip
> 0".
> > In your case, you've defined probabilities of being within these
bins. If
> > those probabilities are meaningful to you, great. If not, consider
> > redefining them.
> >
> > But we verify those probabilities by running Grid-Stat. As you
note,
> there
> > are 360 matched pairs. We verify these by populating a 10x2
probabilistic
> > contingency tables and write those counts out to the PCT line
type. But
> if
> > you look closely, all of those 360 matched pairs fall within the
first of
> > the 10 bins:
> >
> > grep PCT
out/grid_stat/grid_stat_Kasatochi_090000L_20080808_130000V.stat
> >
> > So that means the forecast probability values were always between
0 and
> > 0.1. Since you only have 5 input ensemble members, the only
possible
> > probability values are 0, 0.2, 0.4, 0.6, 0.8, and 1.0. So all the
> forecast
> > probability values are 0.
> >
> > And when you finally get to the point of plotting data in
METviewer,
> you're
> > only seeing a dot for a probability value of 0.05. METviewer is
plotting
> > the mid-point of the first bin (0.05 is the mid-point of the 0 to
0.1
> > bin). You only get a dot there because that's the only bin where
you
> have
> > non-zero data.
> >
> > I'd recommend taking a step back to make sure that your forecast
data and
> > observation data overlap in time and space. I ran MET's
plot_data_plane
> on
> > the output from ensemble-stat and see that all of the probability
values
> > are 0 (see attached):
> >
> > *plot_data_plane
> > out/ensemble_stat/ensemble_stat_volc_20080808_150000V_ens.nc
> > ens_VAFTD_prob.ps 'name="VAFTD_L20000-0_ENS_FREQ_gt0.5.and.le1";
> > level="(*,*)";'*
> >
> > So step back and plot data from one of the input ensemble members
for
> > ensemble-stat (see attached):
> >
> > *plot_data_plane
> >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3/cgrib2.001
> > cgrib2.001_VAFTD.ps <http://cgrib2.001_VAFTD.ps> 'name="VAFTD";
level =
> > "L0-20000"; convert\(x\)=1.636*10^18*\(x\); lead_time="12";'*
> >
> > If you look at the crazy range of values shown in the colorbar,
you can
> see
> > why the event never occurs... and so you always have 0
probabilities!
> >
> > I'm guessing that conversion function you're using is causing the
> problem.
> > So I reran plot_data_plane without it (see attached):
> >
> > *plot_data_plane
> >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3/cgrib2.001
> > cgrib2.001_VAFTD_no_convert.ps
<http://cgrib2.001_VAFTD_no_convert.ps>
> > 'name="VAFTD"; level = "L0-20000"; lead_time="12";'*
> >
> > The values of -13 to -99 seem like a more reasonable range.
> >
> > I'd recommend working on your convert function to put the forecast
and
> > observation data into the same units.
> >
> > John
> >
> >
> > On Wed, May 27, 2020 at 2:34 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=95208 >
> > >
> > > Hello John,
> > >
> > > Thank you for helping me to create the grid_stat files. But I
had
> > problems
> > > using those to make plots using METviewer. I attached the Rely
plot to
> > this
> > > email.
> > >
> > > Looking back at the "run_gs.log" file in your directory "
> > /u/John.H.Gotway/
> > > MET/MET_Help/wang_data_20200511/ run_gs.log", there are some
warning
> like
> > > "Forecast and observation valid times do not match
20080808_150000 !=
> > > 20080808_152000", will this be a problem? "20080808_152000"
comes
> from
> > > " :Last_time = "2008221-152000" in the satellite file, this is
NOT the
> > > real time when the ash data is detected (the only time that ash
is
> > detected
> > > is "2008221-134000"). If the warning is not an issue, why does
it seem
> > > there is ONLY one pair on the "reply" plot while there are more
than
> 360
> > > matching pairs based on the log file.
> > >
> > > Another thing, you suggest me to use Metplus, I heard METplus
can not
> > > handle ensemble at this moment, am I right?
> > >
> > > Thank you.
> > > Binyu
> > >
> > >
> > >
> > > On Mon, May 11, 2020 at 7:16 PM John Halley Gotway via RT <
> > > met_help at ucar.edu>
> > > wrote:
> > >
> > > > Binyu,
> > > >
> > > > I provided answers inline below.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > > On Mon, May 11, 2020 at 1:51 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=95208 >
> > > > >
> > > > > Hello John,
> > > > >
> > > > > Thank you for your help. To save your time, let me make more
clear
> on
> > > my
> > > > > new questions. Actually I have a bunch now after spending
more time
> > on
> > > > > this. Although I did get something but I am not sure it is
correct
> or
> > > > not:
> > > > >
> > > > > 1. I changed my script and config files. Here is my new
script:
> > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/ush/verf_g2g_kasat.sh2
> > > > > Are "ensemble_stat " and "grid_stat " statements correct?
> > > > >
> > > > >
> > > > I'm working on Venus in
> > /u/John.H.Gotway/MET/MET_Help/wang_data_20200511
> > > > Running your script in there reveals lots of warnings like
this:
> > > >
> > > > *WARNING: MetGrib2DataFile::data_plane() -> Using the first of
60
> > > matching
> > > > records for "VAFTD/L20000-0":*
> > > >
> > > > This means that ensemble-stat found multiple matching records
in the
> > > input
> > > > files. Why? Each one of your GRIB2 model files contains
output for
> 60
> > > > different forecast hours. You need to loop over them and
process
> them
> > > > separately.
> > > >
> > > > I would recommend setting up a METplus use case to handle this
time
> > > > looping. But to demonstrate an example, I updated your
ensemble-stat
> > > > config file to reference lead_time = "${LEAD_HR}"; and I
updated your
> > run
> > > > script to set that variable as 11 hours.
> > > >
> > > > And I also updated the Grid-Stat config file to solve this
warning
> > > message:
> > > >
> > > > *WARNING: GridStatVxOpt::process_config() ->
"nc_pairs_var_str"
> ((nul))
> > > is
> > > > deprecated and replaced by "nc_pairs_var_suffix".*
> > > >
> > > > The logs of my running can be seen in:
> > > > /u/John.H.Gotway/MET/MET_Help/wang_data_20200511/run_es.log
and
> > > run_gs.log
> > > >
> > > > Please also look at the two configures files
> > > > > "verf_g2g_ens_stat_regn_config_kasat" and
> > > > > "verf_g2g_grid_stat_regn_config_kasat"
> > > > >
> > > > > 2. Inside of "verf_g2g_ens_stat_regn_config_kasa", what is
the
> > > > relationship
> > > > > of "field" included in "fcst" with that in "ens"? Which one
refers
> > to
> > > > the
> > > > > real forecast? It seems the one in "fcst" is not used at
all
> because
> > > > even
> > > > > if I change the name "VAFTD" under "fcst" to a new name,
there is
> no
> > > > > difference.
> > > > > e.g: my obs is "ASH_MASS_LOADING", my forecast is "VAFTD", I
want
> to
> > > use
> > > > a
> > > > > new name "ASH" in the MET_viewer, how to do that?
> > > > >
> > > >
> > > > In the Ensemble-Stat config file, the "ens" dictionary defines
the
> > fields
> > > > for which you want to derive ensemble mean and probability
fields
> that
> > > are
> > > > written to the output NetCDF file. The "fcst" dictionary
defines the
> > > > fields for which you want to compute ensemble statistics. If
those
> are
> > > the
> > > > same, you could set "fcst = ens;". Those are not necessarily
the same
> > > list
> > > > of fields. In your case they are.
> > > >
> > > >
> > > > > 3 This question is related to the second one: to using
"convert",
> > where
> > > > to
> > > > > use it? Under the "field" of "fcst" or "ens"? Here is the
unit
> > > > relationship
> > > > > of obs and forecast:
> > > > > obs=1.636*10^18*(forecast)
> > > > >
> > > >
> > > > Both spots. Anytime you data that needs to be converted, you
need to
> > > > specify the formula for converting it.
> > > >
> > > >
> > > > >
> > > > > 4. I noticed I got a warning as below while the script is
running,
> > what
> > > > > does that mean?
> > > > > .WARNING: GridStatVxOpt::process_config() ->
"nc_pairs_var_str"
> > ((nul))
> > > > is
> > > > > deprecated and replaced by
> > > "nc_pairs_var_suffix".
> > > > >
> > > > >
> > > > See answer to 1.
> > > >
> > > >
> > > > > Sorry to ask so many questions. I can not find a similar
use of
> > > > > "PYTHON_NUMPY" from tutorial, so if you could confirm my
script and
> > > > config
> > > > > are correct, that will be very very helpful. Let me know if
> anything
> > is
> > > > not
> > > > > clear.
> > > > >
> > > > > Binyu
> > > > >
> > > >
> > > > I understand what you're doing. I would recommend writing
output to
> > > > different directories using the "-outdir" command line option.
And
> you
> > > > really need to loop over the 60 forecast hours and call
ensemble-stat
> > and
> > > > grid-stat separately for each. You could do that manually
with a
> shell
> > > > script, like you're doing now. But it's going to be difficult
to
> find
> > > the
> > > > observation file that is "closest" in time to the forecast
valid
> time.
> > > > Instead, METplus already includes logic to handle that.
> > > >
> > > > So I'd recommend using METplus instead of your shell script.
While
> > it's
> > > a
> > > > big learning curve, it will hopefully make things easier in
the long
> > run.
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Error with using PYTHON_NUMPY in config file
From: binyu.wang at noaa.gov
Time: Thu Jun 04 13:55:07 2020
Thank you for your quick response. John.
I have another question about the grid_stat table (see the
attachment): if
you check columns T (FCST_THRESH) and U (OBS_THRESH)), why the thresh
for
FCST and OBS don't match each other?
They always match each other on the same line for non-ensemble cases.
Binyu
On Thu, Jun 4, 2020 at 12:40 PM John Halley Gotway via RT
<met_help at ucar.edu>
wrote:
> Binyu,
>
> If the same conversion function needs to be applied to the climo
data, then
> yes, it needs to be specified there as well. The forecast data is
read and
> processed separately from the climo mean data.
>
> John
>
> On Thu, Jun 4, 2020 at 10:28 AM binyu.wang at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95208 >
> >
> > John,
> >
> > Based on your suggestion, I did figure out the problem: my
forecast data
> > used in the MET is already processed (LOGx), so I need to add
(10^(x))
> into
> > the convert formula. (Old: 1.636*10^17*(x);
New:1.636*10^17*(10^(x));The
> > plots look reasonable after I made the change. Thank you for your
> > suggestion.
> >
> > At the same time, I do get another question: do I also need to add
the
> same
> > formula converter for "climo_mean" as below or it is not
necessary?
> >
> >
> > climo_mean = fcst;
> > climo_mean = {
> > file_name = "${REFERENCE}";
> > * convert(x) = 1.636*10^17*(10^(x));*
> > time_interp_method = DW_MEAN;
> > match_day = FALSE;
> > time_step = 1;
> > }
> >
> > Thank you.
> > Binyu
> >
> >
> > On Fri, May 29, 2020 at 6:59 PM John Halley Gotway via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > > Binyu,
> > >
> > > OK, I'm looking again in
> /u/John.H.Gotway/MET/MET_Help/wang_data_20200511
> > >
> > > The script (verf_g2g_kasat.sh2) runs Ensemble-Stat to compute a
> > probability
> > > forecasts from 5 input ensemble members. You configured
ensemble-stat
> to
> > > define probabilities for:
> > >
> > > float VAFTD_L20000-0_ENS_FREQ_le0.5(lat, lon) ;
> > > float VAFTD_L20000-0_ENS_FREQ_gt0.5.and.le1(lat, lon) ;
> > > float VAFTD_L20000-0_ENS_FREQ_gt1.and.le2(lat, lon) ;
> > > float VAFTD_L20000-0_ENS_FREQ_gt2.and.le3(lat, lon) ;
> > > float VAFTD_L20000-0_ENS_FREQ_gt3.and.ge5(lat, lon) ;
> > > float VAFTD_L20000-0_ENS_FREQ_gt5.and.le8(lat, lon) ;
> > > float VAFTD_L20000-0_ENS_FREQ_gt8.and.le10(lat, lon) ;
> > > float VAFTD_L20000-0_ENS_FREQ_gt10(lat, lon) ;
> > >
> > > These are rather odd probabilities. For example, the probability
of
> > > precipitation is defined by applying a simple threshold of
"precip >
> 0".
> > > In your case, you've defined probabilities of being within these
bins.
> If
> > > those probabilities are meaningful to you, great. If not,
consider
> > > redefining them.
> > >
> > > But we verify those probabilities by running Grid-Stat. As you
note,
> > there
> > > are 360 matched pairs. We verify these by populating a 10x2
> probabilistic
> > > contingency tables and write those counts out to the PCT line
type. But
> > if
> > > you look closely, all of those 360 matched pairs fall within the
first
> of
> > > the 10 bins:
> > >
> > > grep PCT
> out/grid_stat/grid_stat_Kasatochi_090000L_20080808_130000V.stat
> > >
> > > So that means the forecast probability values were always
between 0 and
> > > 0.1. Since you only have 5 input ensemble members, the only
possible
> > > probability values are 0, 0.2, 0.4, 0.6, 0.8, and 1.0. So all
the
> > forecast
> > > probability values are 0.
> > >
> > > And when you finally get to the point of plotting data in
METviewer,
> > you're
> > > only seeing a dot for a probability value of 0.05. METviewer is
> plotting
> > > the mid-point of the first bin (0.05 is the mid-point of the 0
to 0.1
> > > bin). You only get a dot there because that's the only bin
where you
> > have
> > > non-zero data.
> > >
> > > I'd recommend taking a step back to make sure that your forecast
data
> and
> > > observation data overlap in time and space. I ran MET's
plot_data_plane
> > on
> > > the output from ensemble-stat and see that all of the
probability
> values
> > > are 0 (see attached):
> > >
> > > *plot_data_plane
> > > out/ensemble_stat/ensemble_stat_volc_20080808_150000V_ens.nc
> > > ens_VAFTD_prob.ps 'name="VAFTD_L20000-0_ENS_FREQ_gt0.5.and.le1";
> > > level="(*,*)";'*
> > >
> > > So step back and plot data from one of the input ensemble
members for
> > > ensemble-stat (see attached):
> > >
> > > *plot_data_plane
> > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3/cgrib2.001
> > > cgrib2.001_VAFTD.ps <http://cgrib2.001_VAFTD.ps> 'name="VAFTD";
level
> =
> > > "L0-20000"; convert\(x\)=1.636*10^18*\(x\); lead_time="12";'*
> > >
> > > If you look at the crazy range of values shown in the colorbar,
you can
> > see
> > > why the event never occurs... and so you always have 0
probabilities!
> > >
> > > I'm guessing that conversion function you're using is causing
the
> > problem.
> > > So I reran plot_data_plane without it (see attached):
> > >
> > > *plot_data_plane
> > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3/cgrib2.001
> > > cgrib2.001_VAFTD_no_convert.ps
<http://cgrib2.001_VAFTD_no_convert.ps>
> > > 'name="VAFTD"; level = "L0-20000"; lead_time="12";'*
> > >
> > > The values of -13 to -99 seem like a more reasonable range.
> > >
> > > I'd recommend working on your convert function to put the
forecast and
> > > observation data into the same units.
> > >
> > > John
> > >
> > >
> > > On Wed, May 27, 2020 at 2:34 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=95208
>
> > > >
> > > > Hello John,
> > > >
> > > > Thank you for helping me to create the grid_stat files. But I
had
> > > problems
> > > > using those to make plots using METviewer. I attached the Rely
plot
> to
> > > this
> > > > email.
> > > >
> > > > Looking back at the "run_gs.log" file in your directory "
> > > /u/John.H.Gotway/
> > > > MET/MET_Help/wang_data_20200511/ run_gs.log", there are some
warning
> > like
> > > > "Forecast and observation valid times do not match
20080808_150000 !=
> > > > 20080808_152000", will this be a problem? "20080808_152000"
comes
> > from
> > > > " :Last_time = "2008221-152000" in the satellite file, this
is NOT
> the
> > > > real time when the ash data is detected (the only time that
ash is
> > > detected
> > > > is "2008221-134000"). If the warning is not an issue, why
does it
> seem
> > > > there is ONLY one pair on the "reply" plot while there are
more than
> > 360
> > > > matching pairs based on the log file.
> > > >
> > > > Another thing, you suggest me to use Metplus, I heard METplus
can not
> > > > handle ensemble at this moment, am I right?
> > > >
> > > > Thank you.
> > > > Binyu
> > > >
> > > >
> > > >
> > > > On Mon, May 11, 2020 at 7:16 PM John Halley Gotway via RT <
> > > > met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > > Binyu,
> > > > >
> > > > > I provided answers inline below.
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > > On Mon, May 11, 2020 at 1:51 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=95208 >
> > > > > >
> > > > > > Hello John,
> > > > > >
> > > > > > Thank you for your help. To save your time, let me make
more
> clear
> > on
> > > > my
> > > > > > new questions. Actually I have a bunch now after spending
more
> time
> > > on
> > > > > > this. Although I did get something but I am not sure it is
> correct
> > or
> > > > > not:
> > > > > >
> > > > > > 1. I changed my script and config files. Here is my new
script:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/ush/verf_g2g_kasat.sh2
> > > > > > Are "ensemble_stat " and "grid_stat " statements correct?
> > > > > >
> > > > > >
> > > > > I'm working on Venus in
> > > /u/John.H.Gotway/MET/MET_Help/wang_data_20200511
> > > > > Running your script in there reveals lots of warnings like
this:
> > > > >
> > > > > *WARNING: MetGrib2DataFile::data_plane() -> Using the first
of 60
> > > > matching
> > > > > records for "VAFTD/L20000-0":*
> > > > >
> > > > > This means that ensemble-stat found multiple matching
records in
> the
> > > > input
> > > > > files. Why? Each one of your GRIB2 model files contains
output for
> > 60
> > > > > different forecast hours. You need to loop over them and
process
> > them
> > > > > separately.
> > > > >
> > > > > I would recommend setting up a METplus use case to handle
this time
> > > > > looping. But to demonstrate an example, I updated your
> ensemble-stat
> > > > > config file to reference lead_time = "${LEAD_HR}"; and I
updated
> your
> > > run
> > > > > script to set that variable as 11 hours.
> > > > >
> > > > > And I also updated the Grid-Stat config file to solve this
warning
> > > > message:
> > > > >
> > > > > *WARNING: GridStatVxOpt::process_config() ->
"nc_pairs_var_str"
> > ((nul))
> > > > is
> > > > > deprecated and replaced by "nc_pairs_var_suffix".*
> > > > >
> > > > > The logs of my running can be seen in:
> > > > > /u/John.H.Gotway/MET/MET_Help/wang_data_20200511/run_es.log
and
> > > > run_gs.log
> > > > >
> > > > > Please also look at the two configures files
> > > > > > "verf_g2g_ens_stat_regn_config_kasat" and
> > > > > > "verf_g2g_grid_stat_regn_config_kasat"
> > > > > >
> > > > > > 2. Inside of "verf_g2g_ens_stat_regn_config_kasa", what is
the
> > > > > relationship
> > > > > > of "field" included in "fcst" with that in "ens"? Which
one
> refers
> > > to
> > > > > the
> > > > > > real forecast? It seems the one in "fcst" is not used at
all
> > because
> > > > > even
> > > > > > if I change the name "VAFTD" under "fcst" to a new name,
there is
> > no
> > > > > > difference.
> > > > > > e.g: my obs is "ASH_MASS_LOADING", my forecast is "VAFTD",
I want
> > to
> > > > use
> > > > > a
> > > > > > new name "ASH" in the MET_viewer, how to do that?
> > > > > >
> > > > >
> > > > > In the Ensemble-Stat config file, the "ens" dictionary
defines the
> > > fields
> > > > > for which you want to derive ensemble mean and probability
fields
> > that
> > > > are
> > > > > written to the output NetCDF file. The "fcst" dictionary
defines
> the
> > > > > fields for which you want to compute ensemble statistics.
If those
> > are
> > > > the
> > > > > same, you could set "fcst = ens;". Those are not necessarily
the
> same
> > > > list
> > > > > of fields. In your case they are.
> > > > >
> > > > >
> > > > > > 3 This question is related to the second one: to using
"convert",
> > > where
> > > > > to
> > > > > > use it? Under the "field" of "fcst" or "ens"? Here is the
unit
> > > > > relationship
> > > > > > of obs and forecast:
> > > > > > obs=1.636*10^18*(forecast)
> > > > > >
> > > > >
> > > > > Both spots. Anytime you data that needs to be converted,
you need
> to
> > > > > specify the formula for converting it.
> > > > >
> > > > >
> > > > > >
> > > > > > 4. I noticed I got a warning as below while the script is
> running,
> > > what
> > > > > > does that mean?
> > > > > > .WARNING: GridStatVxOpt::process_config() ->
"nc_pairs_var_str"
> > > ((nul))
> > > > > is
> > > > > > deprecated and replaced by
> > > > "nc_pairs_var_suffix".
> > > > > >
> > > > > >
> > > > > See answer to 1.
> > > > >
> > > > >
> > > > > > Sorry to ask so many questions. I can not find a similar
use of
> > > > > > "PYTHON_NUMPY" from tutorial, so if you could confirm my
script
> and
> > > > > config
> > > > > > are correct, that will be very very helpful. Let me know
if
> > anything
> > > is
> > > > > not
> > > > > > clear.
> > > > > >
> > > > > > Binyu
> > > > > >
> > > > >
> > > > > I understand what you're doing. I would recommend writing
output to
> > > > > different directories using the "-outdir" command line
option. And
> > you
> > > > > really need to loop over the 60 forecast hours and call
> ensemble-stat
> > > and
> > > > > grid-stat separately for each. You could do that manually
with a
> > shell
> > > > > script, like you're doing now. But it's going to be
difficult to
> > find
> > > > the
> > > > > observation file that is "closest" in time to the forecast
valid
> > time.
> > > > > Instead, METplus already includes logic to handle that.
> > > > >
> > > > > So I'd recommend using METplus instead of your shell script.
While
> > > it's
> > > > a
> > > > > big learning curve, it will hopefully make things easier in
the
> long
> > > run.
> > > > >
> > > > > Thanks,
> > > > > John
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Error with using PYTHON_NUMPY in config file
From: John Halley Gotway
Time: Thu Jun 04 15:45:01 2020
When verifying probabilistic fields in Grid-Stat, the forecast
threshold
(FCST_THRESH) is used to define probability bins whereas the
observation
threshold (OBS_THRESH) is used to define the event corresponding to
that
probability forecast.
The FCST_THRESH of ==0.1 is a short-hand way of defining 10 equally
spaced
probability bins between 0 and 1. And the OBS_THRESH of >7 (for
example)
corresponds to the probability forecast of VAFTD_ENS_FREQ_ge7.
John
On Thu, Jun 4, 2020 at 2:06 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=95208 >
>
> Thank you for your quick response. John.
> I have another question about the grid_stat table (see the
attachment): if
> you check columns T (FCST_THRESH) and U (OBS_THRESH)), why the
thresh for
> FCST and OBS don't match each other?
> They always match each other on the same line for non-ensemble
cases.
>
> Binyu
>
>
>
> On Thu, Jun 4, 2020 at 12:40 PM John Halley Gotway via RT <
> met_help at ucar.edu>
> wrote:
>
> > Binyu,
> >
> > If the same conversion function needs to be applied to the climo
data,
> then
> > yes, it needs to be specified there as well. The forecast data is
read
> and
> > processed separately from the climo mean data.
> >
> > John
> >
> > On Thu, Jun 4, 2020 at 10:28 AM binyu.wang at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=95208 >
> > >
> > > John,
> > >
> > > Based on your suggestion, I did figure out the problem: my
forecast
> data
> > > used in the MET is already processed (LOGx), so I need to add
(10^(x))
> > into
> > > the convert formula. (Old: 1.636*10^17*(x);
> New:1.636*10^17*(10^(x));The
> > > plots look reasonable after I made the change. Thank you for
your
> > > suggestion.
> > >
> > > At the same time, I do get another question: do I also need to
add the
> > same
> > > formula converter for "climo_mean" as below or it is not
necessary?
> > >
> > >
> > > climo_mean = fcst;
> > > climo_mean = {
> > > file_name = "${REFERENCE}";
> > > * convert(x) = 1.636*10^17*(10^(x));*
> > > time_interp_method = DW_MEAN;
> > > match_day = FALSE;
> > > time_step = 1;
> > > }
> > >
> > > Thank you.
> > > Binyu
> > >
> > >
> > > On Fri, May 29, 2020 at 6:59 PM John Halley Gotway via RT <
> > > met_help at ucar.edu>
> > > wrote:
> > >
> > > > Binyu,
> > > >
> > > > OK, I'm looking again in
> > /u/John.H.Gotway/MET/MET_Help/wang_data_20200511
> > > >
> > > > The script (verf_g2g_kasat.sh2) runs Ensemble-Stat to compute
a
> > > probability
> > > > forecasts from 5 input ensemble members. You configured
ensemble-stat
> > to
> > > > define probabilities for:
> > > >
> > > > float VAFTD_L20000-0_ENS_FREQ_le0.5(lat, lon) ;
> > > > float VAFTD_L20000-0_ENS_FREQ_gt0.5.and.le1(lat, lon) ;
> > > > float VAFTD_L20000-0_ENS_FREQ_gt1.and.le2(lat, lon) ;
> > > > float VAFTD_L20000-0_ENS_FREQ_gt2.and.le3(lat, lon) ;
> > > > float VAFTD_L20000-0_ENS_FREQ_gt3.and.ge5(lat, lon) ;
> > > > float VAFTD_L20000-0_ENS_FREQ_gt5.and.le8(lat, lon) ;
> > > > float VAFTD_L20000-0_ENS_FREQ_gt8.and.le10(lat, lon) ;
> > > > float VAFTD_L20000-0_ENS_FREQ_gt10(lat, lon) ;
> > > >
> > > > These are rather odd probabilities. For example, the
probability of
> > > > precipitation is defined by applying a simple threshold of
"precip >
> > 0".
> > > > In your case, you've defined probabilities of being within
these
> bins.
> > If
> > > > those probabilities are meaningful to you, great. If not,
consider
> > > > redefining them.
> > > >
> > > > But we verify those probabilities by running Grid-Stat. As you
note,
> > > there
> > > > are 360 matched pairs. We verify these by populating a 10x2
> > probabilistic
> > > > contingency tables and write those counts out to the PCT line
type.
> But
> > > if
> > > > you look closely, all of those 360 matched pairs fall within
the
> first
> > of
> > > > the 10 bins:
> > > >
> > > > grep PCT
> > out/grid_stat/grid_stat_Kasatochi_090000L_20080808_130000V.stat
> > > >
> > > > So that means the forecast probability values were always
between 0
> and
> > > > 0.1. Since you only have 5 input ensemble members, the only
possible
> > > > probability values are 0, 0.2, 0.4, 0.6, 0.8, and 1.0. So all
the
> > > forecast
> > > > probability values are 0.
> > > >
> > > > And when you finally get to the point of plotting data in
METviewer,
> > > you're
> > > > only seeing a dot for a probability value of 0.05. METviewer
is
> > plotting
> > > > the mid-point of the first bin (0.05 is the mid-point of the 0
to 0.1
> > > > bin). You only get a dot there because that's the only bin
where you
> > > have
> > > > non-zero data.
> > > >
> > > > I'd recommend taking a step back to make sure that your
forecast data
> > and
> > > > observation data overlap in time and space. I ran MET's
> plot_data_plane
> > > on
> > > > the output from ensemble-stat and see that all of the
probability
> > values
> > > > are 0 (see attached):
> > > >
> > > > *plot_data_plane
> > > > out/ensemble_stat/ensemble_stat_volc_20080808_150000V_ens.nc
> > > > ens_VAFTD_prob.ps 'name="VAFTD_L20000-
0_ENS_FREQ_gt0.5.and.le1";
> > > > level="(*,*)";'*
> > > >
> > > > So step back and plot data from one of the input ensemble
members for
> > > > ensemble-stat (see attached):
> > > >
> > > > *plot_data_plane
> > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3/cgrib2.001
> > > > cgrib2.001_VAFTD.ps <http://cgrib2.001_VAFTD.ps>
'name="VAFTD";
> level
> > =
> > > > "L0-20000"; convert\(x\)=1.636*10^18*\(x\); lead_time="12";'*
> > > >
> > > > If you look at the crazy range of values shown in the
colorbar, you
> can
> > > see
> > > > why the event never occurs... and so you always have 0
probabilities!
> > > >
> > > > I'm guessing that conversion function you're using is causing
the
> > > problem.
> > > > So I reran plot_data_plane without it (see attached):
> > > >
> > > > *plot_data_plane
> > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/VA_ense/Out_VA.gefs.Kasato.e3/cgrib2.001
> > > > cgrib2.001_VAFTD_no_convert.ps <
> http://cgrib2.001_VAFTD_no_convert.ps>
> > > > 'name="VAFTD"; level = "L0-20000"; lead_time="12";'*
> > > >
> > > > The values of -13 to -99 seem like a more reasonable range.
> > > >
> > > > I'd recommend working on your convert function to put the
forecast
> and
> > > > observation data into the same units.
> > > >
> > > > John
> > > >
> > > >
> > > > On Wed, May 27, 2020 at 2:34 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=95208 >
> > > > >
> > > > > Hello John,
> > > > >
> > > > > Thank you for helping me to create the grid_stat files. But
I had
> > > > problems
> > > > > using those to make plots using METviewer. I attached the
Rely plot
> > to
> > > > this
> > > > > email.
> > > > >
> > > > > Looking back at the "run_gs.log" file in your directory "
> > > > /u/John.H.Gotway/
> > > > > MET/MET_Help/wang_data_20200511/ run_gs.log", there are some
> warning
> > > like
> > > > > "Forecast and observation valid times do not match
20080808_150000
> !=
> > > > > 20080808_152000", will this be a problem?
"20080808_152000" comes
> > > from
> > > > > " :Last_time = "2008221-152000" in the satellite file, this
is NOT
> > the
> > > > > real time when the ash data is detected (the only time that
ash is
> > > > detected
> > > > > is "2008221-134000"). If the warning is not an issue, why
does it
> > seem
> > > > > there is ONLY one pair on the "reply" plot while there are
more
> than
> > > 360
> > > > > matching pairs based on the log file.
> > > > >
> > > > > Another thing, you suggest me to use Metplus, I heard
METplus can
> not
> > > > > handle ensemble at this moment, am I right?
> > > > >
> > > > > Thank you.
> > > > > Binyu
> > > > >
> > > > >
> > > > >
> > > > > On Mon, May 11, 2020 at 7:16 PM John Halley Gotway via RT <
> > > > > met_help at ucar.edu>
> > > > > wrote:
> > > > >
> > > > > > Binyu,
> > > > > >
> > > > > > I provided answers inline below.
> > > > > >
> > > > > > Thanks,
> > > > > > John
> > > > > >
> > > > > > On Mon, May 11, 2020 at 1:51 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=95208
> >
> > > > > > >
> > > > > > > Hello John,
> > > > > > >
> > > > > > > Thank you for your help. To save your time, let me make
more
> > clear
> > > on
> > > > > my
> > > > > > > new questions. Actually I have a bunch now after
spending more
> > time
> > > > on
> > > > > > > this. Although I did get something but I am not sure it
is
> > correct
> > > or
> > > > > > not:
> > > > > > >
> > > > > > > 1. I changed my script and config files. Here is my new
script:
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/modeling/noscrub/Binyu.Wang/MET/grid2grid/verf_met_ens/ush/verf_g2g_kasat.sh2
> > > > > > > Are "ensemble_stat " and "grid_stat " statements
correct?
> > > > > > >
> > > > > > >
> > > > > > I'm working on Venus in
> > > > /u/John.H.Gotway/MET/MET_Help/wang_data_20200511
> > > > > > Running your script in there reveals lots of warnings like
this:
> > > > > >
> > > > > > *WARNING: MetGrib2DataFile::data_plane() -> Using the
first of 60
> > > > > matching
> > > > > > records for "VAFTD/L20000-0":*
> > > > > >
> > > > > > This means that ensemble-stat found multiple matching
records in
> > the
> > > > > input
> > > > > > files. Why? Each one of your GRIB2 model files contains
output
> for
> > > 60
> > > > > > different forecast hours. You need to loop over them and
process
> > > them
> > > > > > separately.
> > > > > >
> > > > > > I would recommend setting up a METplus use case to handle
this
> time
> > > > > > looping. But to demonstrate an example, I updated your
> > ensemble-stat
> > > > > > config file to reference lead_time = "${LEAD_HR}"; and I
updated
> > your
> > > > run
> > > > > > script to set that variable as 11 hours.
> > > > > >
> > > > > > And I also updated the Grid-Stat config file to solve this
> warning
> > > > > message:
> > > > > >
> > > > > > *WARNING: GridStatVxOpt::process_config() ->
"nc_pairs_var_str"
> > > ((nul))
> > > > > is
> > > > > > deprecated and replaced by "nc_pairs_var_suffix".*
> > > > > >
> > > > > > The logs of my running can be seen in:
> > > > > >
/u/John.H.Gotway/MET/MET_Help/wang_data_20200511/run_es.log and
> > > > > run_gs.log
> > > > > >
> > > > > > Please also look at the two configures files
> > > > > > > "verf_g2g_ens_stat_regn_config_kasat" and
> > > > > > > "verf_g2g_grid_stat_regn_config_kasat"
> > > > > > >
> > > > > > > 2. Inside of "verf_g2g_ens_stat_regn_config_kasa", what
is the
> > > > > > relationship
> > > > > > > of "field" included in "fcst" with that in "ens"? Which
one
> > refers
> > > > to
> > > > > > the
> > > > > > > real forecast? It seems the one in "fcst" is not used
at all
> > > because
> > > > > > even
> > > > > > > if I change the name "VAFTD" under "fcst" to a new name,
there
> is
> > > no
> > > > > > > difference.
> > > > > > > e.g: my obs is "ASH_MASS_LOADING", my forecast is
"VAFTD", I
> want
> > > to
> > > > > use
> > > > > > a
> > > > > > > new name "ASH" in the MET_viewer, how to do that?
> > > > > > >
> > > > > >
> > > > > > In the Ensemble-Stat config file, the "ens" dictionary
defines
> the
> > > > fields
> > > > > > for which you want to derive ensemble mean and probability
fields
> > > that
> > > > > are
> > > > > > written to the output NetCDF file. The "fcst" dictionary
defines
> > the
> > > > > > fields for which you want to compute ensemble statistics.
If
> those
> > > are
> > > > > the
> > > > > > same, you could set "fcst = ens;". Those are not
necessarily the
> > same
> > > > > list
> > > > > > of fields. In your case they are.
> > > > > >
> > > > > >
> > > > > > > 3 This question is related to the second one: to using
> "convert",
> > > > where
> > > > > > to
> > > > > > > use it? Under the "field" of "fcst" or "ens"? Here is
the unit
> > > > > > relationship
> > > > > > > of obs and forecast:
> > > > > > > obs=1.636*10^18*(forecast)
> > > > > > >
> > > > > >
> > > > > > Both spots. Anytime you data that needs to be converted,
you
> need
> > to
> > > > > > specify the formula for converting it.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > 4. I noticed I got a warning as below while the script
is
> > running,
> > > > what
> > > > > > > does that mean?
> > > > > > > .WARNING: GridStatVxOpt::process_config() ->
"nc_pairs_var_str"
> > > > ((nul))
> > > > > > is
> > > > > > > deprecated and replaced by
> > > > > "nc_pairs_var_suffix".
> > > > > > >
> > > > > > >
> > > > > > See answer to 1.
> > > > > >
> > > > > >
> > > > > > > Sorry to ask so many questions. I can not find a
similar use
> of
> > > > > > > "PYTHON_NUMPY" from tutorial, so if you could confirm my
script
> > and
> > > > > > config
> > > > > > > are correct, that will be very very helpful. Let me know
if
> > > anything
> > > > is
> > > > > > not
> > > > > > > clear.
> > > > > > >
> > > > > > > Binyu
> > > > > > >
> > > > > >
> > > > > > I understand what you're doing. I would recommend writing
output
> to
> > > > > > different directories using the "-outdir" command line
option.
> And
> > > you
> > > > > > really need to loop over the 60 forecast hours and call
> > ensemble-stat
> > > > and
> > > > > > grid-stat separately for each. You could do that manually
with a
> > > shell
> > > > > > script, like you're doing now. But it's going to be
difficult to
> > > find
> > > > > the
> > > > > > observation file that is "closest" in time to the forecast
valid
> > > time.
> > > > > > Instead, METplus already includes logic to handle that.
> > > > > >
> > > > > > So I'd recommend using METplus instead of your shell
script.
> While
> > > > it's
> > > > > a
> > > > > > big learning curve, it will hopefully make things easier
in the
> > long
> > > > run.
> > > > > >
> > > > > > Thanks,
> > > > > > John
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
------------------------------------------------
Subject: Error with using PYTHON_NUMPY in config file
From: David Fillmore
Time: Tue Oct 13 11:00:43 2020
Closed.
------------------------------------------------
More information about the Met_help
mailing list