[Met_help] Question about MET grids

[John Halley Gotway]

Dan,

In the MODE tool, we definitely do need to know where on the earth the data is located for several reasons:
- to be able to plot it in the PostScript output
- to convert between x,y and lat,lon for computing and writing out the lat,lon location of the object centroids (and other computations)

In the Point-Stat tool, we also need the grid information for converting between x,y and lat,lon.  When we match point observations in lat,lon to gridded data, we need that conversion.

In the Grid-Stat tool, we do use the grid information in a couple of places.  Users can specify lat,lon polylines or pre-defined grids to define verification regions.  When checking which grid points
fall within those polylines or grids, we use the x,y to lat,lon conversion.  Also, we use the x,y to lat,lon conversion when writing out the gridded matched pair data in NetCDF - we're writing out the
lat,lon values for the grid points.

Really, the need for the grid information in MODE and Point-Stat drove the decision to require it of all gridded input data.  We're trying to reuse code from a library to handle reading the input
data.  So having all that data look the same makes the task much easier.  And since we put MET together with the GRIB output of the WRF-PostProcessor in mind, which always has that grid info included,
it seemed reasonable.

>From your perspective though, I can see why it's a hassle.  You're running Grid-Stat, over the whole domain, using NetCDF input.  And the code isn't actually using the grid information we're
requiring.  However, if you were to define a masking grid or define a masking polyline, the grid information would be used at that point.

I'll bring this issue up with the larger MET group here.

Thanks Dan,
John



Daniel Schaffer wrote:
> Sorry, I didn't make my question crystal clear.  What I mean is that for our purposes, we really don't care whether the data reside on an LC or CE grid.  We'd be fine if we could specify a grid in simple X,Y index space.  So ideally, I could tell MET in the vx_grib_code configuration parameter, that the data in my input file lie on an index grid where NX is 1900 and NY is 838.  
> 
> Dan
> 
> -------------------------------------------------------------------------------
> 
> Dan Schaffer, Research Associate            e-mail: Daniel.S.Schaffer at noaa.gov
> NOAA/OAR/Earth System Research Lab         phone:  (303) 497-7252
> Aviation Branch                             fax:    (303) 497-6301
> R/GSD5   325 Broadway                       
> Boulder, CO 80305
> 
> www-ad.fsl.noaa.gov/ac/schaffer.html
> 
> On Wed, 10 Sep 2008, John Halley Gotway wrote:
> 
>> Dan,
>>
>> In Point-Stat and Grid-Stat, we do require that users indicate the region(s) over which they'd like to accumulate statistics.  It may be useful to look at smaller sub-domains to see how you're model
>> is performing in them.  However, you're right - it's often the case that users will simply want to accumulate statistics over the entire native grid.
>>
>> In METv1.0, there was a clunky way of doing this by defining a polyline that fully contains your domain.  Since all of the points in your domain fall within that large polyline, they'd all be included.
>>
>> In METv1.1, we implemented a more direct way of doing this by specifying the work "FULL" in the mask grids section.  "FULL" just means use the full grid.  This is noted in the comments in the
>> Grid-Stat configuration file for v1.1:
>> //
>> // Specify a comma-separated list of grids to be used in masking the data over
>> // which to perform scoring.  An empty list indicates that no masking grid
>> // should be performed.  The standard NCEP grids are named "GNNN" where NNN
>> // indicates the three digit grid number.  Enter "FULL" to score over the
>> // entire domain.
>> // http://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html
>> //
>> // e.g. mask_grids[] = [ "FULL" ];
>> //
>>
>> And it should also be in the user's guide.
>>
>> Let me know if anything else comes up.
>>
>> John
>>
>> Daniel Schaffer wrote:
>>> grid_stat seems to require that we specify a grid upon which the data reside.  Unfortunately, our particular grid is not one of the NCEP available grids.  I have already figured out how to add my own grid and it's fairly trivial.  Still, I wonder if I really need to go through that hoop.  And, of course, every time I take a new version of MET, I have to make that code change again.  For our case, it really doesn't matter what grid the forecast and obs are on, so long as it's the same, since we are just computing counts.  Am I right that we must specify a grid?  If so, why?
>>>
>>> Thanks,
>>> Dan
>>>
>>> -------------------------------------------------------------------------------
>>>
>>> Dan Schaffer, Research Associate            e-mail: Daniel.S.Schaffer at noaa.gov
>>> NOAA/OAR/Earth System Research Lab         phone:  (303) 497-7252
>>> Aviation Branch                             fax:    (303) 497-6301
>>> R/GSD5   325 Broadway                       
>>> Boulder, CO 80305
>>>
>>> www-ad.fsl.noaa.gov/ac/schaffer.html
>>> _______________________________________________
>>> Met_help mailing list
>>> Met_help at mailman.ucar.edu
>>> http://mailman.ucar.edu/mailman/listinfo/met_help