[Met_help] [rt.rap.ucar.edu #100100] History for PB2NC and PointStat questions
George McCabe via RT
met_help at ucar.edu
Wed Jun 16 15:19:10 MDT 2021
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello,
I have three questions that I hope you can help me with: one about the WIND
variable, one about burst sampling and matched pairs, and one about a
variable encoded as a sequence in the GRIB2 file.
I'm trying to understand how PB2NC and PointStat work. I am running on
Hera, using:
module purge
module use -a /contrib/METplus/modulefiles
module load metplus
which gives me met/10.0.0 and metplus/4.0.0
I set up a test directory on Hera:
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/test2
with some data and config files for PB2NC and PointStat. When I run them
from the command line (my commands are in the readme file), they "work" and
I get matched pairs and the stats file (in the output directory) is
produced. I say "work" because PB2NC works but I get a warning in
PointStat that I don't know how to fix:
DEBUG 3: Multiple GRIB2 table entries match lookup criteria (parm_name =
WIND):
DEBUG 3: parm_name: WIND, index_a = 0, grib2_mtab = 14, grib2_cntr = 57,
grib2_ltab = 0, index_b = 2, index_c = 1
DEBUG 3: parm_name: WIND, index_a = 0, grib2_mtab = 1, grib2_cntr = 0,
grib2_ltab = 0, index_b = 2, index_c = 1
It uses the first WIND found, and there are matched pairs and stats
generated. I am trying to use the 10m winds - the model encodes it as L0
in the grib2 file, and I am not sure what the GDAS file has - I tried
asking for the Z10 since L0 might be less than 10m.
I have the script style code in another directory:
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/metplus_config/metplus_use_cases/METplusV4.0/gfs/wave/grid2obs/PointStat_fcstGFS_obsGDAS_Wave_Multifield_PrepBufr.conf
which I've tried to make as identical to the test case as I can, yet when I
run this:
run_metplus.py $METPLUS_WAVES_VERIF/wave.config
$METPLUS_WAVES_G2O/PointStat_fcstGFS_obsGDAS_Wave_Multifield_PrepBufr.conf
I get no matched pairs. For this, the output logs are in:
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/v4.0.0/logs
I suspect it has to do with the OBS_WINDOW begin and end, which I have two
different ones when I run separately in the test case: 3H before and after
in PB2NC, but 30 minutes before and after the hour for PointStat. I've
tried using a separate PB2NC_OBS_WINDOW and POINT_STAT_OBS_WINDOW, but that
also gave no matched pairs.
The obs window is complicated because burst sampling is used for wave
data. So while I want PB2NC to collect all the data it can find, when I
get to POINT_STAT I need to average the data around the hour to match with
the model forecast. I usually use 20 minutes before and after the hour,
but I tried expanding it to 30 minutes to see if it would work.
I also have a question about one of the wave variables, which is encoded in
the grib2 file as a sequence. In the test2 directory:
> wgrib2 -v gfswave.t18z.global.0p25.f000.grib2
9:5203366:d=2021052518:SWELL Significant Height of Swell Waves [m]:1 in
sequence:anl:
10:5700268:d=2021052518:SWELL Significant Height of Swell Waves [m]:2 in
sequence:anl:
11:6127279:d=2021052518:SWELL Significant Height of Swell Waves [m]:3 in
sequence:anl:
How would I ask for this variable in PB2NC or POINT_STAT?
Any help you can give me would be much appreciated!
Many thanks,
Deanna
--
Deanna Spindler, PhD
Research Oceanographer
IMSG at NOAA/NWS/NCEP/Environmental Modeling Center
NOAA Center for Weather and Climate Prediction
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: PB2NC and PointStat questions
From: George McCabe
Time: Mon Jun 07 08:58:05 2021
Hi Deanna,
I see you have some questions about PB2NC and PointStat.
1) The message about the multiple GRIB2 table entry matches is not
actually
a warning. I have reached out to another engineer (John HG) who is
more
familiar to get more information. This is the response:
*"There are multiple instances of "WIND" in the GRIB1 and GRIB2 table
files
defined
here:https://github.com/dtcenter/MET/tree/main_v10.0/met/data/table_files
<https://github.com/dtcenter/MET/tree/main_v10.0/met/data/table_files>*
*This is not a problem. It's very often the case that the same names
are
used across different versions and institutions. But I do realize how
the
"using first match found" log message could cause some concern. That's
a
hold over from earlier versions of MET where the logic was
problematic. The
existing lookup logic should work fine for Deanna and retrieve the
data
she's looking for. I always recommend that people run plot_data_plane
to
confirm that MET is grabbing the data they're looking for."*
It sounds like it is grabbing the correct data in this case. If you
are
concerned that it may not be, then you can run plot_data_plane to
generate
a plot of the data to see what values are being used.
2) I compared the command you ran in the readme file to the command
that
was generated by METplus:
pb2nc gdas.t18z.prepbufr.nr gdas.t18z.nc PB2NCConfig -valid_beg
2021052500 -valid_end 2021052523 -log pb2nc.log -v 3
vs.
/contrib/met/10.0.0/bin/pb2nc -v 2
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/Prod_GDAS/gdas.20210525/
gdas.t00z.prepbufr.nr
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna/
gdas.t2021052500z.nc
/contrib/METplus/METplus-4.0.0/parm/met_config/PB2NCConfig_wrapped
The command generated by the wrapper does not have the -valid_beg and
-valid_end arguments. You can set these by using values relative to
the
valid time in PB2NC_VALID_BEGIN and PB2NC_VALID_END. It looks like you
have
the values from the first command set in VALID_BEG and VALID_END with
a
VALID_INCREMENT value of 6 hours. This will loop over those times and
generate commands for each. I think you want to run once per day, so I
would set something like this:
VALID_BEG = 2021052500
VALID_END = 2021052500
PB2NC_VALID_BEGIN = {valid?fmt=%Y%m%d_%H}
PB2NC_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
This will run once at valid time 2021-05-25 0Z and use 20210525_00 for
-valid_beg and 20210525_23 for -valid_end.
It also looks like you are correct that the obs window values differ.
In
your METplus log file, I see:
06/03 20:43:24.155 metplus INFO: METPLUS_OBS_WINDOW_DICT=obs_window =
{beg
= -10800;end = *10800*;}
while your PB2NCConfig file has:
obs_window = {
beg = -10800;
end = *21600*;
}
To get the same result in PB2NC (-3 hr to +6 hr), you can set:
PB2NC_OBS_WINDOW_BEGIN = -10800
PB2NC_OBS_WINDOW_END = *21600*
Your comments say to use -3/+3, so I thought I should point out that
the
actual values used in the first example differ from that.
Comparing the point_stat commands:
point_stat gfswave.t00z.global.0p25.f000.grib2 gdas.t18z.nc
PointStatConfig -obs_valid_beg 2021052500 -obs_valid_end 2021052523
-outdir $METPLUS_WAVES_VERIF/test2/output -log pointstat.log -v 3
vs.
/contrib/met/10.0.0/bin/point_stat -v 3
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/Prod_Waves/gfs.20210525/gfswave.t00z.global.0p25.f000.grib2
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna/
gdas.t2021052500z.nc
/contrib/METplus/METplus-4.0.0/parm/met_config/PointStatConfig_wrapped
-outdir
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna
I see that the -obs_valid_beg and -obs_valid_end values are missing
from
the generated command. You can set these similarly to the PB2NC
arguments:
POINT_STAT_OBS_VALID_BEG = {valid?fmt=%Y%m%d_%H}
POINT_STAT_OBS_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
To get the obs_window values to match the first command, you can set:
POINT_STAT_OBS_WINDOW_BEG = -1800
POINT_STAT_OBS_WINDOW_END = 1800
3) When reading the wave variables, L# is used to extract a generic
level
type (See
https://met.readthedocs.io/en/latest/Users_Guide/config_options.html#settings-
common-to-multiple-tools
and search for "LNNN" to find the relevant section). I tried
configuring
PointStatConfig to read from SWELL with levels L1, L2, and L3 and
received
different numbers of matched pairs for each, so it appeared to select
each
field. If you want to be certain, you can run plot_data_plane
specifying
each level and see if the correct results are plotted. You won't need
to
configure PB2NC to read this data since it is GRIB2 data and not
prepBUFR.
I hope that helps. Please let me know if you have any other issues
getting
the tools configured to match your previous run or if you have any
other
questions.
Thanks,
George
On Fri, Jun 4, 2021 at 8:21 AM Minna Win via RT <met_help at ucar.edu>
wrote:
>
> Fri Jun 04 08:21:21 2021: Request 100100 was acted upon.
> Transaction: Given to mccabe (George McCabe) by minnawin
> Queue: met_help
> Subject: PB2NC and PointStat questions
> Owner: mccabe
> Requestors: deanna.spindler at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100100 >
>
>
> This transaction appears to have no content
>
--
George McCabe - Software Engineer III
National Center for Atmospheric Research
Research Applications Laboratory
303-497-2768
---
My working day may not be your working day. Please do not feel obliged
to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: PB2NC and PointStat questions
From: John Halley Gotway
Time: Mon Jun 07 10:27:05 2021
Hi Deanna,
This is John Halley Gotway. George asked me to address your question
about
verifying 10-m winds.
In general, I would recommend not filtering point observations in the
PB2NC
tool... by elevation or height... unless you have a specific reason to
do
so. Instead, just pass through all the obs through PB2NC and then
filter
them by Point-Stat.
Verifying winds at 10-m and temperature at 2-m are both considered to
be
"surface" verification. And the logic for surface verification is
handled
by message type rather than strict enforcement of vertical levels.
This
logic is inherited from the verification tools at NOAA/EMC.
When verifying 10-m wind against point observation for "surface"
message
types, all of those observations are used, regardless of their height.
And
if needed, you can configure which message types should be considered
to
exist at the surface via the Point-Stat configuration file. Just add
it to
the comma-separated list of "SURFACE" message types in the
message_type_group_map setting:
https://github.com/dtcenter/MET/blob/0c79e00e9e07054d133cb91ee7fbb7cf4da7ac7e/met/data/config/PointStatConfig_default#L108
Thanks,
John
On Mon, Jun 7, 2021 at 8:58 AM George McCabe via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100100 >
>
> Hi Deanna,
>
> I see you have some questions about PB2NC and PointStat.
>
> 1) The message about the multiple GRIB2 table entry matches is not
actually
> a warning. I have reached out to another engineer (John HG) who is
more
> familiar to get more information. This is the response:
>
>
>
> *"There are multiple instances of "WIND" in the GRIB1 and GRIB2
table files
> defined
>
here:https://github.com/dtcenter/MET/tree/main_v10.0/met/data/table_files
>
<https://github.com/dtcenter/MET/tree/main_v10.0/met/data/table_files>*
> *This is not a problem. It's very often the case that the same names
are
> used across different versions and institutions. But I do realize
how the
> "using first match found" log message could cause some concern.
That's a
> hold over from earlier versions of MET where the logic was
problematic. The
> existing lookup logic should work fine for Deanna and retrieve the
data
> she's looking for. I always recommend that people run
plot_data_plane to
> confirm that MET is grabbing the data they're looking for."*
>
> It sounds like it is grabbing the correct data in this case. If you
are
> concerned that it may not be, then you can run plot_data_plane to
generate
> a plot of the data to see what values are being used.
>
>
> 2) I compared the command you ran in the readme file to the command
that
> was generated by METplus:
>
> pb2nc gdas.t18z.prepbufr.nr gdas.t18z.nc PB2NCConfig -valid_beg
> 2021052500 -valid_end 2021052523 -log pb2nc.log -v 3
>
> vs.
>
> /contrib/met/10.0.0/bin/pb2nc -v 2
>
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/Prod_GDAS/gdas.20210525/
> gdas.t00z.prepbufr.nr
> /scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna/
> gdas.t2021052500z.nc
> /contrib/METplus/METplus-4.0.0/parm/met_config/PB2NCConfig_wrapped
>
> The command generated by the wrapper does not have the -valid_beg
and
> -valid_end arguments. You can set these by using values relative to
the
> valid time in PB2NC_VALID_BEGIN and PB2NC_VALID_END. It looks like
you have
> the values from the first command set in VALID_BEG and VALID_END
with a
> VALID_INCREMENT value of 6 hours. This will loop over those times
and
> generate commands for each. I think you want to run once per day, so
I
> would set something like this:
>
> VALID_BEG = 2021052500
> VALID_END = 2021052500
>
> PB2NC_VALID_BEGIN = {valid?fmt=%Y%m%d_%H}
> PB2NC_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
>
> This will run once at valid time 2021-05-25 0Z and use 20210525_00
for
> -valid_beg and 20210525_23 for -valid_end.
>
> It also looks like you are correct that the obs window values
differ. In
> your METplus log file, I see:
>
> 06/03 20:43:24.155 metplus INFO: METPLUS_OBS_WINDOW_DICT=obs_window
= {beg
> = -10800;end = *10800*;}
>
> while your PB2NCConfig file has:
>
> obs_window = {
> beg = -10800;
> end = *21600*;
> }
>
> To get the same result in PB2NC (-3 hr to +6 hr), you can set:
>
> PB2NC_OBS_WINDOW_BEGIN = -10800
> PB2NC_OBS_WINDOW_END = *21600*
>
> Your comments say to use -3/+3, so I thought I should point out that
the
> actual values used in the first example differ from that.
>
>
> Comparing the point_stat commands:
>
> point_stat gfswave.t00z.global.0p25.f000.grib2 gdas.t18z.nc
> PointStatConfig -obs_valid_beg 2021052500 -obs_valid_end 2021052523
> -outdir $METPLUS_WAVES_VERIF/test2/output -log pointstat.log -v 3
>
> vs.
>
> /contrib/met/10.0.0/bin/point_stat -v 3
>
>
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/Prod_Waves/gfs.20210525/gfswave.t00z.global.0p25.f000.grib2
> /scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna/
> gdas.t2021052500z.nc
> /contrib/METplus/METplus-
4.0.0/parm/met_config/PointStatConfig_wrapped
> -outdir
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna
>
> I see that the -obs_valid_beg and -obs_valid_end values are missing
from
> the generated command. You can set these similarly to the PB2NC
arguments:
>
> POINT_STAT_OBS_VALID_BEG = {valid?fmt=%Y%m%d_%H}
> POINT_STAT_OBS_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
>
> To get the obs_window values to match the first command, you can
set:
>
> POINT_STAT_OBS_WINDOW_BEG = -1800
> POINT_STAT_OBS_WINDOW_END = 1800
>
>
> 3) When reading the wave variables, L# is used to extract a generic
level
> type (See
>
>
https://met.readthedocs.io/en/latest/Users_Guide/config_options.html#settings-
common-to-multiple-tools
> and search for "LNNN" to find the relevant section). I tried
configuring
> PointStatConfig to read from SWELL with levels L1, L2, and L3 and
received
> different numbers of matched pairs for each, so it appeared to
select each
> field. If you want to be certain, you can run plot_data_plane
specifying
> each level and see if the correct results are plotted. You won't
need to
> configure PB2NC to read this data since it is GRIB2 data and not
prepBUFR.
>
>
> I hope that helps. Please let me know if you have any other issues
getting
> the tools configured to match your previous run or if you have any
other
> questions.
>
> Thanks,
> George
>
> On Fri, Jun 4, 2021 at 8:21 AM Minna Win via RT <met_help at ucar.edu>
wrote:
>
> >
> > Fri Jun 04 08:21:21 2021: Request 100100 was acted upon.
> > Transaction: Given to mccabe (George McCabe) by minnawin
> > Queue: met_help
> > Subject: PB2NC and PointStat questions
> > Owner: mccabe
> > Requestors: deanna.spindler at noaa.gov
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100100 >
> >
> >
> > This transaction appears to have no content
> >
>
>
> --
> George McCabe - Software Engineer III
> National Center for Atmospheric Research
> Research Applications Laboratory
> 303-497-2768
> ---
> My working day may not be your working day. Please do not feel
obliged to
> reply to this email outside of your normal working hours.
>
>
------------------------------------------------
Subject: PB2NC and PointStat questions
From: deanna.spindler at noaa.gov
Time: Tue Jun 08 13:20:53 2021
Hello George,
Thank you very much for answering my questions. As always, now I have
more!
I am struggling with understanding how the times (valid/init, windows,
etc)
are set. Here's what I want to do:
1) Run for each day BUT using all the model output available. That's
why I
had
VALID_BEG = 2021052500
VALID_END = 2021052523
VALID_INCREMENT = 6H
because I want to use every run (00, 06, 12, 18 for GFS-Wave) so that
at
any individual location I have four points each day to validate.
In my test case I am only looking at LEAD_SEQ = 0, but once it's
working
correctly I want to change that to hourly for the first 48 hours, then
3-hourly for the next 8 days (so 10 days of forecasts in total). I
only
know how to do the first part of that:
LEAD_SEQ = begin_end_incr(0,48,1)
2) Gather all the observations within a 3H window around each model
run
(00, 06, 12, 18):
PB2NC_VALID_BEGIN = {valid?fmt=%Y%m%d_%H}
PB2NC_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
PB2NC_OBS_WINDOW_BEGIN = -10800
PB2NC_OBS_WINDOW_END = 10800
Question: will this just gather all the data 30 minutes before and
after
each hour? will PointStat average it (below in "3") to be at the hour,
or
do I have to use
PB2NC_TIME_SUMMARY_FLAG = True
PB2NC_TIME_SUMMARY_RAW_DATA = False
PB2NC_TIME_SUMMARY_BEG = 000000 ;; start time of time summary in
HHMMSS
format
PB2NC_TIME_SUMMARY_END = 235959 ;; end time of time summary in HHMMSS
format
PB2NC_TIME_SUMMARY_STEP = 3600
PB2NC_TIME_SUMMARY_WIDTH = 1800
to get data that matches the model's "on the hour" output?
3) The model output is hourly, so I only want to compare obs to model
on
the hour and I need to account for burst sampling (i.e. the data will
not
be "on the hour", so I need to average around the hour)
POINT_STAT_OBS_VALID_BEG = {valid?fmt=%Y%m%d_%H}
POINT_STAT_OBS_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
POINT_STAT_OBS_WINDOW_BEG = -1800
POINT_STAT_OBS_WINDOW_END = 1800
Is this correct?
Thanks,
Deanna
--
Deanna Spindler, PhD
Research Oceanographer
IMSG at NOAA/NWS/NCEP/Environmental Modeling Center
NOAA Center for Weather and Climate Prediction
On Mon, Jun 7, 2021 at 10:58 AM George McCabe via RT
<met_help at ucar.edu>
wrote:
> Hi Deanna,
>
> I see you have some questions about PB2NC and PointStat.
>
> 1) The message about the multiple GRIB2 table entry matches is not
actually
> a warning. I have reached out to another engineer (John HG) who is
more
> familiar to get more information. This is the response:
>
>
>
> *"There are multiple instances of "WIND" in the GRIB1 and GRIB2
table files
> defined
>
here:https://github.com/dtcenter/MET/tree/main_v10.0/met/data/table_files
>
<https://github.com/dtcenter/MET/tree/main_v10.0/met/data/table_files>*
> *This is not a problem. It's very often the case that the same names
are
> used across different versions and institutions. But I do realize
how the
> "using first match found" log message could cause some concern.
That's a
> hold over from earlier versions of MET where the logic was
problematic. The
> existing lookup logic should work fine for Deanna and retrieve the
data
> she's looking for. I always recommend that people run
plot_data_plane to
> confirm that MET is grabbing the data they're looking for."*
>
> It sounds like it is grabbing the correct data in this case. If you
are
> concerned that it may not be, then you can run plot_data_plane to
generate
> a plot of the data to see what values are being used.
>
>
> 2) I compared the command you ran in the readme file to the command
that
> was generated by METplus:
>
> pb2nc gdas.t18z.prepbufr.nr gdas.t18z.nc PB2NCConfig -valid_beg
> 2021052500 -valid_end 2021052523 -log pb2nc.log -v 3
>
> vs.
>
> /contrib/met/10.0.0/bin/pb2nc -v 2
>
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/Prod_GDAS/gdas.20210525/
> gdas.t00z.prepbufr.nr
> /scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna/
> gdas.t2021052500z.nc
> /contrib/METplus/METplus-4.0.0/parm/met_config/PB2NCConfig_wrapped
>
> The command generated by the wrapper does not have the -valid_beg
and
> -valid_end arguments. You can set these by using values relative to
the
> valid time in PB2NC_VALID_BEGIN and PB2NC_VALID_END. It looks like
you have
> the values from the first command set in VALID_BEG and VALID_END
with a
> VALID_INCREMENT value of 6 hours. This will loop over those times
and
> generate commands for each. I think you want to run once per day, so
I
> would set something like this:
>
> VALID_BEG = 2021052500
> VALID_END = 2021052500
>
> PB2NC_VALID_BEGIN = {valid?fmt=%Y%m%d_%H}
> PB2NC_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
>
> This will run once at valid time 2021-05-25 0Z and use 20210525_00
for
> -valid_beg and 20210525_23 for -valid_end.
>
> It also looks like you are correct that the obs window values
differ. In
> your METplus log file, I see:
>
> 06/03 20:43:24.155 metplus INFO: METPLUS_OBS_WINDOW_DICT=obs_window
= {beg
> = -10800;end = *10800*;}
>
> while your PB2NCConfig file has:
>
> obs_window = {
> beg = -10800;
> end = *21600*;
> }
>
> To get the same result in PB2NC (-3 hr to +6 hr), you can set:
>
> PB2NC_OBS_WINDOW_BEGIN = -10800
> PB2NC_OBS_WINDOW_END = *21600*
>
> Your comments say to use -3/+3, so I thought I should point out that
the
> actual values used in the first example differ from that.
>
>
> Comparing the point_stat commands:
>
> point_stat gfswave.t00z.global.0p25.f000.grib2 gdas.t18z.nc
> PointStatConfig -obs_valid_beg 2021052500 -obs_valid_end 2021052523
> -outdir $METPLUS_WAVES_VERIF/test2/output -log pointstat.log -v 3
>
> vs.
>
> /contrib/met/10.0.0/bin/point_stat -v 3
>
>
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/Prod_Waves/gfs.20210525/gfswave.t00z.global.0p25.f000.grib2
> /scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna/
> gdas.t2021052500z.nc
> /contrib/METplus/METplus-
4.0.0/parm/met_config/PointStatConfig_wrapped
> -outdir
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna
>
> I see that the -obs_valid_beg and -obs_valid_end values are missing
from
> the generated command. You can set these similarly to the PB2NC
arguments:
>
> POINT_STAT_OBS_VALID_BEG = {valid?fmt=%Y%m%d_%H}
> POINT_STAT_OBS_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
>
> To get the obs_window values to match the first command, you can
set:
>
> POINT_STAT_OBS_WINDOW_BEG = -1800
> POINT_STAT_OBS_WINDOW_END = 1800
>
>
> 3) When reading the wave variables, L# is used to extract a generic
level
> type (See
>
>
https://met.readthedocs.io/en/latest/Users_Guide/config_options.html#settings-
common-to-multiple-tools
> and search for "LNNN" to find the relevant section). I tried
configuring
> PointStatConfig to read from SWELL with levels L1, L2, and L3 and
received
> different numbers of matched pairs for each, so it appeared to
select each
> field. If you want to be certain, you can run plot_data_plane
specifying
> each level and see if the correct results are plotted. You won't
need to
> configure PB2NC to read this data since it is GRIB2 data and not
prepBUFR.
>
>
> I hope that helps. Please let me know if you have any other issues
getting
> the tools configured to match your previous run or if you have any
other
> questions.
>
> Thanks,
> George
>
> On Fri, Jun 4, 2021 at 8:21 AM Minna Win via RT <met_help at ucar.edu>
wrote:
>
> >
> > Fri Jun 04 08:21:21 2021: Request 100100 was acted upon.
> > Transaction: Given to mccabe (George McCabe) by minnawin
> > Queue: met_help
> > Subject: PB2NC and PointStat questions
> > Owner: mccabe
> > Requestors: deanna.spindler at noaa.gov
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100100 >
> >
> >
> > This transaction appears to have no content
> >
>
>
> --
> George McCabe - Software Engineer III
> National Center for Atmospheric Research
> Research Applications Laboratory
> 303-497-2768
> ---
> My working day may not be your working day. Please do not feel
obliged to
> reply to this email outside of your normal working hours.
>
>
------------------------------------------------
Subject: PB2NC and PointStat questions
From: George McCabe
Time: Tue Jun 08 14:57:10 2021
Hi Deanna,
1) To run hourly for the first 48 hours, then 3-hourly for the next 8
days
(so 10 days of forecasts in total), you should be able to set:
LEAD_SEQ = begin_end_incr(0,48,1), begin_end_incr(48,240,3)
It should expand both lists into a full list of the times you desire.
You
can test this out by setting it and running the Example wrapper
(PROCESS_LIST=Example) and see what forecast hours are looped over.
2) I am going to ask John HG to respond about this, because I am not
100%
sure what the best way to configure this is, but I think you want to
set
the valid_beg and valid_end values to ensure that the window that is
retained corresponds to the valid time you are processing.
>From the documentation about obs_window:
* In PB2NC, the reference time is the PREPBUFR files center time. In
Point-Stat and Ensemble-Stat, the reference time is the forecast valid
time. *
>From what I recall the center time in the PREPBUFR files can vary, so
setting the obs_window values may not get a 3 hour window around the
valid
time depending on what the center time is. I believe you will want to
set:
PB2NC_VALID_BEGIN = {valid?fmt=%Y%m%d_%H?shift=-3H}
PB2NC_VALID_END = {valid?fmt=%Y%m%d_%H?shift=3H}
3) I will let John correct me if I'm wrong, but I believe setting the
POINT_STAT_OBS_WINDOW_BEG and POINT_STAT_OBS_WINDOW_END values that
you
listed should gather all of the obs you need for each hour. I don't
know
that setting the POINT_STAT_OBS_VALID_BEG and
POINT_STAT_OBS_VALID_END
values would be needed here.
I hope that helps!
Thanks,
George
On Tue, Jun 8, 2021 at 1:20 PM deanna.spindler at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100100 >
>
> Hello George,
>
> Thank you very much for answering my questions. As always, now I
have
> more!
> I am struggling with understanding how the times (valid/init,
windows, etc)
> are set. Here's what I want to do:
>
> 1) Run for each day BUT using all the model output available. That's
why I
> had
> VALID_BEG = 2021052500
> VALID_END = 2021052523
> VALID_INCREMENT = 6H
> because I want to use every run (00, 06, 12, 18 for GFS-Wave) so
that at
> any individual location I have four points each day to validate.
>
> In my test case I am only looking at LEAD_SEQ = 0, but once it's
working
> correctly I want to change that to hourly for the first 48 hours,
then
> 3-hourly for the next 8 days (so 10 days of forecasts in total). I
only
> know how to do the first part of that:
> LEAD_SEQ = begin_end_incr(0,48,1)
>
> 2) Gather all the observations within a 3H window around each model
run
> (00, 06, 12, 18):
> PB2NC_VALID_BEGIN = {valid?fmt=%Y%m%d_%H}
> PB2NC_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
> PB2NC_OBS_WINDOW_BEGIN = -10800
> PB2NC_OBS_WINDOW_END = 10800
>
> Question: will this just gather all the data 30 minutes before and
after
> each hour? will PointStat average it (below in "3") to be at the
hour, or
> do I have to use
> PB2NC_TIME_SUMMARY_FLAG = True
> PB2NC_TIME_SUMMARY_RAW_DATA = False
> PB2NC_TIME_SUMMARY_BEG = 000000 ;; start time of time summary in
HHMMSS
> format
> PB2NC_TIME_SUMMARY_END = 235959 ;; end time of time summary in
HHMMSS
> format
> PB2NC_TIME_SUMMARY_STEP = 3600
> PB2NC_TIME_SUMMARY_WIDTH = 1800
> to get data that matches the model's "on the hour" output?
>
> 3) The model output is hourly, so I only want to compare obs to
model on
> the hour and I need to account for burst sampling (i.e. the data
will not
> be "on the hour", so I need to average around the hour)
> POINT_STAT_OBS_VALID_BEG = {valid?fmt=%Y%m%d_%H}
> POINT_STAT_OBS_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
> POINT_STAT_OBS_WINDOW_BEG = -1800
> POINT_STAT_OBS_WINDOW_END = 1800
>
> Is this correct?
>
> Thanks,
> Deanna
>
>
> --
> Deanna Spindler, PhD
> Research Oceanographer
> IMSG at NOAA/NWS/NCEP/Environmental Modeling Center
> NOAA Center for Weather and Climate Prediction
>
>
> On Mon, Jun 7, 2021 at 10:58 AM George McCabe via RT
<met_help at ucar.edu>
> wrote:
>
> > Hi Deanna,
> >
> > I see you have some questions about PB2NC and PointStat.
> >
> > 1) The message about the multiple GRIB2 table entry matches is not
> actually
> > a warning. I have reached out to another engineer (John HG) who is
more
> > familiar to get more information. This is the response:
> >
> >
> >
> > *"There are multiple instances of "WIND" in the GRIB1 and GRIB2
table
> files
> > defined
> > here:
> https://github.com/dtcenter/MET/tree/main_v10.0/met/data/table_files
> >
<https://github.com/dtcenter/MET/tree/main_v10.0/met/data/table_files>*
> > *This is not a problem. It's very often the case that the same
names are
> > used across different versions and institutions. But I do realize
how
> the
> > "using first match found" log message could cause some concern.
That's a
> > hold over from earlier versions of MET where the logic was
problematic.
> The
> > existing lookup logic should work fine for Deanna and retrieve the
data
> > she's looking for. I always recommend that people run
plot_data_plane to
> > confirm that MET is grabbing the data they're looking for."*
> >
> > It sounds like it is grabbing the correct data in this case. If
you are
> > concerned that it may not be, then you can run plot_data_plane to
> generate
> > a plot of the data to see what values are being used.
> >
> >
> > 2) I compared the command you ran in the readme file to the
command that
> > was generated by METplus:
> >
> > pb2nc gdas.t18z.prepbufr.nr gdas.t18z.nc PB2NCConfig -valid_beg
> > 2021052500 -valid_end 2021052523 -log pb2nc.log -v 3
> >
> > vs.
> >
> > /contrib/met/10.0.0/bin/pb2nc -v 2
> >
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/Prod_GDAS/gdas.20210525/
> > gdas.t00z.prepbufr.nr
> > /scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna/
> > gdas.t2021052500z.nc
> > /contrib/METplus/METplus-4.0.0/parm/met_config/PB2NCConfig_wrapped
> >
> > The command generated by the wrapper does not have the -valid_beg
and
> > -valid_end arguments. You can set these by using values relative
to the
> > valid time in PB2NC_VALID_BEGIN and PB2NC_VALID_END. It looks like
you
> have
> > the values from the first command set in VALID_BEG and VALID_END
with a
> > VALID_INCREMENT value of 6 hours. This will loop over those times
and
> > generate commands for each. I think you want to run once per day,
so I
> > would set something like this:
> >
> > VALID_BEG = 2021052500
> > VALID_END = 2021052500
> >
> > PB2NC_VALID_BEGIN = {valid?fmt=%Y%m%d_%H}
> > PB2NC_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
> >
> > This will run once at valid time 2021-05-25 0Z and use 20210525_00
for
> > -valid_beg and 20210525_23 for -valid_end.
> >
> > It also looks like you are correct that the obs window values
differ. In
> > your METplus log file, I see:
> >
> > 06/03 20:43:24.155 metplus INFO:
METPLUS_OBS_WINDOW_DICT=obs_window =
> {beg
> > = -10800;end = *10800*;}
> >
> > while your PB2NCConfig file has:
> >
> > obs_window = {
> > beg = -10800;
> > end = *21600*;
> > }
> >
> > To get the same result in PB2NC (-3 hr to +6 hr), you can set:
> >
> > PB2NC_OBS_WINDOW_BEGIN = -10800
> > PB2NC_OBS_WINDOW_END = *21600*
> >
> > Your comments say to use -3/+3, so I thought I should point out
that the
> > actual values used in the first example differ from that.
> >
> >
> > Comparing the point_stat commands:
> >
> > point_stat gfswave.t00z.global.0p25.f000.grib2 gdas.t18z.nc
> > PointStatConfig -obs_valid_beg 2021052500 -obs_valid_end
2021052523
> > -outdir $METPLUS_WAVES_VERIF/test2/output -log pointstat.log -v 3
> >
> > vs.
> >
> > /contrib/met/10.0.0/bin/point_stat -v 3
> >
> >
>
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/Prod_Waves/gfs.20210525/gfswave.t00z.global.0p25.f000.grib2
> > /scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna/
> > gdas.t2021052500z.nc
> > /contrib/METplus/METplus-
4.0.0/parm/met_config/PointStatConfig_wrapped
> > -outdir
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna
> >
> > I see that the -obs_valid_beg and -obs_valid_end values are
missing from
> > the generated command. You can set these similarly to the PB2NC
> arguments:
> >
> > POINT_STAT_OBS_VALID_BEG = {valid?fmt=%Y%m%d_%H}
> > POINT_STAT_OBS_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
> >
> > To get the obs_window values to match the first command, you can
set:
> >
> > POINT_STAT_OBS_WINDOW_BEG = -1800
> > POINT_STAT_OBS_WINDOW_END = 1800
> >
> >
> > 3) When reading the wave variables, L# is used to extract a
generic level
> > type (See
> >
> >
>
https://met.readthedocs.io/en/latest/Users_Guide/config_options.html#settings-
common-to-multiple-tools
> > and search for "LNNN" to find the relevant section). I tried
configuring
> > PointStatConfig to read from SWELL with levels L1, L2, and L3 and
> received
> > different numbers of matched pairs for each, so it appeared to
select
> each
> > field. If you want to be certain, you can run plot_data_plane
specifying
> > each level and see if the correct results are plotted. You won't
need to
> > configure PB2NC to read this data since it is GRIB2 data and not
> prepBUFR.
> >
> >
> > I hope that helps. Please let me know if you have any other issues
> getting
> > the tools configured to match your previous run or if you have any
other
> > questions.
> >
> > Thanks,
> > George
> >
> > On Fri, Jun 4, 2021 at 8:21 AM Minna Win via RT
<met_help at ucar.edu>
> wrote:
> >
> > >
> > > Fri Jun 04 08:21:21 2021: Request 100100 was acted upon.
> > > Transaction: Given to mccabe (George McCabe) by minnawin
> > > Queue: met_help
> > > Subject: PB2NC and PointStat questions
> > > Owner: mccabe
> > > Requestors: deanna.spindler at noaa.gov
> > > Status: new
> > > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100100
> >
> > >
> > >
> > > This transaction appears to have no content
> > >
> >
> >
> > --
> > George McCabe - Software Engineer III
> > National Center for Atmospheric Research
> > Research Applications Laboratory
> > 303-497-2768
> > ---
> > My working day may not be your working day. Please do not feel
obliged to
> > reply to this email outside of your normal working hours.
> >
> >
>
>
--
George McCabe - Software Engineer III
National Center for Atmospheric Research
Research Applications Laboratory
303-497-2768
---
My working day may not be your working day. Please do not feel obliged
to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: PB2NC and PointStat questions
From: John Halley Gotway
Time: Tue Jun 08 16:17:23 2021
Deanna,
I'm going to work backwards here. When you run Point-Stat the settings
below define a +/- 30 minute time window around the forecast valid
time:
POINT_STAT_OBS_WINDOW_BEG = -1800
POINT_STAT_OBS_WINDOW_END = 1800
Any point observations occurring within that window will be processed.
But
there may be multiple reports from each station within the 1-hour time
window. The Point-Stat obs_summary config file option defines what to
do in
that case. Search this page for "obs_summary":
https://met.readthedocs.io/en/latest/Users_Guide/config_options.html?highlight=obs_summary#settings-
common-to-multiple-tools
Setting it to NONE and all those multiple obs reports will all be
included
in the stats. I'd recommend considering NEAREST to pick the
observation
value that is closest to the valid time of the forecast and ignoring
the
rest.
I agree that you shouldn't need to use the OBS_VALID_BEG or
OBS_VALID_END
settings for point-stat.
Stepping back to PB2NC, I don't think you'd need to use the
time_summary
option... unless you have some specific use in mind. In general this
is for
pre-processing high time frequency observations. For example, maybe
you
want to derive the hourly maximum amount of cloud cover at a station
that
reports every 5 minutes. You just want to pass through the point
observations to the output NetCDF file. And yes, I agree with George
that
using the PB2NC_VALID_BEG and VALID_END options makes sense.
John
On Tue, Jun 8, 2021 at 2:57 PM George McCabe via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100100 >
>
> Hi Deanna,
>
> 1) To run hourly for the first 48 hours, then 3-hourly for the next
8 days
> (so 10 days of forecasts in total), you should be able to set:
>
> LEAD_SEQ = begin_end_incr(0,48,1), begin_end_incr(48,240,3)
>
> It should expand both lists into a full list of the times you
desire. You
> can test this out by setting it and running the Example wrapper
> (PROCESS_LIST=Example) and see what forecast hours are looped over.
>
>
> 2) I am going to ask John HG to respond about this, because I am not
100%
> sure what the best way to configure this is, but I think you want to
set
> the valid_beg and valid_end values to ensure that the window that is
> retained corresponds to the valid time you are processing.
>
> From the documentation about obs_window:
> * In PB2NC, the reference time is the PREPBUFR files center time. In
> Point-Stat and Ensemble-Stat, the reference time is the forecast
valid
> time. *
>
> From what I recall the center time in the PREPBUFR files can vary,
so
> setting the obs_window values may not get a 3 hour window around the
valid
> time depending on what the center time is. I believe you will want
to set:
>
> PB2NC_VALID_BEGIN = {valid?fmt=%Y%m%d_%H?shift=-3H}
> PB2NC_VALID_END = {valid?fmt=%Y%m%d_%H?shift=3H}
>
>
> 3) I will let John correct me if I'm wrong, but I believe setting
the
> POINT_STAT_OBS_WINDOW_BEG and POINT_STAT_OBS_WINDOW_END values that
you
> listed should gather all of the obs you need for each hour. I don't
know
> that setting the POINT_STAT_OBS_VALID_BEG and
POINT_STAT_OBS_VALID_END
> values would be needed here.
>
> I hope that helps!
>
> Thanks,
> George
>
> On Tue, Jun 8, 2021 at 1:20 PM deanna.spindler at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100100 >
> >
> > Hello George,
> >
> > Thank you very much for answering my questions. As always, now I
have
> > more!
> > I am struggling with understanding how the times (valid/init,
windows,
> etc)
> > are set. Here's what I want to do:
> >
> > 1) Run for each day BUT using all the model output available.
That's why
> I
> > had
> > VALID_BEG = 2021052500
> > VALID_END = 2021052523
> > VALID_INCREMENT = 6H
> > because I want to use every run (00, 06, 12, 18 for GFS-Wave) so
that at
> > any individual location I have four points each day to validate.
> >
> > In my test case I am only looking at LEAD_SEQ = 0, but once it's
working
> > correctly I want to change that to hourly for the first 48 hours,
then
> > 3-hourly for the next 8 days (so 10 days of forecasts in total).
I only
> > know how to do the first part of that:
> > LEAD_SEQ = begin_end_incr(0,48,1)
> >
> > 2) Gather all the observations within a 3H window around each
model run
> > (00, 06, 12, 18):
> > PB2NC_VALID_BEGIN = {valid?fmt=%Y%m%d_%H}
> > PB2NC_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
> > PB2NC_OBS_WINDOW_BEGIN = -10800
> > PB2NC_OBS_WINDOW_END = 10800
> >
> > Question: will this just gather all the data 30 minutes before and
after
> > each hour? will PointStat average it (below in "3") to be at the
hour, or
> > do I have to use
> > PB2NC_TIME_SUMMARY_FLAG = True
> > PB2NC_TIME_SUMMARY_RAW_DATA = False
> > PB2NC_TIME_SUMMARY_BEG = 000000 ;; start time of time summary in
HHMMSS
> > format
> > PB2NC_TIME_SUMMARY_END = 235959 ;; end time of time summary in
HHMMSS
> > format
> > PB2NC_TIME_SUMMARY_STEP = 3600
> > PB2NC_TIME_SUMMARY_WIDTH = 1800
> > to get data that matches the model's "on the hour" output?
> >
> > 3) The model output is hourly, so I only want to compare obs to
model on
> > the hour and I need to account for burst sampling (i.e. the data
will not
> > be "on the hour", so I need to average around the hour)
> > POINT_STAT_OBS_VALID_BEG = {valid?fmt=%Y%m%d_%H}
> > POINT_STAT_OBS_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
> > POINT_STAT_OBS_WINDOW_BEG = -1800
> > POINT_STAT_OBS_WINDOW_END = 1800
> >
> > Is this correct?
> >
> > Thanks,
> > Deanna
> >
> >
> > --
> > Deanna Spindler, PhD
> > Research Oceanographer
> > IMSG at NOAA/NWS/NCEP/Environmental Modeling Center
> > NOAA Center for Weather and Climate Prediction
> >
> >
> > On Mon, Jun 7, 2021 at 10:58 AM George McCabe via RT
<met_help at ucar.edu>
> > wrote:
> >
> > > Hi Deanna,
> > >
> > > I see you have some questions about PB2NC and PointStat.
> > >
> > > 1) The message about the multiple GRIB2 table entry matches is
not
> > actually
> > > a warning. I have reached out to another engineer (John HG) who
is more
> > > familiar to get more information. This is the response:
> > >
> > >
> > >
> > > *"There are multiple instances of "WIND" in the GRIB1 and GRIB2
table
> > files
> > > defined
> > > here:
> >
https://github.com/dtcenter/MET/tree/main_v10.0/met/data/table_files
> > >
<https://github.com/dtcenter/MET/tree/main_v10.0/met/data/table_files
> >*
> > > *This is not a problem. It's very often the case that the same
names
> are
> > > used across different versions and institutions. But I do
realize how
> > the
> > > "using first match found" log message could cause some concern.
That's
> a
> > > hold over from earlier versions of MET where the logic was
problematic.
> > The
> > > existing lookup logic should work fine for Deanna and retrieve
the data
> > > she's looking for. I always recommend that people run
plot_data_plane
> to
> > > confirm that MET is grabbing the data they're looking for."*
> > >
> > > It sounds like it is grabbing the correct data in this case. If
you are
> > > concerned that it may not be, then you can run plot_data_plane
to
> > generate
> > > a plot of the data to see what values are being used.
> > >
> > >
> > > 2) I compared the command you ran in the readme file to the
command
> that
> > > was generated by METplus:
> > >
> > > pb2nc gdas.t18z.prepbufr.nr gdas.t18z.nc PB2NCConfig -valid_beg
> > > 2021052500 -valid_end 2021052523 -log pb2nc.log -v 3
> > >
> > > vs.
> > >
> > > /contrib/met/10.0.0/bin/pb2nc -v 2
> > >
>
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/Prod_GDAS/gdas.20210525/
> > > gdas.t00z.prepbufr.nr
> > >
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna/
> > > gdas.t2021052500z.nc
> > > /contrib/METplus/METplus-
4.0.0/parm/met_config/PB2NCConfig_wrapped
> > >
> > > The command generated by the wrapper does not have the
-valid_beg and
> > > -valid_end arguments. You can set these by using values relative
to the
> > > valid time in PB2NC_VALID_BEGIN and PB2NC_VALID_END. It looks
like you
> > have
> > > the values from the first command set in VALID_BEG and VALID_END
with a
> > > VALID_INCREMENT value of 6 hours. This will loop over those
times and
> > > generate commands for each. I think you want to run once per
day, so I
> > > would set something like this:
> > >
> > > VALID_BEG = 2021052500
> > > VALID_END = 2021052500
> > >
> > > PB2NC_VALID_BEGIN = {valid?fmt=%Y%m%d_%H}
> > > PB2NC_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
> > >
> > > This will run once at valid time 2021-05-25 0Z and use
20210525_00 for
> > > -valid_beg and 20210525_23 for -valid_end.
> > >
> > > It also looks like you are correct that the obs window values
differ.
> In
> > > your METplus log file, I see:
> > >
> > > 06/03 20:43:24.155 metplus INFO:
METPLUS_OBS_WINDOW_DICT=obs_window =
> > {beg
> > > = -10800;end = *10800*;}
> > >
> > > while your PB2NCConfig file has:
> > >
> > > obs_window = {
> > > beg = -10800;
> > > end = *21600*;
> > > }
> > >
> > > To get the same result in PB2NC (-3 hr to +6 hr), you can set:
> > >
> > > PB2NC_OBS_WINDOW_BEGIN = -10800
> > > PB2NC_OBS_WINDOW_END = *21600*
> > >
> > > Your comments say to use -3/+3, so I thought I should point out
that
> the
> > > actual values used in the first example differ from that.
> > >
> > >
> > > Comparing the point_stat commands:
> > >
> > > point_stat gfswave.t00z.global.0p25.f000.grib2 gdas.t18z.nc
> > > PointStatConfig -obs_valid_beg 2021052500 -obs_valid_end
2021052523
> > > -outdir $METPLUS_WAVES_VERIF/test2/output -log pointstat.log -v
3
> > >
> > > vs.
> > >
> > > /contrib/met/10.0.0/bin/point_stat -v 3
> > >
> > >
> >
>
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/Prod_Waves/gfs.20210525/gfswave.t00z.global.0p25.f000.grib2
> > >
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna/
> > > gdas.t2021052500z.nc
> > > /contrib/METplus/METplus-
4.0.0/parm/met_config/PointStatConfig_wrapped
> > > -outdir
> /scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna
> > >
> > > I see that the -obs_valid_beg and -obs_valid_end values are
missing
> from
> > > the generated command. You can set these similarly to the PB2NC
> > arguments:
> > >
> > > POINT_STAT_OBS_VALID_BEG = {valid?fmt=%Y%m%d_%H}
> > > POINT_STAT_OBS_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
> > >
> > > To get the obs_window values to match the first command, you can
set:
> > >
> > > POINT_STAT_OBS_WINDOW_BEG = -1800
> > > POINT_STAT_OBS_WINDOW_END = 1800
> > >
> > >
> > > 3) When reading the wave variables, L# is used to extract a
generic
> level
> > > type (See
> > >
> > >
> >
>
https://met.readthedocs.io/en/latest/Users_Guide/config_options.html#settings-
common-to-multiple-tools
> > > and search for "LNNN" to find the relevant section). I tried
> configuring
> > > PointStatConfig to read from SWELL with levels L1, L2, and L3
and
> > received
> > > different numbers of matched pairs for each, so it appeared to
select
> > each
> > > field. If you want to be certain, you can run plot_data_plane
> specifying
> > > each level and see if the correct results are plotted. You won't
need
> to
> > > configure PB2NC to read this data since it is GRIB2 data and not
> > prepBUFR.
> > >
> > >
> > > I hope that helps. Please let me know if you have any other
issues
> > getting
> > > the tools configured to match your previous run or if you have
any
> other
> > > questions.
> > >
> > > Thanks,
> > > George
> > >
> > > On Fri, Jun 4, 2021 at 8:21 AM Minna Win via RT
<met_help at ucar.edu>
> > wrote:
> > >
> > > >
> > > > Fri Jun 04 08:21:21 2021: Request 100100 was acted upon.
> > > > Transaction: Given to mccabe (George McCabe) by minnawin
> > > > Queue: met_help
> > > > Subject: PB2NC and PointStat questions
> > > > Owner: mccabe
> > > > Requestors: deanna.spindler at noaa.gov
> > > > Status: new
> > > > Ticket <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100100
> > >
> > > >
> > > >
> > > > This transaction appears to have no content
> > > >
> > >
> > >
> > > --
> > > George McCabe - Software Engineer III
> > > National Center for Atmospheric Research
> > > Research Applications Laboratory
> > > 303-497-2768
> > > ---
> > > My working day may not be your working day. Please do not feel
obliged
> to
> > > reply to this email outside of your normal working hours.
> > >
> > >
> >
> >
>
> --
> George McCabe - Software Engineer III
> National Center for Atmospheric Research
> Research Applications Laboratory
> 303-497-2768
> ---
> My working day may not be your working day. Please do not feel
obliged to
> reply to this email outside of your normal working hours.
>
>
------------------------------------------------
Subject: PB2NC and PointStat questions
From: deanna.spindler at noaa.gov
Time: Tue Jun 08 16:36:57 2021
Hello George and John,
Thank you both for answering my emails. I modified the script with
your
suggestions
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/metplus_config/metplus_use_cases/METplusV4.0/gfs/wave/grid2obs/PointStat_fcstGFS_obsGDAS_Wave_Multifield_PrepBufr.conf
I did the PB2NC time summary because wave buoys use burst sampling:
basically high frequency sampling for 10 - 20 minutes (as in every few
seconds), which is then averaged for a sample at the center time.
I think I have PB2NC doing what I want to do, at least when I look at
the
nc files they have what I expect:
> ncdump -v hdr_vld_table gdas.t2021052500z.nc
hdr_vld_table =
"20210524_210000",
"20210524_220000",
"20210524_230000",
"20210525_000000",
"20210525_010000",
"20210525_020000" ;
> ncdump -v obs_var gdas.t2021052500z.nc
obs_var =
"UGRD",
"VGRD",
"WDIR",
"WIND",
"HTSGW",
"PERPW",
"WVHGT",
"WVPER",
"SWELL",
"SWPER" ;
> ncdump -v hdr_typ_table gdas.t2021052500z.nc
hdr_typ_table =
"ADPSFC_MIN_010000",
"ADPSFC_MAX_010000",
"ADPSFC_RANGE_010000",
"ADPSFC_MEAN_010000",
"ADPSFC_SDEV_010000",
"ADPSFC_MEDIAN_010000",
"ADPSFC_P95_010000",
"SFCSHP_MIN_010000",
"SFCSHP_MAX_010000",
"SFCSHP_RANGE_010000",
"SFCSHP_MEAN_010000",
"SFCSHP_SDEV_010000",
"SFCSHP_MEDIAN_010000",
"SFCSHP_P95_010000" ;
But I still get no matched pairs in Point-Stat. From the outfile:
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/v4.0.0/logs/metplus.log.20210608221016
it rejects most obs based on the obs var name and valid time, and some
on
level mismatch and message type - although the only message types in
the nc
files are those that I asked for (ADPSFC and SFCSHP).
The obs_var names in the nc files are what I use in Point-Stat, and
what is
encoded in the model grib2 files.
I don't understand why I am not getting any matched pairs.
Can you help, please?
Thanks,
Deanna
--
Deanna Spindler, PhD
Research Oceanographer
IMSG at NOAA/NWS/NCEP/Environmental Modeling Center
NOAA Center for Weather and Climate Prediction
On Tue, Jun 8, 2021 at 4:57 PM George McCabe via RT
<met_help at ucar.edu>
wrote:
> Hi Deanna,
>
> 1) To run hourly for the first 48 hours, then 3-hourly for the next
8 days
> (so 10 days of forecasts in total), you should be able to set:
>
> LEAD_SEQ = begin_end_incr(0,48,1), begin_end_incr(48,240,3)
>
> It should expand both lists into a full list of the times you
desire. You
> can test this out by setting it and running the Example wrapper
> (PROCESS_LIST=Example) and see what forecast hours are looped over.
>
>
> 2) I am going to ask John HG to respond about this, because I am not
100%
> sure what the best way to configure this is, but I think you want to
set
> the valid_beg and valid_end values to ensure that the window that is
> retained corresponds to the valid time you are processing.
>
> From the documentation about obs_window:
> * In PB2NC, the reference time is the PREPBUFR files center time. In
> Point-Stat and Ensemble-Stat, the reference time is the forecast
valid
> time. *
>
> From what I recall the center time in the PREPBUFR files can vary,
so
> setting the obs_window values may not get a 3 hour window around the
valid
> time depending on what the center time is. I believe you will want
to set:
>
> PB2NC_VALID_BEGIN = {valid?fmt=%Y%m%d_%H?shift=-3H}
> PB2NC_VALID_END = {valid?fmt=%Y%m%d_%H?shift=3H}
>
>
> 3) I will let John correct me if I'm wrong, but I believe setting
the
> POINT_STAT_OBS_WINDOW_BEG and POINT_STAT_OBS_WINDOW_END values that
you
> listed should gather all of the obs you need for each hour. I don't
know
> that setting the POINT_STAT_OBS_VALID_BEG and
POINT_STAT_OBS_VALID_END
> values would be needed here.
>
> I hope that helps!
>
> Thanks,
> George
>
> On Tue, Jun 8, 2021 at 1:20 PM deanna.spindler at noaa.gov via RT <
> met_help at ucar.edu> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100100 >
> >
> > Hello George,
> >
> > Thank you very much for answering my questions. As always, now I
have
> > more!
> > I am struggling with understanding how the times (valid/init,
windows,
> etc)
> > are set. Here's what I want to do:
> >
> > 1) Run for each day BUT using all the model output available.
That's why
> I
> > had
> > VALID_BEG = 2021052500
> > VALID_END = 2021052523
> > VALID_INCREMENT = 6H
> > because I want to use every run (00, 06, 12, 18 for GFS-Wave) so
that at
> > any individual location I have four points each day to validate.
> >
> > In my test case I am only looking at LEAD_SEQ = 0, but once it's
working
> > correctly I want to change that to hourly for the first 48 hours,
then
> > 3-hourly for the next 8 days (so 10 days of forecasts in total).
I only
> > know how to do the first part of that:
> > LEAD_SEQ = begin_end_incr(0,48,1)
> >
> > 2) Gather all the observations within a 3H window around each
model run
> > (00, 06, 12, 18):
> > PB2NC_VALID_BEGIN = {valid?fmt=%Y%m%d_%H}
> > PB2NC_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
> > PB2NC_OBS_WINDOW_BEGIN = -10800
> > PB2NC_OBS_WINDOW_END = 10800
> >
> > Question: will this just gather all the data 30 minutes before and
after
> > each hour? will PointStat average it (below in "3") to be at the
hour, or
> > do I have to use
> > PB2NC_TIME_SUMMARY_FLAG = True
> > PB2NC_TIME_SUMMARY_RAW_DATA = False
> > PB2NC_TIME_SUMMARY_BEG = 000000 ;; start time of time summary in
HHMMSS
> > format
> > PB2NC_TIME_SUMMARY_END = 235959 ;; end time of time summary in
HHMMSS
> > format
> > PB2NC_TIME_SUMMARY_STEP = 3600
> > PB2NC_TIME_SUMMARY_WIDTH = 1800
> > to get data that matches the model's "on the hour" output?
> >
> > 3) The model output is hourly, so I only want to compare obs to
model on
> > the hour and I need to account for burst sampling (i.e. the data
will not
> > be "on the hour", so I need to average around the hour)
> > POINT_STAT_OBS_VALID_BEG = {valid?fmt=%Y%m%d_%H}
> > POINT_STAT_OBS_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
> > POINT_STAT_OBS_WINDOW_BEG = -1800
> > POINT_STAT_OBS_WINDOW_END = 1800
> >
> > Is this correct?
> >
> > Thanks,
> > Deanna
> >
> >
> > --
> > Deanna Spindler, PhD
> > Research Oceanographer
> > IMSG at NOAA/NWS/NCEP/Environmental Modeling Center
> > NOAA Center for Weather and Climate Prediction
> >
> >
> > On Mon, Jun 7, 2021 at 10:58 AM George McCabe via RT
<met_help at ucar.edu>
> > wrote:
> >
> > > Hi Deanna,
> > >
> > > I see you have some questions about PB2NC and PointStat.
> > >
> > > 1) The message about the multiple GRIB2 table entry matches is
not
> > actually
> > > a warning. I have reached out to another engineer (John HG) who
is more
> > > familiar to get more information. This is the response:
> > >
> > >
> > >
> > > *"There are multiple instances of "WIND" in the GRIB1 and GRIB2
table
> > files
> > > defined
> > > here:
> >
https://github.com/dtcenter/MET/tree/main_v10.0/met/data/table_files
> > >
<https://github.com/dtcenter/MET/tree/main_v10.0/met/data/table_files
> >*
> > > *This is not a problem. It's very often the case that the same
names
> are
> > > used across different versions and institutions. But I do
realize how
> > the
> > > "using first match found" log message could cause some concern.
That's
> a
> > > hold over from earlier versions of MET where the logic was
problematic.
> > The
> > > existing lookup logic should work fine for Deanna and retrieve
the data
> > > she's looking for. I always recommend that people run
plot_data_plane
> to
> > > confirm that MET is grabbing the data they're looking for."*
> > >
> > > It sounds like it is grabbing the correct data in this case. If
you are
> > > concerned that it may not be, then you can run plot_data_plane
to
> > generate
> > > a plot of the data to see what values are being used.
> > >
> > >
> > > 2) I compared the command you ran in the readme file to the
command
> that
> > > was generated by METplus:
> > >
> > > pb2nc gdas.t18z.prepbufr.nr gdas.t18z.nc PB2NCConfig -valid_beg
> > > 2021052500 -valid_end 2021052523 -log pb2nc.log -v 3
> > >
> > > vs.
> > >
> > > /contrib/met/10.0.0/bin/pb2nc -v 2
> > >
>
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/Prod_GDAS/gdas.20210525/
> > > gdas.t00z.prepbufr.nr
> > >
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna/
> > > gdas.t2021052500z.nc
> > > /contrib/METplus/METplus-
4.0.0/parm/met_config/PB2NCConfig_wrapped
> > >
> > > The command generated by the wrapper does not have the
-valid_beg and
> > > -valid_end arguments. You can set these by using values relative
to the
> > > valid time in PB2NC_VALID_BEGIN and PB2NC_VALID_END. It looks
like you
> > have
> > > the values from the first command set in VALID_BEG and VALID_END
with a
> > > VALID_INCREMENT value of 6 hours. This will loop over those
times and
> > > generate commands for each. I think you want to run once per
day, so I
> > > would set something like this:
> > >
> > > VALID_BEG = 2021052500
> > > VALID_END = 2021052500
> > >
> > > PB2NC_VALID_BEGIN = {valid?fmt=%Y%m%d_%H}
> > > PB2NC_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
> > >
> > > This will run once at valid time 2021-05-25 0Z and use
20210525_00 for
> > > -valid_beg and 20210525_23 for -valid_end.
> > >
> > > It also looks like you are correct that the obs window values
differ.
> In
> > > your METplus log file, I see:
> > >
> > > 06/03 20:43:24.155 metplus INFO:
METPLUS_OBS_WINDOW_DICT=obs_window =
> > {beg
> > > = -10800;end = *10800*;}
> > >
> > > while your PB2NCConfig file has:
> > >
> > > obs_window = {
> > > beg = -10800;
> > > end = *21600*;
> > > }
> > >
> > > To get the same result in PB2NC (-3 hr to +6 hr), you can set:
> > >
> > > PB2NC_OBS_WINDOW_BEGIN = -10800
> > > PB2NC_OBS_WINDOW_END = *21600*
> > >
> > > Your comments say to use -3/+3, so I thought I should point out
that
> the
> > > actual values used in the first example differ from that.
> > >
> > >
> > > Comparing the point_stat commands:
> > >
> > > point_stat gfswave.t00z.global.0p25.f000.grib2 gdas.t18z.nc
> > > PointStatConfig -obs_valid_beg 2021052500 -obs_valid_end
2021052523
> > > -outdir $METPLUS_WAVES_VERIF/test2/output -log pointstat.log -v
3
> > >
> > > vs.
> > >
> > > /contrib/met/10.0.0/bin/point_stat -v 3
> > >
> > >
> >
>
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/Prod_Waves/gfs.20210525/gfswave.t00z.global.0p25.f000.grib2
> > >
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna/
> > > gdas.t2021052500z.nc
> > > /contrib/METplus/METplus-
4.0.0/parm/met_config/PointStatConfig_wrapped
> > > -outdir
> /scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna
> > >
> > > I see that the -obs_valid_beg and -obs_valid_end values are
missing
> from
> > > the generated command. You can set these similarly to the PB2NC
> > arguments:
> > >
> > > POINT_STAT_OBS_VALID_BEG = {valid?fmt=%Y%m%d_%H}
> > > POINT_STAT_OBS_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
> > >
> > > To get the obs_window values to match the first command, you can
set:
> > >
> > > POINT_STAT_OBS_WINDOW_BEG = -1800
> > > POINT_STAT_OBS_WINDOW_END = 1800
> > >
> > >
> > > 3) When reading the wave variables, L# is used to extract a
generic
> level
> > > type (See
> > >
> > >
> >
>
https://met.readthedocs.io/en/latest/Users_Guide/config_options.html#settings-
common-to-multiple-tools
> > > and search for "LNNN" to find the relevant section). I tried
> configuring
> > > PointStatConfig to read from SWELL with levels L1, L2, and L3
and
> > received
> > > different numbers of matched pairs for each, so it appeared to
select
> > each
> > > field. If you want to be certain, you can run plot_data_plane
> specifying
> > > each level and see if the correct results are plotted. You won't
need
> to
> > > configure PB2NC to read this data since it is GRIB2 data and not
> > prepBUFR.
> > >
> > >
> > > I hope that helps. Please let me know if you have any other
issues
> > getting
> > > the tools configured to match your previous run or if you have
any
> other
> > > questions.
> > >
> > > Thanks,
> > > George
> > >
> > > On Fri, Jun 4, 2021 at 8:21 AM Minna Win via RT
<met_help at ucar.edu>
> > wrote:
> > >
> > > >
> > > > Fri Jun 04 08:21:21 2021: Request 100100 was acted upon.
> > > > Transaction: Given to mccabe (George McCabe) by minnawin
> > > > Queue: met_help
> > > > Subject: PB2NC and PointStat questions
> > > > Owner: mccabe
> > > > Requestors: deanna.spindler at noaa.gov
> > > > Status: new
> > > > Ticket <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100100
> > >
> > > >
> > > >
> > > > This transaction appears to have no content
> > > >
> > >
> > >
> > > --
> > > George McCabe - Software Engineer III
> > > National Center for Atmospheric Research
> > > Research Applications Laboratory
> > > 303-497-2768
> > > ---
> > > My working day may not be your working day. Please do not feel
obliged
> to
> > > reply to this email outside of your normal working hours.
> > >
> > >
> >
> >
>
> --
> George McCabe - Software Engineer III
> National Center for Atmospheric Research
> Research Applications Laboratory
> 303-497-2768
> ---
> My working day may not be your working day. Please do not feel
obliged to
> reply to this email outside of your normal working hours.
>
>
------------------------------------------------
Subject: PB2NC and PointStat questions
From: George McCabe
Time: Tue Jun 08 17:42:00 2021
Hi Deanna,
It looks like you don't have message type set in the METplus config
file:
06/08 22:12:47.671 metplus INFO: METPLUS_MESSAGE_TYPE=
This uses the default value in the default MET config file:
DEBUG 1: Default Config File:
/contrib/met/10.0.0/share/met/config/PointStatConfig_default
In this file, you can see that the default value is:
message_type = [ "ADPUPA" ];
Try setting this in your METplus config file:
POINT_STAT_MESSAGE_TYPE = {PB2NC_MESSAGE_TYPE}
You can also try specifying a range of levels for the observation data
since some of the observations may not be exactly at the level you
specified. For example: OBS_VAR1_LEVELS = Z10-20 will get any
observation
between 10 and 20.
Another tip: If you set LOG_LEVEL=DEBUG in your METplus config, the
log
output will include a set of copyable environment variables right
before
the command that is run. You can paste that into your terminal then
run the
command by hand, then change some environment variables to see how it
affects the output. The environment variables that start with METPLUS_
are
used in version 4.0.0. The other variables are only in there to
support
older wrapped MET config files. You can also add this to a command
line
call to run_metplus.py by adding
config.LOG_LEVEL=DEBUG
at the end of the command. Let me know if you are still unable to
produce
any matched pairs. If you turn on DEBUG output then it will be easier
to
recreate the environment for the command and determine what settings
need
to be adjusted.
Thanks,
George
On Tue, Jun 8, 2021 at 4:37 PM deanna.spindler at noaa.gov via RT <
met_help at ucar.edu> wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100100 >
>
> Hello George and John,
>
> Thank you both for answering my emails. I modified the script with
your
> suggestions
>
>
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/metplus_config/metplus_use_cases/METplusV4.0/gfs/wave/grid2obs/PointStat_fcstGFS_obsGDAS_Wave_Multifield_PrepBufr.conf
>
> I did the PB2NC time summary because wave buoys use burst sampling:
> basically high frequency sampling for 10 - 20 minutes (as in every
few
> seconds), which is then averaged for a sample at the center time.
>
> I think I have PB2NC doing what I want to do, at least when I look
at the
> nc files they have what I expect:
> > ncdump -v hdr_vld_table gdas.t2021052500z.nc
> hdr_vld_table =
> "20210524_210000",
> "20210524_220000",
> "20210524_230000",
> "20210525_000000",
> "20210525_010000",
> "20210525_020000" ;
> > ncdump -v obs_var gdas.t2021052500z.nc
> obs_var =
> "UGRD",
> "VGRD",
> "WDIR",
> "WIND",
> "HTSGW",
> "PERPW",
> "WVHGT",
> "WVPER",
> "SWELL",
> "SWPER" ;
> > ncdump -v hdr_typ_table gdas.t2021052500z.nc
> hdr_typ_table =
> "ADPSFC_MIN_010000",
> "ADPSFC_MAX_010000",
> "ADPSFC_RANGE_010000",
> "ADPSFC_MEAN_010000",
> "ADPSFC_SDEV_010000",
> "ADPSFC_MEDIAN_010000",
> "ADPSFC_P95_010000",
> "SFCSHP_MIN_010000",
> "SFCSHP_MAX_010000",
> "SFCSHP_RANGE_010000",
> "SFCSHP_MEAN_010000",
> "SFCSHP_SDEV_010000",
> "SFCSHP_MEDIAN_010000",
> "SFCSHP_P95_010000" ;
>
> But I still get no matched pairs in Point-Stat. From the outfile:
>
>
>
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/v4.0.0/logs/metplus.log.20210608221016
> it rejects most obs based on the obs var name and valid time, and
some on
> level mismatch and message type - although the only message types in
the nc
> files are those that I asked for (ADPSFC and SFCSHP).
> The obs_var names in the nc files are what I use in Point-Stat, and
what is
> encoded in the model grib2 files.
> I don't understand why I am not getting any matched pairs.
>
> Can you help, please?
>
> Thanks,
> Deanna
>
> --
> Deanna Spindler, PhD
> Research Oceanographer
> IMSG at NOAA/NWS/NCEP/Environmental Modeling Center
> NOAA Center for Weather and Climate Prediction
>
>
> On Tue, Jun 8, 2021 at 4:57 PM George McCabe via RT
<met_help at ucar.edu>
> wrote:
>
> > Hi Deanna,
> >
> > 1) To run hourly for the first 48 hours, then 3-hourly for the
next 8
> days
> > (so 10 days of forecasts in total), you should be able to set:
> >
> > LEAD_SEQ = begin_end_incr(0,48,1), begin_end_incr(48,240,3)
> >
> > It should expand both lists into a full list of the times you
desire. You
> > can test this out by setting it and running the Example wrapper
> > (PROCESS_LIST=Example) and see what forecast hours are looped
over.
> >
> >
> > 2) I am going to ask John HG to respond about this, because I am
not 100%
> > sure what the best way to configure this is, but I think you want
to set
> > the valid_beg and valid_end values to ensure that the window that
is
> > retained corresponds to the valid time you are processing.
> >
> > From the documentation about obs_window:
> > * In PB2NC, the reference time is the PREPBUFR files center time.
In
> > Point-Stat and Ensemble-Stat, the reference time is the forecast
valid
> > time. *
> >
> > From what I recall the center time in the PREPBUFR files can vary,
so
> > setting the obs_window values may not get a 3 hour window around
the
> valid
> > time depending on what the center time is. I believe you will want
to
> set:
> >
> > PB2NC_VALID_BEGIN = {valid?fmt=%Y%m%d_%H?shift=-3H}
> > PB2NC_VALID_END = {valid?fmt=%Y%m%d_%H?shift=3H}
> >
> >
> > 3) I will let John correct me if I'm wrong, but I believe setting
the
> > POINT_STAT_OBS_WINDOW_BEG and POINT_STAT_OBS_WINDOW_END values
that you
> > listed should gather all of the obs you need for each hour. I
don't know
> > that setting the POINT_STAT_OBS_VALID_BEG and
POINT_STAT_OBS_VALID_END
> > values would be needed here.
> >
> > I hope that helps!
> >
> > Thanks,
> > George
> >
> > On Tue, Jun 8, 2021 at 1:20 PM deanna.spindler at noaa.gov via RT <
> > met_help at ucar.edu> wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100100 >
> > >
> > > Hello George,
> > >
> > > Thank you very much for answering my questions. As always, now
I have
> > > more!
> > > I am struggling with understanding how the times (valid/init,
windows,
> > etc)
> > > are set. Here's what I want to do:
> > >
> > > 1) Run for each day BUT using all the model output available.
That's
> why
> > I
> > > had
> > > VALID_BEG = 2021052500
> > > VALID_END = 2021052523
> > > VALID_INCREMENT = 6H
> > > because I want to use every run (00, 06, 12, 18 for GFS-Wave) so
that
> at
> > > any individual location I have four points each day to validate.
> > >
> > > In my test case I am only looking at LEAD_SEQ = 0, but once it's
> working
> > > correctly I want to change that to hourly for the first 48
hours, then
> > > 3-hourly for the next 8 days (so 10 days of forecasts in total).
I
> only
> > > know how to do the first part of that:
> > > LEAD_SEQ = begin_end_incr(0,48,1)
> > >
> > > 2) Gather all the observations within a 3H window around each
model run
> > > (00, 06, 12, 18):
> > > PB2NC_VALID_BEGIN = {valid?fmt=%Y%m%d_%H}
> > > PB2NC_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
> > > PB2NC_OBS_WINDOW_BEGIN = -10800
> > > PB2NC_OBS_WINDOW_END = 10800
> > >
> > > Question: will this just gather all the data 30 minutes before
and
> after
> > > each hour? will PointStat average it (below in "3") to be at the
hour,
> or
> > > do I have to use
> > > PB2NC_TIME_SUMMARY_FLAG = True
> > > PB2NC_TIME_SUMMARY_RAW_DATA = False
> > > PB2NC_TIME_SUMMARY_BEG = 000000 ;; start time of time summary
in
> HHMMSS
> > > format
> > > PB2NC_TIME_SUMMARY_END = 235959 ;; end time of time summary in
HHMMSS
> > > format
> > > PB2NC_TIME_SUMMARY_STEP = 3600
> > > PB2NC_TIME_SUMMARY_WIDTH = 1800
> > > to get data that matches the model's "on the hour" output?
> > >
> > > 3) The model output is hourly, so I only want to compare obs to
model
> on
> > > the hour and I need to account for burst sampling (i.e. the data
will
> not
> > > be "on the hour", so I need to average around the hour)
> > > POINT_STAT_OBS_VALID_BEG = {valid?fmt=%Y%m%d_%H}
> > > POINT_STAT_OBS_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
> > > POINT_STAT_OBS_WINDOW_BEG = -1800
> > > POINT_STAT_OBS_WINDOW_END = 1800
> > >
> > > Is this correct?
> > >
> > > Thanks,
> > > Deanna
> > >
> > >
> > > --
> > > Deanna Spindler, PhD
> > > Research Oceanographer
> > > IMSG at NOAA/NWS/NCEP/Environmental Modeling Center
> > > NOAA Center for Weather and Climate Prediction
> > >
> > >
> > > On Mon, Jun 7, 2021 at 10:58 AM George McCabe via RT <
> met_help at ucar.edu>
> > > wrote:
> > >
> > > > Hi Deanna,
> > > >
> > > > I see you have some questions about PB2NC and PointStat.
> > > >
> > > > 1) The message about the multiple GRIB2 table entry matches is
not
> > > actually
> > > > a warning. I have reached out to another engineer (John HG)
who is
> more
> > > > familiar to get more information. This is the response:
> > > >
> > > >
> > > >
> > > > *"There are multiple instances of "WIND" in the GRIB1 and
GRIB2 table
> > > files
> > > > defined
> > > > here:
> > >
https://github.com/dtcenter/MET/tree/main_v10.0/met/data/table_files
> > > > <
> https://github.com/dtcenter/MET/tree/main_v10.0/met/data/table_files
> > >*
> > > > *This is not a problem. It's very often the case that the same
names
> > are
> > > > used across different versions and institutions. But I do
realize
> how
> > > the
> > > > "using first match found" log message could cause some
concern.
> That's
> > a
> > > > hold over from earlier versions of MET where the logic was
> problematic.
> > > The
> > > > existing lookup logic should work fine for Deanna and retrieve
the
> data
> > > > she's looking for. I always recommend that people run
plot_data_plane
> > to
> > > > confirm that MET is grabbing the data they're looking for."*
> > > >
> > > > It sounds like it is grabbing the correct data in this case.
If you
> are
> > > > concerned that it may not be, then you can run plot_data_plane
to
> > > generate
> > > > a plot of the data to see what values are being used.
> > > >
> > > >
> > > > 2) I compared the command you ran in the readme file to the
command
> > that
> > > > was generated by METplus:
> > > >
> > > > pb2nc gdas.t18z.prepbufr.nr gdas.t18z.nc PB2NCConfig
-valid_beg
> > > > 2021052500 -valid_end 2021052523 -log pb2nc.log -v 3
> > > >
> > > > vs.
> > > >
> > > > /contrib/met/10.0.0/bin/pb2nc -v 2
> > > >
> >
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/Prod_GDAS/gdas.20210525/
> > > > gdas.t00z.prepbufr.nr
> > > >
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna/
> > > > gdas.t2021052500z.nc
> > > > /contrib/METplus/METplus-
4.0.0/parm/met_config/PB2NCConfig_wrapped
> > > >
> > > > The command generated by the wrapper does not have the
-valid_beg and
> > > > -valid_end arguments. You can set these by using values
relative to
> the
> > > > valid time in PB2NC_VALID_BEGIN and PB2NC_VALID_END. It looks
like
> you
> > > have
> > > > the values from the first command set in VALID_BEG and
VALID_END
> with a
> > > > VALID_INCREMENT value of 6 hours. This will loop over those
times and
> > > > generate commands for each. I think you want to run once per
day, so
> I
> > > > would set something like this:
> > > >
> > > > VALID_BEG = 2021052500
> > > > VALID_END = 2021052500
> > > >
> > > > PB2NC_VALID_BEGIN = {valid?fmt=%Y%m%d_%H}
> > > > PB2NC_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
> > > >
> > > > This will run once at valid time 2021-05-25 0Z and use
20210525_00
> for
> > > > -valid_beg and 20210525_23 for -valid_end.
> > > >
> > > > It also looks like you are correct that the obs window values
differ.
> > In
> > > > your METplus log file, I see:
> > > >
> > > > 06/03 20:43:24.155 metplus INFO:
METPLUS_OBS_WINDOW_DICT=obs_window =
> > > {beg
> > > > = -10800;end = *10800*;}
> > > >
> > > > while your PB2NCConfig file has:
> > > >
> > > > obs_window = {
> > > > beg = -10800;
> > > > end = *21600*;
> > > > }
> > > >
> > > > To get the same result in PB2NC (-3 hr to +6 hr), you can set:
> > > >
> > > > PB2NC_OBS_WINDOW_BEGIN = -10800
> > > > PB2NC_OBS_WINDOW_END = *21600*
> > > >
> > > > Your comments say to use -3/+3, so I thought I should point
out that
> > the
> > > > actual values used in the first example differ from that.
> > > >
> > > >
> > > > Comparing the point_stat commands:
> > > >
> > > > point_stat gfswave.t00z.global.0p25.f000.grib2 gdas.t18z.nc
> > > > PointStatConfig -obs_valid_beg 2021052500 -obs_valid_end
2021052523
> > > > -outdir $METPLUS_WAVES_VERIF/test2/output -log pointstat.log
-v 3
> > > >
> > > > vs.
> > > >
> > > > /contrib/met/10.0.0/bin/point_stat -v 3
> > > >
> > > >
> > >
> >
>
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/Prod_Waves/gfs.20210525/gfswave.t00z.global.0p25.f000.grib2
> > > >
/scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna/
> > > > gdas.t2021052500z.nc
> > > >
> /contrib/METplus/METplus-
4.0.0/parm/met_config/PointStatConfig_wrapped
> > > > -outdir
> > /scratch2/NCEPDEV/ocean/Deanna.Spindler/save/MET/output/BigKahuna
> > > >
> > > > I see that the -obs_valid_beg and -obs_valid_end values are
missing
> > from
> > > > the generated command. You can set these similarly to the
PB2NC
> > > arguments:
> > > >
> > > > POINT_STAT_OBS_VALID_BEG = {valid?fmt=%Y%m%d_%H}
> > > > POINT_STAT_OBS_VALID_END = {valid?fmt=%Y%m%d_%H?shift=23H}
> > > >
> > > > To get the obs_window values to match the first command, you
can set:
> > > >
> > > > POINT_STAT_OBS_WINDOW_BEG = -1800
> > > > POINT_STAT_OBS_WINDOW_END = 1800
> > > >
> > > >
> > > > 3) When reading the wave variables, L# is used to extract a
generic
> > level
> > > > type (See
> > > >
> > > >
> > >
> >
>
https://met.readthedocs.io/en/latest/Users_Guide/config_options.html#settings-
common-to-multiple-tools
> > > > and search for "LNNN" to find the relevant section). I tried
> > configuring
> > > > PointStatConfig to read from SWELL with levels L1, L2, and L3
and
> > > received
> > > > different numbers of matched pairs for each, so it appeared to
select
> > > each
> > > > field. If you want to be certain, you can run plot_data_plane
> > specifying
> > > > each level and see if the correct results are plotted. You
won't need
> > to
> > > > configure PB2NC to read this data since it is GRIB2 data and
not
> > > prepBUFR.
> > > >
> > > >
> > > > I hope that helps. Please let me know if you have any other
issues
> > > getting
> > > > the tools configured to match your previous run or if you have
any
> > other
> > > > questions.
> > > >
> > > > Thanks,
> > > > George
> > > >
> > > > On Fri, Jun 4, 2021 at 8:21 AM Minna Win via RT
<met_help at ucar.edu>
> > > wrote:
> > > >
> > > > >
> > > > > Fri Jun 04 08:21:21 2021: Request 100100 was acted upon.
> > > > > Transaction: Given to mccabe (George McCabe) by minnawin
> > > > > Queue: met_help
> > > > > Subject: PB2NC and PointStat questions
> > > > > Owner: mccabe
> > > > > Requestors: deanna.spindler at noaa.gov
> > > > > Status: new
> > > > > Ticket <URL:
> > https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=100100
> > > >
> > > > >
> > > > >
> > > > > This transaction appears to have no content
> > > > >
> > > >
> > > >
> > > > --
> > > > George McCabe - Software Engineer III
> > > > National Center for Atmospheric Research
> > > > Research Applications Laboratory
> > > > 303-497-2768
> > > > ---
> > > > My working day may not be your working day. Please do not feel
> obliged
> > to
> > > > reply to this email outside of your normal working hours.
> > > >
> > > >
> > >
> > >
> >
> > --
> > George McCabe - Software Engineer III
> > National Center for Atmospheric Research
> > Research Applications Laboratory
> > 303-497-2768
> > ---
> > My working day may not be your working day. Please do not feel
obliged to
> > reply to this email outside of your normal working hours.
> >
> >
>
>
--
George McCabe - Software Engineer III
National Center for Atmospheric Research
Research Applications Laboratory
303-497-2768
---
My working day may not be your working day. Please do not feel obliged
to
reply to this email outside of your normal working hours.
------------------------------------------------
More information about the Met_help
mailing list