[Met_help] [rt.rap.ucar.edu #50725] History for RE: problems with APCP in wrfpost for EMSv3.2.1beta?
John Halley Gotway via RT
met_help at ucar.edu
Wed Oct 19 09:23:15 MDT 2011
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi John,
I found *exactly* where MET is failing. I am running METv3.0.1 (I think).
Beginning on line 997 of the file lib/vx_met_util/read_grib.cc, it has several case statements in the file to determine the time unit of the input grib field. Since there is not a case statement for time units 10, 11, 12, each of these instances fails when running pcp_combine -- basically every 3 hours in the WRF EMS output.
It ought to be a rather simple fix to support these additional time units, I figure. I can try to look up the TimeU in the link you sent me to add the necessary source code and recompile.
Thanks for responding!
JonC
-----Original Message-----
From: John Halley Gotway [mailto:johnhg at ucar.edu]
Sent: Thursday, October 13, 2011 5:53 PM
To: Case, Jonathan (MSFC-VP61)[ENSCO INC]
Cc: Robert Rozumalski; pgo >> Paul Oldenburg
Subject: Re: problems with APCP in wrfpost for EMSv3.2.1beta?
Jon,
Looking at this wgrib output, I do see the odd settings in the P1 and P2 values. But when you consider the TimeU entry, it actually makes sense.
Here's a table describing how those time unit (TimeU) values should be interpreted:
http://www.nco.ncep.noaa.gov/pmb/docs/on388/table4.html
So in the 3rd record, P2=1 and TimeU=10. That means that the end of the accumulation interval is 1 3-hour time unit = 3 hours.
In the last record, P2=4 and TimeU=12. That means that the end of the accumulation interval is 4 12-hour time units = 48 hours.
This is a bit odd. Typically I see the same TimeU value used throughout an entire GRIB file. But there's nothing *wrong* about using it this way.
If MET is not handling this data correctly, please send us some data to met_help at ucar.edu so we can figure it out. We'll also need a description of exactly how it is "choking" so we can troubleshoot.
Thanks,
John
On 10/13/2011 04:33 PM, Case, Jonathan (MSFC-VP61)[ENSCO INC] wrote:
> Hi Bob,
>
> I have set "ACCUMFREQ = Run" in the post_grib.conf file in hopes that the output would contain a running total of the accumulated precip for each grid during a simulation.
> That generally appears to be the case, however, the internal times assigned in the GRIB files appear to be conflicting.
>
> As a working example below, I have the 48 hourly output from my domain 2 run, grepping for the APCP variable. It appears that every 3 hours, the times are not consistent in the GRIB files (look at the "P2" entries). This is causing the MET model verification software to choke on processing these data. Can you possibly translate what your version of wrfpost is doing in this instance? Is there anything I can do to overcome the problem I'm experiencing with the internal times?
>
> Thanks for the feedback,
> Jon
>
> 203:51896392:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=1:TimeU=1:sfc:0-1hr acc:NAve=0
> 203:52417870:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=2:TimeU=1:sfc:0-2hr acc:NAve=0
> 203:52533754:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=1:TimeU=10:sfc:0-3hr acc:NAve=0
> 203:53364256:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=4:TimeU=1:sfc:0-4hr acc:NAve=0
> 203:53383570:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=5:TimeU=1:sfc:0-5hr acc:NAve=0
> 203:53287000:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=1:TimeU=11:sfc:0-6hr acc:NAve=0
> 203:53402884:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=7:TimeU=1:sfc:0-7hr acc:NAve=0
> 203:53557396:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=8:TimeU=1:sfc:0-8hr acc:NAve=0
> 203:53808478:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=3:TimeU=10:sfc:0-9hr acc:NAve=0
> 203:53576710:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=10:TimeU=1:sfc:0-10hr acc:NAve=0
> 203:53422198:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=11:TimeU=1:sfc:0-11hr acc:NAve=0
> 203:53441512:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=1:TimeU=12:sfc:0-12hr acc:NAve=0
> 203:53364256:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=13:TimeU=1:sfc:0-13hr acc:NAve=0
> 203:53460826:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=14:TimeU=1:sfc:0-14hr acc:NAve=0
> 203:53499454:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=5:TimeU=10:sfc:0-15hr acc:NAve=0
> 203:53576710:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=16:TimeU=1:sfc:0-16hr acc:NAve=0
> 203:53711908:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=17:TimeU=1:sfc:0-17hr acc:NAve=0
> 203:53634652:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=3:TimeU=11:sfc:0-18hr acc:NAve=0
> 203:53731222:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=19:TimeU=1:sfc:0-19hr acc:NAve=0
> 203:53731222:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=20:TimeU=1:sfc:0-20hr acc:NAve=0
> 203:53480140:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=7:TimeU=10:sfc:0-21hr acc:NAve=0
> 203:53518768:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=22:TimeU=1:sfc:0-22hr acc:NAve=0
> 203:53750536:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=23:TimeU=1:sfc:0-23hr acc:NAve=0
> 203:53538082:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=2:TimeU=12:sfc:0-24hr acc:NAve=0
> 203:53692594:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=25:TimeU=1:sfc:0-25hr acc:NAve=0
> 203:53557396:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=26:TimeU=1:sfc:0-26hr acc:NAve=0
> 203:53711908:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=9:TimeU=10:sfc:0-27hr acc:NAve=0
> 203:53596024:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=28:TimeU=1:sfc:0-28hr acc:NAve=0
> 203:53480140:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=29:TimeU=1:sfc:0-29hr acc:NAve=0
> 203:53267686:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=5:TimeU=11:sfc:0-30hr acc:NAve=0
> 203:53151802:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=31:TimeU=1:sfc:0-31hr acc:NAve=0
> 203:53750536:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=32:TimeU=1:sfc:0-32hr acc:NAve=0
> 203:53750536:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=11:TimeU=10:sfc:0-33hr acc:NAve=0
> 203:53731222:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=34:TimeU=1:sfc:0-34hr acc:NAve=0
> 203:53905048:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=35:TimeU=1:sfc:0-35hr acc:NAve=0
> 203:53113174:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=3:TimeU=12:sfc:0-36hr acc:NAve=0
> 203:53383570:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=37:TimeU=1:sfc:0-37hr acc:NAve=0
> 203:53364256:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=38:TimeU=1:sfc:0-38hr acc:NAve=0
> 203:53287000:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=13:TimeU=10:sfc:0-39hr acc:NAve=0
> 203:53248372:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=40:TimeU=1:sfc:0-40hr acc:NAve=0
> 203:53267686:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=41:TimeU=1:sfc:0-41hr acc:NAve=0
> 203:53557396:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=7:TimeU=11:sfc:0-42hr acc:NAve=0
> 203:53538082:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=43:TimeU=1:sfc:0-43hr acc:NAve=0
> 203:53229058:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=44:TimeU=1:sfc:0-44hr acc:NAve=0
> 203:53441512:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=15:TimeU=10:sfc:0-45hr acc:NAve=0
> 203:53596024:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=46:TimeU=1:sfc:0-46hr acc:NAve=0
> 203:53248372:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=47:TimeU=1:sfc:0-47hr acc:NAve=0
> 203:53499454:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=4:TimeU=12:sfc:0-48hr acc:NAve=0
>
> --------------------------------------------------------------------------------------------------
> Jonathan Case, ENSCO Inc.
> NASA Short-term Prediction Research and Transition Center (aka SPoRT Center)
> 320 Sparkman Drive, Room 3062
> Huntsville, AL 35805
> Voice: 256.961.7504
> Fax: 256.961.7788
> Emails: Jonathan.Case-1 at nasa.gov / case.jonathan at ensco.com
> --------------------------------------------------------------------------------------------------
>
> "Whether the weather is cold, or whether the weather is hot, we'll weather
> the weather whether we like it or not!"
>
>
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #50725] RE: problems with APCP in wrfpost for EMSv3.2.1beta?
From: John Halley Gotway
Time: Thu Oct 13 19:01:13 2011
Jon,
Yep, that should be a very easy fix. This is obviously the first GRIB
file we've encountered that make use of those settings. Can you
please
send us one of those files so that we can test to be certain the fix
is
correct.
You can post it to our ftp site following these instructions:
http://www.dtcenter.org/met/users/support/met_help.php#ftp
Thanks,
John
>
> Thu Oct 13 17:21:20 2011: Request 50725 was acted upon.
> Transaction: Ticket created by jonathan.case-1 at nasa.gov
> Queue: met_help
> Subject: RE: problems with APCP in wrfpost for EMSv3.2.1beta?
> Owner: Nobody
> Requestors: jonathan.case-1 at nasa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=50725 >
>
>
> Hi John,
>
> I found *exactly* where MET is failing. I am running METv3.0.1 (I
think).
> Beginning on line 997 of the file lib/vx_met_util/read_grib.cc, it
has
> several case statements in the file to determine the time unit of
the
> input grib field. Since there is not a case statement for time
units 10,
> 11, 12, each of these instances fails when running pcp_combine --
> basically every 3 hours in the WRF EMS output.
>
> It ought to be a rather simple fix to support these additional time
units,
> I figure. I can try to look up the TimeU in the link you sent me to
add
> the necessary source code and recompile.
>
> Thanks for responding!
> JonC
>
> -----Original Message-----
> From: John Halley Gotway [mailto:johnhg at ucar.edu]
> Sent: Thursday, October 13, 2011 5:53 PM
> To: Case, Jonathan (MSFC-VP61)[ENSCO INC]
> Cc: Robert Rozumalski; pgo >> Paul Oldenburg
> Subject: Re: problems with APCP in wrfpost for EMSv3.2.1beta?
>
> Jon,
>
> Looking at this wgrib output, I do see the odd settings in the P1
and P2
> values. But when you consider the TimeU entry, it actually makes
sense.
>
> Here's a table describing how those time unit (TimeU) values should
be
> interpreted:
> http://www.nco.ncep.noaa.gov/pmb/docs/on388/table4.html
>
> So in the 3rd record, P2=1 and TimeU=10. That means that the end of
the
> accumulation interval is 1 3-hour time unit = 3 hours.
> In the last record, P2=4 and TimeU=12. That means that the end of
the
> accumulation interval is 4 12-hour time units = 48 hours.
>
> This is a bit odd. Typically I see the same TimeU value used
throughout
> an entire GRIB file. But there's nothing *wrong* about using it
this way.
>
> If MET is not handling this data correctly, please send us some data
to
> met_help at ucar.edu so we can figure it out. We'll also need a
description
> of exactly how it is "choking" so we can troubleshoot.
>
> Thanks,
> John
>
> On 10/13/2011 04:33 PM, Case, Jonathan (MSFC-VP61)[ENSCO INC] wrote:
>> Hi Bob,
>>
>> I have set "ACCUMFREQ = Run" in the post_grib.conf file in hopes
that
>> the output would contain a running total of the accumulated precip
for
>> each grid during a simulation.
>> That generally appears to be the case, however, the internal times
>> assigned in the GRIB files appear to be conflicting.
>>
>> As a working example below, I have the 48 hourly output from my
domain 2
>> run, grepping for the APCP variable. It appears that every 3
hours, the
>> times are not consistent in the GRIB files (look at the "P2"
entries).
>> This is causing the MET model verification software to choke on
>> processing these data. Can you possibly translate what your
version of
>> wrfpost is doing in this instance? Is there anything I can do to
>> overcome the problem I'm experiencing with the internal times?
>>
>> Thanks for the feedback,
>> Jon
>>
>>
203:51896392:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=1:TimeU=1:sfc:0-
1hr
>> acc:NAve=0
>>
203:52417870:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=2:TimeU=1:sfc:0-
2hr
>> acc:NAve=0
>>
203:52533754:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=1:TimeU=10:sfc:0-
3hr
>> acc:NAve=0
>>
203:53364256:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=4:TimeU=1:sfc:0-
4hr
>> acc:NAve=0
>>
203:53383570:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=5:TimeU=1:sfc:0-
5hr
>> acc:NAve=0
>>
203:53287000:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=1:TimeU=11:sfc:0-
6hr
>> acc:NAve=0
>>
203:53402884:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=7:TimeU=1:sfc:0-
7hr
>> acc:NAve=0
>>
203:53557396:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=8:TimeU=1:sfc:0-
8hr
>> acc:NAve=0
>>
203:53808478:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=3:TimeU=10:sfc:0-
9hr
>> acc:NAve=0
>>
203:53576710:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=10:TimeU=1:sfc:0-
10hr
>> acc:NAve=0
>>
203:53422198:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=11:TimeU=1:sfc:0-
11hr
>> acc:NAve=0
>>
203:53441512:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=1:TimeU=12:sfc:0-
12hr
>> acc:NAve=0
>>
203:53364256:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=13:TimeU=1:sfc:0-
13hr
>> acc:NAve=0
>>
203:53460826:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=14:TimeU=1:sfc:0-
14hr
>> acc:NAve=0
>>
203:53499454:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=5:TimeU=10:sfc:0-
15hr
>> acc:NAve=0
>>
203:53576710:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=16:TimeU=1:sfc:0-
16hr
>> acc:NAve=0
>>
203:53711908:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=17:TimeU=1:sfc:0-
17hr
>> acc:NAve=0
>>
203:53634652:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=3:TimeU=11:sfc:0-
18hr
>> acc:NAve=0
>>
203:53731222:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=19:TimeU=1:sfc:0-
19hr
>> acc:NAve=0
>>
203:53731222:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=20:TimeU=1:sfc:0-
20hr
>> acc:NAve=0
>>
203:53480140:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=7:TimeU=10:sfc:0-
21hr
>> acc:NAve=0
>>
203:53518768:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=22:TimeU=1:sfc:0-
22hr
>> acc:NAve=0
>>
203:53750536:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=23:TimeU=1:sfc:0-
23hr
>> acc:NAve=0
>>
203:53538082:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=2:TimeU=12:sfc:0-
24hr
>> acc:NAve=0
>>
203:53692594:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=25:TimeU=1:sfc:0-
25hr
>> acc:NAve=0
>>
203:53557396:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=26:TimeU=1:sfc:0-
26hr
>> acc:NAve=0
>>
203:53711908:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=9:TimeU=10:sfc:0-
27hr
>> acc:NAve=0
>>
203:53596024:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=28:TimeU=1:sfc:0-
28hr
>> acc:NAve=0
>>
203:53480140:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=29:TimeU=1:sfc:0-
29hr
>> acc:NAve=0
>>
203:53267686:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=5:TimeU=11:sfc:0-
30hr
>> acc:NAve=0
>>
203:53151802:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=31:TimeU=1:sfc:0-
31hr
>> acc:NAve=0
>>
203:53750536:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=32:TimeU=1:sfc:0-
32hr
>> acc:NAve=0
>>
203:53750536:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=11:TimeU=10:sfc:0-
33hr
>> acc:NAve=0
>>
203:53731222:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=34:TimeU=1:sfc:0-
34hr
>> acc:NAve=0
>>
203:53905048:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=35:TimeU=1:sfc:0-
35hr
>> acc:NAve=0
>>
203:53113174:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=3:TimeU=12:sfc:0-
36hr
>> acc:NAve=0
>>
203:53383570:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=37:TimeU=1:sfc:0-
37hr
>> acc:NAve=0
>>
203:53364256:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=38:TimeU=1:sfc:0-
38hr
>> acc:NAve=0
>>
203:53287000:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=13:TimeU=10:sfc:0-
39hr
>> acc:NAve=0
>>
203:53248372:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=40:TimeU=1:sfc:0-
40hr
>> acc:NAve=0
>>
203:53267686:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=41:TimeU=1:sfc:0-
41hr
>> acc:NAve=0
>>
203:53557396:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=7:TimeU=11:sfc:0-
42hr
>> acc:NAve=0
>>
203:53538082:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=43:TimeU=1:sfc:0-
43hr
>> acc:NAve=0
>>
203:53229058:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=44:TimeU=1:sfc:0-
44hr
>> acc:NAve=0
>>
203:53441512:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=15:TimeU=10:sfc:0-
45hr
>> acc:NAve=0
>>
203:53596024:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=46:TimeU=1:sfc:0-
46hr
>> acc:NAve=0
>>
203:53248372:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=47:TimeU=1:sfc:0-
47hr
>> acc:NAve=0
>>
203:53499454:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=4:TimeU=12:sfc:0-
48hr
>> acc:NAve=0
>>
>>
--------------------------------------------------------------------------------------------------
>> Jonathan Case, ENSCO Inc.
>> NASA Short-term Prediction Research and Transition Center (aka
SPoRT
>> Center)
>> 320 Sparkman Drive, Room 3062
>> Huntsville, AL 35805
>> Voice: 256.961.7504
>> Fax: 256.961.7788
>> Emails: Jonathan.Case-1 at nasa.gov / case.jonathan at ensco.com
>>
--------------------------------------------------------------------------------------------------
>>
>> "Whether the weather is cold, or whether the weather is hot, we'll
>> weather
>> the weather whether we like it or not!"
>>
>>
>
------------------------------------------------
Subject: RE: [rt.rap.ucar.edu #50725] RE: problems with APCP in wrfpost for EMSv3.2.1beta?
From: Case, Jonathan[ENSCO INC]
Time: Thu Oct 13 21:55:50 2011
Hello again JohnH-G/Methelp,
I uploaded all 48 hours of APCP from a sample run (no other variables
-- space saver) to my ftp directory at:
ftp://ftp.nsstc.org/outgoing/casejl/met/
You have 7 days to obtain these GRIB1 files before they self-destruct!
Every 3 hours, the time units change, varying between 10, 11, or 12.
All other forecast hours have time units of 1.
Enjoy!
JonC
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Thursday, October 13, 2011 8:01 PM
To: Case, Jonathan (MSFC-VP61)[ENSCO INC]
Cc: Srikishen, Jayanthi (MSFC-VP61)[Universities Space Research
Association (USRA)]; pgoldenb at ucar.edu; rozumal at ucar.edu
Subject: Re: [rt.rap.ucar.edu #50725] RE: problems with APCP in
wrfpost for EMSv3.2.1beta?
Jon,
Yep, that should be a very easy fix. This is obviously the first GRIB
file we've encountered that make use of those settings. Can you
please
send us one of those files so that we can test to be certain the fix
is
correct.
You can post it to our ftp site following these instructions:
http://www.dtcenter.org/met/users/support/met_help.php#ftp
Thanks,
John
>
> Thu Oct 13 17:21:20 2011: Request 50725 was acted upon.
> Transaction: Ticket created by jonathan.case-1 at nasa.gov
> Queue: met_help
> Subject: RE: problems with APCP in wrfpost for EMSv3.2.1beta?
> Owner: Nobody
> Requestors: jonathan.case-1 at nasa.gov
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=50725 >
>
>
> Hi John,
>
> I found *exactly* where MET is failing. I am running METv3.0.1 (I
think).
> Beginning on line 997 of the file lib/vx_met_util/read_grib.cc, it
has
> several case statements in the file to determine the time unit of
the
> input grib field. Since there is not a case statement for time
units 10,
> 11, 12, each of these instances fails when running pcp_combine --
> basically every 3 hours in the WRF EMS output.
>
> It ought to be a rather simple fix to support these additional time
units,
> I figure. I can try to look up the TimeU in the link you sent me to
add
> the necessary source code and recompile.
>
> Thanks for responding!
> JonC
>
> -----Original Message-----
> From: John Halley Gotway [mailto:johnhg at ucar.edu]
> Sent: Thursday, October 13, 2011 5:53 PM
> To: Case, Jonathan (MSFC-VP61)[ENSCO INC]
> Cc: Robert Rozumalski; pgo >> Paul Oldenburg
> Subject: Re: problems with APCP in wrfpost for EMSv3.2.1beta?
>
> Jon,
>
> Looking at this wgrib output, I do see the odd settings in the P1
and P2
> values. But when you consider the TimeU entry, it actually makes
sense.
>
> Here's a table describing how those time unit (TimeU) values should
be
> interpreted:
> http://www.nco.ncep.noaa.gov/pmb/docs/on388/table4.html
>
> So in the 3rd record, P2=1 and TimeU=10. That means that the end of
the
> accumulation interval is 1 3-hour time unit = 3 hours.
> In the last record, P2=4 and TimeU=12. That means that the end of
the
> accumulation interval is 4 12-hour time units = 48 hours.
>
> This is a bit odd. Typically I see the same TimeU value used
throughout
> an entire GRIB file. But there's nothing *wrong* about using it
this way.
>
> If MET is not handling this data correctly, please send us some data
to
> met_help at ucar.edu so we can figure it out. We'll also need a
description
> of exactly how it is "choking" so we can troubleshoot.
>
> Thanks,
> John
>
> On 10/13/2011 04:33 PM, Case, Jonathan (MSFC-VP61)[ENSCO INC] wrote:
>> Hi Bob,
>>
>> I have set "ACCUMFREQ = Run" in the post_grib.conf file in hopes
that
>> the output would contain a running total of the accumulated precip
for
>> each grid during a simulation.
>> That generally appears to be the case, however, the internal times
>> assigned in the GRIB files appear to be conflicting.
>>
>> As a working example below, I have the 48 hourly output from my
domain 2
>> run, grepping for the APCP variable. It appears that every 3
hours, the
>> times are not consistent in the GRIB files (look at the "P2"
entries).
>> This is causing the MET model verification software to choke on
>> processing these data. Can you possibly translate what your
version of
>> wrfpost is doing in this instance? Is there anything I can do to
>> overcome the problem I'm experiencing with the internal times?
>>
>> Thanks for the feedback,
>> Jon
>>
>>
203:51896392:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=1:TimeU=1:sfc:0-
1hr
>> acc:NAve=0
>>
203:52417870:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=2:TimeU=1:sfc:0-
2hr
>> acc:NAve=0
>>
203:52533754:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=1:TimeU=10:sfc:0-
3hr
>> acc:NAve=0
>>
203:53364256:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=4:TimeU=1:sfc:0-
4hr
>> acc:NAve=0
>>
203:53383570:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=5:TimeU=1:sfc:0-
5hr
>> acc:NAve=0
>>
203:53287000:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=1:TimeU=11:sfc:0-
6hr
>> acc:NAve=0
>>
203:53402884:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=7:TimeU=1:sfc:0-
7hr
>> acc:NAve=0
>>
203:53557396:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=8:TimeU=1:sfc:0-
8hr
>> acc:NAve=0
>>
203:53808478:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=3:TimeU=10:sfc:0-
9hr
>> acc:NAve=0
>>
203:53576710:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=10:TimeU=1:sfc:0-
10hr
>> acc:NAve=0
>>
203:53422198:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=11:TimeU=1:sfc:0-
11hr
>> acc:NAve=0
>>
203:53441512:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=1:TimeU=12:sfc:0-
12hr
>> acc:NAve=0
>>
203:53364256:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=13:TimeU=1:sfc:0-
13hr
>> acc:NAve=0
>>
203:53460826:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=14:TimeU=1:sfc:0-
14hr
>> acc:NAve=0
>>
203:53499454:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=5:TimeU=10:sfc:0-
15hr
>> acc:NAve=0
>>
203:53576710:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=16:TimeU=1:sfc:0-
16hr
>> acc:NAve=0
>>
203:53711908:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=17:TimeU=1:sfc:0-
17hr
>> acc:NAve=0
>>
203:53634652:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=3:TimeU=11:sfc:0-
18hr
>> acc:NAve=0
>>
203:53731222:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=19:TimeU=1:sfc:0-
19hr
>> acc:NAve=0
>>
203:53731222:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=20:TimeU=1:sfc:0-
20hr
>> acc:NAve=0
>>
203:53480140:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=7:TimeU=10:sfc:0-
21hr
>> acc:NAve=0
>>
203:53518768:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=22:TimeU=1:sfc:0-
22hr
>> acc:NAve=0
>>
203:53750536:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=23:TimeU=1:sfc:0-
23hr
>> acc:NAve=0
>>
203:53538082:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=2:TimeU=12:sfc:0-
24hr
>> acc:NAve=0
>>
203:53692594:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=25:TimeU=1:sfc:0-
25hr
>> acc:NAve=0
>>
203:53557396:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=26:TimeU=1:sfc:0-
26hr
>> acc:NAve=0
>>
203:53711908:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=9:TimeU=10:sfc:0-
27hr
>> acc:NAve=0
>>
203:53596024:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=28:TimeU=1:sfc:0-
28hr
>> acc:NAve=0
>>
203:53480140:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=29:TimeU=1:sfc:0-
29hr
>> acc:NAve=0
>>
203:53267686:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=5:TimeU=11:sfc:0-
30hr
>> acc:NAve=0
>>
203:53151802:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=31:TimeU=1:sfc:0-
31hr
>> acc:NAve=0
>>
203:53750536:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=32:TimeU=1:sfc:0-
32hr
>> acc:NAve=0
>>
203:53750536:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=11:TimeU=10:sfc:0-
33hr
>> acc:NAve=0
>>
203:53731222:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=34:TimeU=1:sfc:0-
34hr
>> acc:NAve=0
>>
203:53905048:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=35:TimeU=1:sfc:0-
35hr
>> acc:NAve=0
>>
203:53113174:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=3:TimeU=12:sfc:0-
36hr
>> acc:NAve=0
>>
203:53383570:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=37:TimeU=1:sfc:0-
37hr
>> acc:NAve=0
>>
203:53364256:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=38:TimeU=1:sfc:0-
38hr
>> acc:NAve=0
>>
203:53287000:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=13:TimeU=10:sfc:0-
39hr
>> acc:NAve=0
>>
203:53248372:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=40:TimeU=1:sfc:0-
40hr
>> acc:NAve=0
>>
203:53267686:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=41:TimeU=1:sfc:0-
41hr
>> acc:NAve=0
>>
203:53557396:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=7:TimeU=11:sfc:0-
42hr
>> acc:NAve=0
>>
203:53538082:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=43:TimeU=1:sfc:0-
43hr
>> acc:NAve=0
>>
203:53229058:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=44:TimeU=1:sfc:0-
44hr
>> acc:NAve=0
>>
203:53441512:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=15:TimeU=10:sfc:0-
45hr
>> acc:NAve=0
>>
203:53596024:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=46:TimeU=1:sfc:0-
46hr
>> acc:NAve=0
>>
203:53248372:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=47:TimeU=1:sfc:0-
47hr
>> acc:NAve=0
>>
203:53499454:d=11100906:APCP:kpds5=61:kpds6=1:kpds7=0:TR=4:P1=0:P2=4:TimeU=12:sfc:0-
48hr
>> acc:NAve=0
>>
>>
--------------------------------------------------------------------------------------------------
>> Jonathan Case, ENSCO Inc.
>> NASA Short-term Prediction Research and Transition Center (aka
SPoRT
>> Center)
>> 320 Sparkman Drive, Room 3062
>> Huntsville, AL 35805
>> Voice: 256.961.7504
>> Fax: 256.961.7788
>> Emails: Jonathan.Case-1 at nasa.gov / case.jonathan at ensco.com
>>
--------------------------------------------------------------------------------------------------
>>
>> "Whether the weather is cold, or whether the weather is hot, we'll
>> weather
>> the weather whether we like it or not!"
>>
>>
>
------------------------------------------------
More information about the Met_help
mailing list