[Met_help] PWAT verification with MET Tools
John Halley Gotway
johnhg at ucar.edu
Thu Nov 19 08:23:06 MST 2009
Thomas,
Good news. I was able to reproduce the segmentation fault you're seeing. For the longest time, it was running fine on my code. And then I realized that I'm running with the latest patches for
METv2.0, while you may not be. So I reverted back to the originally released code, and I layered on the 2 changes I had sent you. And then I did see the segmentation fault.
The good news is that the latest set of patches posted on the MET website fixes this problem. I'm not exactly sure which patch fixes it, but it shouldn't matter.
Please do the following:
(1) Retrieve the latest set of patches from:
http://www.dtcenter.org/met/users/support/known_issues/METv2.0/patches/METv2.0_patches_20091022.tar.gz
(2) Place that tar file into your top-level METv2.0 directory, and untar it:
tar -xvzf METv2.0_patches_20091022.tar.gz
(3) That will overwrite several source code files with the latest patches. Unfortunately, one of the files which will be overwritten is "read_grib.cc" which we updated a couple days ago with that
patch. Please go ahead and apply the patches first. Second, copy the attached file "read_grib.cc" into METv2.0/lib/vx_met_util/read_grib.cc. The attached version includes the patch I sent you a
couple days ago.
(4) Then rebuild MET being sure to do a "make clean" first.
Hope that does the trick.
Thanks,
John
Thomas Schwitalla wrote:
> John,
>
> unfortunately this does not work. When I look into the core file with
> gdb, it contains the following:
>
> Core was generated by `./point_stat
> /taifun/20070720_cops_WRF_sensitivity/assim/wrf_files/postprd/WRFP'.
>
> Program terminated with signal 11, Segmentation fault.
>
> [New process 26026]
>
> #0 0x0000000000440cf7 in GCPairData::compute_interp ()
>
>
> Is it possible, that sth. is wrong with my observations?
>
> Thomas
>
> John Halley Gotway schrieb:
>> Thomas,
>>
>> I'm able to run that data without a problem. I'm not sure what the
>> source of your problem is. Please try redirecting the output to some
>> directory other than the default one.
>> For example, try this:
>>
>> mkdir ~/met_out
>> ./point_stat
>> /taifun/20070720_cops_WRF_sensitivity/assim/wrf_files/postprd/WRFPRS_2007072000_d01.000
>> \
>> 20070720_pwat.nc \
>> PointStatConfig \
>> -v 3 -outdir ~/met_out
>>
>> Perhaps there's some problem with where it's trying to create the
>> output files.
>>
>> John
>>
>> Thomas Schwitalla wrote:
>>
>>> John,
>>>
>>> I uploaded the 000 file and the new observation data.
>>> Maybe the error is caused due PWAT being an integrated variable?
>>>
>>> Best regards
>>> Thomas
>>>
>>> John Halley Gotway schrieb:
>>>
>>>> Thomas,
>>>>
>>>> Hmmm. I'll try running it here to see if can reproduce the seg-fault
>>>> you're seeing.
>>>>
>>>> I have the file: WRFPRS_2007072000_d01.001
>>>> But I don't have the file: WRFPRS_2007072000_d01.000
>>>>
>>>> Could you post that 000 file to the ftp site, and I'll try running
>>>> with it later today?
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>> Thomas Schwitalla wrote:
>>>>
>>>>
>>>>> John,
>>>>>
>>>>> I get a segmentation fault .... :-(
>>>>> I never had this before with T2M, TD2m, wind, precipitation...
>>>>>
>>>>> Thomas
>>>>>
>>>>> John Halley Gotway schrieb:
>>>>>
>>>>>> Thomas,
>>>>>>
>>>>>> Looks fine to me, and I don't see that config file error in the log
>>>>>> file you sent. Is there still a problem, or is working fine for you?
>>>>>>
>>>>>> John
>>>>>>
>>>>>> Thomas Schwitalla wrote:
>>>>>>
>>>>>>
>>>>>>> John,
>>>>>>>
>>>>>>> the command I use is:
>>>>>>> ./point_stat
>>>>>>> /taifun/20070720_cops_WRF_sensitivity/assim/wrf_files/postprd/WRFPRS_2007072000_d01.000
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 20070720_pwat.nc PointStatConfig -v 10 >& log (attached)
>>>>>>>
>>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>>
>>>>>>> John Halley Gotway schrieb:
>>>>>>>
>>>>>>>> Thomas,
>>>>>>>>
>>>>>>>> I'm thinking that you've made a mistake in how you're calling
>>>>>>>> Point-Stat on the command line.
>>>>>>>>
>>>>>>>> Take a look at how you're calling it on the command line and make
>>>>>>>> sure
>>>>>>>> it matches the calling sequence:
>>>>>>>> point_stat fcst_file obs_file config_file
>>>>>>>>
>>>>>>>> Based on the error, my guess is that you're passing the
>>>>>>>> "obs_file" in
>>>>>>>> the "config_file" spot.
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>> Thomas Schwitalla wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> John,
>>>>>>>>>
>>>>>>>>> with
>>>>>>>>>
>>>>>>>>> fcst_field[] = [ "PWAT/L0" ];
>>>>>>>>>
>>>>>>>>> it works.
>>>>>>>>> Concerning the times, I had a mistake in my original conversion
>>>>>>>>> program
>>>>>>>>> which should be solved now....
>>>>>>>>>
>>>>>>>>> but now I get:
>>>>>>>>>
>>>>>>>>> config() -> syntax error in file "20070720_pwat.nc"
>>>>>>>>>
>>>>>>>>> line = 1
>>>>>>>>>
>>>>>>>>> econfig_column = 7
>>>>>>>>>
>>>>>>>>> text = "V8"
>>>>>>>>>
>>>>>>>>> CDF
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks again for your help!
>>>>>>>>>
>>>>>>>>> Thomas
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> John Halley Gotway schrieb:
>>>>>>>>>
>>>>>>>>>> Thomas,
>>>>>>>>>>
>>>>>>>>>> OK, sorry, my mistake. You need to use:
>>>>>>>>>> fcst_field[] = [ "PWAT/L0" ];
>>>>>>>>>>
>>>>>>>>>> The "L0" says "give me a field with a level value of 0 and I
>>>>>>>>>> don't
>>>>>>>>>> care what type of level it is". When you say "Z0" the code
>>>>>>>>>> looks at
>>>>>>>>>> what type of level is in the GRIB file and only uses the one
>>>>>>>>>> defined on vertical levels. But PWAT isn't defined on a vertical
>>>>>>>>>> level - it's level type is the "entire atmosphere (considered
>>>>>>>>>> as a
>>>>>>>>>> single layer)".
>>>>>>>>>>
>>>>>>>>>> The reason why we have all these silly letters is to avoid
>>>>>>>>>> conflicts. For example, other users have had temperature at
>>>>>>>>>> 2-meters
>>>>>>>>>> and 2 mb. Both records will have a level value of 2, but "Z2"
>>>>>>>>>> will
>>>>>>>>>> get
>>>>>>>>>> you the first one, while "P2" will get you the second one.
>>>>>>>>>> And if
>>>>>>>>>> all
>>>>>>>>>> else fails, you can always say "PWAT/R171" to explicitly give you
>>>>>>>>>> GRIB
>>>>>>>>>> record number 171 - which wgrib told us is the record
>>>>>>>>>> number for PWAT in that file.
>>>>>>>>>>
>>>>>>>>>> I was able to get it to run using "PWAT/L0", but initially
>>>>>>>>>> Point-Stat
>>>>>>>>>> found no matched pairs. It looks like there a slight time offset
>>>>>>>>>> that's causing the problem. This is a 1-hour forecast
>>>>>>>>>> initialized at 2007072000 - so the valid time is 2007072001. I
>>>>>>>>>> looked
>>>>>>>>>> at the observations your using, and they range in time from
>>>>>>>>>> 20070720_230700 to 20070720_235200.
>>>>>>>>>>
>>>>>>>>>> You're welcome to compare this forecast to these observations if
>>>>>>>>>> you'd
>>>>>>>>>> like, but you'll need to set the matching time window
>>>>>>>>>> differently to
>>>>>>>>>> do so. In the config file, you can set the "beg_ds" and
>>>>>>>>>> "end_ds" parameters to define the matching time window in
>>>>>>>>>> reference to
>>>>>>>>>> the forecast time window. Alternatively, the "-valid_beg" and
>>>>>>>>>> "-valid_end" command line options override the "beg_ds" and
>>>>>>>>>> "end_ds" settings in the config file.
>>>>>>>>>>
>>>>>>>>>> Once I changed the time window, I was able to get matched pairs.
>>>>>>>>>>
>>>>>>>>>> Hope that helps.
>>>>>>>>>>
>>>>>>>>>> John
>>>>>>>>>>
>>>>>>>>>> Thomas Schwitalla wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> I uploaded the data on your ftp server, as one timestep is about
>>>>>>>>>>> 100MB...
>>>>>>>>>>>
>>>>>>>>>>> Thanks again for your effort! Your reaction time is
>>>>>>>>>>> fantastic! 8-)
>>>>>>>>>>>
>>>>>>>>>>> Thomas
>>>>>>>>>>>
>>>>>>>>>>> John Halley Gotway schrieb:
>>>>>>>>>>>
>>>>>>>>>>>> Thomas,
>>>>>>>>>>>>
>>>>>>>>>>>> Please send me a sample forecast file, a sample ASCII file,
>>>>>>>>>>>> and the
>>>>>>>>>>>> PointStatConfig file you're using. I'll take a look and see if
>>>>>>>>>>>> I can
>>>>>>>>>>>> figure it out.
>>>>>>>>>>>>
>>>>>>>>>>>> If the forecast file is pretty large, you could post those
>>>>>>>>>>>> to our
>>>>>>>>>>>> anonymous ftp site:
>>>>>>>>>>>>
>>>>>>>>>>>> ftp ftp.rap.ucar.edu
>>>>>>>>>>>> username=anonymous
>>>>>>>>>>>> password="your email address"
>>>>>>>>>>>> cd incoming/irap/met_help/schwitalla_data
>>>>>>>>>>>> put "your files, 1 at a time"
>>>>>>>>>>>> bye
>>>>>>>>>>>>
>>>>>>>>>>>> Just let me know when you've posted the files.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> John
>>>>>>>>>>>>
>>>>>>>>>>>> Thomas Schwitalla wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> John,
>>>>>>>>>>>>>
>>>>>>>>>>>>> when I try your suggestion, I got the following message:
>>>>>>>>>>>>>
>>>>>>>>>>>>> ERROR: process_grib_codes() -> no records matching GRIB
>>>>>>>>>>>>> code 54
>>>>>>>>>>>>> with
>>>>>>>>>>>>> level indicator of Z0 found in GRIB file:
>>>>>>>>>>>>> /taifun/20070720_cops_WRF_sensitivity/assim/wrf_files/postprd/WRFPRS_2007072000_d01.002
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> "wgrib -v" on this file gives:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 171:80565400:D=2007072001:PWAT:atmos col:kpds=54,200,0:1hr
>>>>>>>>>>>>> fcst:winds in
>>>>>>>>>>>>> grid direction:"Precipitable water [kg/m^2]
>>>>>>>>>>>>>
>>>>>>>>>>>>> A sample line of my ASCII file reads:
>>>>>>>>>>>>>
>>>>>>>>>>>>> ADPSFC 0007 20070720_233700 52.9480 12.3922
>>>>>>>>>>>>> 60.9550 54
>>>>>>>>>>>>> -9999 60.9550 31.3000
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now I am a bit confused...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thomas
>>>>>>>>>>>>>
>>>>>>>>>>>>> John Halley Gotway schrieb:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thomas,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Just to be clear...
>>>>>>>>>>>>>> (1) Your forecast from WPP of precipitable water is a value
>>>>>>>>>>>>>> that's
>>>>>>>>>>>>>> integrated over the whole column of air above each grid
>>>>>>>>>>>>>> point.
>>>>>>>>>>>>>> (2) Your point observations of precipitable water are the
>>>>>>>>>>>>>> same
>>>>>>>>>>>>>> - a
>>>>>>>>>>>>>> value for the whole column of air above the observation
>>>>>>>>>>>>>> point at
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> surface.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If that's true, I'd set up the PointStatConfig file as
>>>>>>>>>>>>>> follows:
>>>>>>>>>>>>>> fcst_field[] = [ "PWAT/Z0" ];
>>>>>>>>>>>>>> message_type[] = [ "ADPSFC" ];
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That means "give me the precipitable water field with a level
>>>>>>>>>>>>>> value of
>>>>>>>>>>>>>> 0", which is how's it's stored in your GRIB file. And verify
>>>>>>>>>>>>>> against
>>>>>>>>>>>>>> "surface" observations. When you call ASCII2NC, be sure to
>>>>>>>>>>>>>> encode these PWAT observations using the "ADPSFC" message
>>>>>>>>>>>>>> type.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Give that a try and let me know if you have any problems.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> John
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thomas Schwitalla wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> John,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I want to verify WRF forecasts (postprocessed with WPP)
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> PWAT
>>>>>>>>>>>>>>> data
>>>>>>>>>>>>>>> from GPS stations. I already wrote it to NETCDF with
>>>>>>>>>>>>>>> ascii2nc
>>>>>>>>>>>>>>> but I
>>>>>>>>>>>>>>> haven't figured out how to edit PointStatConfig that I
>>>>>>>>>>>>>>> can use
>>>>>>>>>>>>>>> PWAT. My
>>>>>>>>>>>>>>> problem is: What value to set for the level type/code as
>>>>>>>>>>>>>>> PWAT
>>>>>>>>>>>>>>> is an
>>>>>>>>>>>>>>> integrated value?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> wgrib output looks as follows:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> PWAT kpds5=54 kpds6=200 kpds7=0 levels=(0,0) grid=255 atmos
>>>>>>>>>>>>>>> col
>>>>>>>>>>>>>>> 1hr
>>>>>>>>>>>>>>> fcst:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>> Thomas
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: read_grib.cc
Type: text/x-c++src
Size: 50295 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/met_help/attachments/20091119/45925813/attachment-0001.bin
More information about the Met_help
mailing list