[Met_help] [rt.rap.ucar.edu #93824] History for METplus: set input for FCST_PCP_COMBINE_ADD to be from the same model cycle?
George McCabe via RT
met_help at ucar.edu
Tue Jan 28 13:38:48 MST 2020
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello. I noticed that when I'm running 24h verification for a model with a
3h APCP accumulation bucket, the 3-hourly QPF amounts to be added into a
24h total do not come from the same model cycle, e.g. it looks something
like this:
... /noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine -name APCP_24
-add \
$PATH/hiresw.20200112/hiresw.t12z.nmmb_5km.f00.conus.grib2 3 \
$PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f09.conus.grib2 3 \
$PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f06.conus.grib2 3 \
$PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f03.conus.grib2 3 \
$PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f00.conus.grib2 3 \
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f09.conus.grib2 3 \
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f06.conus.grib2 3 \
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f03.conus.grib2 3 \
*/conusnmmb/bucket/20200112/conusnmmb.v2020011212_f024_a24h -v 5
(from the attached master_metplus.log.* file, with some editing ($PATH) to
make it more readable). What I actually meant to have pcp_combine do is
like this:
... /noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine -name APCP_24
-add \
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f03.conus.grib2 3 \
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f06.conus.grib2 3 \
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f09.conus.grib2 3 \
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f12.conus.grib2 3 \
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f15.conus.grib2 3 \
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f18.conus.grib2 3 \
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f21.conus.grib2 3 \
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f24.conus.grib2 3 \
*/conusnmmb/bucket/20200112/conusnmmb.v2020011212_f024_a24h -v 5
i.e. all 3h APCP should come from the same model forecast cycle. Is there
something I should have specified in the model config file (attached
conusnmmb_24h.conf) to specify that constraint? I see that in the
parm/use_cases/qpf/examples/nationalblend-vs-mrms-qpe.conf and several
others, there is "LOOP_BY = INIT" (I have "LOOP_BY = VALID") and I'll try
"LOOP_BY = INIT" to see if that works, but if in the model config I could
have specified "all component QPFs for a pcp_combine should be from the
same model run cycle" that would be great (the use cases with "LOOP_BY =
INIT" all have just one initial time; this could get complicated with
routine verifications for four-cycle-per-day models).
Thank you -
Yin
---
Ying Lin
NCEP/EMC/Verification, Post-processing and Product Generation Branch
NCWCP Cubicle No. 2015
Ying.Lin at noaa.gov
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: METplus: set input for FCST_PCP_COMBINE_ADD to be from the same model cycle?
From: Minna Win
Time: Thu Jan 16 12:36:13 2020
Hi Ying,
It looks like you are having some issues setting up METplus and MET
for
your QPF use case. I'm assigning this ticket to George McCabe, who is
familiar with the QPF use case and the PcpCombine METplus wrapper.
Please
allow a few business days for a complete reply.
Regards,
Minna
---------------
Minna Win
National Center for Atmospheric Research
Developmental Testbed Center
Phone: 303-497-8423
Fax: 303-497-8401
On Thu, Jan 16, 2020 at 10:26 AM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
> Thu Jan 16 10:25:12 2020: Request 93824 was acted upon.
> Transaction: Ticket created by ying.lin at noaa.gov
> Queue: met_help
> Subject: METplus: set input for FCST_PCP_COMBINE_ADD to be from
the
> same model cycle?
> Owner: Nobody
> Requestors: ying.lin at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93824 >
>
>
> Hello. I noticed that when I'm running 24h verification for a model
with a
> 3h APCP accumulation bucket, the 3-hourly QPF amounts to be added
into a
> 24h total do not come from the same model cycle, e.g. it looks
something
> like this:
>
> ... /noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine -name
APCP_24
> -add \
> $PATH/hiresw.20200112/hiresw.t12z.nmmb_5km.f00.conus.grib2 3
\
> $PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f09.conus.grib2 3
\
> $PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f06.conus.grib2 3
\
> $PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f03.conus.grib2 3
\
> $PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f00.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f09.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f06.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f03.conus.grib2 3
\
> */conusnmmb/bucket/20200112/conusnmmb.v2020011212_f024_a24h
-v 5
>
> (from the attached master_metplus.log.* file, with some editing
($PATH) to
> make it more readable). What I actually meant to have pcp_combine
do is
> like this:
> ... /noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine -name
APCP_24
> -add \
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f03.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f06.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f09.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f12.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f15.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f18.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f21.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f24.conus.grib2 3
\
> */conusnmmb/bucket/20200112/conusnmmb.v2020011212_f024_a24h
-v 5
>
> i.e. all 3h APCP should come from the same model forecast cycle. Is
there
> something I should have specified in the model config file (attached
> conusnmmb_24h.conf) to specify that constraint? I see that in the
> parm/use_cases/qpf/examples/nationalblend-vs-mrms-qpe.conf and
several
> others, there is "LOOP_BY = INIT" (I have "LOOP_BY = VALID") and
I'll try
> "LOOP_BY = INIT" to see if that works, but if in the model config I
could
> have specified "all component QPFs for a pcp_combine should be from
the
> same model run cycle" that would be great (the use cases with
"LOOP_BY =
> INIT" all have just one initial time; this could get complicated
with
> routine verifications for four-cycle-per-day models).
>
> Thank you -
>
> Yin
>
> ---
> Ying Lin
> NCEP/EMC/Verification, Post-processing and Product Generation Branch
> NCWCP Cubicle No. 2015
> Ying.Lin at noaa.gov
>
>
------------------------------------------------
Subject: METplus: set input for FCST_PCP_COMBINE_ADD to be from the same model cycle?
From: George McCabe
Time: Thu Jan 16 12:40:34 2020
Hi Ying,
The PCPCombine wrapper tries to be clever and find the lowest possible
forecast lead associated with each valid time it is trying to find.
While
this was useful for another use case, it appears to be causing
problems
with this case. It looks like we may need an option to have the script
find
the forecast files differently than forcing it to get the lowest
forecast
lead. I could add an option to force it to use a constant init time
(FCST_PCP_COMBINE_CONSTANT_INIT?) and if that is set, it will only
find
files that have the init time of the current run. Does that sound like
a
solution that would work for you? If so, I can try to get this change
in
before the next release code freeze.
On Thu, Jan 16, 2020 at 5:26 PM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
> Thu Jan 16 10:25:12 2020: Request 93824 was acted upon.
> Transaction: Ticket created by ying.lin at noaa.gov
> Queue: met_help
> Subject: METplus: set input for FCST_PCP_COMBINE_ADD to be from
the
> same model cycle?
> Owner: Nobody
> Requestors: ying.lin at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93824 >
>
>
> Hello. I noticed that when I'm running 24h verification for a model
with a
> 3h APCP accumulation bucket, the 3-hourly QPF amounts to be added
into a
> 24h total do not come from the same model cycle, e.g. it looks
something
> like this:
>
> ... /noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine -name
APCP_24
> -add \
> $PATH/hiresw.20200112/hiresw.t12z.nmmb_5km.f00.conus.grib2 3
\
> $PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f09.conus.grib2 3
\
> $PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f06.conus.grib2 3
\
> $PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f03.conus.grib2 3
\
> $PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f00.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f09.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f06.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f03.conus.grib2 3
\
> */conusnmmb/bucket/20200112/conusnmmb.v2020011212_f024_a24h
-v 5
>
> (from the attached master_metplus.log.* file, with some editing
($PATH) to
> make it more readable). What I actually meant to have pcp_combine
do is
> like this:
> ... /noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine -name
APCP_24
> -add \
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f03.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f06.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f09.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f12.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f15.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f18.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f21.conus.grib2 3
\
> $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f24.conus.grib2 3
\
> */conusnmmb/bucket/20200112/conusnmmb.v2020011212_f024_a24h
-v 5
>
> i.e. all 3h APCP should come from the same model forecast cycle. Is
there
> something I should have specified in the model config file (attached
> conusnmmb_24h.conf) to specify that constraint? I see that in the
> parm/use_cases/qpf/examples/nationalblend-vs-mrms-qpe.conf and
several
> others, there is "LOOP_BY = INIT" (I have "LOOP_BY = VALID") and
I'll try
> "LOOP_BY = INIT" to see if that works, but if in the model config I
could
> have specified "all component QPFs for a pcp_combine should be from
the
> same model run cycle" that would be great (the use cases with
"LOOP_BY =
> INIT" all have just one initial time; this could get complicated
with
> routine verifications for four-cycle-per-day models).
>
> Thank you -
>
> Yin
>
> ---
> Ying Lin
> NCEP/EMC/Verification, Post-processing and Product Generation Branch
> NCWCP Cubicle No. 2015
> Ying.Lin at noaa.gov
>
>
--
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: METplus: set input for FCST_PCP_COMBINE_ADD to be from the same model cycle?
From: Ying Lin
Time: Thu Jan 16 13:35:25 2020
Hi George (and Minna),
Thank you for your quick response. Yes, please add the
FCST_PCP_COMBINE_CONSTANT_INIT, that'll be really useful for precip
(the
more "modern" models - the FV3s, the Canadians, the RAP/HRRR - have
continuously-accumulating precip buckets now but some models don't).
Would
this be added to METplus 3?
Ying
---
Ying Lin
NCEP/EMC/Verification, Post-processing and Product Generation Branch
NCWCP Cubicle No. 2015
Ying.Lin at noaa.gov
On Thu, Jan 16, 2020 at 2:40 PM George McCabe via RT
<met_help at ucar.edu>
wrote:
> Hi Ying,
>
> The PCPCombine wrapper tries to be clever and find the lowest
possible
> forecast lead associated with each valid time it is trying to find.
While
> this was useful for another use case, it appears to be causing
problems
> with this case. It looks like we may need an option to have the
script find
> the forecast files differently than forcing it to get the lowest
forecast
> lead. I could add an option to force it to use a constant init time
> (FCST_PCP_COMBINE_CONSTANT_INIT?) and if that is set, it will only
find
> files that have the init time of the current run. Does that sound
like a
> solution that would work for you? If so, I can try to get this
change in
> before the next release code freeze.
>
> On Thu, Jan 16, 2020 at 5:26 PM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
> >
> > Thu Jan 16 10:25:12 2020: Request 93824 was acted upon.
> > Transaction: Ticket created by ying.lin at noaa.gov
> > Queue: met_help
> > Subject: METplus: set input for FCST_PCP_COMBINE_ADD to be
from the
> > same model cycle?
> > Owner: Nobody
> > Requestors: ying.lin at noaa.gov
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93824 >
> >
> >
> > Hello. I noticed that when I'm running 24h verification for a
model
> with a
> > 3h APCP accumulation bucket, the 3-hourly QPF amounts to be added
into a
> > 24h total do not come from the same model cycle, e.g. it looks
something
> > like this:
> >
> > ... /noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine -name
APCP_24
> > -add \
> > $PATH/hiresw.20200112/hiresw.t12z.nmmb_5km.f00.conus.grib2
3 \
> > $PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f09.conus.grib2
3 \
> > $PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f06.conus.grib2
3 \
> > $PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f03.conus.grib2
3 \
> > $PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f00.conus.grib2
3 \
> > $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f09.conus.grib2
3 \
> > $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f06.conus.grib2
3 \
> > $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f03.conus.grib2
3 \
> >
*/conusnmmb/bucket/20200112/conusnmmb.v2020011212_f024_a24h -v 5
> >
> > (from the attached master_metplus.log.* file, with some editing
($PATH)
> to
> > make it more readable). What I actually meant to have pcp_combine
do is
> > like this:
> > ... /noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine -name
APCP_24
> > -add \
> > $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f03.conus.grib2
3 \
> > $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f06.conus.grib2
3 \
> > $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f09.conus.grib2
3 \
> > $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f12.conus.grib2
3 \
> > $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f15.conus.grib2
3 \
> > $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f18.conus.grib2
3 \
> > $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f21.conus.grib2
3 \
> > $PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f24.conus.grib2
3 \
> >
*/conusnmmb/bucket/20200112/conusnmmb.v2020011212_f024_a24h -v 5
> >
> > i.e. all 3h APCP should come from the same model forecast cycle.
Is
> there
> > something I should have specified in the model config file
(attached
> > conusnmmb_24h.conf) to specify that constraint? I see that in the
> > parm/use_cases/qpf/examples/nationalblend-vs-mrms-qpe.conf and
several
> > others, there is "LOOP_BY = INIT" (I have "LOOP_BY = VALID") and
I'll try
> > "LOOP_BY = INIT" to see if that works, but if in the model config
I could
> > have specified "all component QPFs for a pcp_combine should be
from the
> > same model run cycle" that would be great (the use cases with
"LOOP_BY =
> > INIT" all have just one initial time; this could get complicated
with
> > routine verifications for four-cycle-per-day models).
> >
> > Thank you -
> >
> > Yin
> >
> > ---
> > Ying Lin
> > NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> > NCWCP Cubicle No. 2015
> > Ying.Lin at noaa.gov
> >
> >
>
> --
> 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: METplus: set input for FCST_PCP_COMBINE_ADD to be from the same model cycle?
From: George McCabe
Time: Thu Jan 16 15:06:18 2020
Hi Ying,
I should be able to get this into the 3.0 release. We are freezing the
code
on Friday. Would you be willing to test the changes to make sure it
selects
the correct files? It would be easier to make sure it picks the files
correctly with a full dataset. I think I recall you tested a beta
release
that uses Python 3 for METplus a little while ago. Is that correct?
Let me
know and I can send you a beta release to test.
On Thu, Jan 16, 2020 at 8:35 PM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93824 >
>
> Hi George (and Minna),
>
> Thank you for your quick response. Yes, please add the
> FCST_PCP_COMBINE_CONSTANT_INIT, that'll be really useful for precip
(the
> more "modern" models - the FV3s, the Canadians, the RAP/HRRR - have
> continuously-accumulating precip buckets now but some models don't).
Would
> this be added to METplus 3?
>
> Ying
> ---
> Ying Lin
> NCEP/EMC/Verification, Post-processing and Product Generation Branch
> NCWCP Cubicle No. 2015
> Ying.Lin at noaa.gov
>
>
>
> On Thu, Jan 16, 2020 at 2:40 PM George McCabe via RT
<met_help at ucar.edu>
> wrote:
>
> > Hi Ying,
> >
> > The PCPCombine wrapper tries to be clever and find the lowest
possible
> > forecast lead associated with each valid time it is trying to
find. While
> > this was useful for another use case, it appears to be causing
problems
> > with this case. It looks like we may need an option to have the
script
> find
> > the forecast files differently than forcing it to get the lowest
forecast
> > lead. I could add an option to force it to use a constant init
time
> > (FCST_PCP_COMBINE_CONSTANT_INIT?) and if that is set, it will only
find
> > files that have the init time of the current run. Does that sound
like a
> > solution that would work for you? If so, I can try to get this
change in
> > before the next release code freeze.
> >
> > On Thu, Jan 16, 2020 at 5:26 PM Ying Lin via RT
<met_help at ucar.edu>
> wrote:
> >
> > >
> > > Thu Jan 16 10:25:12 2020: Request 93824 was acted upon.
> > > Transaction: Ticket created by ying.lin at noaa.gov
> > > Queue: met_help
> > > Subject: METplus: set input for FCST_PCP_COMBINE_ADD to be
from
> the
> > > same model cycle?
> > > Owner: Nobody
> > > Requestors: ying.lin at noaa.gov
> > > Status: new
> > > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93824
> >
> > >
> > >
> > > Hello. I noticed that when I'm running 24h verification for a
model
> > with a
> > > 3h APCP accumulation bucket, the 3-hourly QPF amounts to be
added into
> a
> > > 24h total do not come from the same model cycle, e.g. it looks
> something
> > > like this:
> > >
> > > ... /noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine -name
APCP_24
> > > -add \
> > >
$PATH/hiresw.20200112/hiresw.t12z.nmmb_5km.f00.conus.grib2 3 \
> > >
$PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f09.conus.grib2 3 \
> > >
$PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f06.conus.grib2 3 \
> > >
$PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f03.conus.grib2 3 \
> > >
$PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f00.conus.grib2 3 \
> > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f09.conus.grib2 3 \
> > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f06.conus.grib2 3 \
> > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f03.conus.grib2 3 \
> > >
*/conusnmmb/bucket/20200112/conusnmmb.v2020011212_f024_a24h -v
> 5
> > >
> > > (from the attached master_metplus.log.* file, with some editing
($PATH)
> > to
> > > make it more readable). What I actually meant to have
pcp_combine do
> is
> > > like this:
> > > ... /noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine -name
APCP_24
> > > -add \
> > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f03.conus.grib2 3 \
> > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f06.conus.grib2 3 \
> > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f09.conus.grib2 3 \
> > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f12.conus.grib2 3 \
> > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f15.conus.grib2 3 \
> > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f18.conus.grib2 3 \
> > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f21.conus.grib2 3 \
> > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f24.conus.grib2 3 \
> > >
*/conusnmmb/bucket/20200112/conusnmmb.v2020011212_f024_a24h -v
> 5
> > >
> > > i.e. all 3h APCP should come from the same model forecast cycle.
Is
> > there
> > > something I should have specified in the model config file
(attached
> > > conusnmmb_24h.conf) to specify that constraint? I see that in
the
> > > parm/use_cases/qpf/examples/nationalblend-vs-mrms-qpe.conf and
several
> > > others, there is "LOOP_BY = INIT" (I have "LOOP_BY = VALID") and
I'll
> try
> > > "LOOP_BY = INIT" to see if that works, but if in the model
config I
> could
> > > have specified "all component QPFs for a pcp_combine should be
from the
> > > same model run cycle" that would be great (the use cases with
"LOOP_BY
> =
> > > INIT" all have just one initial time; this could get complicated
with
> > > routine verifications for four-cycle-per-day models).
> > >
> > > Thank you -
> > >
> > > Yin
> > >
> > > ---
> > > Ying Lin
> > > NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> > > NCWCP Cubicle No. 2015
> > > Ying.Lin at noaa.gov
> > >
> > >
> >
> > --
> > 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: METplus: set input for FCST_PCP_COMBINE_ADD to be from the same model cycle?
From: Ying Lin
Time: Thu Jan 16 15:48:37 2020
Hi George,
Yes, please send me the beta release when ready. I tried the
earlier
METplus 3 (?) beta months ago but didn't get pass the "load the proper
modules for the beta METplus" stage, and gave up after a few fruitless
attempts. It's time I pick that up again. Thank you for your
willingness
to add the FCST_PCP_COMBINE_CONSTANT_INIT this close to the code
freeze
time.
Ying
---
Ying Lin
NCEP/EMC/Verification, Post-processing and Product Generation Branch
NCWCP Cubicle No. 2015
Ying.Lin at noaa.gov
On Thu, Jan 16, 2020 at 5:06 PM George McCabe via RT
<met_help at ucar.edu>
wrote:
> Hi Ying,
>
> I should be able to get this into the 3.0 release. We are freezing
the code
> on Friday. Would you be willing to test the changes to make sure it
selects
> the correct files? It would be easier to make sure it picks the
files
> correctly with a full dataset. I think I recall you tested a beta
release
> that uses Python 3 for METplus a little while ago. Is that correct?
Let me
> know and I can send you a beta release to test.
>
> On Thu, Jan 16, 2020 at 8:35 PM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93824 >
> >
> > Hi George (and Minna),
> >
> > Thank you for your quick response. Yes, please add the
> > FCST_PCP_COMBINE_CONSTANT_INIT, that'll be really useful for
precip (the
> > more "modern" models - the FV3s, the Canadians, the RAP/HRRR -
have
> > continuously-accumulating precip buckets now but some models
don't).
> Would
> > this be added to METplus 3?
> >
> > Ying
> > ---
> > Ying Lin
> > NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> > NCWCP Cubicle No. 2015
> > Ying.Lin at noaa.gov
> >
> >
> >
> > On Thu, Jan 16, 2020 at 2:40 PM George McCabe via RT
<met_help at ucar.edu>
> > wrote:
> >
> > > Hi Ying,
> > >
> > > The PCPCombine wrapper tries to be clever and find the lowest
possible
> > > forecast lead associated with each valid time it is trying to
find.
> While
> > > this was useful for another use case, it appears to be causing
problems
> > > with this case. It looks like we may need an option to have the
script
> > find
> > > the forecast files differently than forcing it to get the lowest
> forecast
> > > lead. I could add an option to force it to use a constant init
time
> > > (FCST_PCP_COMBINE_CONSTANT_INIT?) and if that is set, it will
only find
> > > files that have the init time of the current run. Does that
sound like
> a
> > > solution that would work for you? If so, I can try to get this
change
> in
> > > before the next release code freeze.
> > >
> > > On Thu, Jan 16, 2020 at 5:26 PM Ying Lin via RT
<met_help at ucar.edu>
> > wrote:
> > >
> > > >
> > > > Thu Jan 16 10:25:12 2020: Request 93824 was acted upon.
> > > > Transaction: Ticket created by ying.lin at noaa.gov
> > > > Queue: met_help
> > > > Subject: METplus: set input for FCST_PCP_COMBINE_ADD to
be from
> > the
> > > > same model cycle?
> > > > Owner: Nobody
> > > > Requestors: ying.lin at noaa.gov
> > > > Status: new
> > > > Ticket <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93824
> > >
> > > >
> > > >
> > > > Hello. I noticed that when I'm running 24h verification for a
model
> > > with a
> > > > 3h APCP accumulation bucket, the 3-hourly QPF amounts to be
added
> into
> > a
> > > > 24h total do not come from the same model cycle, e.g. it looks
> > something
> > > > like this:
> > > >
> > > > ... /noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine
-name
> APCP_24
> > > > -add \
> > > >
$PATH/hiresw.20200112/hiresw.t12z.nmmb_5km.f00.conus.grib2 3 \
> > > >
$PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f09.conus.grib2 3 \
> > > >
$PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f06.conus.grib2 3 \
> > > >
$PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f03.conus.grib2 3 \
> > > >
$PATH/hiresw.20200112/hiresw.t00z.nmmb_5km.f00.conus.grib2 3 \
> > > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f09.conus.grib2 3 \
> > > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f06.conus.grib2 3 \
> > > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f03.conus.grib2 3 \
> > > >
*/conusnmmb/bucket/20200112/conusnmmb.v2020011212_f024_a24h
> -v
> > 5
> > > >
> > > > (from the attached master_metplus.log.* file, with some
editing
> ($PATH)
> > > to
> > > > make it more readable). What I actually meant to have
pcp_combine do
> > is
> > > > like this:
> > > > ... /noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine
-name
> APCP_24
> > > > -add \
> > > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f03.conus.grib2 3 \
> > > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f06.conus.grib2 3 \
> > > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f09.conus.grib2 3 \
> > > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f12.conus.grib2 3 \
> > > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f15.conus.grib2 3 \
> > > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f18.conus.grib2 3 \
> > > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f21.conus.grib2 3 \
> > > >
$PATH/hiresw.20200111/hiresw.t12z.nmmb_5km.f24.conus.grib2 3 \
> > > >
*/conusnmmb/bucket/20200112/conusnmmb.v2020011212_f024_a24h
> -v
> > 5
> > > >
> > > > i.e. all 3h APCP should come from the same model forecast
cycle. Is
> > > there
> > > > something I should have specified in the model config file
(attached
> > > > conusnmmb_24h.conf) to specify that constraint? I see that in
the
> > > > parm/use_cases/qpf/examples/nationalblend-vs-mrms-qpe.conf and
> several
> > > > others, there is "LOOP_BY = INIT" (I have "LOOP_BY = VALID")
and I'll
> > try
> > > > "LOOP_BY = INIT" to see if that works, but if in the model
config I
> > could
> > > > have specified "all component QPFs for a pcp_combine should be
from
> the
> > > > same model run cycle" that would be great (the use cases with
> "LOOP_BY
> > =
> > > > INIT" all have just one initial time; this could get
complicated with
> > > > routine verifications for four-cycle-per-day models).
> > > >
> > > > Thank you -
> > > >
> > > > Yin
> > > >
> > > > ---
> > > > Ying Lin
> > > > NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> > > > NCWCP Cubicle No. 2015
> > > > Ying.Lin at noaa.gov
> > > >
> > > >
> > >
> > > --
> > > 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