[Met_help] polyline define

[John Halley Gotway]

Segayle,

(1) For Grid-Stat, I'd suggest using the default interpolation method:
   interp_method[] = [ "UW_MEAN" ];
   interp_width[]  = [ 1 ];

That essentially means to do no smoothing.  Since the forecast and observation fields are on the same grid, using a width of 1 means to match each forecast point to the closest observation point.
Since those points exactly overlap, that means do no smoothing.  But yes, you do need to specify something.  If you empty either out, you should get a error when you run Grid-Stat.

(2) The points in the polyline file should define the boundary of a polyline region.  I don't think it matters if they're listed in clockwise or counter-clockwise order, but they should be listed in
order as you step around the boundary.  Adjacent points in the list are connected and the last point in the list is connected up the first point.  The lat/lon's do not need to be the location of grid
points.  MET will draw the lat/lon polyline and then step through each point in the grid.  For each point, if it's corresponding lat/lon value falls inside the polyline, it's turned on.  If not, it's
turned off.

Hope that helps.

John




Segayle Thompson wrote:
> John,
> 
> I am not sure what happened. I reran it last night and it worked. I must
> have been doing something wrong (not sure).
> 
> I do have some other questions.
> 
> 1) When I run grid_stat is it necessary to set Interpolation_method (in
> GridStatConfig_APCP_hr file)? Can I leave it blank? In the previous runs
> I used UW_MEAN with an interp_width of 1. This just provides a smoothing
> of the forecast data right.
> 2) when creating my own poly file is there a particular order that that
> points must be organized? For example can I just use my wrfoutput file
> and generate the lat/long file. I am asking because the manual says that
> the first and last points are connected. Should the Lat/lon file be just
> the outer boundary of the grid or should it be the location of grid points?
> 
> Segayle
> 
> 
> On Apr 27, 2010, at 10:36 AM, John Halley Gotway wrote:
> 
>> Segayle,
>>
>> I'm not sure exactly what you're doing.
>>
>> When you run the "-subtract" option, PCP-Combine checks to make sure
>> the initialization times of the two input files match.  If not, it
>> errors out.  If they are equal, it uses that init time for the
>> output file.  And it uses the valid time of the first input file as
>> the valid time of the output file.  So the output init and valid times
>> will only match if they are set as the same value in the
>> first input file.
>>
>> If you'd like, you could send me the files you're using as well as
>> your command line call to PCP-Combine.  I could try running it here
>> and let you know if what you're doing make sense.  If you'd like
>> to do that, you could post the data to our anonymous ftp site as follows:
>>
>> ftp ftp.rap.ucar.edu
>> username=anonymous
>> password="your email address"
>> cd incoming/irap/met_help/thompson_data
>> put "your files one by one"
>> bye
>>
>> Just let me know if/when you've posted data there.  And I will also
>> need to see how you're calling PCP-Combine on the command line.
>>
>> Thanks,
>> John
>>
>> Segayle Thompson wrote:
>>> yes. I am saying that when i do ncdump -h on the output from pcpcombine
>>> (subtract) the initialization and valid times are the same. Is this
>>> normal or am I doing something wrong?
>>>
>>> Segayle
>>>
>>> On Apr 26, 2010, at 6:45 PM, John Halley Gotway wrote:
>>>
>>>> me here.  Using the -subtract option to compute 72hr - 48hr = 24
>>>> hours of accumulation for ARW is fine.  Is there a problem in how the
>>>> initialization and valid times are being stored?
> 
> Segayle Thompson
> walford02 at hotmail.com
> walford07 at gmail.com
> 
>