[Met_help] [rt.rap.ucar.edu #58023] History for running MET: problems encountered
John Halley Gotway via RT
met_help at ucar.edu
Wed Aug 29 08:07:46 MDT 2012
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Dear Tressa,
I started running METv3.1 with our model latlon gridded data in GRIB1 and station observations in ASCII for the Sochi Olympic region. The first step with the POINT_STAT tool is O.K. including statistics and plots, I really enjoy using the MET and have already translated the Guide into Russian.
So it works, but we encountered several problems which I guess we can solve quicker with your help since I couldn't find explanations in the Guide.
1. The gen_poly_mask tool.
I looked at masks in data/poly directory to get some notion of how to create my own one. Am I right that the tool is using a definitely oriented (closed) chain of lat-lon points so that all grid points to the LEFT when passing from the first poly_point to the last are included into the polygon? Thus, when I walk in the opposite direction - I get all points OUTSIDE the polygon included?
2. !!!The Grid definition.
The GRIB1 header reserves only a HALF-WORD for lat-lon increments. We DON'T use it directly since this rounds the lat increment of 0.0125 in our COSMO model with about 1x1 km mesh and we get a 6 km shift accumulated to the center of the integration region.
We actually take the first, the last grid points and the corresponding NX,NY dimensions from the GRIB1 header to precisely calculate both increments. Now we had do manipulate these increment values in the GRIB1 header to match the requirements of MET. When I use our approach (recalculation of ZERO increments in the GRIB header) MET doesn't work. In the latter case ncdump applied to the gen_poly_mask output gives all latitudes and longitudes EQUAL to the first grid point in the GRIB header. I superficially looked through directories and codes - 'delta' values are used, for example, in src/libcode/vx_grid codes for different transformation.
I suppose your mesoscale grids are fine enough to need more than three digits after the point as it's the case in the GRIB1 increment coding. How do you solve this problem within MET?
Thank you in advance, and best regards,
Anatoly
........................................
Dr. Anatoly Muravyev
THE HYDROMETEOROLOGICAL RESEARCH CENTRE
OF THE RUSSIAN FEDERATION
11-13, Bolshoi Predtechensky Per.
123242, Moscow, Russia
Phone: + 7-499-7952127
Fax: + 7-499-2551582
E-mail: muravev at mecom.ru
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #58023] running MET: problems encountered
From: John Halley Gotway
Time: Mon Aug 27 12:52:43 2012
Anatoly,
I'll do my best to answer your questions:
(1) No, the direction in which you specify the polyline does not
matter. Whether you specify the points clockwise around the polyline
or counter-clockwise, the gen_poly_mask tool will define the same
region. Are you trying to perform verification over the region
*outside* the polyline? If so, there's a way to set that up in the
MET config files, but I won't go into the details unless you need
them.
(2) Yes, GRIB1 certainly has it's limitations! We are only able to
specify grid components out to the 1000-ths decimal place. For users
who want to regrid GRIB1 files, we recommend using the copygb
tool
(http://www.dtcenter.org/met/users/support/online_tutorial/METv3.1/copygb/index.php).
But the grid specification for copygb is done using integers in milli-
degrees (i.e. 1000-ths decimal place).
If your grid spacing is finer than 0.001, GRIB1 will not work well.
- One option would be to use GRIB2 which doesn't have the
limitations that GRIB1 does. METv4.0 and METv4.1 support the use of
GRIB2 - so if you can get your data into GRIB2, that could work.
- A second option is using the pinterp post-processing tool for WRF-
ARW. The limitation there though is that MET can only handle
variables defined at mass points. So basically, it won't read winds
since they're staggered.
- A third option is to write your data in a gridded NetCDF file that
MET can read. That would enable you to specify the grid at whatever
resolution you'd like, but it may not be an easy format with
which to work otherwise. We are working on adding support for
generalized CF-compliant NetCDF files in the next release. But as of
METv4.1, it's a rather specific format of NetCDF that MET can read
(basically you'd need to make it look very similar to the NetCDF
output of the pcp_combine tool).
If more questions arise, please feel free to write us at
met_help at ucar.edu.
Thanks,
John Halley Gotway
On 08/27/2012 12:22 PM, Tressa Fowler via RT wrote:
>
> Mon Aug 27 12:22:49 2012: Request 58023 was acted upon.
> Transaction: Ticket created by tressa
> Queue: met_help
> Subject: running MET: problems encountered
> Owner: Nobody
> Requestors: muravev at mecom.ru
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=58023 >
>
>
> Dear Tressa,
>
> I started running METv3.1 with our model latlon gridded data in
GRIB1 and station observations in ASCII for the Sochi Olympic region.
The first step with the POINT_STAT tool is O.K. including statistics
and plots, I really enjoy using the MET and have already translated
the Guide into Russian.
>
> So it works, but we encountered several problems which I guess we
can solve quicker with your help since I couldn't find explanations in
the Guide.
>
> 1. The gen_poly_mask tool.
>
> I looked at masks in data/poly directory to get some notion of how
to create my own one. Am I right that the tool is using a definitely
oriented (closed) chain of lat-lon points so that all grid points to
the LEFT when passing from the first poly_point to the last are
included into the polygon? Thus, when I walk in the opposite direction
- I get all points OUTSIDE the polygon included?
>
> 2. !!!The Grid definition.
>
> The GRIB1 header reserves only a HALF-WORD for lat-lon increments.
We DON'T use it directly since this rounds the lat increment of 0.0125
in our COSMO model with about 1x1 km mesh and we get a 6 km shift
accumulated to the center of the integration region.
>
> We actually take the first, the last grid points and the
corresponding NX,NY dimensions from the GRIB1 header to precisely
calculate both increments. Now we had do manipulate these increment
values in the GRIB1 header to match the requirements of MET. When I
use our approach (recalculation of ZERO increments in the GRIB header)
MET doesn't work. In the latter case ncdump applied to the
gen_poly_mask output gives all latitudes and longitudes EQUAL to the
first grid point in the GRIB header. I superficially looked through
directories and codes - 'delta' values are used, for example, in
src/libcode/vx_grid codes for different transformation.
>
> I suppose your mesoscale grids are fine enough to need more than
three digits after the point as it's the case in the GRIB1 increment
coding. How do you solve this problem within MET?
>
> Thank you in advance, and best regards,
> Anatoly
>
> ........................................
> Dr. Anatoly Muravyev
> THE HYDROMETEOROLOGICAL RESEARCH CENTRE
> OF THE RUSSIAN FEDERATION
> 11-13, Bolshoi Predtechensky Per.
> 123242, Moscow, Russia
> Phone: + 7-499-7952127
> Fax: + 7-499-2551582
> E-mail: muravev at mecom.ru
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #58023] running MET: problems encountered
From: John Halley Gotway
Time: Mon Aug 27 13:25:59 2012
Anatoly,
I realize that I may have misled you a bit. The current released
version of MET is METv4.0. The next release (in about January 2013)
will be METv4.1.
Sorry for the confusion.
Thanks,
John
On 08/27/2012 12:52 PM, John Halley Gotway wrote:
> Anatoly,
>
> I'll do my best to answer your questions:
>
> (1) No, the direction in which you specify the polyline does not
matter. Whether you specify the points clockwise around the polyline
or counter-clockwise, the gen_poly_mask tool will define the same
> region. Are you trying to perform verification over the region
*outside* the polyline? If so, there's a way to set that up in the
MET config files, but I won't go into the details unless you need
them.
>
> (2) Yes, GRIB1 certainly has it's limitations! We are only able to
specify grid components out to the 1000-ths decimal place. For users
who want to regrid GRIB1 files, we recommend using the copygb
> tool
(http://www.dtcenter.org/met/users/support/online_tutorial/METv3.1/copygb/index.php).
But the grid specification for copygb is done using integers in milli-
degrees (i.e. 1000-ths decimal place).
> If your grid spacing is finer than 0.001, GRIB1 will not work
well.
>
> - One option would be to use GRIB2 which doesn't have the
limitations that GRIB1 does. METv4.0 and METv4.1 support the use of
GRIB2 - so if you can get your data into GRIB2, that could work.
>
> - A second option is using the pinterp post-processing tool for
WRF-ARW. The limitation there though is that MET can only handle
variables defined at mass points. So basically, it won't read winds
> since they're staggered.
>
> - A third option is to write your data in a gridded NetCDF file
that MET can read. That would enable you to specify the grid at
whatever resolution you'd like, but it may not be an easy format with
> which to work otherwise. We are working on adding support for
generalized CF-compliant NetCDF files in the next release. But as of
METv4.1, it's a rather specific format of NetCDF that MET can read
> (basically you'd need to make it look very similar to the NetCDF
output of the pcp_combine tool).
>
> If more questions arise, please feel free to write us at
met_help at ucar.edu.
>
> Thanks,
> John Halley Gotway
>
> On 08/27/2012 12:22 PM, Tressa Fowler via RT wrote:
>>
>> Mon Aug 27 12:22:49 2012: Request 58023 was acted upon.
>> Transaction: Ticket created by tressa
>> Queue: met_help
>> Subject: running MET: problems encountered
>> Owner: Nobody
>> Requestors: muravev at mecom.ru
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=58023 >
>>
>>
>> Dear Tressa,
>>
>> I started running METv3.1 with our model latlon gridded data in
GRIB1 and station observations in ASCII for the Sochi Olympic region.
The first step with the POINT_STAT tool is O.K. including
>> statistics and plots, I really enjoy using the MET and have already
translated the Guide into Russian.
>>
>> So it works, but we encountered several problems which I guess we
can solve quicker with your help since I couldn't find explanations in
the Guide.
>>
>> 1. The gen_poly_mask tool.
>>
>> I looked at masks in data/poly directory to get some notion of how
to create my own one. Am I right that the tool is using a definitely
oriented (closed) chain of lat-lon points so that all grid
>> points to the LEFT when passing from the first poly_point to the
last are included into the polygon? Thus, when I walk in the opposite
direction - I get all points OUTSIDE the polygon included?
>>
>> 2. !!!The Grid definition.
>>
>> The GRIB1 header reserves only a HALF-WORD for lat-lon increments.
We DON'T use it directly since this rounds the lat increment of 0.0125
in our COSMO model with about 1x1 km mesh and we get a 6 km
>> shift accumulated to the center of the integration region.
>>
>> We actually take the first, the last grid points and the
corresponding NX,NY dimensions from the GRIB1 header to precisely
calculate both increments. Now we had do manipulate these increment
values
>> in the GRIB1 header to match the requirements of MET. When I use
our approach (recalculation of ZERO increments in the GRIB header) MET
doesn't work. In the latter case ncdump applied to the
>> gen_poly_mask output gives all latitudes and longitudes EQUAL to
the first grid point in the GRIB header. I superficially looked
through directories and codes - 'delta' values are used, for
>> example, in src/libcode/vx_grid codes for different
transformation.
>>
>> I suppose your mesoscale grids are fine enough to need more than
three digits after the point as it's the case in the GRIB1 increment
coding. How do you solve this problem within MET?
>>
>> Thank you in advance, and best regards,
>> Anatoly
>>
>> ........................................
>> Dr. Anatoly Muravyev
>> THE HYDROMETEOROLOGICAL RESEARCH CENTRE
>> OF THE RUSSIAN FEDERATION
>> 11-13, Bolshoi Predtechensky Per.
>> 123242, Moscow, Russia
>> Phone: + 7-499-7952127
>> Fax: + 7-499-2551582
>> E-mail: muravev at mecom.ru
>>
>
------------------------------------------------
Subject: Re[2]: [rt.rap.ucar.edu #58023] running MET: problems encountered
From: muravev at mecom.ru
Time: Tue Aug 28 01:37:27 2012
Dear John,
Thank you very much for your swift and informative answer, I really
appreciate it. I see your name in cpp-codes, glad to meet you, John.
(1) I am not trying to specify points outside the polyline. But the
sphere is a closed manifold mathematically speaking. Take the polyline
on a great circle of the sphere, which hemisphere does the
gen_poly_mask define?
(2) Yes, we understand the limitations of GRIB1 format. But we have
collected voluminous archives in GRIB1 for testing the model, with the
GRIB2 in perspective.
We will consider all options you proposed, but I was itching to
directly put precise 'data.delta_lat' and 'data.delta_lat' values into
src/libcode/vx_grid/latlon_grid.cc and elsewhere. Reinstalling the
package.
Anyway, we'll thoroughly think over what you proposed and I'll be glad
to communicate with you on the matter.
Let me ask you in the end: are there any conceptual changes in the
package that I should take the METv4.0 version right now?
Regards,
Anatoly
JHGvR> Anatoly,
JHGvR> I realize that I may have misled you a bit. The
JHGvR> current released version of MET is METv4.0. The next release
JHGvR> (in about January 2013) will be METv4.1.
JHGvR> Sorry for the confusion.
JHGvR> Thanks,
JHGvR> John
JHGvR> On 08/27/2012 12:52 PM, John Halley Gotway wrote:
>> Anatoly,
>>
>> I'll do my best to answer your questions:
>>
>> (1) No, the direction in which you specify the polyline does
>> not matter. Whether you specify the points clockwise around the
>> polyline or counter-clockwise, the gen_poly_mask tool will define
>> the same
>> region. Are you trying to perform verification over the region
>> *outside* the polyline? If so, there's a way to set that up in the
>> MET config files, but I won't go into the details unless you need
>> them.
>>
>> (2) Yes, GRIB1 certainly has it's limitations! We are only
>> able to specify grid components out to the 1000-ths decimal place.
>> For users who want to regrid GRIB1 files, we recommend using the
>> copygb
>> tool
>>
(http://www.dtcenter.org/met/users/support/online_tutorial/METv3.1/copygb/index.php).
>> But the grid specification for copygb is done using integers in
>> milli-degrees (i.e. 1000-ths decimal place).
>> If your grid spacing is finer than 0.001, GRIB1 will not work
well.
>>
>> - One option would be to use GRIB2 which doesn't have the
>> limitations that GRIB1 does. METv4.0 and METv4.1 support the use
>> of GRIB2 - so if you can get your data into GRIB2, that could work.
>>
>> - A second option is using the pinterp post-processing tool
>> for WRF-ARW. The limitation there though is that MET can only
>> handle variables defined at mass points. So basically, it won't
>> read winds
>> since they're staggered.
>>
>> - A third option is to write your data in a gridded NetCDF
>> file that MET can read. That would enable you to specify the grid
>> at whatever resolution you'd like, but it may not be an easy format
>> with
>> which to work otherwise. We are working on adding support for
>> generalized CF-compliant NetCDF files in the next release. But as
>> of METv4.1, it's a rather specific format of NetCDF that MET can
>> read
>> (basically you'd need to make it look very similar to the
>> NetCDF output of the pcp_combine tool).
>>
>> If more questions arise, please feel free to write us at
met_help at ucar.edu.
>>
>> Thanks,
>> John Halley Gotway
>>
>> On 08/27/2012 12:22 PM, Tressa Fowler via RT wrote:
>>>
>>> Mon Aug 27 12:22:49 2012: Request 58023 was acted upon.
>>> Transaction: Ticket created by tressa
>>> Queue: met_help
>>> Subject: running MET: problems encountered
>>> Owner: Nobody
>>> Requestors: muravev at mecom.ru
>>> Status: new
>>> Ticket <URL:
>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=58023 >
>>>
>>>
>>> Dear Tressa,
>>>
>>> I started running METv3.1 with our model latlon gridded data
>>> in GRIB1 and station observations in ASCII for the Sochi Olympic
>>> region. The first step with the POINT_STAT tool is O.K. including
>>> statistics and plots, I really enjoy using the MET and have
>>> already translated the Guide into Russian.
>>>
>>> So it works, but we encountered several problems which I
>>> guess we can solve quicker with your help since I couldn't find
>>> explanations in the Guide.
>>>
>>> 1. The gen_poly_mask tool.
>>>
>>> I looked at masks in data/poly directory to get some notion
>>> of how to create my own one. Am I right that the tool is using a
>>> definitely oriented (closed) chain of lat-lon points so that all
>>> grid
>>> points to the LEFT when passing from the first poly_point to
>>> the last are included into the polygon? Thus, when I walk in the
>>> opposite direction - I get all points OUTSIDE the polygon
included?
>>>
>>> 2. !!!The Grid definition.
>>>
>>> The GRIB1 header reserves only a HALF-WORD for lat-lon
>>> increments. We DON'T use it directly since this rounds the lat
>>> increment of 0.0125 in our COSMO model with about 1x1 km mesh and
>>> we get a 6 km
>>> shift accumulated to the center of the integration region.
>>>
>>> We actually take the first, the last grid points and the
>>> corresponding NX,NY dimensions from the GRIB1 header to precisely
>>> calculate both increments. Now we had do manipulate these
>>> increment values
>>> in the GRIB1 header to match the requirements of MET. When I
>>> use our approach (recalculation of ZERO increments in the GRIB
>>> header) MET doesn't work. In the latter case ncdump applied to the
>>> gen_poly_mask output gives all latitudes and longitudes EQUAL
>>> to the first grid point in the GRIB header. I superficially
>>> looked through directories and codes - 'delta' values are used,
>>> for
>>> example, in src/libcode/vx_grid codes for different
transformation.
>>>
>>> I suppose your mesoscale grids are fine enough to need more
>>> than three digits after the point as it's the case in the GRIB1
>>> increment coding. How do you solve this problem within MET?
>>>
>>> Thank you in advance, and best regards,
>>> Anatoly
>>>
>>> ........................................
>>> Dr. Anatoly Muravyev
>>> THE HYDROMETEOROLOGICAL RESEARCH CENTRE
>>> OF THE RUSSIAN FEDERATION
>>> 11-13, Bolshoi Predtechensky Per.
>>> 123242, Moscow, Russia
>>> Phone: + 7-499-7952127
>>> Fax: + 7-499-2551582
>>> E-mail: muravev at mecom.ru
>>>
>>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #58023] running MET: problems encountered
From: John Halley Gotway
Time: Tue Aug 28 07:39:52 2012
Anatoly,
(1) I can't provide you with very much detail on the algorithm behind
polyline masking. But I could refer you to the developer of that code
if you'd like. If you look in the code
(METv3.1/src/libcode/vx_analysis_util/mask_poly.cc) at the is_inside()
function, you'll see the following comments:
//
// This routine tests whether or not the point
// ( x_test, y_test ) is inside the region determined
// by the points ( x[i], y[i] ), 0 <= i < n.
//
// If the test point is not inside the region, a zero value is
// returned, otherwise the value tells how many times the region
// wraps around the test point, and the sign tells the direction
// in which the winding occurs: + CCW, - CW.
//
// This routine does not test to see if the point is exactly
// on the boundary of the region.
//
// It assumes the vertices are connected by straight lines
//
//
// Author: Randy Bullock
//
I'd suggest just trying this out using the gen_poly_mask tool. Just
run that tool using a sample gridded data file and the polyline in
which you're interested. Then use the ncview utility, or the
plot_data_plane utility in MET to display the results of the masking.
That would give you the best idea of how it's working. The following
sample commands do exactly that:
bin/gen_poly_mask
data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212
data/poly/EAST.poly sample_east.nc
bin/plot_data_plane sample_east.nc sample_east.ps "EAST(*,*)"
gv sample_east.ps
You can apply the same steps to your data/polyline and see what it
looks like.
(2) It's fine to modify the code however you'd like to get it to do
what you want it to do. However, be sure to keep track of the changes
you've applied so that you can re-apply them when you upgrade
to a newer version. Of course a more robust solution would be
preferable, but sometimes you just need to get the job done.
Regarding METv4.0, here are the release notes:
http://www.dtcenter.org/met/users/support/release_notes/METv4.0_release_notes.php
The two main upgrades are listed first. Adding support for GRIB2 has
a big impact, but also the restructuring of the config files is a big
change. We modified the config file language to allow for
finer control over the verification tasks to be performed. But it
does take some getting used to the new way of specifying things in the
METv4.0 config files. If you have the option of upgrading
now, I would suggest doing so. But if you're half-way through an
ongoing experiment, then I'd wait until you're at a good transition
point.
Thanks,
John
On 08/28/2012 01:37 AM, muravev at mecom.ru via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=58023 >
>
> Dear John,
>
> Thank you very much for your swift and informative answer, I really
appreciate it. I see your name in cpp-codes, glad to meet you, John.
>
> (1) I am not trying to specify points outside the polyline. But the
sphere is a closed manifold mathematically speaking. Take the polyline
on a great circle of the sphere, which hemisphere does the
gen_poly_mask define?
>
> (2) Yes, we understand the limitations of GRIB1 format. But we have
collected voluminous archives in GRIB1 for testing the model, with the
GRIB2 in perspective.
>
> We will consider all options you proposed, but I was itching to
directly put precise 'data.delta_lat' and 'data.delta_lat' values into
src/libcode/vx_grid/latlon_grid.cc and elsewhere. Reinstalling the
package.
>
> Anyway, we'll thoroughly think over what you proposed and I'll be
glad to communicate with you on the matter.
>
> Let me ask you in the end: are there any conceptual changes in the
package that I should take the METv4.0 version right now?
>
> Regards,
> Anatoly
>
>
> JHGvR> Anatoly,
>
> JHGvR> I realize that I may have misled you a bit. The
> JHGvR> current released version of MET is METv4.0. The next release
> JHGvR> (in about January 2013) will be METv4.1.
>
> JHGvR> Sorry for the confusion.
>
> JHGvR> Thanks,
> JHGvR> John
>
> JHGvR> On 08/27/2012 12:52 PM, John Halley Gotway wrote:
>>> Anatoly,
>>>
>>> I'll do my best to answer your questions:
>>>
>>> (1) No, the direction in which you specify the polyline does
>>> not matter. Whether you specify the points clockwise around the
>>> polyline or counter-clockwise, the gen_poly_mask tool will define
>>> the same
>>> region. Are you trying to perform verification over the region
>>> *outside* the polyline? If so, there's a way to set that up in
the
>>> MET config files, but I won't go into the details unless you need
>>> them.
>>>
>>> (2) Yes, GRIB1 certainly has it's limitations! We are only
>>> able to specify grid components out to the 1000-ths decimal place.
>>> For users who want to regrid GRIB1 files, we recommend using the
>>> copygb
>>> tool
>>>
(http://www.dtcenter.org/met/users/support/online_tutorial/METv3.1/copygb/index.php).
>>> But the grid specification for copygb is done using integers in
>>> milli-degrees (i.e. 1000-ths decimal place).
>>> If your grid spacing is finer than 0.001, GRIB1 will not work
well.
>>>
>>> - One option would be to use GRIB2 which doesn't have the
>>> limitations that GRIB1 does. METv4.0 and METv4.1 support the use
>>> of GRIB2 - so if you can get your data into GRIB2, that could
work.
>>>
>>> - A second option is using the pinterp post-processing tool
>>> for WRF-ARW. The limitation there though is that MET can only
>>> handle variables defined at mass points. So basically, it won't
>>> read winds
>>> since they're staggered.
>>>
>>> - A third option is to write your data in a gridded NetCDF
>>> file that MET can read. That would enable you to specify the grid
>>> at whatever resolution you'd like, but it may not be an easy
format
>>> with
>>> which to work otherwise. We are working on adding support for
>>> generalized CF-compliant NetCDF files in the next release. But as
>>> of METv4.1, it's a rather specific format of NetCDF that MET can
>>> read
>>> (basically you'd need to make it look very similar to the
>>> NetCDF output of the pcp_combine tool).
>>>
>>> If more questions arise, please feel free to write us at
met_help at ucar.edu.
>>>
>>> Thanks,
>>> John Halley Gotway
>>>
>>> On 08/27/2012 12:22 PM, Tressa Fowler via RT wrote:
>>>>
>>>> Mon Aug 27 12:22:49 2012: Request 58023 was acted upon.
>>>> Transaction: Ticket created by tressa
>>>> Queue: met_help
>>>> Subject: running MET: problems encountered
>>>> Owner: Nobody
>>>> Requestors: muravev at mecom.ru
>>>> Status: new
>>>> Ticket <URL:
>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=58023 >
>>>>
>>>>
>>>> Dear Tressa,
>>>>
>>>> I started running METv3.1 with our model latlon gridded data
>>>> in GRIB1 and station observations in ASCII for the Sochi Olympic
>>>> region. The first step with the POINT_STAT tool is O.K. including
>>>> statistics and plots, I really enjoy using the MET and have
>>>> already translated the Guide into Russian.
>>>>
>>>> So it works, but we encountered several problems which I
>>>> guess we can solve quicker with your help since I couldn't find
>>>> explanations in the Guide.
>>>>
>>>> 1. The gen_poly_mask tool.
>>>>
>>>> I looked at masks in data/poly directory to get some notion
>>>> of how to create my own one. Am I right that the tool is using a
>>>> definitely oriented (closed) chain of lat-lon points so that all
>>>> grid
>>>> points to the LEFT when passing from the first poly_point to
>>>> the last are included into the polygon? Thus, when I walk in the
>>>> opposite direction - I get all points OUTSIDE the polygon
included?
>>>>
>>>> 2. !!!The Grid definition.
>>>>
>>>> The GRIB1 header reserves only a HALF-WORD for lat-lon
>>>> increments. We DON'T use it directly since this rounds the lat
>>>> increment of 0.0125 in our COSMO model with about 1x1 km mesh and
>>>> we get a 6 km
>>>> shift accumulated to the center of the integration region.
>>>>
>>>> We actually take the first, the last grid points and the
>>>> corresponding NX,NY dimensions from the GRIB1 header to precisely
>>>> calculate both increments. Now we had do manipulate these
>>>> increment values
>>>> in the GRIB1 header to match the requirements of MET. When I
>>>> use our approach (recalculation of ZERO increments in the GRIB
>>>> header) MET doesn't work. In the latter case ncdump applied to
the
>>>> gen_poly_mask output gives all latitudes and longitudes EQUAL
>>>> to the first grid point in the GRIB header. I superficially
>>>> looked through directories and codes - 'delta' values are used,
>>>> for
>>>> example, in src/libcode/vx_grid codes for different
transformation.
>>>>
>>>> I suppose your mesoscale grids are fine enough to need more
>>>> than three digits after the point as it's the case in the GRIB1
>>>> increment coding. How do you solve this problem within MET?
>>>>
>>>> Thank you in advance, and best regards,
>>>> Anatoly
>>>>
>>>> ........................................
>>>> Dr. Anatoly Muravyev
>>>> THE HYDROMETEOROLOGICAL RESEARCH CENTRE
>>>> OF THE RUSSIAN FEDERATION
>>>> 11-13, Bolshoi Predtechensky Per.
>>>> 123242, Moscow, Russia
>>>> Phone: + 7-499-7952127
>>>> Fax: + 7-499-2551582
>>>> E-mail: muravev at mecom.ru
>>>>
>>>
>
>
>
------------------------------------------------
Subject: Re[2]: [rt.rap.ucar.edu #58023] running MET: problems encountered
From: muravev at mecom.ru
Time: Wed Aug 29 01:47:30 2012
Dear John,
Thank you very much for your time and effort spent, you've given us
enough material for considerations and further action.
(1) Anyway there is no problem with region masking around Sochi.
Thanks for the reference and comments in the mask_poly.cc.
(2) Now I'll try to 'get the job done' with the POINT_STAT tool
utilizing our accumulated GRIB1-data.
For the time present I'll use some of the options you proposed on this
METv3.1 version.
The experience gained with your generous help will lighten our work on
newer MET versions.
Best regards,
Anatoly
JHGvR> Anatoly,
JHGvR> (1) I can't provide you with very much detail on the
JHGvR> algorithm behind polyline masking. But I could refer you to
JHGvR> the developer of that code if you'd like. If you look in the
JHGvR> code
JHGvR> (METv3.1/src/libcode/vx_analysis_util/mask_poly.cc) at
JHGvR> the is_inside() function, you'll see the following comments:
JHGvR> //
JHGvR> // This routine tests whether or not the point
JHGvR> // ( x_test, y_test ) is inside the region determined
JHGvR> // by the points ( x[i], y[i] ), 0 <= i < n.
JHGvR> //
JHGvR> // If the test point is not inside the region, a zero
value is
JHGvR> // returned, otherwise the value tells how many times the
region
JHGvR> // wraps around the test point, and the sign tells the
direction
JHGvR> // in which the winding occurs: + CCW, - CW.
JHGvR> //
JHGvR> // This routine does not test to see if the point is
exactly
JHGvR> // on the boundary of the region.
JHGvR> //
JHGvR> // It assumes the vertices are connected by straight lines
JHGvR> //
JHGvR> //
JHGvR> // Author: Randy Bullock
JHGvR> //
JHGvR> I'd suggest just trying this out using the
JHGvR> gen_poly_mask tool. Just run that tool using a sample gridded
JHGvR> data file and the polyline in which you're interested. Then
JHGvR> use the ncview utility, or the
JHGvR> plot_data_plane utility in MET to display the results
JHGvR> of the masking. That would give you the best idea of how it's
JHGvR> working. The following sample commands do exactly that:
JHGvR> bin/gen_poly_mask
JHGvR> data/sample_fcst/2005080700/wrfprs_ruc13_12.tm00_G212
JHGvR> data/poly/EAST.poly sample_east.nc
JHGvR> bin/plot_data_plane sample_east.nc sample_east.ps
"EAST(*,*)"
JHGvR> gv sample_east.ps
JHGvR> You can apply the same steps to your data/polyline and see what
it looks like.
JHGvR> (2) It's fine to modify the code however you'd like to
JHGvR> get it to do what you want it to do. However, be sure to keep
JHGvR> track of the changes you've applied so that you can re-apply
JHGvR> them when you upgrade
JHGvR> to a newer version. Of course a more robust solution
JHGvR> would be preferable, but sometimes you just need to get the job
JHGvR> done.
JHGvR> Regarding METv4.0, here are the release notes:
JHGvR>
JHGvR>
http://www.dtcenter.org/met/users/support/release_notes/METv4.0_release_notes.php
JHGvR> The two main upgrades are listed first. Adding support
JHGvR> for GRIB2 has a big impact, but also the restructuring of the
JHGvR> config files is a big change. We modified the config file
JHGvR> language to allow for
JHGvR> finer control over the verification tasks to be
JHGvR> performed. But it does take some getting used to the new way
JHGvR> of specifying things in the METv4.0 config files. If you have
JHGvR> the option of upgrading
JHGvR> now, I would suggest doing so. But if you're half-way
JHGvR> through an ongoing experiment, then I'd wait until you're at a
JHGvR> good transition point.
JHGvR> Thanks,
JHGvR> John
JHGvR> On 08/28/2012 01:37 AM, muravev at mecom.ru via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=58023 >
>>
>> Dear John,
>>
>> Thank you very much for your swift and informative answer, I
>> really appreciate it. I see your name in cpp-codes, glad to meet
>> you, John.
>>
>> (1) I am not trying to specify points outside the polyline. But
>> the sphere is a closed manifold mathematically speaking. Take the
>> polyline on a great circle of the sphere, which hemisphere does the
>> gen_poly_mask define?
>>
>> (2) Yes, we understand the limitations of GRIB1 format. But we
>> have collected voluminous archives in GRIB1 for testing the model,
>> with the GRIB2 in perspective.
>>
>> We will consider all options you proposed, but I was itching to
>> directly put precise 'data.delta_lat' and 'data.delta_lat' values
>> into src/libcode/vx_grid/latlon_grid.cc and elsewhere. Reinstalling
>> the package.
>>
>> Anyway, we'll thoroughly think over what you proposed and I'll
>> be glad to communicate with you on the matter.
>>
>> Let me ask you in the end: are there any conceptual changes in
>> the package that I should take the METv4.0 version right now?
>>
>> Regards,
>> Anatoly
>>
>>
>> JHGvR> Anatoly,
>>
>> JHGvR> I realize that I may have misled you a bit. The
>> JHGvR> current released version of MET is METv4.0. The next
release
>> JHGvR> (in about January 2013) will be METv4.1.
>>
>> JHGvR> Sorry for the confusion.
>>
>> JHGvR> Thanks,
>> JHGvR> John
>>
>> JHGvR> On 08/27/2012 12:52 PM, John Halley Gotway wrote:
>>>> Anatoly,
>>>>
>>>> I'll do my best to answer your questions:
>>>>
>>>> (1) No, the direction in which you specify the polyline does
>>>> not matter. Whether you specify the points clockwise around the
>>>> polyline or counter-clockwise, the gen_poly_mask tool will define
>>>> the same
>>>> region. Are you trying to perform verification over the region
>>>> *outside* the polyline? If so, there's a way to set that up in
the
>>>> MET config files, but I won't go into the details unless you need
>>>> them.
>>>>
>>>> (2) Yes, GRIB1 certainly has it's limitations! We are only
>>>> able to specify grid components out to the 1000-ths decimal
place.
>>>> For users who want to regrid GRIB1 files, we recommend using the
>>>> copygb
>>>> tool
>>>>
(http://www.dtcenter.org/met/users/support/online_tutorial/METv3.1/copygb/index.php).
>>>> But the grid specification for copygb is done using integers in
>>>> milli-degrees (i.e. 1000-ths decimal place).
>>>> If your grid spacing is finer than 0.001, GRIB1 will not work
well.
>>>>
>>>> - One option would be to use GRIB2 which doesn't have the
>>>> limitations that GRIB1 does. METv4.0 and METv4.1 support the use
>>>> of GRIB2 - so if you can get your data into GRIB2, that could
work.
>>>>
>>>> - A second option is using the pinterp post-processing tool
>>>> for WRF-ARW. The limitation there though is that MET can only
>>>> handle variables defined at mass points. So basically, it won't
>>>> read winds
>>>> since they're staggered.
>>>>
>>>> - A third option is to write your data in a gridded NetCDF
>>>> file that MET can read. That would enable you to specify the
grid
>>>> at whatever resolution you'd like, but it may not be an easy
format
>>>> with
>>>> which to work otherwise. We are working on adding support for
>>>> generalized CF-compliant NetCDF files in the next release. But
as
>>>> of METv4.1, it's a rather specific format of NetCDF that MET can
>>>> read
>>>> (basically you'd need to make it look very similar to the
>>>> NetCDF output of the pcp_combine tool).
>>>>
>>>> If more questions arise, please feel free to write us at
met_help at ucar.edu.
>>>>
>>>> Thanks,
>>>> John Halley Gotway
>>>>
>>>> On 08/27/2012 12:22 PM, Tressa Fowler via RT wrote:
>>>>>
>>>>> Mon Aug 27 12:22:49 2012: Request 58023 was acted upon.
>>>>> Transaction: Ticket created by tressa
>>>>> Queue: met_help
>>>>> Subject: running MET: problems encountered
>>>>> Owner: Nobody
>>>>> Requestors: muravev at mecom.ru
>>>>> Status: new
>>>>> Ticket <URL:
>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=58023 >
>>>>>
>>>>>
>>>>> Dear Tressa,
>>>>>
>>>>> I started running METv3.1 with our model latlon gridded data
>>>>> in GRIB1 and station observations in ASCII for the Sochi Olympic
>>>>> region. The first step with the POINT_STAT tool is O.K.
including
>>>>> statistics and plots, I really enjoy using the MET and have
>>>>> already translated the Guide into Russian.
>>>>>
>>>>> So it works, but we encountered several problems which I
>>>>> guess we can solve quicker with your help since I couldn't find
>>>>> explanations in the Guide.
>>>>>
>>>>> 1. The gen_poly_mask tool.
>>>>>
>>>>> I looked at masks in data/poly directory to get some notion
>>>>> of how to create my own one. Am I right that the tool is using a
>>>>> definitely oriented (closed) chain of lat-lon points so that all
>>>>> grid
>>>>> points to the LEFT when passing from the first poly_point to
>>>>> the last are included into the polygon? Thus, when I walk in the
>>>>> opposite direction - I get all points OUTSIDE the polygon
included?
>>>>>
>>>>> 2. !!!The Grid definition.
>>>>>
>>>>> The GRIB1 header reserves only a HALF-WORD for lat-lon
>>>>> increments. We DON'T use it directly since this rounds the lat
>>>>> increment of 0.0125 in our COSMO model with about 1x1 km mesh
and
>>>>> we get a 6 km
>>>>> shift accumulated to the center of the integration region.
>>>>>
>>>>> We actually take the first, the last grid points and the
>>>>> corresponding NX,NY dimensions from the GRIB1 header to
precisely
>>>>> calculate both increments. Now we had do manipulate these
>>>>> increment values
>>>>> in the GRIB1 header to match the requirements of MET. When I
>>>>> use our approach (recalculation of ZERO increments in the GRIB
>>>>> header) MET doesn't work. In the latter case ncdump applied to
the
>>>>> gen_poly_mask output gives all latitudes and longitudes EQUAL
>>>>> to the first grid point in the GRIB header. I superficially
>>>>> looked through directories and codes - 'delta' values are used,
>>>>> for
>>>>> example, in src/libcode/vx_grid codes for different
transformation.
>>>>>
>>>>> I suppose your mesoscale grids are fine enough to need more
>>>>> than three digits after the point as it's the case in the GRIB1
>>>>> increment coding. How do you solve this problem within MET?
>>>>>
>>>>> Thank you in advance, and best regards,
>>>>> Anatoly
>>>>>
>>>>> ........................................
>>>>> Dr. Anatoly Muravyev
>>>>> THE HYDROMETEOROLOGICAL RESEARCH CENTRE
>>>>> OF THE RUSSIAN FEDERATION
>>>>> 11-13, Bolshoi Predtechensky Per.
>>>>> 123242, Moscow, Russia
>>>>> Phone: + 7-499-7952127
>>>>> Fax: + 7-499-2551582
>>>>> E-mail: muravev at mecom.ru
>>>>>
>>>>
>>
>>
>>
------------------------------------------------
More information about the Met_help
mailing list