[Met_help] How to specify the surface variable inthepoint_stat?

John Halley Gotway johnhg at rap.ucar.edu
Wed Jul 1 11:06:53 MDT 2009


I took at look at the seg-fault you're seeing when using "TMP/L0", and I see why it's occurring.  Actually, the seg fault doesn't occur in the latest internal development version of the code.  You
really should be using "TMP/Z0" for Point-Stat, so I don't think that a bug fix is really warranted.  As long as you stick with "TMP/Z0" you won't have any problems.  However, that doesn't solve the
issue of you wanting to treat the MSONET observations as "surface" obs.

If you'd like to interpret all MSONET observations as surface obs, and therefore match them to surface temperature (TMP/Z0), there's a one line change you could make.  You'll need to make a code
change and then recompile MET.

In the file "METv2.0/lib/vx_met_util/constants.h", change line number 39,
FROM: static const char onlysf_msg_typ_str[] = "ADPSFC SFCSHP";
TO:   static const char onlysf_msg_typ_str[] = "ADPSFC SFCSHP MSONET";

I tried making this change, and when I ran the test data you sent, I got 644 pairs for MSONET observations.  Is it correct, that all of your MSONET observations are actually at the surface?

Thanks,
John

Zhu wrote:
> Hi, John:
> 
> 
>     Thank you very much! 
> 
>     Yeah, I'm trying to run with 'Z0', 'L0', 'R0' and forgot to change it back. Using "Z0" will get no error, but no result, just as you point out i should use ADPSFC type of data. But I'm thinking about use mesonet data as truth, so i didn't try the other kinds. Acctually, it do get results when i use the type like ADPSFC as i run the point_stat as a test before.
> 
> Kefeng      
> 
> 
> 2009-06-30 
> 
> 
> 
> Zhu,Kefeng 
> 
> 
> 
> 发件人: John Halley Gotway 
> 发送时间: 2009-06-30  16:16:14 
> 收件人: Zhu, Kefeng 
> 抄送: John Halley Gotway 
> 主题: Re: Re: [Met_help] How to specify the surface variable inthepoint_stat? 
>  
> Kefeng,
> It's no problem at all.  I'm happy to help.
> I ran your data exactly as you sent it through my version of METv2.0, and
> it did not produce the segmentation fault you're seeing.
> I noticed though that in the PointStatConfig file you sent, you're using
> "TMP/Z0", but in the error message you sent it lists "TMP/L0".  When I
> changed the config file to use "TMP/L0", I do see the segmentation fault
> you're seeing.
> I'll look into what's causing that seg-fault tomorrow.  In the meantime,
> stick with using "TMP/Z0".  However, when using "TMP/Z0" you'll notice
> that you get 0 matched pairs for MSONET.  The reason for that is how
> matching is done in the vertical for surface variables which I explained
> in a previous email.  I've cut-and-pasted that info below.
> Thanks,
> John
>> Here's the scoop on matching to vertical levels in Point-Stat...
>> Point-Stat doesn't even look at the height value for the observation
>> points.  Instead, the matching for surface variables is done entirely by
>> message type.  Any observations with a message type of ADPSFC or SFCSHP
>> are considered to be at the surface and are matched to surface variables.
>> So if you're verifying TMP/Z0, you should verify using observations with
>> a
>> message type of ADPSFC or SFCSHP.
>> For this reason, in METv2.0 you won't be able to match MSONET
>> observations
>> to surface variables because the code doesn't consider the MSONET message
>> type to be at the surface.
>> I realize that this logic for matching in the veritical is rather
>> simplistic.  We inherited it from some exisitng NCEP verification code,
>> and decided not to alter it until it becomes necessary to do so.
>> If this doesn't meet your needs, let me know.  And we can look for more
>> sophsticated ways of matching in the vertical.  If that is needed, it'd
>> be
>> helpful for you to send us a sample forecast file, sample point
>> observation file, and a description of how exactly you'd like them to be
>> matched up in the vertical.
>> Hi, John:
>>
>>     Sorry to bother you again and again. I start to do the point_stat
>> analysis as you told me. I want to use the Oklahoma Mesonet data as
>> truth. Using the parameter like "TMP/L0", but get segmentation fault.
>>
>> /work/01008/kfzhu/verification/METv2.0/bin/point_stat
>> /work/01008/kfzhu/result/wpp/control/control_grib/wrfprs_d01.2007081907
>> /work/01008/kfzhu/result/prebufr/pb2nc/pb2007081907.nc
>> config/PointStatConfig_OKC -outdir
>> /work/01008/kfzhu/result/metout/control/point_stat/ -v 2
>> GSL_RNG_TYPE=mt19937
>> GSL_RNG_SEED=3110750794
>> Forecast File:
>> /work/01008/kfzhu/result/wpp/control/control_grib/wrfprs_d01.2007081907
>> Climatology File: none
>> Configuration File: config/PointStatConfig_OKC
>> Observation File: /work/01008/kfzhu/result/prebufr/pb2nc/pb2007081907.nc
>> ----------------------------------------
>> Reading records for TMP/L0.
>> For TMP/L0 found 1 forecast levels and 0 climatology levels.
>> ----------------------------------------
>> Searching 229002 observations from 54900 PrepBufr messages.
>> Segmentation fault
>>
>> Here is the link of the sampe data.
>> http://www.caps.ou.edu/~kzhu/dataerin.tar.gz
>> 20072310700.t07z.prebufr: orgrinal NCEP prepbufr data
>> Oklahoma.poly: Masking area
>> pb2007081907.nc : after data process of pb2nc using METv2.0
>> PB2NCConfig_OKC: configure file of pb2nc
>> PointStatConfig_OKC: configure file of point_stat
>> wrfprs_d01.2007081907: the forecasted filed
>>
>> I have looked into the NETCDF file after pb2nc, and find that there're 171
>> mesonet site in the Oklahoma region. The attachment show the site
>> location. And the grib type of the data are 7,11,17,32,33,34,51,52,53.
>> Could you help me to look into these data?
>>
>> Thank you!
>>
>> Kefeng
>>
>>
>>
>> 2009-06-30
>>
>>
>>
>> Zhu,Kefeng
>>
>>
>>
>> 发件人: John Halley Gotway
>> 发送时间: 2009-05-29  21:02:47
>> 收件人: Zhu, Kefeng
>> 抄送: met_help
>> 主题: Re: [Met_help] How to specify the surface variable in
>> thepoint_stat?
>>
>> Kefeng,
>> Sorry for the delay in getting back with you.
>> Yes, specifying "TMP/Z0" should tell Point-Stat to retrieve the surface
>> temperature variable.  If for some reason that doesn't work, try using
>> "TMP/L0" instead.  The difference is that when you say Z0, Point-Stat
>> tries to find a GRIB record that's defined as a VERTICAL level with a
>> level value of 0.  When you say L0, Point-Stat tries to find a GRIB
>> record
>> with a level value of 0 regardless of what "type" of level it is:
>> vertical
>> level, pressure level, or any other type of level.  But "TMP/Z0" should
>> do
>> the trick.
>> Here's the scoop on matching to vertical levels in Point-Stat...
>> Point-Stat doesn't even look at the height value for the observation
>> points.  Instead, the matching for surface variables is done entirely by
>> message type.  Any observations with a message type of ADPSFC or SFCSHP
>> are considered to be at the surface and are matched to surface variables.
>> So if you're verifying TMP/Z0, you should verify using observations with
>> a
>> message type of ADPSFC or SFCSHP.
>> For this reason, in METv2.0 you won't be able to match MSONET
>> observations
>> to surface variables because the code doesn't consider the MSONET message
>> type to be at the surface.
>> I realize that this logic for matching in the veritical is rather
>> simplistic.  We inherited it from some exisitng NCEP verification code,
>> and decided not to alter it until it becomes necessary to do so.
>> If this doesn't meet your needs, let me know.  And we can look for more
>> sophsticated ways of matching in the vertical.  If that is needed, it'd
>> be
>> helpful for you to send us a sample forecast file, sample point
>> observation file, and a description of how exactly you'd like them to be
>> matched up in the vertical.
>> I'll be out of town all next week at a conference, so I won't have much
>> time to respond until the following week.
>> Thanks,
>> John Halley Gotway
>> johnhg at ucar.edu
>>> Hi:
>>>
>>>     I'm wondering how to specify the surface variable like surface
>>> temperature? Does 'TMP/Z0' work? How does MET deal with the
>>> observation when i specify 'TMP/Z0' while actually the observed
>>> temperature are at 1.5m height?
>>>      Another question is do MET have any detail instruction about what
>>> kind of variable can be verified by specified type of observation
>>> like MSONET?  Beacuse when i set the
>>> fcst_field[] = [ "TMP/Z0", "UGRD/Z10", "VGRD/Z10" ];
>>> message_type[] = [ "MSONET" ];
>>>     I got nothing after the point_stat analysis.
>>>     Thanks!
>>>
>>> Kefeng
>>>
>>> 2009-05-27
>>>
>>>
>>>
>>> Zhu,Kefeng
>>> _______________________________________________
>>> 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