[Met_help] [rt.rap.ucar.edu #41832] History for Error with pcp_combine for V3.0
RAL HelpDesk {for John Halley Gotway}
met_help at ucar.edu
Fri Oct 29 15:52:21 MDT 2010
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello.
I'm getting unresolved errors when trying to run pcp_combine the way I want
to:
[jdduda at pircsds8 05_May_2008]$ /usr/local/METv3.0/bin/pcp_combine -subtract
WRFPRS_d02.005_45 \
054500 WRFPRS_d02.004_45 044500 control_1745-1645
Reading input file: WRFPRS_d02.005_45
ERROR: get_field() -> can't find grib code 61 with accumulation of 054500 in
GRIB file: WRFPRS_d02.005_45
I tried using other grib codes, but the error message just replaced 61 with
whatever I put in. It's like it still doesn't see the new accumulation
interval like it's supposed to.
Any suggestions?
Jeff Duda
--
Jeff Duda
Iowa State University
Meteorology Graduate Student
3134 Agronomy Hall
www.meteor.iastate.edu/~jdduda
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #41832] Error with pcp_combine for V3.0
From: John Halley Gotway
Time: Fri Oct 29 12:22:26 2010
Jeff,
You may find it useful to run those files through "wgrib" to see
what's in there:
wgrib WRFPRS_d02.005_45 | grep APCP
wgrib WRFPRS_d02.004_45 | grep APCP
I suspect this may have to do with the limitations of the GRIB1 format
for storing accumulation intervals. I'm guessing that your
accumulation intervals are overflowing the 1 byte that's allocated in
GRIB1. A 5hr 45min accumulation is 345 minutes - which is larger than
the max value of 255 that can be stored in 1 byte.
Out of curiosity, does the following job work as expected?
/usr/local/METv3.0/bin/pcp_combine -subtract WRFPRS_d02.003_45
034500 WRFPRS_d02.002_45 024500 test.nc
If so, then what I described above is in fact occurring.
Can you please send me those two files you're using? I'll take a look
here to see if there's a way around this issue.
Please send me the files via our anonymous ftp site, as described
here:
http://www.dtcenter.org/met/users/support/met_help.php#ftp
Thanks,
John
On 10/29/2010 10:52 AM, RAL HelpDesk {for jdduda at iastate.edu} wrote:
>
> Fri Oct 29 10:52:18 2010: Request 41832 was acted upon.
> Transaction: Ticket created by jdduda at iastate.edu
> Queue: met_help
> Subject: Error with pcp_combine for V3.0
> Owner: Nobody
> Requestors: jdduda at iastate.edu
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41832 >
>
>
> Hello.
> I'm getting unresolved errors when trying to run pcp_combine the way
I want
> to:
>
> [jdduda at pircsds8 05_May_2008]$ /usr/local/METv3.0/bin/pcp_combine
-subtract
> WRFPRS_d02.005_45 \
> 054500 WRFPRS_d02.004_45 044500 control_1745-1645
> Reading input file: WRFPRS_d02.005_45
>
> ERROR: get_field() -> can't find grib code 61 with accumulation of
054500 in
> GRIB file: WRFPRS_d02.005_45
>
> I tried using other grib codes, but the error message just replaced
61 with
> whatever I put in. It's like it still doesn't see the new
accumulation
> interval like it's supposed to.
>
> Any suggestions?
>
> Jeff Duda
>
------------------------------------------------
Subject: Error with pcp_combine for V3.0
From: jdduda at iastate.edu
Time: Fri Oct 29 12:57:00 2010
John,
No, the new command didn't work either. I got the same error. I
uploaded
four files to jdduda_data on the ftp server. Thanks.
Jeff
On Fri, Oct 29, 2010 at 1:22 PM, RAL HelpDesk {for John Halley Gotway}
<
met_help at ucar.edu> wrote:
> Jeff,
>
> You may find it useful to run those files through "wgrib" to see
what's in
> there:
> wgrib WRFPRS_d02.005_45 | grep APCP
> wgrib WRFPRS_d02.004_45 | grep APCP
>
> I suspect this may have to do with the limitations of the GRIB1
format for
> storing accumulation intervals. I'm guessing that your accumulation
> intervals are overflowing the 1 byte that's allocated in
> GRIB1. A 5hr 45min accumulation is 345 minutes - which is larger
than the
> max value of 255 that can be stored in 1 byte.
>
> Out of curiosity, does the following job work as expected?
> /usr/local/METv3.0/bin/pcp_combine -subtract WRFPRS_d02.003_45
034500
> WRFPRS_d02.002_45 024500 test.nc
>
> If so, then what I described above is in fact occurring.
>
> Can you please send me those two files you're using? I'll take a
look here
> to see if there's a way around this issue.
>
> Please send me the files via our anonymous ftp site, as described
here:
> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>
> Thanks,
> John
>
> On 10/29/2010 10:52 AM, RAL HelpDesk {for jdduda at iastate.edu} wrote:
> >
> > Fri Oct 29 10:52:18 2010: Request 41832 was acted upon.
> > Transaction: Ticket created by jdduda at iastate.edu
> > Queue: met_help
> > Subject: Error with pcp_combine for V3.0
> > Owner: Nobody
> > Requestors: jdduda at iastate.edu
> > Status: new
> > Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41832 >
> >
> >
> > Hello.
> > I'm getting unresolved errors when trying to run pcp_combine the
way I
> want
> > to:
> >
> > [jdduda at pircsds8 05_May_2008]$ /usr/local/METv3.0/bin/pcp_combine
> -subtract
> > WRFPRS_d02.005_45 \
> > 054500 WRFPRS_d02.004_45 044500 control_1745-1645
> > Reading input file: WRFPRS_d02.005_45
> >
> > ERROR: get_field() -> can't find grib code 61 with accumulation of
054500
> in
> > GRIB file: WRFPRS_d02.005_45
> >
> > I tried using other grib codes, but the error message just
replaced 61
> with
> > whatever I put in. It's like it still doesn't see the new
accumulation
> > interval like it's supposed to.
> >
> > Any suggestions?
> >
> > Jeff Duda
> >
>
>
--
Jeff Duda
Iowa State University
Meteorology Graduate Student
3134 Agronomy Hall
www.meteor.iastate.edu/~jdduda
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #41832] Error with pcp_combine for V3.0
From: John Halley Gotway
Time: Fri Oct 29 13:22:43 2010
Jeff,
OK, I see what's going on. I ran these through wgrib, looking only at
the APCP records, and I see the following:
WRFPRS_d02.002_45
3:153132:d=08050512:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=120:P2=165:TimeU=0:sfc:120-
165min acc:NAve=0
WRFPRS_d02.003_45
3:153132:d=08050512:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=180:P2=225:TimeU=0:sfc:180-
225min acc:NAve=0
WRFPRS_d02.004_45
3:167036:d=08050512:APCP:kpds5=61:kpds6=1:kpds7=0:TR=10:P1=1:P2=29:TimeU=0:sfc:285min
fcst:NAve=0
WRFPRS_d02.005_45
3:167036:d=08050512:APCP:kpds5=61:kpds6=1:kpds7=0:TR=10:P1=1:P2=89:TimeU=0:sfc:345min
fcst:NAve=0
You'll notice the time strings go like this: 120-165min acc, 180-
225min acc, 285min fcst, and 345min fcst.
For the first two files, the times are stored as accumulations of 45
minutes (120-165min and 180-225min). You must have configured WRF in
such a way to make this happen.
For the last two files, the times are stored as instantaneous values
(285min and 345min). This happens because these time values
overflowed the 255 limit for the 1 byte allocated in the GRIB format.
So it's up to you to know what the accumulation intervals ACTUALLY are
for these last two - we know that they're really 240-285min and 300-
345min.
I'm guessing that you set your output accumulation interval to 1 hour
when you ran WRF. That means, after every hour, it dumps the bucket
and starts new accumulations. When you output at 45 minutes
past the hour, you're getting the 45 minutes of accumulation since the
last time the bucket was dumped. If that's the case, the PCP-Combine
jobs you're running don't really make much sense. You'd be
subtracting 45 minutes of accumulation minus a different 45 minutes of
accumulation.
Perhaps, that's not really what you want. Perhaps you really want to
just have a runtime accumulation. That means, for every output time,
you'd have the accumulation from the beginning of the
simulation. And then you're PCP-Combine jobs really would make sense.
You'd need to adjust your WRF configuration to make this happen. I
know for NMM that means setting a "tprec" value, but I don't
recall how to do it for ARW.
Just given the data you sent me, the following commands should make
PCP-Combine run without error:
pcp_combine -subtract WRFPRS_d02.003_45 004500 WRFPRS_d02.002_45
004500 test1.nc
pcp_combine -subtract WRFPRS_d02.005_45 00 WRFPRS_d02.004_45 00
test2.nc
Please note that in the second example, I listed the accumulation
intervals as 0. That's because your GRIB data is actually stored as
an instantaneous time, not an accumulation - due to the overflow
issue described above. And it's up to you to keep track of the fact
that these are really 45 minute accumulations.
Hope that helps clarify.
John
On 10/29/2010 12:57 PM, RAL HelpDesk {for jdduda at iastate.edu} wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41832 >
>
> John,
> No, the new command didn't work either. I got the same error. I
uploaded
> four files to jdduda_data on the ftp server. Thanks.
>
> Jeff
>
> On Fri, Oct 29, 2010 at 1:22 PM, RAL HelpDesk {for John Halley
Gotway} <
> met_help at ucar.edu> wrote:
>
>> Jeff,
>>
>> You may find it useful to run those files through "wgrib" to see
what's in
>> there:
>> wgrib WRFPRS_d02.005_45 | grep APCP
>> wgrib WRFPRS_d02.004_45 | grep APCP
>>
>> I suspect this may have to do with the limitations of the GRIB1
format for
>> storing accumulation intervals. I'm guessing that your
accumulation
>> intervals are overflowing the 1 byte that's allocated in
>> GRIB1. A 5hr 45min accumulation is 345 minutes - which is larger
than the
>> max value of 255 that can be stored in 1 byte.
>>
>> Out of curiosity, does the following job work as expected?
>> /usr/local/METv3.0/bin/pcp_combine -subtract WRFPRS_d02.003_45
034500
>> WRFPRS_d02.002_45 024500 test.nc
>>
>> If so, then what I described above is in fact occurring.
>>
>> Can you please send me those two files you're using? I'll take a
look here
>> to see if there's a way around this issue.
>>
>> Please send me the files via our anonymous ftp site, as described
here:
>> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>
>> Thanks,
>> John
>>
>> On 10/29/2010 10:52 AM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
>>>
>>> Fri Oct 29 10:52:18 2010: Request 41832 was acted upon.
>>> Transaction: Ticket created by jdduda at iastate.edu
>>> Queue: met_help
>>> Subject: Error with pcp_combine for V3.0
>>> Owner: Nobody
>>> Requestors: jdduda at iastate.edu
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41832 >
>>>
>>>
>>> Hello.
>>> I'm getting unresolved errors when trying to run pcp_combine the
way I
>> want
>>> to:
>>>
>>> [jdduda at pircsds8 05_May_2008]$ /usr/local/METv3.0/bin/pcp_combine
>> -subtract
>>> WRFPRS_d02.005_45 \
>>> 054500 WRFPRS_d02.004_45 044500 control_1745-1645
>>> Reading input file: WRFPRS_d02.005_45
>>>
>>> ERROR: get_field() -> can't find grib code 61 with accumulation of
054500
>> in
>>> GRIB file: WRFPRS_d02.005_45
>>>
>>> I tried using other grib codes, but the error message just
replaced 61
>> with
>>> whatever I put in. It's like it still doesn't see the new
accumulation
>>> interval like it's supposed to.
>>>
>>> Any suggestions?
>>>
>>> Jeff Duda
>>>
>>
>>
>
>
------------------------------------------------
Subject: Error with pcp_combine for V3.0
From: jdduda at iastate.edu
Time: Fri Oct 29 15:29:56 2010
John,
Wow, I was not expecting the problems to root this deep. Thanks for
the
mouthful of explanation! You are very knowledgeful.
Regarding the issue, I see in phys/module_diagnostics.F the following
text/code:
! Handle accumulations with buckets to prevent round-off truncation in
long
runs
! This is done every 360 minutes assuming time step fits exactly into
360
minutes
IF(bucket_mm .gt. 0. .AND. MOD(NINT(XTIME),360) .EQ. 0)THEN
bucket_mm can be set in the namelist, but I have not specified it, so
it
defaults to -1. Thus in my runs, this IF statement is false so the
bucket
subtraction code should never be running. I have the variables
I_RAINC and
I_RAINNC in my wrfout history files, but they're filled with zeroes.
My
guess from this is that I should have simulation accumulated precip
(which
is something I was told by other grad students probably a year ago,
and
something I've been operating under the assumption of). Obviously,
given
the results from wgrib, that doesn't appear to be the case. However,
all
four of those files came from the exact same simulation.
Nevertheless, I'm
confused.
Jeff
On Fri, Oct 29, 2010 at 2:22 PM, RAL HelpDesk {for John Halley Gotway}
<
met_help at ucar.edu> wrote:
> Jeff,
>
> OK, I see what's going on. I ran these through wgrib, looking only
at the
> APCP records, and I see the following:
>
> WRFPRS_d02.002_45
>
>
3:153132:d=08050512:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=120:P2=165:TimeU=0:sfc:120-
165min
> acc:NAve=0
> WRFPRS_d02.003_45
>
>
3:153132:d=08050512:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=180:P2=225:TimeU=0:sfc:180-
225min
> acc:NAve=0
> WRFPRS_d02.004_45
>
>
3:167036:d=08050512:APCP:kpds5=61:kpds6=1:kpds7=0:TR=10:P1=1:P2=29:TimeU=0:sfc:285min
> fcst:NAve=0
> WRFPRS_d02.005_45
>
>
3:167036:d=08050512:APCP:kpds5=61:kpds6=1:kpds7=0:TR=10:P1=1:P2=89:TimeU=0:sfc:345min
> fcst:NAve=0
>
> You'll notice the time strings go like this: 120-165min acc, 180-
225min
> acc, 285min fcst, and 345min fcst.
>
> For the first two files, the times are stored as accumulations of 45
> minutes (120-165min and 180-225min). You must have configured WRF
in such a
> way to make this happen.
> For the last two files, the times are stored as instantaneous values
> (285min and 345min). This happens because these time values
overflowed the
> 255 limit for the 1 byte allocated in the GRIB format.
>
> So it's up to you to know what the accumulation intervals ACTUALLY
are for
> these last two - we know that they're really 240-285min and 300-
345min.
>
> I'm guessing that you set your output accumulation interval to 1
hour when
> you ran WRF. That means, after every hour, it dumps the bucket and
starts
> new accumulations. When you output at 45 minutes
> past the hour, you're getting the 45 minutes of accumulation since
the last
> time the bucket was dumped. If that's the case, the PCP-Combine
jobs you're
> running don't really make much sense. You'd be
> subtracting 45 minutes of accumulation minus a different 45 minutes
of
> accumulation.
>
> Perhaps, that's not really what you want. Perhaps you really want
to just
> have a runtime accumulation. That means, for every output time,
you'd have
> the accumulation from the beginning of the
> simulation. And then you're PCP-Combine jobs really would make
sense.
> You'd need to adjust your WRF configuration to make this happen. I
know
> for NMM that means setting a "tprec" value, but I don't
> recall how to do it for ARW.
>
> Just given the data you sent me, the following commands should make
> PCP-Combine run without error:
> pcp_combine -subtract WRFPRS_d02.003_45 004500 WRFPRS_d02.002_45
004500
> test1.nc
> pcp_combine -subtract WRFPRS_d02.005_45 00 WRFPRS_d02.004_45
00
> test2.nc
>
> Please note that in the second example, I listed the accumulation
intervals
> as 0. That's because your GRIB data is actually stored as an
instantaneous
> time, not an accumulation - due to the overflow
> issue described above. And it's up to you to keep track of the fact
that
> these are really 45 minute accumulations.
>
> Hope that helps clarify.
>
> John
>
> On 10/29/2010 12:57 PM, RAL HelpDesk {for jdduda at iastate.edu} wrote:
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41832 >
> >
> > John,
> > No, the new command didn't work either. I got the same error. I
> uploaded
> > four files to jdduda_data on the ftp server. Thanks.
> >
> > Jeff
> >
> > On Fri, Oct 29, 2010 at 1:22 PM, RAL HelpDesk {for John Halley
Gotway} <
> > met_help at ucar.edu> wrote:
> >
> >> Jeff,
> >>
> >> You may find it useful to run those files through "wgrib" to see
what's
> in
> >> there:
> >> wgrib WRFPRS_d02.005_45 | grep APCP
> >> wgrib WRFPRS_d02.004_45 | grep APCP
> >>
> >> I suspect this may have to do with the limitations of the GRIB1
format
> for
> >> storing accumulation intervals. I'm guessing that your
accumulation
> >> intervals are overflowing the 1 byte that's allocated in
> >> GRIB1. A 5hr 45min accumulation is 345 minutes - which is larger
than
> the
> >> max value of 255 that can be stored in 1 byte.
> >>
> >> Out of curiosity, does the following job work as expected?
> >> /usr/local/METv3.0/bin/pcp_combine -subtract WRFPRS_d02.003_45
034500
> >> WRFPRS_d02.002_45 024500 test.nc
> >>
> >> If so, then what I described above is in fact occurring.
> >>
> >> Can you please send me those two files you're using? I'll take a
look
> here
> >> to see if there's a way around this issue.
> >>
> >> Please send me the files via our anonymous ftp site, as described
here:
> >> http://www.dtcenter.org/met/users/support/met_help.php#ftp
> >>
> >> Thanks,
> >> John
> >>
> >> On 10/29/2010 10:52 AM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
> >>>
> >>> Fri Oct 29 10:52:18 2010: Request 41832 was acted upon.
> >>> Transaction: Ticket created by jdduda at iastate.edu
> >>> Queue: met_help
> >>> Subject: Error with pcp_combine for V3.0
> >>> Owner: Nobody
> >>> Requestors: jdduda at iastate.edu
> >>> Status: new
> >>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41832>
> >>>
> >>>
> >>> Hello.
> >>> I'm getting unresolved errors when trying to run pcp_combine the
way I
> >> want
> >>> to:
> >>>
> >>> [jdduda at pircsds8 05_May_2008]$
/usr/local/METv3.0/bin/pcp_combine
> >> -subtract
> >>> WRFPRS_d02.005_45 \
> >>> 054500 WRFPRS_d02.004_45 044500 control_1745-1645
> >>> Reading input file: WRFPRS_d02.005_45
> >>>
> >>> ERROR: get_field() -> can't find grib code 61 with accumulation
of
> 054500
> >> in
> >>> GRIB file: WRFPRS_d02.005_45
> >>>
> >>> I tried using other grib codes, but the error message just
replaced 61
> >> with
> >>> whatever I put in. It's like it still doesn't see the new
accumulation
> >>> interval like it's supposed to.
> >>>
> >>> Any suggestions?
> >>>
> >>> Jeff Duda
> >>>
> >>
> >>
> >
> >
>
>
--
Jeff Duda
Iowa State University
Meteorology Graduate Student
3134 Agronomy Hall
www.meteor.iastate.edu/~jdduda
------------------------------------------------
Subject: Error with pcp_combine for V3.0
From: jdduda at iastate.edu
Time: Fri Oct 29 15:50:58 2010
John,
I forgot to mention that those new commands you suggested did work.
I'm not
sure exactly what that means or why it worked when I was using on-hour
times
for this, but if the shoe fits...
Jeff
On Fri, Oct 29, 2010 at 4:29 PM, Jeffrey Duda <jdduda at iastate.edu>
wrote:
> John,
> Wow, I was not expecting the problems to root this deep. Thanks for
the
> mouthful of explanation! You are very knowledgeful.
>
> Regarding the issue, I see in phys/module_diagnostics.F the
following
> text/code:
>
> ! Handle accumulations with buckets to prevent round-off truncation
in long
> runs
> ! This is done every 360 minutes assuming time step fits exactly
into 360
> minutes
> IF(bucket_mm .gt. 0. .AND. MOD(NINT(XTIME),360) .EQ. 0)THEN
>
> bucket_mm can be set in the namelist, but I have not specified it,
so it
> defaults to -1. Thus in my runs, this IF statement is false so the
bucket
> subtraction code should never be running. I have the variables
I_RAINC and
> I_RAINNC in my wrfout history files, but they're filled with zeroes.
My
> guess from this is that I should have simulation accumulated precip
(which
> is something I was told by other grad students probably a year ago,
and
> something I've been operating under the assumption of). Obviously,
given
> the results from wgrib, that doesn't appear to be the case.
However, all
> four of those files came from the exact same simulation.
Nevertheless, I'm
> confused.
>
>
> Jeff
>
> On Fri, Oct 29, 2010 at 2:22 PM, RAL HelpDesk {for John Halley
Gotway} <
> met_help at ucar.edu> wrote:
>
>> Jeff,
>>
>> OK, I see what's going on. I ran these through wgrib, looking only
at the
>> APCP records, and I see the following:
>>
>> WRFPRS_d02.002_45
>>
>>
3:153132:d=08050512:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=120:P2=165:TimeU=0:sfc:120-
165min
>> acc:NAve=0
>> WRFPRS_d02.003_45
>>
>>
3:153132:d=08050512:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=180:P2=225:TimeU=0:sfc:180-
225min
>> acc:NAve=0
>> WRFPRS_d02.004_45
>>
>>
3:167036:d=08050512:APCP:kpds5=61:kpds6=1:kpds7=0:TR=10:P1=1:P2=29:TimeU=0:sfc:285min
>> fcst:NAve=0
>> WRFPRS_d02.005_45
>>
>>
3:167036:d=08050512:APCP:kpds5=61:kpds6=1:kpds7=0:TR=10:P1=1:P2=89:TimeU=0:sfc:345min
>> fcst:NAve=0
>>
>> You'll notice the time strings go like this: 120-165min acc, 180-
225min
>> acc, 285min fcst, and 345min fcst.
>>
>> For the first two files, the times are stored as accumulations of
45
>> minutes (120-165min and 180-225min). You must have configured WRF
in such a
>> way to make this happen.
>> For the last two files, the times are stored as instantaneous
values
>> (285min and 345min). This happens because these time values
overflowed the
>> 255 limit for the 1 byte allocated in the GRIB format.
>>
>> So it's up to you to know what the accumulation intervals ACTUALLY
are for
>> these last two - we know that they're really 240-285min and 300-
345min.
>>
>> I'm guessing that you set your output accumulation interval to 1
hour when
>> you ran WRF. That means, after every hour, it dumps the bucket and
starts
>> new accumulations. When you output at 45 minutes
>> past the hour, you're getting the 45 minutes of accumulation since
the
>> last time the bucket was dumped. If that's the case, the PCP-
Combine jobs
>> you're running don't really make much sense. You'd be
>> subtracting 45 minutes of accumulation minus a different 45 minutes
of
>> accumulation.
>>
>> Perhaps, that's not really what you want. Perhaps you really want
to just
>> have a runtime accumulation. That means, for every output time,
you'd have
>> the accumulation from the beginning of the
>> simulation. And then you're PCP-Combine jobs really would make
sense.
>> You'd need to adjust your WRF configuration to make this happen.
I know
>> for NMM that means setting a "tprec" value, but I don't
>> recall how to do it for ARW.
>>
>> Just given the data you sent me, the following commands should make
>> PCP-Combine run without error:
>> pcp_combine -subtract WRFPRS_d02.003_45 004500 WRFPRS_d02.002_45
004500
>> test1.nc
>> pcp_combine -subtract WRFPRS_d02.005_45 00 WRFPRS_d02.004_45
00
>> test2.nc
>>
>> Please note that in the second example, I listed the accumulation
>> intervals as 0. That's because your GRIB data is actually stored
as an
>> instantaneous time, not an accumulation - due to the overflow
>> issue described above. And it's up to you to keep track of the
fact that
>> these are really 45 minute accumulations.
>>
>> Hope that helps clarify.
>>
>> John
>>
>> On 10/29/2010 12:57 PM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
>> >
>> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41832 >
>> >
>> > John,
>> > No, the new command didn't work either. I got the same error. I
>> uploaded
>> > four files to jdduda_data on the ftp server. Thanks.
>> >
>> > Jeff
>> >
>> > On Fri, Oct 29, 2010 at 1:22 PM, RAL HelpDesk {for John Halley
Gotway} <
>> > met_help at ucar.edu> wrote:
>> >
>> >> Jeff,
>> >>
>> >> You may find it useful to run those files through "wgrib" to see
what's
>> in
>> >> there:
>> >> wgrib WRFPRS_d02.005_45 | grep APCP
>> >> wgrib WRFPRS_d02.004_45 | grep APCP
>> >>
>> >> I suspect this may have to do with the limitations of the GRIB1
format
>> for
>> >> storing accumulation intervals. I'm guessing that your
accumulation
>> >> intervals are overflowing the 1 byte that's allocated in
>> >> GRIB1. A 5hr 45min accumulation is 345 minutes - which is
larger than
>> the
>> >> max value of 255 that can be stored in 1 byte.
>> >>
>> >> Out of curiosity, does the following job work as expected?
>> >> /usr/local/METv3.0/bin/pcp_combine -subtract WRFPRS_d02.003_45
034500
>> >> WRFPRS_d02.002_45 024500 test.nc
>> >>
>> >> If so, then what I described above is in fact occurring.
>> >>
>> >> Can you please send me those two files you're using? I'll take
a look
>> here
>> >> to see if there's a way around this issue.
>> >>
>> >> Please send me the files via our anonymous ftp site, as
described here:
>> >> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>> >>
>> >> Thanks,
>> >> John
>> >>
>> >> On 10/29/2010 10:52 AM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
>> >>>
>> >>> Fri Oct 29 10:52:18 2010: Request 41832 was acted upon.
>> >>> Transaction: Ticket created by jdduda at iastate.edu
>> >>> Queue: met_help
>> >>> Subject: Error with pcp_combine for V3.0
>> >>> Owner: Nobody
>> >>> Requestors: jdduda at iastate.edu
>> >>> Status: new
>> >>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41832>
>> >>>
>> >>>
>> >>> Hello.
>> >>> I'm getting unresolved errors when trying to run pcp_combine
the way I
>> >> want
>> >>> to:
>> >>>
>> >>> [jdduda at pircsds8 05_May_2008]$
/usr/local/METv3.0/bin/pcp_combine
>> >> -subtract
>> >>> WRFPRS_d02.005_45 \
>> >>> 054500 WRFPRS_d02.004_45 044500 control_1745-1645
>> >>> Reading input file: WRFPRS_d02.005_45
>> >>>
>> >>> ERROR: get_field() -> can't find grib code 61 with accumulation
of
>> 054500
>> >> in
>> >>> GRIB file: WRFPRS_d02.005_45
>> >>>
>> >>> I tried using other grib codes, but the error message just
replaced 61
>> >> with
>> >>> whatever I put in. It's like it still doesn't see the new
>> accumulation
>> >>> interval like it's supposed to.
>> >>>
>> >>> Any suggestions?
>> >>>
>> >>> Jeff Duda
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>
>
> --
> Jeff Duda
> Iowa State University
> Meteorology Graduate Student
> 3134 Agronomy Hall
> www.meteor.iastate.edu/~jdduda
<http://www.meteor.iastate.edu/%7Ejdduda>
>
--
Jeff Duda
Iowa State University
Meteorology Graduate Student
3134 Agronomy Hall
www.meteor.iastate.edu/~jdduda
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #41832] Error with pcp_combine for V3.0
From: John Halley Gotway
Time: Fri Oct 29 15:52:07 2010
Jeff,
It's difficult to say exactly where the issue lies. Some
possibilities include:
(1) How your WRF parameter file is set up.
(2) Since you're creating sub-hourly output, it's possible that WRF
isn't handling it as expected somewhere.
(3) Or it's possible that WRF-Post isn't handling it as expected
somewhere.
For all of those situations, I'd refer you to wrfhelp at ucar.edu for
more info.
I believe that the "prec_acc_dt" parameter in your "namelist.input"
file controls the accumulation frequency for ARW. Setting it to 0
should give you a run-time accumulation. If it's NOT 0, I'd
suggest changing it to 0 and rerunning.
If you can't make any progress, I'd recommend forwarding our
correspondence to wrfhelp. When you write wrfhelp, please send your
"namelist.input" file and a perhaps header dump (ncdump -h) of one our
your WRFOUT files so they can see what your configuration and output
look like.
I'll go ahead and resolve this ticket. But let me know if more
questions arise in your use of the MET tools.
Thanks,
John
On 10/29/2010 03:29 PM, RAL HelpDesk {for jdduda at iastate.edu} wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41832 >
>
> John,
> Wow, I was not expecting the problems to root this deep. Thanks for
the
> mouthful of explanation! You are very knowledgeful.
>
> Regarding the issue, I see in phys/module_diagnostics.F the
following
> text/code:
>
> ! Handle accumulations with buckets to prevent round-off truncation
in long
> runs
> ! This is done every 360 minutes assuming time step fits exactly
into 360
> minutes
> IF(bucket_mm .gt. 0. .AND. MOD(NINT(XTIME),360) .EQ. 0)THEN
>
> bucket_mm can be set in the namelist, but I have not specified it,
so it
> defaults to -1. Thus in my runs, this IF statement is false so the
bucket
> subtraction code should never be running. I have the variables
I_RAINC and
> I_RAINNC in my wrfout history files, but they're filled with zeroes.
My
> guess from this is that I should have simulation accumulated precip
(which
> is something I was told by other grad students probably a year ago,
and
> something I've been operating under the assumption of). Obviously,
given
> the results from wgrib, that doesn't appear to be the case.
However, all
> four of those files came from the exact same simulation.
Nevertheless, I'm
> confused.
>
> Jeff
>
> On Fri, Oct 29, 2010 at 2:22 PM, RAL HelpDesk {for John Halley
Gotway} <
> met_help at ucar.edu> wrote:
>
>> Jeff,
>>
>> OK, I see what's going on. I ran these through wgrib, looking only
at the
>> APCP records, and I see the following:
>>
>> WRFPRS_d02.002_45
>>
>>
3:153132:d=08050512:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=120:P2=165:TimeU=0:sfc:120-
165min
>> acc:NAve=0
>> WRFPRS_d02.003_45
>>
>>
3:153132:d=08050512:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=180:P2=225:TimeU=0:sfc:180-
225min
>> acc:NAve=0
>> WRFPRS_d02.004_45
>>
>>
3:167036:d=08050512:APCP:kpds5=61:kpds6=1:kpds7=0:TR=10:P1=1:P2=29:TimeU=0:sfc:285min
>> fcst:NAve=0
>> WRFPRS_d02.005_45
>>
>>
3:167036:d=08050512:APCP:kpds5=61:kpds6=1:kpds7=0:TR=10:P1=1:P2=89:TimeU=0:sfc:345min
>> fcst:NAve=0
>>
>> You'll notice the time strings go like this: 120-165min acc, 180-
225min
>> acc, 285min fcst, and 345min fcst.
>>
>> For the first two files, the times are stored as accumulations of
45
>> minutes (120-165min and 180-225min). You must have configured WRF
in such a
>> way to make this happen.
>> For the last two files, the times are stored as instantaneous
values
>> (285min and 345min). This happens because these time values
overflowed the
>> 255 limit for the 1 byte allocated in the GRIB format.
>>
>> So it's up to you to know what the accumulation intervals ACTUALLY
are for
>> these last two - we know that they're really 240-285min and 300-
345min.
>>
>> I'm guessing that you set your output accumulation interval to 1
hour when
>> you ran WRF. That means, after every hour, it dumps the bucket and
starts
>> new accumulations. When you output at 45 minutes
>> past the hour, you're getting the 45 minutes of accumulation since
the last
>> time the bucket was dumped. If that's the case, the PCP-Combine
jobs you're
>> running don't really make much sense. You'd be
>> subtracting 45 minutes of accumulation minus a different 45 minutes
of
>> accumulation.
>>
>> Perhaps, that's not really what you want. Perhaps you really want
to just
>> have a runtime accumulation. That means, for every output time,
you'd have
>> the accumulation from the beginning of the
>> simulation. And then you're PCP-Combine jobs really would make
sense.
>> You'd need to adjust your WRF configuration to make this happen.
I know
>> for NMM that means setting a "tprec" value, but I don't
>> recall how to do it for ARW.
>>
>> Just given the data you sent me, the following commands should make
>> PCP-Combine run without error:
>> pcp_combine -subtract WRFPRS_d02.003_45 004500 WRFPRS_d02.002_45
004500
>> test1.nc
>> pcp_combine -subtract WRFPRS_d02.005_45 00 WRFPRS_d02.004_45
00
>> test2.nc
>>
>> Please note that in the second example, I listed the accumulation
intervals
>> as 0. That's because your GRIB data is actually stored as an
instantaneous
>> time, not an accumulation - due to the overflow
>> issue described above. And it's up to you to keep track of the
fact that
>> these are really 45 minute accumulations.
>>
>> Hope that helps clarify.
>>
>> John
>>
>> On 10/29/2010 12:57 PM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41832 >
>>>
>>> John,
>>> No, the new command didn't work either. I got the same error. I
>> uploaded
>>> four files to jdduda_data on the ftp server. Thanks.
>>>
>>> Jeff
>>>
>>> On Fri, Oct 29, 2010 at 1:22 PM, RAL HelpDesk {for John Halley
Gotway} <
>>> met_help at ucar.edu> wrote:
>>>
>>>> Jeff,
>>>>
>>>> You may find it useful to run those files through "wgrib" to see
what's
>> in
>>>> there:
>>>> wgrib WRFPRS_d02.005_45 | grep APCP
>>>> wgrib WRFPRS_d02.004_45 | grep APCP
>>>>
>>>> I suspect this may have to do with the limitations of the GRIB1
format
>> for
>>>> storing accumulation intervals. I'm guessing that your
accumulation
>>>> intervals are overflowing the 1 byte that's allocated in
>>>> GRIB1. A 5hr 45min accumulation is 345 minutes - which is larger
than
>> the
>>>> max value of 255 that can be stored in 1 byte.
>>>>
>>>> Out of curiosity, does the following job work as expected?
>>>> /usr/local/METv3.0/bin/pcp_combine -subtract WRFPRS_d02.003_45
034500
>>>> WRFPRS_d02.002_45 024500 test.nc
>>>>
>>>> If so, then what I described above is in fact occurring.
>>>>
>>>> Can you please send me those two files you're using? I'll take a
look
>> here
>>>> to see if there's a way around this issue.
>>>>
>>>> Please send me the files via our anonymous ftp site, as described
here:
>>>> http://www.dtcenter.org/met/users/support/met_help.php#ftp
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>> On 10/29/2010 10:52 AM, RAL HelpDesk {for jdduda at iastate.edu}
wrote:
>>>>>
>>>>> Fri Oct 29 10:52:18 2010: Request 41832 was acted upon.
>>>>> Transaction: Ticket created by jdduda at iastate.edu
>>>>> Queue: met_help
>>>>> Subject: Error with pcp_combine for V3.0
>>>>> Owner: Nobody
>>>>> Requestors: jdduda at iastate.edu
>>>>> Status: new
>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=41832>
>>>>>
>>>>>
>>>>> Hello.
>>>>> I'm getting unresolved errors when trying to run pcp_combine the
way I
>>>> want
>>>>> to:
>>>>>
>>>>> [jdduda at pircsds8 05_May_2008]$
/usr/local/METv3.0/bin/pcp_combine
>>>> -subtract
>>>>> WRFPRS_d02.005_45 \
>>>>> 054500 WRFPRS_d02.004_45 044500 control_1745-1645
>>>>> Reading input file: WRFPRS_d02.005_45
>>>>>
>>>>> ERROR: get_field() -> can't find grib code 61 with accumulation
of
>> 054500
>>>> in
>>>>> GRIB file: WRFPRS_d02.005_45
>>>>>
>>>>> I tried using other grib codes, but the error message just
replaced 61
>>>> with
>>>>> whatever I put in. It's like it still doesn't see the new
accumulation
>>>>> interval like it's supposed to.
>>>>>
>>>>> Any suggestions?
>>>>>
>>>>> Jeff Duda
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
------------------------------------------------
More information about the Met_help
mailing list