mark.seefeldt at Colorado.EDU
Tue Apr 28 12:09:29 MDT 2009
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.
John Halley Gotway wrote:
> 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!
> Mark Seefeldt wrote:
>> 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.
>> John Halley Gotway wrote:
>>> 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.
>>>> Mark _______________________________________________ Met_help
>>>> mailing list Met_help at mailman.ucar.edu
More information about the Met_help