[Met_help] [rt.rap.ucar.edu #93939] History for METplus-3.0-beta2: PcpCombine issue
George McCabe via RT
met_help at ucar.edu
Tue Jan 28 13:37:10 MST 2020
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi George, I'm trying out METplus-3.0-beta2 - Logan D. pointed me to
https://github.com/NCAR/METplus/archive/v3.0-beta2.zip, and how to use
ush/validate_config.py (that was really helpful, by the way).
In the case of continuously accumulating precipitation buckets, the
v3.0-beta2 doesn't seem to work with the initial accumulation period, i.e.
in a test run, I'm running 24h (12Z-12Z) verifications, the bucket
accumulation for forecast hours of 24-48 worked fine, since PcpCombine
simply subtracted f24 from f48; but the initial 24h accumulation didn't
work: in the attached run.out, there is:
01/27 22:36:15.071 metplus.PCPCombine (command_builder.py:93) ERROR:
(command_builder.py:584) Command returned a non-zero return code:
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine
-v 5 -add
/gpfs/hps2/ptmp/Matthew.Pyle/oconus_new/com/hiresw/para/hiresw.20200124/hiresw.t12z.fv3_5km.f24.conus.grib2
86400
/gpfs/dell2/ptmp/Ying.Lin/metplus.v3.out/conusfv3/bucket/20200125/conusfv3.v2020012512_f024_a24h
Recall that back in mid/late September you made a fix in v2.1's
pcp_combine_wrapper.py so that in the case of models
continuously-accumulating precipitation bucket like the GFS, the initial
hour's file is not used to do a subtraction (GFS' zero-hour file does not
have APCP). It seems to work correctly in v2.1.
Attached: config file, run script, run output, metplus_final.config for the
above run in question.
Also, did the "FCST_PCP_COMBINE_ADD to be from the same model cycle" (in re
ticket #93824) get included in this v3.0-beta2 release? I see that
pcp_combine_wrapper.py in the v3.0-beta2 are different - grew by over 20% -
but don't know enough to be able to tell if the "add from the same model
cycle" has been included, or why the treatment of the initial (e.g.) 24h -
without subtracting the forecast hour zero field - no longer works.
Thank you very much -
Ying
---
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-3.0-beta2: PcpCombine issue
From: George McCabe
Time: Mon Jan 27 18:51:06 2020
Ah, it looks like I created a bug for that case when I refactored the
code
to allow subhourly data. The lead time is now stored in seconds, then
converted to "MET time" format when passed to the PCPCombine. I forgot
to
convert seconds to MET time for this case, so it is passing in 86400
instead of 24. You will need to add the following (in bold) at line
678:
if lead2 == 0 and level_type == 'A':
self.logger.debug("Subtracted accumulation is 0, so
running ADD
mode on one file")
self.method = 'ADD'
* lead = time_util.seconds_to_met_time(lead)*
self.add_input_file(file1, lead)
return self.get_command()
Please add this line and let me know if it works. If it does, I will
check
in the change so it will be included in the 3.0 release. Thank you for
testing this with the beta release so it makes it into the final 3.0
release! Let me know if you find any other issues.
- George
On Mon, Jan 27, 2020 at 6:35 PM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
> Mon Jan 27 18:35:13 2020: Request 93939 was acted upon.
> Transaction: Ticket created by ying.lin at noaa.gov
> Queue: met_help
> Subject: METplus-3.0-beta2: PcpCombine issue
> Owner: Nobody
> Requestors: ying.lin at noaa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93939 >
>
>
> Hi George, I'm trying out METplus-3.0-beta2 - Logan D. pointed me to
> https://github.com/NCAR/METplus/archive/v3.0-beta2.zip, and how to
use
> ush/validate_config.py (that was really helpful, by the way).
>
> In the case of continuously accumulating precipitation buckets, the
> v3.0-beta2 doesn't seem to work with the initial accumulation
period, i.e.
> in a test run, I'm running 24h (12Z-12Z) verifications, the bucket
> accumulation for forecast hours of 24-48 worked fine, since
PcpCombine
> simply subtracted f24 from f48; but the initial 24h accumulation
didn't
> work: in the attached run.out, there is:
>
> 01/27 22:36:15.071 metplus.PCPCombine (command_builder.py:93) ERROR:
> (command_builder.py:584) Command returned a non-zero return code:
>
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine
> -v 5 -add
>
>
/gpfs/hps2/ptmp/Matthew.Pyle/oconus_new/com/hiresw/para/hiresw.20200124/hiresw.t12z.fv3_5km.f24.conus.grib2
> 86400
>
>
/gpfs/dell2/ptmp/Ying.Lin/metplus.v3.out/conusfv3/bucket/20200125/conusfv3.v2020012512_f024_a24h
>
> Recall that back in mid/late September you made a fix in v2.1's
> pcp_combine_wrapper.py so that in the case of models
> continuously-accumulating precipitation bucket like the GFS, the
initial
> hour's file is not used to do a subtraction (GFS' zero-hour file
does not
> have APCP). It seems to work correctly in v2.1.
>
> Attached: config file, run script, run output, metplus_final.config
for the
> above run in question.
>
> Also, did the "FCST_PCP_COMBINE_ADD to be from the same model cycle"
(in re
> ticket #93824) get included in this v3.0-beta2 release? I see that
> pcp_combine_wrapper.py in the v3.0-beta2 are different - grew by
over 20% -
> but don't know enough to be able to tell if the "add from the same
model
> cycle" has been included, or why the treatment of the initial (e.g.)
24h -
> without subtracting the forecast hour zero field - no longer works.
>
> Thank you very much -
>
> Ying
> ---
> 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-3.0-beta2: PcpCombine issue
From: Ying Lin
Time: Tue Jan 28 12:41:40 2020
Hi George,
The one additional line you provided for
ush/pcp_combine_wrapper.py
fixed the problem of running PcpCombine I also saw the "modify
config
file while running ush/validate_config.py" in action - nice!
It seems that METplus-3.0-beta2 doesn't yet correctly handle the
"when
adding QPFs using PcpCombine, make sure all the QPF to be added is
from the
same model run cycle". When I tried this I got the following (broke
up the
one-line command/substituted path with $modpath for easier viewing):
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine
\
-v 5 -name APCP_24 -add \
$modpath/hiresw.20200125/hiresw.t12z.nmmb_5km.f00.conus.grib2 03 \
$modpath/hiresw.20200125/hiresw.t00z.nmmb_5km.f09.conus.grib2 03 \
$modpath/hiresw.20200125/hiresw.t00z.nmmb_5km.f06.conus.grib2 03 \
$modpath/hiresw.20200125/hiresw.t00z.nmmb_5km.f03.conus.grib2 03 \
$modpath/hiresw.20200125/hiresw.t00z.nmmb_5km.f00.conus.grib2 03 \
$modpath/hiresw.20200124/hiresw.t12z.nmmb_5km.f09.conus.grib2 03 \
$modpath/hiresw.20200124/hiresw.t12z.nmmb_5km.f06.conus.grib2 03 \
$modpath/hiresw.20200124/hiresw.t12z.nmmb_5km.f03.conus.grib2 03 \
/gpfs/dell2/ptmp/Ying.Lin/metplus.v3.out/conusnmmb/bucket/20200125/conusnmmb.v2020012512_f024_a24h
By the way, when adding we don't want the APCP from the initial time
(f00)
because sometimes it is not zero (as one would expect).
Thank you again for the speedy fix of the ush/pcp_combine_wrapper.py
for
the PcpCcombine (initial [non]subtract).
Ying
---
Ying Lin
NCEP/EMC/Verification, Post-processing and Product Generation Branch
NCWCP Cubicle No. 2015
Ying.Lin at noaa.gov
On Mon, Jan 27, 2020 at 8:51 PM George McCabe via RT
<met_help at ucar.edu>
wrote:
> Ah, it looks like I created a bug for that case when I refactored
the code
> to allow subhourly data. The lead time is now stored in seconds,
then
> converted to "MET time" format when passed to the PCPCombine. I
forgot to
> convert seconds to MET time for this case, so it is passing in 86400
> instead of 24. You will need to add the following (in bold) at line
678:
>
> if lead2 == 0 and level_type == 'A':
> self.logger.debug("Subtracted accumulation is 0, so
running ADD
> mode on one file")
> self.method = 'ADD'
> * lead = time_util.seconds_to_met_time(lead)*
> self.add_input_file(file1, lead)
> return self.get_command()
>
> Please add this line and let me know if it works. If it does, I will
check
> in the change so it will be included in the 3.0 release. Thank you
for
> testing this with the beta release so it makes it into the final 3.0
> release! Let me know if you find any other issues.
>
> - George
>
> On Mon, Jan 27, 2020 at 6:35 PM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
> >
> > Mon Jan 27 18:35:13 2020: Request 93939 was acted upon.
> > Transaction: Ticket created by ying.lin at noaa.gov
> > Queue: met_help
> > Subject: METplus-3.0-beta2: PcpCombine issue
> > Owner: Nobody
> > Requestors: ying.lin at noaa.gov
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93939 >
> >
> >
> > Hi George, I'm trying out METplus-3.0-beta2 - Logan D. pointed me
to
> > https://github.com/NCAR/METplus/archive/v3.0-beta2.zip, and how to
use
> > ush/validate_config.py (that was really helpful, by the way).
> >
> > In the case of continuously accumulating precipitation buckets,
the
> > v3.0-beta2 doesn't seem to work with the initial accumulation
period,
> i.e.
> > in a test run, I'm running 24h (12Z-12Z) verifications, the bucket
> > accumulation for forecast hours of 24-48 worked fine, since
PcpCombine
> > simply subtracted f24 from f48; but the initial 24h accumulation
didn't
> > work: in the attached run.out, there is:
> >
> > 01/27 22:36:15.071 metplus.PCPCombine (command_builder.py:93)
ERROR:
> > (command_builder.py:584) Command returned a non-zero return code:
> >
> >
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine
> > -v 5 -add
> >
> >
>
/gpfs/hps2/ptmp/Matthew.Pyle/oconus_new/com/hiresw/para/hiresw.20200124/hiresw.t12z.fv3_5km.f24.conus.grib2
> > 86400
> >
> >
>
/gpfs/dell2/ptmp/Ying.Lin/metplus.v3.out/conusfv3/bucket/20200125/conusfv3.v2020012512_f024_a24h
> >
> > Recall that back in mid/late September you made a fix in v2.1's
> > pcp_combine_wrapper.py so that in the case of models
> > continuously-accumulating precipitation bucket like the GFS, the
initial
> > hour's file is not used to do a subtraction (GFS' zero-hour file
does not
> > have APCP). It seems to work correctly in v2.1.
> >
> > Attached: config file, run script, run output,
metplus_final.config for
> the
> > above run in question.
> >
> > Also, did the "FCST_PCP_COMBINE_ADD to be from the same model
cycle" (in
> re
> > ticket #93824) get included in this v3.0-beta2 release? I see
that
> > pcp_combine_wrapper.py in the v3.0-beta2 are different - grew by
over
> 20% -
> > but don't know enough to be able to tell if the "add from the same
model
> > cycle" has been included, or why the treatment of the initial
(e.g.) 24h
> -
> > without subtracting the forecast hour zero field - no longer
works.
> >
> > Thank you very much -
> >
> > Ying
> > ---
> > 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-3.0-beta2: PcpCombine issue
From: George McCabe
Time: Tue Jan 28 12:58:13 2020
Hi Ying,
Did you see FCST_PCP_COMBINE_CONSTANT_INIT to True? You will need to
set
this to make sure the same initialization time is used for each input
file.
On Tue, Jan 28, 2020 at 12:41 PM Ying Lin via RT <met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93939 >
>
> Hi George,
>
> The one additional line you provided for
ush/pcp_combine_wrapper.py
> fixed the problem of running PcpCombine I also saw the "modify
config
> file while running ush/validate_config.py" in action - nice!
>
> It seems that METplus-3.0-beta2 doesn't yet correctly handle
the "when
> adding QPFs using PcpCombine, make sure all the QPF to be added is
from the
> same model run cycle". When I tried this I got the following (broke
up the
> one-line command/substituted path with $modpath for easier viewing):
>
>
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine
> \
> -v 5 -name APCP_24 -add \
> $modpath/hiresw.20200125/hiresw.t12z.nmmb_5km.f00.conus.grib2 03
\
> $modpath/hiresw.20200125/hiresw.t00z.nmmb_5km.f09.conus.grib2 03
\
> $modpath/hiresw.20200125/hiresw.t00z.nmmb_5km.f06.conus.grib2 03
\
> $modpath/hiresw.20200125/hiresw.t00z.nmmb_5km.f03.conus.grib2 03
\
> $modpath/hiresw.20200125/hiresw.t00z.nmmb_5km.f00.conus.grib2 03
\
> $modpath/hiresw.20200124/hiresw.t12z.nmmb_5km.f09.conus.grib2 03
\
> $modpath/hiresw.20200124/hiresw.t12z.nmmb_5km.f06.conus.grib2 03
\
> $modpath/hiresw.20200124/hiresw.t12z.nmmb_5km.f03.conus.grib2 03
\
>
>
>
/gpfs/dell2/ptmp/Ying.Lin/metplus.v3.out/conusnmmb/bucket/20200125/conusnmmb.v2020012512_f024_a24h
>
> By the way, when adding we don't want the APCP from the initial time
(f00)
> because sometimes it is not zero (as one would expect).
>
> Thank you again for the speedy fix of the ush/pcp_combine_wrapper.py
for
> the PcpCcombine (initial [non]subtract).
>
> Ying
>
> ---
> Ying Lin
> NCEP/EMC/Verification, Post-processing and Product Generation Branch
> NCWCP Cubicle No. 2015
> Ying.Lin at noaa.gov
>
>
>
> On Mon, Jan 27, 2020 at 8:51 PM George McCabe via RT
<met_help at ucar.edu>
> wrote:
>
> > Ah, it looks like I created a bug for that case when I refactored
the
> code
> > to allow subhourly data. The lead time is now stored in seconds,
then
> > converted to "MET time" format when passed to the PCPCombine. I
forgot to
> > convert seconds to MET time for this case, so it is passing in
86400
> > instead of 24. You will need to add the following (in bold) at
line 678:
> >
> > if lead2 == 0 and level_type == 'A':
> > self.logger.debug("Subtracted accumulation is 0, so
running
> ADD
> > mode on one file")
> > self.method = 'ADD'
> > * lead = time_util.seconds_to_met_time(lead)*
> > self.add_input_file(file1, lead)
> > return self.get_command()
> >
> > Please add this line and let me know if it works. If it does, I
will
> check
> > in the change so it will be included in the 3.0 release. Thank you
for
> > testing this with the beta release so it makes it into the final
3.0
> > release! Let me know if you find any other issues.
> >
> > - George
> >
> > On Mon, Jan 27, 2020 at 6:35 PM Ying Lin via RT
<met_help at ucar.edu>
> wrote:
> >
> > >
> > > Mon Jan 27 18:35:13 2020: Request 93939 was acted upon.
> > > Transaction: Ticket created by ying.lin at noaa.gov
> > > Queue: met_help
> > > Subject: METplus-3.0-beta2: PcpCombine issue
> > > Owner: Nobody
> > > Requestors: ying.lin at noaa.gov
> > > Status: new
> > > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93939
> >
> > >
> > >
> > > Hi George, I'm trying out METplus-3.0-beta2 - Logan D. pointed
me to
> > > https://github.com/NCAR/METplus/archive/v3.0-beta2.zip, and how
to use
> > > ush/validate_config.py (that was really helpful, by the way).
> > >
> > > In the case of continuously accumulating precipitation buckets,
the
> > > v3.0-beta2 doesn't seem to work with the initial accumulation
period,
> > i.e.
> > > in a test run, I'm running 24h (12Z-12Z) verifications, the
bucket
> > > accumulation for forecast hours of 24-48 worked fine, since
PcpCombine
> > > simply subtracted f24 from f48; but the initial 24h accumulation
didn't
> > > work: in the attached run.out, there is:
> > >
> > > 01/27 22:36:15.071 metplus.PCPCombine (command_builder.py:93)
ERROR:
> > > (command_builder.py:584) Command returned a non-zero return
code:
> > >
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine
> > > -v 5 -add
> > >
> > >
> >
>
/gpfs/hps2/ptmp/Matthew.Pyle/oconus_new/com/hiresw/para/hiresw.20200124/hiresw.t12z.fv3_5km.f24.conus.grib2
> > > 86400
> > >
> > >
> >
>
/gpfs/dell2/ptmp/Ying.Lin/metplus.v3.out/conusfv3/bucket/20200125/conusfv3.v2020012512_f024_a24h
> > >
> > > Recall that back in mid/late September you made a fix in v2.1's
> > > pcp_combine_wrapper.py so that in the case of models
> > > continuously-accumulating precipitation bucket like the GFS, the
> initial
> > > hour's file is not used to do a subtraction (GFS' zero-hour file
does
> not
> > > have APCP). It seems to work correctly in v2.1.
> > >
> > > Attached: config file, run script, run output,
metplus_final.config for
> > the
> > > above run in question.
> > >
> > > Also, did the "FCST_PCP_COMBINE_ADD to be from the same model
cycle"
> (in
> > re
> > > ticket #93824) get included in this v3.0-beta2 release? I see
that
> > > pcp_combine_wrapper.py in the v3.0-beta2 are different - grew by
over
> > 20% -
> > > but don't know enough to be able to tell if the "add from the
same
> model
> > > cycle" has been included, or why the treatment of the initial
(e.g.)
> 24h
> > -
> > > without subtracting the forecast hour zero field - no longer
works.
> > >
> > > Thank you very much -
> > >
> > > Ying
> > > ---
> > > 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-3.0-beta2: PcpCombine issue
From: Ying Lin
Time: Tue Jan 28 13:32:26 2020
Hi George,
No, I didn't. Adding FCST_PCP_COMBINE_CONSTANT_INIT = True fixed the
problem. I'm now seeing
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine
\
-v 5 -name APCP_24 -add \
$modpath/hiresw.20200124/hiresw.t12z.nmmb_5km.f24.conus.grib2 03 \
$modpath/hiresw.20200124/hiresw.t12z.nmmb_5km.f21.conus.grib2 03 \
$modpath/hiresw.20200124/hiresw.t12z.nmmb_5km.f18.conus.grib2 03 \
$modpath/hiresw.20200124/hiresw.t12z.nmmb_5km.f15.conus.grib2 03 \
$modpath/hiresw.20200124/hiresw.t12z.nmmb_5km.f12.conus.grib2 03 \
$modpath/hiresw.20200124/hiresw.t12z.nmmb_5km.f09.conus.grib2 03 \
$modpath/hiresw.20200124/hiresw.t12z.nmmb_5km.f06.conus.grib2 03 \
$modpath/hiresw.20200124/hiresw.t12z.nmmb_5km.f03.conus.grib2 03 \
/gpfs/dell2/ptmp/Ying.Lin/metplus.v3.out/conusnmmb/bucket/20200125/conusnmmb.v2020012512_f024_a24h
So now it's correct.
Please feel free to close yesterday's ticket (for this email subject
line)
and the 1/16 ticket (#93824) as you see fit.
Thanks again,
Ying
---
Ying Lin
NCEP/EMC/Verification, Post-processing and Product Generation Branch
NCWCP Cubicle No. 2015
Ying.Lin at noaa.gov
On Tue, Jan 28, 2020 at 2:58 PM George McCabe via RT
<met_help at ucar.edu>
wrote:
> Hi Ying,
>
> Did you see FCST_PCP_COMBINE_CONSTANT_INIT to True? You will need to
set
> this to make sure the same initialization time is used for each
input file.
>
> On Tue, Jan 28, 2020 at 12:41 PM Ying Lin via RT <met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93939 >
> >
> > Hi George,
> >
> > The one additional line you provided for
ush/pcp_combine_wrapper.py
> > fixed the problem of running PcpCombine I also saw the "modify
config
> > file while running ush/validate_config.py" in action - nice!
> >
> > It seems that METplus-3.0-beta2 doesn't yet correctly handle
the
> "when
> > adding QPFs using PcpCombine, make sure all the QPF to be added is
from
> the
> > same model run cycle". When I tried this I got the following
(broke up
> the
> > one-line command/substituted path with $modpath for easier
viewing):
> >
> >
> >
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine
> > \
> > -v 5 -name APCP_24 -add \
> > $modpath/hiresw.20200125/hiresw.t12z.nmmb_5km.f00.conus.grib2
03 \
> > $modpath/hiresw.20200125/hiresw.t00z.nmmb_5km.f09.conus.grib2
03 \
> > $modpath/hiresw.20200125/hiresw.t00z.nmmb_5km.f06.conus.grib2
03 \
> > $modpath/hiresw.20200125/hiresw.t00z.nmmb_5km.f03.conus.grib2
03 \
> > $modpath/hiresw.20200125/hiresw.t00z.nmmb_5km.f00.conus.grib2
03 \
> > $modpath/hiresw.20200124/hiresw.t12z.nmmb_5km.f09.conus.grib2
03 \
> > $modpath/hiresw.20200124/hiresw.t12z.nmmb_5km.f06.conus.grib2
03 \
> > $modpath/hiresw.20200124/hiresw.t12z.nmmb_5km.f03.conus.grib2
03 \
> >
> >
> >
>
/gpfs/dell2/ptmp/Ying.Lin/metplus.v3.out/conusnmmb/bucket/20200125/conusnmmb.v2020012512_f024_a24h
> >
> > By the way, when adding we don't want the APCP from the initial
time
> (f00)
> > because sometimes it is not zero (as one would expect).
> >
> > Thank you again for the speedy fix of the
ush/pcp_combine_wrapper.py for
> > the PcpCcombine (initial [non]subtract).
> >
> > Ying
> >
> > ---
> > Ying Lin
> > NCEP/EMC/Verification, Post-processing and Product Generation
Branch
> > NCWCP Cubicle No. 2015
> > Ying.Lin at noaa.gov
> >
> >
> >
> > On Mon, Jan 27, 2020 at 8:51 PM George McCabe via RT
<met_help at ucar.edu>
> > wrote:
> >
> > > Ah, it looks like I created a bug for that case when I
refactored the
> > code
> > > to allow subhourly data. The lead time is now stored in seconds,
then
> > > converted to "MET time" format when passed to the PCPCombine. I
forgot
> to
> > > convert seconds to MET time for this case, so it is passing in
86400
> > > instead of 24. You will need to add the following (in bold) at
line
> 678:
> > >
> > > if lead2 == 0 and level_type == 'A':
> > > self.logger.debug("Subtracted accumulation is 0, so
running
> > ADD
> > > mode on one file")
> > > self.method = 'ADD'
> > > * lead = time_util.seconds_to_met_time(lead)*
> > > self.add_input_file(file1, lead)
> > > return self.get_command()
> > >
> > > Please add this line and let me know if it works. If it does, I
will
> > check
> > > in the change so it will be included in the 3.0 release. Thank
you for
> > > testing this with the beta release so it makes it into the final
3.0
> > > release! Let me know if you find any other issues.
> > >
> > > - George
> > >
> > > On Mon, Jan 27, 2020 at 6:35 PM Ying Lin via RT
<met_help at ucar.edu>
> > wrote:
> > >
> > > >
> > > > Mon Jan 27 18:35:13 2020: Request 93939 was acted upon.
> > > > Transaction: Ticket created by ying.lin at noaa.gov
> > > > Queue: met_help
> > > > Subject: METplus-3.0-beta2: PcpCombine issue
> > > > Owner: Nobody
> > > > Requestors: ying.lin at noaa.gov
> > > > Status: new
> > > > Ticket <URL:
> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=93939
> > >
> > > >
> > > >
> > > > Hi George, I'm trying out METplus-3.0-beta2 - Logan D. pointed
me to
> > > > https://github.com/NCAR/METplus/archive/v3.0-beta2.zip, and
how to
> use
> > > > ush/validate_config.py (that was really helpful, by the way).
> > > >
> > > > In the case of continuously accumulating precipitation
buckets, the
> > > > v3.0-beta2 doesn't seem to work with the initial accumulation
period,
> > > i.e.
> > > > in a test run, I'm running 24h (12Z-12Z) verifications, the
bucket
> > > > accumulation for forecast hours of 24-48 worked fine, since
> PcpCombine
> > > > simply subtracted f24 from f48; but the initial 24h
accumulation
> didn't
> > > > work: in the attached run.out, there is:
> > > >
> > > > 01/27 22:36:15.071 metplus.PCPCombine (command_builder.py:93)
ERROR:
> > > > (command_builder.py:584) Command returned a non-zero return
code:
> > > >
> > > >
> > >
> >
>
/gpfs/dell2/emc/verification/noscrub/Julie.Prestopnik/met/8.1/bin/pcp_combine
> > > > -v 5 -add
> > > >
> > > >
> > >
> >
>
/gpfs/hps2/ptmp/Matthew.Pyle/oconus_new/com/hiresw/para/hiresw.20200124/hiresw.t12z.fv3_5km.f24.conus.grib2
> > > > 86400
> > > >
> > > >
> > >
> >
>
/gpfs/dell2/ptmp/Ying.Lin/metplus.v3.out/conusfv3/bucket/20200125/conusfv3.v2020012512_f024_a24h
> > > >
> > > > Recall that back in mid/late September you made a fix in
v2.1's
> > > > pcp_combine_wrapper.py so that in the case of models
> > > > continuously-accumulating precipitation bucket like the GFS,
the
> > initial
> > > > hour's file is not used to do a subtraction (GFS' zero-hour
file does
> > not
> > > > have APCP). It seems to work correctly in v2.1.
> > > >
> > > > Attached: config file, run script, run output,
metplus_final.config
> for
> > > the
> > > > above run in question.
> > > >
> > > > Also, did the "FCST_PCP_COMBINE_ADD to be from the same model
cycle"
> > (in
> > > re
> > > > ticket #93824) get included in this v3.0-beta2 release? I see
that
> > > > pcp_combine_wrapper.py in the v3.0-beta2 are different - grew
by over
> > > 20% -
> > > > but don't know enough to be able to tell if the "add from the
same
> > model
> > > > cycle" has been included, or why the treatment of the initial
(e.g.)
> > 24h
> > > -
> > > > without subtracting the forecast hour zero field - no longer
works.
> > > >
> > > > Thank you very much -
> > > >
> > > > Ying
> > > > ---
> > > > 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