[Met_help] Troubleshooting test cases with MET 2.0
John Halley Gotway
johnhg at rap.ucar.edu
Thu Apr 23 07:20:08 MDT 2009
Remi,
For ASCII2NC, the data should be separated by one or more spaces. Commas and tabs won't work.
Based on your question, it sounds like you'd like to use MET (ASCII2NC and Point-Stat) to verify precipitation at the surface. Your point observations are SYNOP stations with 6 hourly accumulation of
rainfall. As of METv2.0, we are not actually using two of the columns of data in the ASCII2NC format - specifically, the "Elevation" of the station and the "Height" of the observation.
Even though MET doesn't currently use "Elevation" and "Height", we've included them in there for a couple of reasons:
- That information is readily available in PrepBufr files and is retained by the PB2NC tool.
- We may want to use the vertical level information to do more sophisticated matching in the future.
However, since we're not actually using those values in METv2.0, you can supply a fill value of "-9999" for them. Don't worry about trying to parse them out of metadata.
Currently, MET does matching in the vertical in a pretty simplistic way - based only on the value of the "Message_Type". MET only matches forecasts at the surface (i.e. rainfall at the surface,
temperature at 2-meters, winds at 10-meters) to point observations with a message type value of "ADPSFC" or "SFCSHP". So to verify precipitation at the surface, I'd suggest using the "ADPSFC"
Message_Type for ASCII2NC. For observations of precip, the "Level" value should be set to the accumulation interval you're verifying - in your case, 6 for 6 hours. When verifying upper-air
forecasts, (i.e. Temperature at 500mb) the "Level" value should instead be filled with the pressure level for that observation. For upper-air, MET does matching in the vertical based on pressure levels.
As for the "Grib_Code", for precip we typically use a value of 61 for "Total Precipitation". Here's a link to the table from NCEP: http://www.nco.ncep.noaa.gov/pmb/docs/on388/table2.html
I do see that in Parameter Table version 130 and 131, 140 is "Categorical Rain" and 162 is "Liquid Precipitation". Ultimately, the GRIB code number will need to match the code used in your model
output. And the GRIB output of the WRF PostProcessor uses 61 for accumulated precip I believe. So that's what I'd suggest.
Another thing I'd mention, in that NCEP table, we use Parameter Table version number 2 as the default. If you'd like to use variables from a different parameter table version (i.e. 130 or 131),
you'll need to indicate that in the MET config files. So if you were using GRIB code 140 for "Categorical Rain" from Paramter Table version 130, you'd need to set the "grib_ptv" variable in the MET
config files to 130.
And lastly, as for documentation for how MET is actually being used... unfortunately, I don't have much to offer. We actually began discussing this last week though. We'd like to work on a list of
MET and MET-related publications to post on the MET website. Hopefully in the coming months, we'll make additions to that.
Please let me know if you need any more clarification or if other questions arise.
Thanks,
John
Remi Montroty wrote:
> John,
>
> I'd have to agree : if the WRF/WRF mode test works....
>
> And regarding other matters, I have recently been hired to develop
> activities with MET that could be used as showcases for us.
> Any documentation from users that you could send over or point me
> towards, I'd happy to have a look at in order to get more inspiration on
> what we ought to do locally.
>
> Also, I'm working on adapting our local observations for ASCII2NC : it
> is not quite clear what the field separator should be (tab or space).
>
> I also was wondering how critical the Elevation (p3-12), Level, &
> Height (p3-13 of the user guide) were in order to successfully use this
> data as verification.
> Typically, I'm asking this because we're using SYNOP stations for
> accumulated rain over 6h. Turns out those stations only have their
> elevation in meters in a METADATA file...
> I've converted that to MSL using the standard atmosphere hypothesis but
> I'm not sure this is sufficient and whether the file will in the end be
> consistent with the model output it is expecting?
>
> Finally, regarding Grib_Code (p3-13), for my typical example (rain
> accumulation), I have found both code 162 from NWS/NCEP webpage & code
> 140 from my WRF files.
> Could you clarify what code needs to be used? Is there a reference table
> that I'm missing?
>
> Many thanks,
>
> Remi
>
> John Halley Gotway wrote:
>> Remi,
>>
>> I spoke with the other MET developer about this and spent some time
>> looking into it. Our initial guess is that it may be some floating
>> point issue particular to your machine/OS/compiler. However,
>> that'd be pretty difficult to debug remotely. I'd suggest continuing
>> to run MODE on your local WRF output, and if you encounter any more
>> errors similar to these, please let us know. You could send
>> us your input data and configuration files, and we could try to
>> reproduce the error here. We'd be happy to help.
>>
>> I agree that this issue is likely somewhere in vx_wrfdata.cc around
>> line 1045. In particular, I'm wondering about lines 1038 to 1040. Is
>> the angle value being computed actually <= 360.0 or is
>> something odd going on?
>> angle = deg_per_rad*atan2(beta, alpha);
>> angle -= 360.0*floor(angle/360.0);
>>
>> Please let us know if you encounter any more errors or have questions
>> about running MET.
>>
>> Thanks,
>> John Halley Gotway
>>
>> John Halley Gotway wrote:
>>
>>> Remi,
>>>
>>> The developer who really needs to look at this is out sick today.
>>> But I'll talk to him about it tomorrow.
>>>
>>> I'm very glad to hear that you're able to run MODE on your local WRF
>>> data without any errors. Ultimately, that's more important than the
>>> test scripts. But that makes the errors you're seeing even
>>> more puzzling. Why would you see this error message with the test
>>> data, but not with your local GRIB output?
>>>
>>> Please let me know if you see this or any other errors when running
>>> MET on your local WRF output.
>>>
>>> Thanks,
>>> John
>>>
>>> Remi Montroty wrote:
>>>
>>>> John,
>>>>
>>>> Yes, we were looking at that portion of the code and it would seem that
>>>> in vx_wrfdata, the angle is never set properly. Thus j stays at -1 and
>>>> we get that error message.
>>>> (around line 1045 of vx_wrfdata.cc). Given how the test that is
>>>> done, we
>>>> don't quite understand why it is not set to k (j=k in the loop)...
>>>>
>>>> Regarding the GNU compilers, we did not manage to compile partly
>>>> because
>>>> netcdf had been compiled with intel compilers first and that caused
>>>> problems.
>>>> However, even after recompiling netcdf with GNU compilers, we still had
>>>> an error message and I must say we gladly gave up.... So in other
>>>> terms, we never got that message about convex hulls since we never
>>>> managed to compile! I could have another look at it if need be.
>>>>
>>>> Any debugging file welcome. FYI, on the suggestion of a colleague, we
>>>> tested the MODE binary on two of our GRIB1 files (India domain) and
>>>> made
>>>> it work smoothly. It would seem the test_mode.sh is thus causing more
>>>> problems than our local WRF run output files.
>>>>
>>>> Thanks,
>>>>
>>>> Remi
>>>>
>>>>
>>>> John Halley Gotway wrote:
>>>>
>>>>> Remi,
>>>>>
>>>>> Thanks for registering.
>>>>>
>>>>> The error message you're seeing is rather odd. This is the first time
>>>>> I've seen this one. I really don't think that it has anything to do
>>>>> with NetCDF because you're getting the same error message
>>>>> from the last of the 3 MODE test cases which uses only GRIB input
>>>>> files.
>>>>>
>>>>> Just to clarify, when you say that you tried the GNU compilers to no
>>>>> avail, do you mean that you got the exact same error message about the
>>>>> convex hulls? Or were there other problems?
>>>>>
>>>>> I'll talk to the developer who wrote this section of code. We may
>>>>> want to send you a debug version of a file or two, have you recompile
>>>>> MET, and rerun the MODE test case. But I'll let you know.
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>> Remi Montroty wrote:
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am trying to make sure MET v2.0 installed properly.
>>>>>>
>>>>>> I seem to have a problem with test_mode.sh as follows:
>>>>>> [met at cipsproc3 scripts]$ ./test_mode.sh
>>>>>>
>>>>>> *** Running MODE on APCP using netCDF input for both forecast and
>>>>>> observation ***
>>>>>> Forecast File: ../out/pcp_combine/sample_fcst_12L_2005080712V_12A.nc
>>>>>> Observation File: ../out/pcp_combine/sample_obs_2005080712V_12A.nc
>>>>>> Match Config File: config/WrfModeConfig_APCP_12
>>>>>> Merge Config File: config/WrfModeConfig_APCP_12
>>>>>> Forecast Field: APCP_12 at SFC
>>>>>> Observation Field: APCP_12 at SFC
>>>>>> Identifying objects in the forecast and observation fields...
>>>>>> Computing contingency table statistics...
>>>>>> Identified: 7 forecast objects and 4 observation objects.
>>>>>> Performing merging (threshold merging) in the forecast field.
>>>>>> Performing merging (threshold merging) in the observation field.
>>>>>> Remaining: 7 forecast objects and 4 observation objects.
>>>>>> Performing matching between the forecast and observation fields.
>>>>>>
>>>>>>
>>>>>> ERROR: convex_hull(Polyline &) -> can't find next hull point
>>>>>>
>>>>>>
>>>>>> *** Running MODE on APCP using a GRIB forecast and netCDF observation
>>>>>> ***
>>>>>> Forecast File:
>>>>>> ../data/sample_fcst/2005080700/wrfprs_ruc13_24.tm00_G212
>>>>>> Observation File: ../out/pcp_combine/sample_obs_2005080800V_24A.nc
>>>>>> Match Config File: config/WrfModeConfig_APCP_24
>>>>>> Merge Config File: config/WrfModeConfig_APCP_24
>>>>>> Searching GRIB forecast file for GRIB code 61 with accumulation/level
>>>>>> indicator of A24.
>>>>>> Forecast Field: APCP_24 at SFC
>>>>>> Observation Field: APCP_24 at SFC
>>>>>> Identifying objects in the forecast and observation fields...
>>>>>> Computing contingency table statistics...
>>>>>> Identified: 4 forecast objects and 6 observation objects.
>>>>>> Performing merging (no merging) in the forecast field.
>>>>>> Performing merging (no merging) in the observation field.
>>>>>> Remaining: 4 forecast objects and 6 observation objects.
>>>>>> Performing matching between the forecast and observation fields.
>>>>>>
>>>>>>
>>>>>> ERROR: convex_hull(Polyline &) -> can't find next hull point
>>>>>>
>>>>>>
>>>>>> *** Running MODE on RH at 500mb using GRIB input for both forecast
>>>>>> and observation ***
>>>>>> Forecast File:
>>>>>> ../data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212
>>>>>> Observation File:
>>>>>> ../data/sample_fcst/2005080712/wrfprs_ruc13_00.tm00_G212
>>>>>> Match Config File: config/WrfModeConfig_RH
>>>>>> Merge Config File: config/WrfModeConfig_RH
>>>>>> Searching GRIB forecast file for GRIB code 52 with accumulation/level
>>>>>> indicator of P500.
>>>>>> Searching GRIB observation file for GRIB code 52 with
>>>>>> accumulation/level indicator of P500.
>>>>>> Forecast Field: RH at ISBL_500
>>>>>> Observation Field: RH at ISBL_500
>>>>>> Identifying objects in the forecast and observation fields...
>>>>>> Computing contingency table statistics...
>>>>>> Identified: 8 forecast objects and 12 observation objects.
>>>>>> Performing merging (no merging) in the forecast field.
>>>>>> Performing merging (no merging) in the observation field.
>>>>>> Remaining: 8 forecast objects and 12 observation objects.
>>>>>> Performing matching between the forecast and observation fields.
>>>>>>
>>>>>> ERROR: convex_hull(Polyline &) -> can't find next hull point
>>>>>>
>>>>>> The fact that the convex_hull function fails seems problematic. What
>>>>>> should I look into?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Remi
>>>>>>
>>>>>>
>>>>>
>>> _______________________________________________
>>> 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