[Met_help] verifying 2m temperaures with PointStat
John Halley Gotway
johnhg at rap.ucar.edu
Sun Dec 7 16:09:21 MST 2008
Joe,
The work-around is to extract the GRIB records containing vertical level
type data (i.e. at 2 meters) from the file and write them to a separate
file. Then run the separate file through MET. So we basically splitting
out the 2-meter records from the 2-mb records.
The following copygb command will extract only the vertical-level type
records from your files:
copygb -k'5*-1 105' -x in_file.grb out_file.grb
That pulls out all the GRIB records with the level indicator equal to a
value of 105. A value of 105 means "specified height level above ground
in meters" (taken from
http://www.nco.ncep.noaa.gov/pmb/docs/on388/table3.html).
I'm sure you could come up with variants to this copygb command that would
have the result of splitting out the 2 meter record from the 2mb record.
So you're welcome to play around with it. Alternatively, you could turn
off the output of 2mb data from the WRF-PostProcessor... unless you need
it for something else.
A note of caution, you will have the same problem with 10meter winds
versus 10mb winds.
This issue will be fixed in METv2.0 in February.
Thanks!
John
> Hi John,
>
> Thanks for your prompt reply. I'm sorry I couldn't get to this
> sooner... It looks like I am having the same problem you have seen
> before. The output from the point-stat -v3 is:
> Grib Record Index = 9
>
> but the wgrib output is:
> 342
> :
> 12591866
> :d=08120700:TMP:kpds5=11:kpds6=105:kpds7=2:TR=0:P1=0:P2=0:TimeU=1:2 m
> above gnd:anl:NAve=0
>
> and like you suspected, point-stat is was looking for the temperatures
> at 2 mb:
> 9
> :
> 310172
> :d=08120700:TMP:kpds5=11:kpds6=100:kpds7=2:TR=0:P1=0:P2=0:TimeU=1:2
> mb:anl:NAve=0
>
> I'll anxiously await your reply for the work-around.
>
> Thank you very much,
> Joe
>
>
> On Dec 5, 2008, at 9:23 AM, John Halley Gotway wrote:
>
>> Joe,
>>
>> I have heard of a similar concern from another user - not with
>> temperature but with 10 meter winds. In his case, it turned out
>> that while he we was requesting 10 meter winds, the MET code was
>> incorrectly retrieving 10mb winds and using those!
>>
>> In METv1.1, we're not matching the GRIB records as closely as we
>> should. Specifically, METv1.1 is ignoring the "Z" part of the "TMP/
>> Z2" and just looking for a temperature record with a level value of
>> 2. I've fixed this problem for the next version of MET, METv2.0 in
>> February. But the fix touched several files so it wasn't put out as
>> a fix for METv1.1. Instead, there's a pretty simple workaround.
>>
>> But first, let try to determine if you're in this situation. Please
>> try the following:
>> (1) Run the same point-stat command but with the "-v 3" option to
>> turn on more logging.
>> (2) Look for the line "Grib Record Index ="... actually look for the
>> second time that shows up. The first time will just say "Grib
>> Record Index = 1".
>> (3) Next run a "wgrib" command to find out which record we actually
>> want to use in Point-Stat:
>> wgrib FORECAST_FILE_NAME | grep TMP
>> (4) Find the temperature record in the wgrib output that says "2 m
>> above gnd"
>> (5) Look at the index number for that record at the beginning of the
>> line.
>>
>> Does the index number for that record in the wgrib output match the
>> index number for the record Point-Stat is using?
>>
>> If not, then we've found the problem. Just let me know, and I can
>> help you with a work-around.
>>
>> If they do match, then maybe something else is going on here. If
>> they match, please go ahead and send me some sample data:
>> (1) a sample forecast file
>> (2) the corresponding observation file (output of PB2NC)
>> (3) the Point-Stat config file you're using
>>
>> And I'll look into it some more.
>>
>> Thanks,
>> John Halley-Gotway
>> johnhg at ucar.edu
>>
>> Joe Olson wrote:
>>> I'm trying to verify 2m temps output from WRF-ARW v3.0 and using
>>> METv1.1
>>> (PointStat).
>>>
>>> First, I have performed the following to prepare the prepbufr:
>>>
>>> 1) cwordsh block prepbufr_file prepbufr_file.blk
>>> 2) Converted Prepbufr to netcdf:
>>> /METdir/bin/pb2nc prepbufr_file.blk prepbufr.ncdf
>>> /METconfigdir/PB2NCConfig
>>>
>>> So far, this seems to work fine, since I have successfully used this
>>> file to verify upper-level temperatures...
>>>
>>> Then, convert wrfouts (netcdf) to an A-grid (grib)
>>> 3) run_wrfpost
>>> This outputs my wrfprs_d01.XX file.
>>> In the wrf_cntrl.parm configuration file, I made sure to specify
>>> various forms of temperatures:
>>>
>>> (SHELTER TEMPERATURE ) SCAL=( 5.0)
>>> L=(10000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000
>>> 00000 00000 00000)
>>> (TEMP ON PRESS SFCS ) SCAL=( 4.0)
>>> L=(11111 11111 11111 11111 11111 11111 11111 11111 11111 10000 00000
>>> 00000 00000 00000)
>>> etc...
>>>
>>> Then, when running PointStat with the output from (2) and (3) and
>>> using
>>> the following edits to the config file:
>>>
>>> vx_grib_code[] = [ "TMP/Z2"];
>>> thresholds[] = [ "gt0"];
>>> message_type[] = [ "ADPSFC", "SFCSHP" ];
>>>
>>> I get the requested output, but looking at the mpr file, the model
>>> forecast is way too cold (229-233 K) while the observations seem
>>> correct
>>> (270-278 K)
>>> :
>>>
>>> TOTAL INDEX OBS_LAT OBS_LON OBS_LVL OBS_ELV FCST OBS
>>> CLIMO
>>> 1 286 1 58.68 -156.65 989.3 14.98281 232.3029 277.05
>>> -9999
>>> 2 286 2 59.75 -154.92 995.2 49.12878 233.0589 275.95
>>> -9999
>>> 3 286 3 57.75 -152.50 997.9 33.93378 232.8184 278.15
>>> -9999
>>> 4 286 4 59.52 -139.67 1026.3 9.02245 230.9946 272.55
>>> -9999
>>> 5 286 5 58.37 -134.58 1029.5 6.98383 230.5191 270.95
>>> -9999
>>> 6 286 6 62.30 -150.10 1004.5 109.13992 233.0715 269.25
>>> -9999
>>> 7 286 7 55.13 -131.58 1031.8 0.00000 230.0803 277.15
>>> -9999
>>> 8 286 8 55.13 -131.58 1031.8 0.00000 230.0803 276.15
>>> -9999
>>> 9 286 9 55.35 -131.70 1027.3 28.94379 230.0819 275.35
>>> -9999
>>> 10 286 10 56.97 -133.95 1031.5 0.00000 229.8285 274.15
>>> -9999
>>> 11 286 11 56.97 -133.95 1031.2 0.00000 229.8285 273.15
>>> -9999
>>> etc....
>>>
>>> Has anyone seen a problem like this? Are there any other steps I
>>> need to
>>> consider?
>>>
>>> -joe
>>> _______________________________________________
>>> Met_help mailing list
>>> Met_help at mailman.ucar.edu
>>> http://mailman.ucar.edu/mailman/listinfo/met_help
>
More information about the Met_help
mailing list