[Met_help] redux: problems with point_stat

[John Halley Gotway]

Great, I'm glad you were able to fix it.

Thanks,
John

Huiling Yuan wrote:
> John,
>             Thanks a lot. It is scan mode problem in WRF postprocessor.
> It generates a lat/lon text information automatically. I change the scan
> mode to 64. It works correctly for pcp_combine.
> 
> Huiling
> 
> Ed Tollerud wrote:
>> John,
>>
>> Thanks for the very quick reply! I've attached a GRIB file for which we
>> seem to have this problem, and another for which we do not (labelled
>> appropriately). To be clear, these are output grib files from runs of
>> WPP that we input to pcp_combine to sum up or subtract precipitation
>> amounts, so I assume that the scanning mode flag ambiguity arises from
>> the WPP runs. Why would the problem be projection-dependent?
>>
>> Ed
>>
>> John Halley Gotway wrote:
>>   
>>> Ed,
>>>
>>> I put my responses inline.
>>>
>>> John
>>>
>>> Ed Tollerud wrote:
>>>   
>>>     
>>>> John,
>>>>
>>>> Here are a couple of comments and a mystery for you to consider.
>>>>
>>>> 1) Re: our correspondence below, after some trial-and-error, we found
>>>> out that it does matter in point_stat what choice is made for 'message
>>>> type'; it needs to be one of the NCEP possibility choices in the
>>>> configuration file. MC_PCP doesn't work. After then trying 'ANYSFC',
>>>> which also did not work, we settled on 'ADPSFC', which seems to have
>>>> gotten us through.
>>>>     
>>>>       
>>> Sorry I didn't give better guidance on this before.  Glad you were able to get something to work.
>>>
>>>   
>>>     
>>>> 2) When running point_stat with high verbosity, some of the diagnostic
>>>> variables that are displayed appear to be incorrect. In particular, in
>>>> our runs with a domain in the western US, the longitude is given as an
>>>> incorrect positive value (i.e., in the eastern hemisphere). However, in
>>>> the actual computations of point-stat the correct longitudes appear to
>>>> have been used.
>>>>     
>>>>       
>>> I understand why this looks troubling.  The internal MET library which handles the grid definition (vx_data_grids) expects longitude to be in degrees west - as opposed to the degrees east that most
>>> other people use.  For MET, all longitude values that we read in or write out are in degrees east.  After reading it in, we switch from degrees east to west.  And before writing it out, we switch it
>>> back.  So that's what you're seeing.  As long as your grids aren't showing up on the opposite side of the world, we're handling it correctly.
>>>
>>>   
>>>     
>>>> 3) For the same western U.S. domain, we have found that one projection
>>>> (the lat-lon) fails in pcp_combine. In particular, it appears to grab
>>>> onto the upper-left domain corner and assume it is the lower-left, thus
>>>> giving a domain that is far north of the desired one (and hence gave no
>>>> matches with our verification data). Also, when we examined via ncview
>>>> the actual output from pcp_combine, the actual precipitation values seem
>>>> to be partially garbled; a latitudinal (N-S) strip from the western half
>>>> of our domain seems to have been placed on the east side of the domain
>>>> instead. This issue appeared with both NMM and ARW runs, but not for
>>>> fields translated by WPP onto a Lambert projection, and it showed up for
>>>> MET installed in several places (all LINUX). It appears that it might be
>>>> a MET coding glitsch, but it is difficult for us to decipher the actual
>>>> C code and it is hard to believe that this issue hasn't appeared for
>>>> someone else and have been posted on the MET website. So the possibility
>>>> that it is still some kind of hardware effect of our installation or our
>>>> use is still there though we have eliminated all the local FAB/wJET
>>>> possibilities that we can think of.
>>>>     
>>>>       
>>> I think there are 2 likely culprits here.  First, it could be a bug in the MET code.  Second, and I think more likely, there may be an error in how the GRIB data is packed.  In particular, there's a
>>> flag in the Grid Description Section of a GRIB record called the "scanning mode flag".  It tells you the order in which the data is packed in the record: left->right vs right->left and up->down vs
>>> down->up.  If this is set incorrectly, you'd see the type of behavior you're seeing.  And I have helped another user with a similar issue with the scanning mode flag.
>>>
>>> Here's a page that describes this:
>>> http://www.nco.ncep.noaa.gov/pmb/docs/on388/table8.html
>>>
>>> It'd probably be easiest for you to send me a sample GRIB data file.  I'll take a look to see how the GRIB flags are set.
>>>
>>> If they are incorrect, you could either try to repair the GRIB files by modifying the flags.  Or I could help you make a change to code and "hard-code" what the value of scanning mode flag should be.
>>>  I think that's what I did for the last user with this similar issue.
>>>
>>> Just let me know.
>>>
>>> John
>>>
>>>   
>>>     
>>>> John Halley Gotway wrote:
>>>>     
>>>>       
>>>>> Ed,
>>>>>
>>>>> You're right, Point-Stat does expect the message type field to be filled.  I believe that you could make up your own - although I've never done exactly what you're doing before, so I'm not positive.
>>>>> I believe that NCEP generally uses "MC_PCP" as a precipitation message type.  So you could use that convention if you like.
>>>>>
>>>>> As for the model name, it's included in the configuration file for exactly the reason your asking about.  When verifying output from multiple models, you should choose a descriptive "model" name that
>>>>> will allow you differentiate the verification results for each model.  Suppose for example that you're verifying WRF runs with two different sets of physics options.  You might choose models names of
>>>>> "WRF_PH1" and "WRF_PH2".  All the MET tools do with the model name is copy it to the output data.  So now you'll be able to distinguish the results of the two models based on the model name in the
>>>>> output.  Please note though that since the model names are different, you'd need to use two different configuration files - one for each model.
>>>>>
>>>>> Thanks for the heads up about the typos.  We'll fix them for the next release.
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>> Ed Tollerud wrote:
>>>>>   
>>>>>       
>>>>>         
>>>>>> John,
>>>>>>
>>>>>> I had a couple of questions about using point_stat. I am setting up to
>>>>>> introduce my own file of point precipitation obs as verification data
>>>>>> using ascii2nc. In that first step (ascii2nc), I interpreted the
>>>>>> description of the first column (Message_type) as indicating that I
>>>>>> could use an empty bracket [ ] in this case. In the description of the
>>>>>> configuration file for point_stat I see that a message_type is needed.
>>>>>> Should I have 'invented' a message_type for the input to ascii2nc that
>>>>>> would carryover to point_stat? Also, can the model name (eg., "wrf") be
>>>>>> anything useful that I define (we have several previously defined
>>>>>> 'flavors' of WRF that we want to verify and compare)?
>>>>>>
>>>>>> At the risk of sounding petty, I did find two typos that wouldn't
>>>>>> confuse anyone but which you might want to change. In the list of
>>>>>> argument descriptions for the config file for point_stat, one argument
>>>>>> is missing (temp_dir). In the description of ascii2nc in Section 3.6.1,
>>>>>> your title for Required Arguments includes pb2nc instead of ascii2nc.
>>>>>>
>>>>>> Ed
>>>>>>
>>>>>>     
>>>>>>         
>>>>>>           
>>