[Met_help] point_stat

[Mark Seefeldt]

John,

Thanks for the update.  Please pass around the fix when you have it 
completed.  The information you provided is valuable as it means that I 
can start processing the GRIB files for the complete evaluation.

Mark

John Halley Gotway wrote:
> Mark,
> 
> Thanks for sending the data.  I see what the problem is - there's a
> bug in the library code that reads the valid time of the GRIB
> forecast file.  It thinks it 2098 as opposed to 1998.  So Point-Stat 
> is looking for observation values that are in the time window
> 20980430 +/- 5400 seconds.  And of course, it doesn't find any!
> 
> I'm headed out for the day, but I'll put together a fix and send it
> to you tomorrow.
> 
> In the meantime, try using the "-valid_beg" and "-valid_end" command
> line options to manually set the matching time window.  That should
> get you non-zero matched pairs.
> 
> Thanks for finding this issue!
> 
> John
> 
> Mark Seefeldt wrote:
>> John,
>> 
>> Thank you for all of the tips and suggestions which you have
>> provided. I have worked through the different items and I am still
>> not getting matched pairs when I should be.
>> 
>> I have uploaded the following files to the anonymous ftp: 
>> phy_sheba-barrow-d01-199805.nc - nc observation file 
>> phy_sheba-barrow-d01-199805.txt - text observation file 
>> wppout_d01_1998-04-30_00.grb - GRIB output from using WPPv3.1 
>> PointStatConfig-phy_sheba - point_stat configuration file
>> 
>> The WRF simulation is for an entire month, centered over Alaska.
>> The observations are surface pressure, temperature, relative
>> humidity, downwelling shortwave, and downwelling longwave radiation
>> for a single site, Barrow, Alaska.
>> 
>> Let me know if you have any additional questions.
>> 
>> Thanks
>> 
>> Mark
>> 
>> John Halley Gotway wrote:
>>> Mark,
>>> 
>>> Let me make a few comments about this.
>>> 
>>> First, depending on how you configure Point-Stat, getting 0
>>> matched pairs for certain combinations of variables/message type
>>> may be fine. For example, if you configure Point-Stat to verify
>>> Temperature at 2-meters above the surface (TMP/Z2) and at 500mb
>>> (TMP/P500) using message types of ADPSFC (surface obs) and APDUPA
>>> (upper air obs), you would actually expect to get 0 matched pairs
>>> for TMP/Z2 vs APDUPA and 0 matched pairs for TMP/P500 vs ADPSFC.
>>> So sometimes having 0 matched pairs is fine.
>>> 
>>> However, if you're getting 0 matched pairs when you expect that
>>> you should actually be finding some, here's what I'd ask myself:
>>> 
>>> - Am I applying some masking region (a grid or a polyline) that
>>> is perhaps not working like I expect?  Try rerunning with the
>>> masking grid set to FULL to verify over the whole domain.
>>> 
>>> - Does my forecast field contain valid data?  Clearly Point-Stat
>>> is finding the fields you'd like to verify, otherwise it'd error
>>> out. But if what it's finding contains only bad data, it won't
>>> find any matched pairs.  Can you view the forecast field with
>>> some other tool to check that the field contains valid data?  For
>>> NetCDF format, use ncview.  For GRIB, "wgrib -V" will tell you
>>> the min/max data values. Or you could view the GRIB file using
>>> NCL or IDV.  Or you could run it through the MET-MODE tool and
>>> look at the output plot.
>>> 
>>> - Do I have my valid times correct?  Am I using observations that
>>> are valid around the same time that my forecast file is valid?
>>> In the Point-Stat config file, you could set the "beg_ds" and
>>> "end_ds" values to define a VERY large time window to see if you
>>> can get some matched pairs.
>>> 
>>> - Lastly, do the observations I'm using not match my forecast for
>>>  some other reason?  For example, are the message types for the 
>>> observations correct?  You could try doing an ncdump to see what 
>>> message types are in your point observation file (ncdump -v
>>> hdr_typ file_name.nc | sort -u).  Or are the observations not
>>> matching for some other reason?  This would be the most difficult
>>> to determine!
>>> 
>>> Hopefully that'll help you figure out what's going on with your
>>> data. I'd suggest "opening" things up as much as possible (mask
>>> grid = FULL and set beg_ds/end_ds very large) to try to get
>>> non-zero matched pairs, and go from there.
>>> 
>>> If you're still having problems after trying these things, feel
>>> free to send me some sample files, and I could take a look to see
>>> what going on.  You'd need to send me: (1) Forecast file input
>>> for Point-Stat. (2) Observation file input for Point-Stat. (3) 
>>> Configuration file input for Point-Stat. And you could post those
>>>  files to RAL's anonymous ftp site: ftp ftp.rap.ucar.edu username
>>> = anonymous password = "your email address" cd
>>> incoming/irap/johnhg put "those 3 files" bye (to exit ftp)
>>> 
>>> Thanks and good luck, John
>>> 
>>> 
>>> Mark Seefeldt wrote:
>>>> I am working on a model evaluation using point_stat in MET.  As
>>>> it processes I am getting 0 pairs matched, therefore no
>>>> statistics. Is there a preferred method to identify if it is
>>>> the observation file, the forecast file, or the configuration
>>>> file where the error resides resulting in the lack of matched
>>>> obs/fcst values?  I am at a loss as to what is wrong in my
>>>> setup which is preventing the obs/fcst pairs to be matched and
>>>> to create the output.
>>>> 
>>>> Thanks
>>>> 
>>>> Mark _______________________________________________ Met_help 
>>>> mailing list Met_help at mailman.ucar.edu 
>>>> http://mailman.ucar.edu/mailman/listinfo/met_help
>