[Met_help] [rt.rap.ucar.edu #52045] History for Request for assistance (UNCLASSIFIED)
John Halley Gotway via RT
met_help at ucar.edu
Thu Jan 5 09:36:13 MST 2012
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Classification: UNCLASSIFIED
Caveats: NONE
We have been trying to run Grid-Stat using a 1km resolution WRF forecast GRIB1
file (WRFPRS_d02.00)and an RTMA file (rtma_1km.grb) which we converted
from GRIB2 to GRIB1 and then used copygb to re-grid it to match the grid of
the WRF.
We are running into an ERROR which states that the forecast and observation
grids do not match.
Could you take a look at the attached files to see if you can diagnose the
problem?
Some details on how we are running Grid-Stat follow:
grid_stat ../MET_WRFpostprd/${Start_Date}/WRFPRS_d02.00
../MET_obs/RTMA/rtma_1km.grb1 ./GridStatConfig_m2o2_rtma -outdir
./results_m2o2/${Start_Date} -v 2
User specifies the Start_Date at the keyboard.
The config file (GridStatConfig_m2o2_rtma) is attached. I use a mask_poly file
(DUGd02.poly, also attached) to make sure that the scoring is done over the
same geographic area as the WRF grid.
The valid times/dates do not match, but this is just for testing.
Thanks.
R/
John
Mr John W. Raby, Meteorologist
U.S. Army Research Laboratory
White Sands Missile Range, NM 88002
(575) 678-2004 DSN 258-2004
FAX (575) 678-1230 DSN 258-1230
Email: john.w.raby2.civ at mail.mil
Classification: UNCLASSIFIED
Caveats: NONE
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance (UNCLASSIFIED)
From: John Halley Gotway
Time: Wed Dec 14 15:27:48 2011
John,
I ran the following two wgrib commands on the data you sent to see
what the grids are. I've included the grid definition information
output from wgrib:
% wgrib -d 1 -V WRFPRS_d02.00
...
Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP 0.000000
North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
% wgrib -V -d 1 rtma_1km.grb1
...
Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.488000
Latin1 25.000000 Latin2 25.000000 LatSP 0.000000 LonSP 0.000000
North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
As you can see, while the grid dimensions are both 102x102, the grid
definition parameters differ a lot. So the arguments you're using in
your call to copygb need to be modified to make the rtma grid
exactly the same as the WRF grid.
There is an example of doing this in the MET online tutorial here:
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.0/copygb/run3.php
Using that website as an example, here's the grid definition argument
you should be using in your call to copygb:
"255 3 NX NY STARTLAT STARTLON 8 CENLON DX DY 0 64 TRUELAT1
TRUELAT2"
"255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64 40135
40135"
Next I ran the rtma file through copygb like this:
% copygb -xg"255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64
40135 40135" rtma_1km.grb1 rtma_1km_regrid.grb1
And checked to make sure that the grids match now:
% wgrib -d 1 -V rtma_1km_regrid.grb1
...
Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP 0.000000
North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
And they do. So that should solve your problem.
Thanks,
John
On 12/14/2011 03:04 PM, Raby, John W USA CIV via RT wrote:
>
> Wed Dec 14 15:04:57 2011: Request 52045 was acted upon.
> Transaction: Ticket created by john.w.raby2.civ at mail.mil
> Queue: met_help
> Subject: Request for assistance (UNCLASSIFIED)
> Owner: Nobody
> Requestors: john.w.raby2.civ at mail.mil
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045 >
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> We have been trying to run Grid-Stat using a 1km resolution WRF
forecast GRIB1
> file (WRFPRS_d02.00)and an RTMA file (rtma_1km.grb) which we
converted
> from GRIB2 to GRIB1 and then used copygb to re-grid it to match the
grid of
> the WRF.
>
> We are running into an ERROR which states that the forecast and
observation
> grids do not match.
>
> Could you take a look at the attached files to see if you can
diagnose the
> problem?
>
> Some details on how we are running Grid-Stat follow:
>
> grid_stat ../MET_WRFpostprd/${Start_Date}/WRFPRS_d02.00
> ../MET_obs/RTMA/rtma_1km.grb1 ./GridStatConfig_m2o2_rtma -outdir
> ./results_m2o2/${Start_Date} -v 2
>
> User specifies the Start_Date at the keyboard.
>
> The config file (GridStatConfig_m2o2_rtma) is attached. I use a
mask_poly file
> (DUGd02.poly, also attached) to make sure that the scoring is done
over the
> same geographic area as the WRF grid.
>
> The valid times/dates do not match, but this is just for testing.
>
> Thanks.
>
> R/
> John
>
> Mr John W. Raby, Meteorologist
> U.S. Army Research Laboratory
> White Sands Missile Range, NM 88002
> (575) 678-2004 DSN 258-2004
> FAX (575) 678-1230 DSN 258-1230
> Email: john.w.raby2.civ at mail.mil
>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
------------------------------------------------
Subject: Request for assistance (UNCLASSIFIED)
From: Raby, John W USA CIV
Time: Wed Dec 14 15:34:30 2011
Classification: UNCLASSIFIED
Caveats: NONE
John -
Thanks for the quick and detailed diagnosis and solution! Steve Kirby
and I
will work on implementing your solution and let you know how it goes.
R/
John
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Wednesday, December 14, 2011 3:28 PM
To: Raby, John W USA CIV (US)
Cc: Kirby, Stephen F USA CIV (US)
Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
(UNCLASSIFIED)
John,
I ran the following two wgrib commands on the data you sent to see
what the
grids are. I've included the grid definition information output from
wgrib:
% wgrib -d 1 -V WRFPRS_d02.00
...
Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP 0.000000
North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
% wgrib -V -d 1 rtma_1km.grb1
...
Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.488000
Latin1 25.000000 Latin2 25.000000 LatSP 0.000000 LonSP 0.000000
North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
As you can see, while the grid dimensions are both 102x102, the grid
definition parameters differ a lot. So the arguments you're using in
your
call to copygb need to be modified to make the rtma grid exactly the
same as
the WRF grid.
There is an example of doing this in the MET online tutorial here:
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.0/copygb/run3.php
Using that website as an example, here's the grid definition argument
you
should be using in your call to copygb:
"255 3 NX NY STARTLAT STARTLON 8 CENLON DX DY 0 64 TRUELAT1
TRUELAT2"
"255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64 40135
40135"
Next I ran the rtma file through copygb like this:
% copygb -xg"255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64
40135
40135" rtma_1km.grb1 rtma_1km_regrid.grb1
And checked to make sure that the grids match now:
% wgrib -d 1 -V rtma_1km_regrid.grb1
...
Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP 0.000000
North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
And they do. So that should solve your problem.
Thanks,
John
On 12/14/2011 03:04 PM, Raby, John W USA CIV via RT wrote:
>
> Wed Dec 14 15:04:57 2011: Request 52045 was acted upon.
> Transaction: Ticket created by john.w.raby2.civ at mail.mil
> Queue: met_help
> Subject: Request for assistance (UNCLASSIFIED)
> Owner: Nobody
> Requestors: john.w.raby2.civ at mail.mil
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045
> >
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> We have been trying to run Grid-Stat using a 1km resolution WRF
> forecast GRIB1 file (WRFPRS_d02.00)and an RTMA file (rtma_1km.grb)
> which we converted from GRIB2 to GRIB1 and then used copygb to re-
grid
> it to match the grid of the WRF.
>
> We are running into an ERROR which states that the forecast and
> observation grids do not match.
>
> Could you take a look at the attached files to see if you can
diagnose
> the problem?
>
> Some details on how we are running Grid-Stat follow:
>
> grid_stat ../MET_WRFpostprd/${Start_Date}/WRFPRS_d02.00
> ../MET_obs/RTMA/rtma_1km.grb1 ./GridStatConfig_m2o2_rtma -outdir
> ./results_m2o2/${Start_Date} -v 2
>
> User specifies the Start_Date at the keyboard.
>
> The config file (GridStatConfig_m2o2_rtma) is attached. I use a
> mask_poly file (DUGd02.poly, also attached) to make sure that the
> scoring is done over the same geographic area as the WRF grid.
>
> The valid times/dates do not match, but this is just for testing.
>
> Thanks.
>
> R/
> John
>
> Mr John W. Raby, Meteorologist
> U.S. Army Research Laboratory
> White Sands Missile Range, NM 88002
> (575) 678-2004 DSN 258-2004
> FAX (575) 678-1230 DSN 258-1230
> Email: john.w.raby2.civ at mail.mil
>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
Classification: UNCLASSIFIED
Caveats: NONE
------------------------------------------------
Subject: Request for assistance (UNCLASSIFIED)
From: Raby, John W USA CIV
Time: Thu Dec 15 10:50:51 2011
Classification: UNCLASSIFIED
Caveats: NONE
John -
Steve Kirby implemented your solution below and it worked just as you
said!
This information was invaluable for us to progress in our attempts to
use the
RTMA product as a gridded observation data set.
I have a question which came out of the testing I did this morning
with
Grid-Stat.
I ran the Grid-Stat tests 2 ways which were both successful. The first
was
done assuming that the RTMA file was for a slightly larger area
than the Dugway, UT WRF forecast domain. I restricted the scoring to a
subset
of
that area by using a mask_poly file to define the geographic area
according to
the coordinates (lat/long corners) of the Dugway WRF domain we have
been using
in the past. The second
test was done by removing the restriction and scoring over the full
area of
the 2 grids.
The TOTAL # of forecast-observation pairs for the first test was 10207
and for
the second test was 10404. So it appears that by allowing Grid-Stat to
score
over the entire grid it actually scored over a slightly larger area
than was
the case in the first test.
I checked the User's Guide and it says that when you use a value of
"FULL" in
the mask_grid variable it scores over the "entire grid on which the
data
resides". Which grid are you talking about? I would assume that since
you are
trying to verify the forecast, that the grid used is the forecast
grid, but I
wanted to be sure.
The implication is that if I specify the use of "FULL" vice using a
mask_poly
file, that Grid-Stat will always score over that subset of the gridded
observation field and as long as you ensure that the gridded
observation field
is a larger area than you need, you will always get results.
What would happen if the gridded observation dataset was over a
smaller area
than the forecast field and you specified "FULL" for scoring?
What I'm getting at is a way to decide what geographic size of RTMA
file I
should download to make sure that I can just use the "FULL" scoring in
the
mask_grid variable and not worry about having to "guess" the actual
size where
scoring will occur unless I have a specific reason to focus in on a
particular
subset of the region.
Thanks for all your help. This service is very helpful for MET users.
We rely
on this service frequently for assistance in answering questions and
resolving
issues and have found it to be very efficient and accurate with a high
level
of responsiveness.
R/
John
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Wednesday, December 14, 2011 3:28 PM
To: Raby, John W USA CIV (US)
Cc: Kirby, Stephen F USA CIV (US)
Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
(UNCLASSIFIED)
John,
I ran the following two wgrib commands on the data you sent to see
what the
grids are. I've included the grid definition information output from
wgrib:
% wgrib -d 1 -V WRFPRS_d02.00
...
Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP 0.000000
North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
% wgrib -V -d 1 rtma_1km.grb1
...
Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.488000
Latin1 25.000000 Latin2 25.000000 LatSP 0.000000 LonSP 0.000000
North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
As you can see, while the grid dimensions are both 102x102, the grid
definition parameters differ a lot. So the arguments you're using in
your
call to copygb need to be modified to make the rtma grid exactly the
same as
the WRF grid.
There is an example of doing this in the MET online tutorial here:
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.0/copygb/run3.php
Using that website as an example, here's the grid definition argument
you
should be using in your call to copygb:
"255 3 NX NY STARTLAT STARTLON 8 CENLON DX DY 0 64 TRUELAT1
TRUELAT2"
"255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64 40135
40135"
Next I ran the rtma file through copygb like this:
% copygb -xg"255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64
40135
40135" rtma_1km.grb1 rtma_1km_regrid.grb1
And checked to make sure that the grids match now:
% wgrib -d 1 -V rtma_1km_regrid.grb1
...
Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP 0.000000
North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
And they do. So that should solve your problem.
Thanks,
John
On 12/14/2011 03:04 PM, Raby, John W USA CIV via RT wrote:
>
> Wed Dec 14 15:04:57 2011: Request 52045 was acted upon.
> Transaction: Ticket created by john.w.raby2.civ at mail.mil
> Queue: met_help
> Subject: Request for assistance (UNCLASSIFIED)
> Owner: Nobody
> Requestors: john.w.raby2.civ at mail.mil
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045
> >
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> We have been trying to run Grid-Stat using a 1km resolution WRF
> forecast GRIB1 file (WRFPRS_d02.00)and an RTMA file (rtma_1km.grb)
> which we converted from GRIB2 to GRIB1 and then used copygb to re-
grid
> it to match the grid of the WRF.
>
> We are running into an ERROR which states that the forecast and
> observation grids do not match.
>
> Could you take a look at the attached files to see if you can
diagnose
> the problem?
>
> Some details on how we are running Grid-Stat follow:
>
> grid_stat ../MET_WRFpostprd/${Start_Date}/WRFPRS_d02.00
> ../MET_obs/RTMA/rtma_1km.grb1 ./GridStatConfig_m2o2_rtma -outdir
> ./results_m2o2/${Start_Date} -v 2
>
> User specifies the Start_Date at the keyboard.
>
> The config file (GridStatConfig_m2o2_rtma) is attached. I use a
> mask_poly file (DUGd02.poly, also attached) to make sure that the
> scoring is done over the same geographic area as the WRF grid.
>
> The valid times/dates do not match, but this is just for testing.
>
> Thanks.
>
> R/
> John
>
> Mr John W. Raby, Meteorologist
> U.S. Army Research Laboratory
> White Sands Missile Range, NM 88002
> (575) 678-2004 DSN 258-2004
> FAX (575) 678-1230 DSN 258-1230
> Email: john.w.raby2.civ at mail.mil
>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
Classification: UNCLASSIFIED
Caveats: NONE
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance (UNCLASSIFIED)
From: John Halley Gotway
Time: Thu Dec 15 11:11:05 2011
John,
Lots of questions in there!
First, I'm glad you were able to get it working.
Next, you mention that you ran Grid-Stat two times - once to score
over the full domain and a second time to score over a subset of the
domain. I want to point out that you really only need to run
Grid-Stat once in this case. Just set up your config file with
something like this:
mask_grid[] = [ "FULL" ];
mask_poly[] = [ "path/to/your/mask/poly" ];
Each time you run Grid-Stat, it will compute statistics for *each* of
the masking regions you specify. In this case, you'll see output for
both the FULL domain and the polyline you've specified.
Your next question - what does the FULL domain mean? Before running
Grid-Stat, you have to put your forecast and observations onto a
common grid. When you tell the MET tools score over the "FULL"
domain, that means, just use all of those grid points on which the
data resides. Don't throw any of them out. The fact that you got
more matched pairs for the FULL domain than you got for the
polyline subset makes complete sense.
Because of the requirement that the data be on the same grid, every
time you run Grid-Stat, there will be values at each point in both the
forecast and observation fields. But suppose that you
started with an RTMA file whose domain did not fully cover your WRF
domain. You'd first need to run that RTMA file through copygb to put
it onto the WRF grid. That step will result in a data file
that have valid data in the middle (where the RTMA was valid)
surrounded by missing data values around the edge (where there was no
RTMA data). Now suppose you run Grid-Stat to compare the RTMA to a
WRF file, and tell it to score over the FULL region. Grid-Stat will
loop through the grid looking at all the points (since we chose FULL),
and it will get a forecast/observation pair for each grid
point. Because of the missing RTMA values around the edge, you'll end
up with some matched pairs where the observation is a missing value.
And in that case, Grid-Stat won't use those matched pairs -
it'll toss them out, as it should.
Generally, speaking when Point-Stat and Grid-Stat are run, the first
step is to compute a bunch of forecast/observation matched pairs. And
the next step is to throw out any matched pairs where either
the forecast or observation contains bad data. Then statistics are
computed over only those matched pairs with good data for both.
That explanation is a long way of suggesting that when retrieving RTMA
data, be sure it completely covers your WRF domain. And if you have
an option on resolution of the RTMA data, choose one that
most closely matches the resolution of your model run.
Hope that helps.
John
On 12/15/2011 10:50 AM, Raby, John W USA CIV via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045 >
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> John -
>
> Steve Kirby implemented your solution below and it worked just as
you said!
> This information was invaluable for us to progress in our attempts
to use the
> RTMA product as a gridded observation data set.
>
> I have a question which came out of the testing I did this morning
with
> Grid-Stat.
>
> I ran the Grid-Stat tests 2 ways which were both successful. The
first was
> done assuming that the RTMA file was for a slightly larger area
> than the Dugway, UT WRF forecast domain. I restricted the scoring to
a subset
> of
> that area by using a mask_poly file to define the geographic area
according to
> the coordinates (lat/long corners) of the Dugway WRF domain we have
been using
> in the past. The second
> test was done by removing the restriction and scoring over the full
area of
> the 2 grids.
>
> The TOTAL # of forecast-observation pairs for the first test was
10207 and for
> the second test was 10404. So it appears that by allowing Grid-Stat
to score
> over the entire grid it actually scored over a slightly larger area
than was
> the case in the first test.
>
> I checked the User's Guide and it says that when you use a value of
"FULL" in
> the mask_grid variable it scores over the "entire grid on which the
data
> resides". Which grid are you talking about? I would assume that
since you are
> trying to verify the forecast, that the grid used is the forecast
grid, but I
> wanted to be sure.
>
> The implication is that if I specify the use of "FULL" vice using a
mask_poly
> file, that Grid-Stat will always score over that subset of the
gridded
> observation field and as long as you ensure that the gridded
observation field
> is a larger area than you need, you will always get results.
>
> What would happen if the gridded observation dataset was over a
smaller area
> than the forecast field and you specified "FULL" for scoring?
>
> What I'm getting at is a way to decide what geographic size of RTMA
file I
> should download to make sure that I can just use the "FULL" scoring
in the
> mask_grid variable and not worry about having to "guess" the actual
size where
> scoring will occur unless I have a specific reason to focus in on a
particular
> subset of the region.
>
> Thanks for all your help. This service is very helpful for MET
users. We rely
> on this service frequently for assistance in answering questions and
resolving
> issues and have found it to be very efficient and accurate with a
high level
> of responsiveness.
>
> R/
> John
>
>
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Wednesday, December 14, 2011 3:28 PM
> To: Raby, John W USA CIV (US)
> Cc: Kirby, Stephen F USA CIV (US)
> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
(UNCLASSIFIED)
>
> John,
>
> I ran the following two wgrib commands on the data you sent to see
what the
> grids are. I've included the grid definition information output
from wgrib:
>
> % wgrib -d 1 -V WRFPRS_d02.00
> ...
> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
>
> % wgrib -V -d 1 rtma_1km.grb1
> ...
> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.488000
> Latin1 25.000000 Latin2 25.000000 LatSP 0.000000 LonSP
0.000000
> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
>
> As you can see, while the grid dimensions are both 102x102, the grid
> definition parameters differ a lot. So the arguments you're using
in your
> call to copygb need to be modified to make the rtma grid exactly the
same as
> the WRF grid.
>
> There is an example of doing this in the MET online tutorial here:
>
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.0/copygb/run3.php
>
> Using that website as an example, here's the grid definition
argument you
> should be using in your call to copygb:
> "255 3 NX NY STARTLAT STARTLON 8 CENLON DX DY 0 64
TRUELAT1
> TRUELAT2"
> "255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64 40135
40135"
>
> Next I ran the rtma file through copygb like this:
> % copygb -xg"255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64
40135
> 40135" rtma_1km.grb1 rtma_1km_regrid.grb1
>
> And checked to make sure that the grids match now:
> % wgrib -d 1 -V rtma_1km_regrid.grb1
> ...
> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
>
> And they do. So that should solve your problem.
>
> Thanks,
> John
>
>
> On 12/14/2011 03:04 PM, Raby, John W USA CIV via RT wrote:
>>
>> Wed Dec 14 15:04:57 2011: Request 52045 was acted upon.
>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>> Queue: met_help
>> Subject: Request for assistance (UNCLASSIFIED)
>> Owner: Nobody
>> Requestors: john.w.raby2.civ at mail.mil
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> We have been trying to run Grid-Stat using a 1km resolution WRF
>> forecast GRIB1 file (WRFPRS_d02.00)and an RTMA file (rtma_1km.grb)
>> which we converted from GRIB2 to GRIB1 and then used copygb to re-
grid
>> it to match the grid of the WRF.
>>
>> We are running into an ERROR which states that the forecast and
>> observation grids do not match.
>>
>> Could you take a look at the attached files to see if you can
diagnose
>> the problem?
>>
>> Some details on how we are running Grid-Stat follow:
>>
>> grid_stat ../MET_WRFpostprd/${Start_Date}/WRFPRS_d02.00
>> ../MET_obs/RTMA/rtma_1km.grb1 ./GridStatConfig_m2o2_rtma -outdir
>> ./results_m2o2/${Start_Date} -v 2
>>
>> User specifies the Start_Date at the keyboard.
>>
>> The config file (GridStatConfig_m2o2_rtma) is attached. I use a
>> mask_poly file (DUGd02.poly, also attached) to make sure that the
>> scoring is done over the same geographic area as the WRF grid.
>>
>> The valid times/dates do not match, but this is just for testing.
>>
>> Thanks.
>>
>> R/
>> John
>>
>> Mr John W. Raby, Meteorologist
>> U.S. Army Research Laboratory
>> White Sands Missile Range, NM 88002
>> (575) 678-2004 DSN 258-2004
>> FAX (575) 678-1230 DSN 258-1230
>> Email: john.w.raby2.civ at mail.mil
>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
------------------------------------------------
Subject: Request for assistance (UNCLASSIFIED)
From: Raby, John W USA CIV
Time: Thu Dec 15 12:52:23 2011
Classification: UNCLASSIFIED
Caveats: NONE
John -
Very interesting. I find that I learn something new about MET every
time we
have these exchanges. Thanks.
Let's assume I take the tact of requesting RTMA files for areas larger
(slightly, but without a doubt, larger) than the WRF area because the
user
interface for the RTMA system only allows you to specify a square box
(left
lon, right lon, top lat, bottom lat) but the WRF domain is really not
a true
box in terms of lat/lon. By requesting the RTMA for a larger area, I
ensure
that my RTMA file will never be smaller than the WRF which is
desirable for my
purposes now and I don't have to get into the business of trying to
guess at
making a perfect match.
Given the above: What would be the symptoms/problems of a situation
where I
run Grid-Stat using an RTMA file for an area that was slightly larger
than the
WRF area? Would this be detrimental to good practice?
Thanks.
R/
John
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Thursday, December 15, 2011 11:11 AM
To: Raby, John W USA CIV (US)
Cc: Kirby, Stephen F USA CIV (US)
Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
(UNCLASSIFIED)
John,
Lots of questions in there!
First, I'm glad you were able to get it working.
Next, you mention that you ran Grid-Stat two times - once to score
over the
full domain and a second time to score over a subset of the domain. I
want to
point out that you really only need to run Grid-Stat once in this
case. Just
set up your config file with something like this:
mask_grid[] = [ "FULL" ];
mask_poly[] = [ "path/to/your/mask/poly" ];
Each time you run Grid-Stat, it will compute statistics for *each* of
the
masking regions you specify. In this case, you'll see output for both
the
FULL domain and the polyline you've specified.
Your next question - what does the FULL domain mean? Before running
Grid-Stat, you have to put your forecast and observations onto a
common grid.
When you tell the MET tools score over the "FULL"
domain, that means, just use all of those grid points on which the
data
resides. Don't throw any of them out. The fact that you got more
matched
pairs for the FULL domain than you got for the polyline subset makes
complete
sense.
Because of the requirement that the data be on the same grid, every
time you
run Grid-Stat, there will be values at each point in both the forecast
and
observation fields. But suppose that you started with an RTMA file
whose
domain did not fully cover your WRF domain. You'd first need to run
that RTMA
file through copygb to put it onto the WRF grid. That step will
result in a
data file that have valid data in the middle (where the RTMA was
valid)
surrounded by missing data values around the edge (where there was no
RTMA
data). Now suppose you run Grid-Stat to compare the RTMA to a WRF
file, and
tell it to score over the FULL region. Grid-Stat will loop through
the grid
looking at all the points (since we chose FULL), and it will get a
forecast/observation pair for each grid point. Because of the missing
RTMA
values around the edge, you'll end up with some matched pairs where
the
observation is a missing value. And in that case, Grid-Stat won't use
those
matched pairs - it'll toss them out, as it should.
Generally, speaking when Point-Stat and Grid-Stat are run, the first
step is
to compute a bunch of forecast/observation matched pairs. And the
next step
is to throw out any matched pairs where either the forecast or
observation
contains bad data. Then statistics are computed over only those
matched pairs
with good data for both.
That explanation is a long way of suggesting that when retrieving RTMA
data,
be sure it completely covers your WRF domain. And if you have an
option on
resolution of the RTMA data, choose one that most closely matches the
resolution of your model run.
Hope that helps.
John
On 12/15/2011 10:50 AM, Raby, John W USA CIV via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045 >
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> John -
>
> Steve Kirby implemented your solution below and it worked just as
you said!
> This information was invaluable for us to progress in our attempts
to
> use the RTMA product as a gridded observation data set.
>
> I have a question which came out of the testing I did this morning
> with Grid-Stat.
>
> I ran the Grid-Stat tests 2 ways which were both successful. The
first
> was done assuming that the RTMA file was for a slightly larger area
> than the Dugway, UT WRF forecast domain. I restricted the scoring to
a
> subset of that area by using a mask_poly file to define the
geographic
> area according to the coordinates (lat/long corners) of the Dugway
WRF
> domain we have been using in the past. The second test was done by
> removing the restriction and scoring over the full area of the 2
> grids.
>
> The TOTAL # of forecast-observation pairs for the first test was
10207
> and for the second test was 10404. So it appears that by allowing
> Grid-Stat to score over the entire grid it actually scored over a
> slightly larger area than was the case in the first test.
>
> I checked the User's Guide and it says that when you use a value of
> "FULL" in the mask_grid variable it scores over the "entire grid on
> which the data resides". Which grid are you talking about? I would
> assume that since you are trying to verify the forecast, that the
grid
> used is the forecast grid, but I wanted to be sure.
>
> The implication is that if I specify the use of "FULL" vice using a
> mask_poly file, that Grid-Stat will always score over that subset of
> the gridded observation field and as long as you ensure that the
> gridded observation field is a larger area than you need, you will
always
> get results.
>
> What would happen if the gridded observation dataset was over a
> smaller area than the forecast field and you specified "FULL" for
scoring?
>
> What I'm getting at is a way to decide what geographic size of RTMA
> file I should download to make sure that I can just use the "FULL"
> scoring in the mask_grid variable and not worry about having to
> "guess" the actual size where scoring will occur unless I have a
> specific reason to focus in on a particular subset of the region.
>
> Thanks for all your help. This service is very helpful for MET
users.
> We rely on this service frequently for assistance in answering
> questions and resolving issues and have found it to be very
efficient
> and accurate with a high level of responsiveness.
>
> R/
> John
>
>
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Wednesday, December 14, 2011 3:28 PM
> To: Raby, John W USA CIV (US)
> Cc: Kirby, Stephen F USA CIV (US)
> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
> (UNCLASSIFIED)
>
> John,
>
> I ran the following two wgrib commands on the data you sent to see
> what the grids are. I've included the grid definition information
output
> from wgrib:
>
> % wgrib -d 1 -V WRFPRS_d02.00
> ...
> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
>
> % wgrib -V -d 1 rtma_1km.grb1
> ...
> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.488000
> Latin1 25.000000 Latin2 25.000000 LatSP 0.000000 LonSP
0.000000
> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
>
> As you can see, while the grid dimensions are both 102x102, the grid
> definition parameters differ a lot. So the arguments you're using
in
> your call to copygb need to be modified to make the rtma grid
exactly
> the same as the WRF grid.
>
> There is an example of doing this in the MET online tutorial here:
>
>
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.0/copy
> gb/run3.php
>
> Using that website as an example, here's the grid definition
argument
> you should be using in your call to copygb:
> "255 3 NX NY STARTLAT STARTLON 8 CENLON DX DY 0 64
TRUELAT1
> TRUELAT2"
> "255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64 40135
40135"
>
> Next I ran the rtma file through copygb like this:
> % copygb -xg"255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64
> 40135 40135" rtma_1km.grb1 rtma_1km_regrid.grb1
>
> And checked to make sure that the grids match now:
> % wgrib -d 1 -V rtma_1km_regrid.grb1
> ...
> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
>
> And they do. So that should solve your problem.
>
> Thanks,
> John
>
>
> On 12/14/2011 03:04 PM, Raby, John W USA CIV via RT wrote:
>>
>> Wed Dec 14 15:04:57 2011: Request 52045 was acted upon.
>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>> Queue: met_help
>> Subject: Request for assistance (UNCLASSIFIED)
>> Owner: Nobody
>> Requestors: john.w.raby2.civ at mail.mil
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> We have been trying to run Grid-Stat using a 1km resolution WRF
>> forecast GRIB1 file (WRFPRS_d02.00)and an RTMA file (rtma_1km.grb)
>> which we converted from GRIB2 to GRIB1 and then used copygb to
>> re-grid it to match the grid of the WRF.
>>
>> We are running into an ERROR which states that the forecast and
>> observation grids do not match.
>>
>> Could you take a look at the attached files to see if you can
>> diagnose the problem?
>>
>> Some details on how we are running Grid-Stat follow:
>>
>> grid_stat ../MET_WRFpostprd/${Start_Date}/WRFPRS_d02.00
>> ../MET_obs/RTMA/rtma_1km.grb1 ./GridStatConfig_m2o2_rtma -outdir
>> ./results_m2o2/${Start_Date} -v 2
>>
>> User specifies the Start_Date at the keyboard.
>>
>> The config file (GridStatConfig_m2o2_rtma) is attached. I use a
>> mask_poly file (DUGd02.poly, also attached) to make sure that the
>> scoring is done over the same geographic area as the WRF grid.
>>
>> The valid times/dates do not match, but this is just for testing.
>>
>> Thanks.
>>
>> R/
>> John
>>
>> Mr John W. Raby, Meteorologist
>> U.S. Army Research Laboratory
>> White Sands Missile Range, NM 88002
>> (575) 678-2004 DSN 258-2004
>> FAX (575) 678-1230 DSN 258-1230
>> Email: john.w.raby2.civ at mail.mil
>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
Classification: UNCLASSIFIED
Caveats: NONE
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance (UNCLASSIFIED)
From: John Halley Gotway
Time: Fri Dec 16 09:24:07 2011
John,
Yes, I'd recommend doing exactly what you describe - request RTMA data
on a grid that fully encompasses your WRF domain. And you're correct
to realize that differences in projection may require an
RTMA grid slightly larger than your WRF grid. Just get the RTMA data
and regrid it using copygb. Then you could use the IDV tool to
display that regridded RTMA data and make sure there aren't any
strips of missing data along the edges. Or if you don't use IDV, you
could just run the data through Grid-Stat, writing out the matched
pairs file, and look at the matched pair output using the
ncview utility - and check that there isn't any missing data along the
edges.
So the process we described is to regrid the RTMA analysis to your WRF
grid and verify over the model domain. Another option would be to go
the other way - regrid your model data to an RTMA grid and
verify over the RTMA domain. There are arguments for doing it both
ways.
Generally, if you have the option of verifying on the forecast domain
or the observation domain, you'd choose the one with the coarser
resolution. I assume in your case that the RTMA data is on a
coarser grid than your model data. When you interpolate from a
coarser domain to a finer domain, you're kind of inventing a lot of
data points. That being said, most users just want to verify on
their model domain using whatever observations are available. So that
what is often done I believe. For further detail on that issue, I'd
refer you to Tressa.
Thanks,
John
On 12/15/2011 12:52 PM, Raby, John W USA CIV via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045 >
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> John -
>
> Very interesting. I find that I learn something new about MET every
time we
> have these exchanges. Thanks.
>
> Let's assume I take the tact of requesting RTMA files for areas
larger
> (slightly, but without a doubt, larger) than the WRF area because
the user
> interface for the RTMA system only allows you to specify a square
box (left
> lon, right lon, top lat, bottom lat) but the WRF domain is really
not a true
> box in terms of lat/lon. By requesting the RTMA for a larger area, I
ensure
> that my RTMA file will never be smaller than the WRF which is
desirable for my
> purposes now and I don't have to get into the business of trying to
guess at
> making a perfect match.
>
> Given the above: What would be the symptoms/problems of a situation
where I
> run Grid-Stat using an RTMA file for an area that was slightly
larger than the
> WRF area? Would this be detrimental to good practice?
>
> Thanks.
>
> R/
> John
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Thursday, December 15, 2011 11:11 AM
> To: Raby, John W USA CIV (US)
> Cc: Kirby, Stephen F USA CIV (US)
> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
(UNCLASSIFIED)
>
> John,
>
> Lots of questions in there!
>
> First, I'm glad you were able to get it working.
>
> Next, you mention that you ran Grid-Stat two times - once to score
over the
> full domain and a second time to score over a subset of the domain.
I want to
> point out that you really only need to run Grid-Stat once in this
case. Just
> set up your config file with something like this:
> mask_grid[] = [ "FULL" ];
> mask_poly[] = [ "path/to/your/mask/poly" ];
>
> Each time you run Grid-Stat, it will compute statistics for *each*
of the
> masking regions you specify. In this case, you'll see output for
both the
> FULL domain and the polyline you've specified.
>
> Your next question - what does the FULL domain mean? Before running
> Grid-Stat, you have to put your forecast and observations onto a
common grid.
> When you tell the MET tools score over the "FULL"
> domain, that means, just use all of those grid points on which the
data
> resides. Don't throw any of them out. The fact that you got more
matched
> pairs for the FULL domain than you got for the polyline subset makes
complete
> sense.
>
> Because of the requirement that the data be on the same grid, every
time you
> run Grid-Stat, there will be values at each point in both the
forecast and
> observation fields. But suppose that you started with an RTMA file
whose
> domain did not fully cover your WRF domain. You'd first need to run
that RTMA
> file through copygb to put it onto the WRF grid. That step will
result in a
> data file that have valid data in the middle (where the RTMA was
valid)
> surrounded by missing data values around the edge (where there was
no RTMA
> data). Now suppose you run Grid-Stat to compare the RTMA to a WRF
file, and
> tell it to score over the FULL region. Grid-Stat will loop through
the grid
> looking at all the points (since we chose FULL), and it will get a
> forecast/observation pair for each grid point. Because of the
missing RTMA
> values around the edge, you'll end up with some matched pairs where
the
> observation is a missing value. And in that case, Grid-Stat won't
use those
> matched pairs - it'll toss them out, as it should.
>
> Generally, speaking when Point-Stat and Grid-Stat are run, the first
step is
> to compute a bunch of forecast/observation matched pairs. And the
next step
> is to throw out any matched pairs where either the forecast or
observation
> contains bad data. Then statistics are computed over only those
matched pairs
> with good data for both.
>
> That explanation is a long way of suggesting that when retrieving
RTMA data,
> be sure it completely covers your WRF domain. And if you have an
option on
> resolution of the RTMA data, choose one that most closely matches
the
> resolution of your model run.
>
> Hope that helps.
>
> John
>
>
>
>
> On 12/15/2011 10:50 AM, Raby, John W USA CIV via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045 >
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> John -
>>
>> Steve Kirby implemented your solution below and it worked just as
you said!
>> This information was invaluable for us to progress in our attempts
to
>> use the RTMA product as a gridded observation data set.
>>
>> I have a question which came out of the testing I did this morning
>> with Grid-Stat.
>>
>> I ran the Grid-Stat tests 2 ways which were both successful. The
first
>> was done assuming that the RTMA file was for a slightly larger area
>> than the Dugway, UT WRF forecast domain. I restricted the scoring
to a
>> subset of that area by using a mask_poly file to define the
geographic
>> area according to the coordinates (lat/long corners) of the Dugway
WRF
>> domain we have been using in the past. The second test was done by
>> removing the restriction and scoring over the full area of the 2
>> grids.
>>
>> The TOTAL # of forecast-observation pairs for the first test was
10207
>> and for the second test was 10404. So it appears that by allowing
>> Grid-Stat to score over the entire grid it actually scored over a
>> slightly larger area than was the case in the first test.
>>
>> I checked the User's Guide and it says that when you use a value of
>> "FULL" in the mask_grid variable it scores over the "entire grid on
>> which the data resides". Which grid are you talking about? I would
>> assume that since you are trying to verify the forecast, that the
grid
>> used is the forecast grid, but I wanted to be sure.
>>
>> The implication is that if I specify the use of "FULL" vice using a
>> mask_poly file, that Grid-Stat will always score over that subset
of
>> the gridded observation field and as long as you ensure that the
>> gridded observation field is a larger area than you need, you will
always
>> get results.
>>
>> What would happen if the gridded observation dataset was over a
>> smaller area than the forecast field and you specified "FULL" for
scoring?
>>
>> What I'm getting at is a way to decide what geographic size of RTMA
>> file I should download to make sure that I can just use the "FULL"
>> scoring in the mask_grid variable and not worry about having to
>> "guess" the actual size where scoring will occur unless I have a
>> specific reason to focus in on a particular subset of the region.
>>
>> Thanks for all your help. This service is very helpful for MET
users.
>> We rely on this service frequently for assistance in answering
>> questions and resolving issues and have found it to be very
efficient
>> and accurate with a high level of responsiveness.
>>
>> R/
>> John
>>
>>
>>
>>
>> -----Original Message-----
>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> Sent: Wednesday, December 14, 2011 3:28 PM
>> To: Raby, John W USA CIV (US)
>> Cc: Kirby, Stephen F USA CIV (US)
>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>> (UNCLASSIFIED)
>>
>> John,
>>
>> I ran the following two wgrib commands on the data you sent to see
>> what the grids are. I've included the grid definition information
output
>> from wgrib:
>>
>> % wgrib -d 1 -V WRFPRS_d02.00
>> ...
>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
>> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
>>
>> % wgrib -V -d 1 rtma_1km.grb1
>> ...
>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.488000
>> Latin1 25.000000 Latin2 25.000000 LatSP 0.000000 LonSP
0.000000
>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
>>
>> As you can see, while the grid dimensions are both 102x102, the
grid
>> definition parameters differ a lot. So the arguments you're using
in
>> your call to copygb need to be modified to make the rtma grid
exactly
>> the same as the WRF grid.
>>
>> There is an example of doing this in the MET online tutorial here:
>>
>>
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.0/copy
>> gb/run3.php
>>
>> Using that website as an example, here's the grid definition
argument
>> you should be using in your call to copygb:
>> "255 3 NX NY STARTLAT STARTLON 8 CENLON DX DY 0 64
TRUELAT1
>> TRUELAT2"
>> "255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64 40135
40135"
>>
>> Next I ran the rtma file through copygb like this:
>> % copygb -xg"255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64
>> 40135 40135" rtma_1km.grb1 rtma_1km_regrid.grb1
>>
>> And checked to make sure that the grids match now:
>> % wgrib -d 1 -V rtma_1km_regrid.grb1
>> ...
>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
>> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
>>
>> And they do. So that should solve your problem.
>>
>> Thanks,
>> John
>>
>>
>> On 12/14/2011 03:04 PM, Raby, John W USA CIV via RT wrote:
>>>
>>> Wed Dec 14 15:04:57 2011: Request 52045 was acted upon.
>>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>>> Queue: met_help
>>> Subject: Request for assistance (UNCLASSIFIED)
>>> Owner: Nobody
>>> Requestors: john.w.raby2.civ at mail.mil
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045
>>>>
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> We have been trying to run Grid-Stat using a 1km resolution WRF
>>> forecast GRIB1 file (WRFPRS_d02.00)and an RTMA file (rtma_1km.grb)
>>> which we converted from GRIB2 to GRIB1 and then used copygb to
>>> re-grid it to match the grid of the WRF.
>>>
>>> We are running into an ERROR which states that the forecast and
>>> observation grids do not match.
>>>
>>> Could you take a look at the attached files to see if you can
>>> diagnose the problem?
>>>
>>> Some details on how we are running Grid-Stat follow:
>>>
>>> grid_stat ../MET_WRFpostprd/${Start_Date}/WRFPRS_d02.00
>>> ../MET_obs/RTMA/rtma_1km.grb1 ./GridStatConfig_m2o2_rtma -outdir
>>> ./results_m2o2/${Start_Date} -v 2
>>>
>>> User specifies the Start_Date at the keyboard.
>>>
>>> The config file (GridStatConfig_m2o2_rtma) is attached. I use a
>>> mask_poly file (DUGd02.poly, also attached) to make sure that the
>>> scoring is done over the same geographic area as the WRF grid.
>>>
>>> The valid times/dates do not match, but this is just for testing.
>>>
>>> Thanks.
>>>
>>> R/
>>> John
>>>
>>> Mr John W. Raby, Meteorologist
>>> U.S. Army Research Laboratory
>>> White Sands Missile Range, NM 88002
>>> (575) 678-2004 DSN 258-2004
>>> FAX (575) 678-1230 DSN 258-1230
>>> Email: john.w.raby2.civ at mail.mil
>>>
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
------------------------------------------------
Subject: Request for assistance (UNCLASSIFIED)
From: Raby, John W USA CIV
Time: Fri Dec 16 10:14:52 2011
Classification: UNCLASSIFIED
Caveats: NONE
John -
Thanks for providing some answers to all my questions that last couple
of
days. We see this a breakthrough for us as we are trying to verify our
high
resolution WRF Nowcast model which has four dimensional data
assimilation
(WRF/FDDA). We need to augment our verification process which, up to
now, has
just the traditional statistics from Point-Stat and Stat-Analysis by
adding
fuzzy and spatial verification techniques and have been stymied by the
lack of
a gridded observation dataset until now.
We hope to use the RTMA product to start using Grid-Stat for
neighborhood
(fuzzy) verification statistics and MODE for spatial verification. We
want to
focus on "objects" defined by thresholds we set within the continuous
met
variable fields of temperature, dewpoint, and windspeed for now since
that is
what the RTMA gives us. We want to see how well the model forecasts
these
"objects" when compared to the same objects in the RTMA observations.
By adding Grid-Stat and MODE assessments to traditional evaluations we
want to
be able to tell the complete story about the performance of the
WRF/FDDA.
R/
John
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Friday, December 16, 2011 9:24 AM
To: Raby, John W USA CIV (US)
Cc: Kirby, Stephen F USA CIV (US)
Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
(UNCLASSIFIED)
John,
Yes, I'd recommend doing exactly what you describe - request RTMA data
on a
grid that fully encompasses your WRF domain. And you're correct to
realize
that differences in projection may require an RTMA grid slightly
larger than
your WRF grid. Just get the RTMA data and regrid it using copygb.
Then you
could use the IDV tool to display that regridded RTMA data and make
sure there
aren't any strips of missing data along the edges. Or if you don't
use IDV,
you could just run the data through Grid-Stat, writing out the matched
pairs
file, and look at the matched pair output using the ncview utility -
and check
that there isn't any missing data along the edges.
So the process we described is to regrid the RTMA analysis to your WRF
grid
and verify over the model domain. Another option would be to go the
other
way - regrid your model data to an RTMA grid and verify over the RTMA
domain.
There are arguments for doing it both ways.
Generally, if you have the option of verifying on the forecast domain
or the
observation domain, you'd choose the one with the coarser resolution.
I
assume in your case that the RTMA data is on a coarser grid than your
model
data. When you interpolate from a coarser domain to a finer domain,
you're
kind of inventing a lot of data points. That being said, most users
just want
to verify on their model domain using whatever observations are
available. So
that what is often done I believe. For further detail on that issue,
I'd
refer you to Tressa.
Thanks,
John
On 12/15/2011 12:52 PM, Raby, John W USA CIV via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045 >
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> John -
>
> Very interesting. I find that I learn something new about MET every
> time we have these exchanges. Thanks.
>
> Let's assume I take the tact of requesting RTMA files for areas
larger
> (slightly, but without a doubt, larger) than the WRF area because
the
> user interface for the RTMA system only allows you to specify a
square
> box (left lon, right lon, top lat, bottom lat) but the WRF domain is
> really not a true box in terms of lat/lon. By requesting the RTMA
for
> a larger area, I ensure that my RTMA file will never be smaller than
> the WRF which is desirable for my purposes now and I don't have to
get
> into the business of trying to guess at making a perfect match.
>
> Given the above: What would be the symptoms/problems of a situation
> where I run Grid-Stat using an RTMA file for an area that was
slightly
> larger than the WRF area? Would this be detrimental to good
practice?
>
> Thanks.
>
> R/
> John
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Thursday, December 15, 2011 11:11 AM
> To: Raby, John W USA CIV (US)
> Cc: Kirby, Stephen F USA CIV (US)
> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
> (UNCLASSIFIED)
>
> John,
>
> Lots of questions in there!
>
> First, I'm glad you were able to get it working.
>
> Next, you mention that you ran Grid-Stat two times - once to score
> over the full domain and a second time to score over a subset of the
> domain. I want to point out that you really only need to run
> Grid-Stat once in this case. Just set up your config file with
something
> like this:
> mask_grid[] = [ "FULL" ];
> mask_poly[] = [ "path/to/your/mask/poly" ];
>
> Each time you run Grid-Stat, it will compute statistics for *each*
of
> the masking regions you specify. In this case, you'll see output
for
> both the FULL domain and the polyline you've specified.
>
> Your next question - what does the FULL domain mean? Before running
> Grid-Stat, you have to put your forecast and observations onto a
common
> grid.
> When you tell the MET tools score over the "FULL"
> domain, that means, just use all of those grid points on which the
> data resides. Don't throw any of them out. The fact that you got
> more matched pairs for the FULL domain than you got for the polyline
> subset makes complete sense.
>
> Because of the requirement that the data be on the same grid, every
> time you run Grid-Stat, there will be values at each point in both
the
> forecast and observation fields. But suppose that you started with
an
> RTMA file whose domain did not fully cover your WRF domain. You'd
> first need to run that RTMA file through copygb to put it onto the
WRF
> grid. That step will result in a data file that have valid data in
> the middle (where the RTMA was valid) surrounded by missing data
> values around the edge (where there was no RTMA data). Now suppose
> you run Grid-Stat to compare the RTMA to a WRF file, and tell it to
> score over the FULL region. Grid-Stat will loop through the grid
> looking at all the points (since we chose FULL), and it will get a
> forecast/observation pair for each grid point. Because of the
missing
> RTMA values around the edge, you'll end up with some matched pairs
> where the observation is a missing value. And in that case, Grid-
Stat won't
> use those matched pairs - it'll toss them out, as it should.
>
> Generally, speaking when Point-Stat and Grid-Stat are run, the first
> step is to compute a bunch of forecast/observation matched pairs.
And
> the next step is to throw out any matched pairs where either the
> forecast or observation contains bad data. Then statistics are
> computed over only those matched pairs with good data for both.
>
> That explanation is a long way of suggesting that when retrieving
RTMA
> data, be sure it completely covers your WRF domain. And if you have
> an option on resolution of the RTMA data, choose one that most
closely
> matches the resolution of your model run.
>
> Hope that helps.
>
> John
>
>
>
>
> On 12/15/2011 10:50 AM, Raby, John W USA CIV via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045 >
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> John -
>>
>> Steve Kirby implemented your solution below and it worked just as
you said!
>> This information was invaluable for us to progress in our attempts
to
>> use the RTMA product as a gridded observation data set.
>>
>> I have a question which came out of the testing I did this morning
>> with Grid-Stat.
>>
>> I ran the Grid-Stat tests 2 ways which were both successful. The
>> first was done assuming that the RTMA file was for a slightly
larger
>> area than the Dugway, UT WRF forecast domain. I restricted the
>> scoring to a subset of that area by using a mask_poly file to
define
>> the geographic area according to the coordinates (lat/long corners)
>> of the Dugway WRF domain we have been using in the past. The second
>> test was done by removing the restriction and scoring over the full
>> area of the 2 grids.
>>
>> The TOTAL # of forecast-observation pairs for the first test was
>> 10207 and for the second test was 10404. So it appears that by
>> allowing Grid-Stat to score over the entire grid it actually scored
>> over a slightly larger area than was the case in the first test.
>>
>> I checked the User's Guide and it says that when you use a value of
>> "FULL" in the mask_grid variable it scores over the "entire grid on
>> which the data resides". Which grid are you talking about? I would
>> assume that since you are trying to verify the forecast, that the
>> grid used is the forecast grid, but I wanted to be sure.
>>
>> The implication is that if I specify the use of "FULL" vice using a
>> mask_poly file, that Grid-Stat will always score over that subset
of
>> the gridded observation field and as long as you ensure that the
>> gridded observation field is a larger area than you need, you will
>> always get results.
>>
>> What would happen if the gridded observation dataset was over a
>> smaller area than the forecast field and you specified "FULL" for
scoring?
>>
>> What I'm getting at is a way to decide what geographic size of RTMA
>> file I should download to make sure that I can just use the "FULL"
>> scoring in the mask_grid variable and not worry about having to
>> "guess" the actual size where scoring will occur unless I have a
>> specific reason to focus in on a particular subset of the region.
>>
>> Thanks for all your help. This service is very helpful for MET
users.
>> We rely on this service frequently for assistance in answering
>> questions and resolving issues and have found it to be very
efficient
>> and accurate with a high level of responsiveness.
>>
>> R/
>> John
>>
>>
>>
>>
>> -----Original Message-----
>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> Sent: Wednesday, December 14, 2011 3:28 PM
>> To: Raby, John W USA CIV (US)
>> Cc: Kirby, Stephen F USA CIV (US)
>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>> (UNCLASSIFIED)
>>
>> John,
>>
>> I ran the following two wgrib commands on the data you sent to see
>> what the grids are. I've included the grid definition information
>> output from wgrib:
>>
>> % wgrib -d 1 -V WRFPRS_d02.00
>> ...
>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
>> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
>>
>> % wgrib -V -d 1 rtma_1km.grb1
>> ...
>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.488000
>> Latin1 25.000000 Latin2 25.000000 LatSP 0.000000 LonSP
0.000000
>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
>>
>> As you can see, while the grid dimensions are both 102x102, the
grid
>> definition parameters differ a lot. So the arguments you're using
in
>> your call to copygb need to be modified to make the rtma grid
exactly
>> the same as the WRF grid.
>>
>> There is an example of doing this in the MET online tutorial here:
>>
>>
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.0/cop
>> y
>> gb/run3.php
>>
>> Using that website as an example, here's the grid definition
argument
>> you should be using in your call to copygb:
>> "255 3 NX NY STARTLAT STARTLON 8 CENLON DX DY 0 64
TRUELAT1
>> TRUELAT2"
>> "255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64 40135
>> 40135"
>>
>> Next I ran the rtma file through copygb like this:
>> % copygb -xg"255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64
>> 40135 40135" rtma_1km.grb1 rtma_1km_regrid.grb1
>>
>> And checked to make sure that the grids match now:
>> % wgrib -d 1 -V rtma_1km_regrid.grb1 ...
>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
>> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode 8
...
>>
>> And they do. So that should solve your problem.
>>
>> Thanks,
>> John
>>
>>
>> On 12/14/2011 03:04 PM, Raby, John W USA CIV via RT wrote:
>>>
>>> Wed Dec 14 15:04:57 2011: Request 52045 was acted upon.
>>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>>> Queue: met_help
>>> Subject: Request for assistance (UNCLASSIFIED)
>>> Owner: Nobody
>>> Requestors: john.w.raby2.civ at mail.mil
>>> Status: new
>>> Ticket <URL:
>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045
>>>>
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> We have been trying to run Grid-Stat using a 1km resolution WRF
>>> forecast GRIB1 file (WRFPRS_d02.00)and an RTMA file (rtma_1km.grb)
>>> which we converted from GRIB2 to GRIB1 and then used copygb to
>>> re-grid it to match the grid of the WRF.
>>>
>>> We are running into an ERROR which states that the forecast and
>>> observation grids do not match.
>>>
>>> Could you take a look at the attached files to see if you can
>>> diagnose the problem?
>>>
>>> Some details on how we are running Grid-Stat follow:
>>>
>>> grid_stat ../MET_WRFpostprd/${Start_Date}/WRFPRS_d02.00
>>> ../MET_obs/RTMA/rtma_1km.grb1 ./GridStatConfig_m2o2_rtma -outdir
>>> ./results_m2o2/${Start_Date} -v 2
>>>
>>> User specifies the Start_Date at the keyboard.
>>>
>>> The config file (GridStatConfig_m2o2_rtma) is attached. I use a
>>> mask_poly file (DUGd02.poly, also attached) to make sure that the
>>> scoring is done over the same geographic area as the WRF grid.
>>>
>>> The valid times/dates do not match, but this is just for testing.
>>>
>>> Thanks.
>>>
>>> R/
>>> John
>>>
>>> Mr John W. Raby, Meteorologist
>>> U.S. Army Research Laboratory
>>> White Sands Missile Range, NM 88002
>>> (575) 678-2004 DSN 258-2004
>>> FAX (575) 678-1230 DSN 258-1230
>>> Email: john.w.raby2.civ at mail.mil
>>>
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
Classification: UNCLASSIFIED
Caveats: NONE
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance (UNCLASSIFIED)
From: John Halley Gotway
Time: Fri Dec 16 10:31:46 2011
That sounds great John.
I'll go ahead and resolve this ticket. Just let us know if more
questions/problems arise.
Thanks,
John
On 12/16/2011 10:14 AM, Raby, John W USA CIV via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045 >
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> John -
>
> Thanks for providing some answers to all my questions that last
couple of
> days. We see this a breakthrough for us as we are trying to verify
our high
> resolution WRF Nowcast model which has four dimensional data
assimilation
> (WRF/FDDA). We need to augment our verification process which, up to
now, has
> just the traditional statistics from Point-Stat and Stat-Analysis by
adding
> fuzzy and spatial verification techniques and have been stymied by
the lack of
> a gridded observation dataset until now.
>
> We hope to use the RTMA product to start using Grid-Stat for
neighborhood
> (fuzzy) verification statistics and MODE for spatial verification.
We want to
> focus on "objects" defined by thresholds we set within the
continuous met
> variable fields of temperature, dewpoint, and windspeed for now
since that is
> what the RTMA gives us. We want to see how well the model forecasts
these
> "objects" when compared to the same objects in the RTMA
observations.
>
> By adding Grid-Stat and MODE assessments to traditional evaluations
we want to
> be able to tell the complete story about the performance of the
WRF/FDDA.
>
> R/
> John
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Friday, December 16, 2011 9:24 AM
> To: Raby, John W USA CIV (US)
> Cc: Kirby, Stephen F USA CIV (US)
> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
(UNCLASSIFIED)
>
> John,
>
> Yes, I'd recommend doing exactly what you describe - request RTMA
data on a
> grid that fully encompasses your WRF domain. And you're correct to
realize
> that differences in projection may require an RTMA grid slightly
larger than
> your WRF grid. Just get the RTMA data and regrid it using copygb.
Then you
> could use the IDV tool to display that regridded RTMA data and make
sure there
> aren't any strips of missing data along the edges. Or if you don't
use IDV,
> you could just run the data through Grid-Stat, writing out the
matched pairs
> file, and look at the matched pair output using the ncview utility -
and check
> that there isn't any missing data along the edges.
>
> So the process we described is to regrid the RTMA analysis to your
WRF grid
> and verify over the model domain. Another option would be to go the
other
> way - regrid your model data to an RTMA grid and verify over the
RTMA domain.
> There are arguments for doing it both ways.
>
> Generally, if you have the option of verifying on the forecast
domain or the
> observation domain, you'd choose the one with the coarser
resolution. I
> assume in your case that the RTMA data is on a coarser grid than
your model
> data. When you interpolate from a coarser domain to a finer domain,
you're
> kind of inventing a lot of data points. That being said, most users
just want
> to verify on their model domain using whatever observations are
available. So
> that what is often done I believe. For further detail on that
issue, I'd
> refer you to Tressa.
>
> Thanks,
> John
>
> On 12/15/2011 12:52 PM, Raby, John W USA CIV via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045 >
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> John -
>>
>> Very interesting. I find that I learn something new about MET every
>> time we have these exchanges. Thanks.
>>
>> Let's assume I take the tact of requesting RTMA files for areas
larger
>> (slightly, but without a doubt, larger) than the WRF area because
the
>> user interface for the RTMA system only allows you to specify a
square
>> box (left lon, right lon, top lat, bottom lat) but the WRF domain
is
>> really not a true box in terms of lat/lon. By requesting the RTMA
for
>> a larger area, I ensure that my RTMA file will never be smaller
than
>> the WRF which is desirable for my purposes now and I don't have to
get
>> into the business of trying to guess at making a perfect match.
>>
>> Given the above: What would be the symptoms/problems of a situation
>> where I run Grid-Stat using an RTMA file for an area that was
slightly
>> larger than the WRF area? Would this be detrimental to good
practice?
>>
>> Thanks.
>>
>> R/
>> John
>>
>> -----Original Message-----
>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> Sent: Thursday, December 15, 2011 11:11 AM
>> To: Raby, John W USA CIV (US)
>> Cc: Kirby, Stephen F USA CIV (US)
>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>> (UNCLASSIFIED)
>>
>> John,
>>
>> Lots of questions in there!
>>
>> First, I'm glad you were able to get it working.
>>
>> Next, you mention that you ran Grid-Stat two times - once to score
>> over the full domain and a second time to score over a subset of
the
>> domain. I want to point out that you really only need to run
>> Grid-Stat once in this case. Just set up your config file with
something
>> like this:
>> mask_grid[] = [ "FULL" ];
>> mask_poly[] = [ "path/to/your/mask/poly" ];
>>
>> Each time you run Grid-Stat, it will compute statistics for *each*
of
>> the masking regions you specify. In this case, you'll see output
for
>> both the FULL domain and the polyline you've specified.
>>
>> Your next question - what does the FULL domain mean? Before
running
>> Grid-Stat, you have to put your forecast and observations onto a
common
>> grid.
>> When you tell the MET tools score over the "FULL"
>> domain, that means, just use all of those grid points on which the
>> data resides. Don't throw any of them out. The fact that you got
>> more matched pairs for the FULL domain than you got for the
polyline
>> subset makes complete sense.
>>
>> Because of the requirement that the data be on the same grid, every
>> time you run Grid-Stat, there will be values at each point in both
the
>> forecast and observation fields. But suppose that you started with
an
>> RTMA file whose domain did not fully cover your WRF domain. You'd
>> first need to run that RTMA file through copygb to put it onto the
WRF
>> grid. That step will result in a data file that have valid data in
>> the middle (where the RTMA was valid) surrounded by missing data
>> values around the edge (where there was no RTMA data). Now suppose
>> you run Grid-Stat to compare the RTMA to a WRF file, and tell it to
>> score over the FULL region. Grid-Stat will loop through the grid
>> looking at all the points (since we chose FULL), and it will get a
>> forecast/observation pair for each grid point. Because of the
missing
>> RTMA values around the edge, you'll end up with some matched pairs
>> where the observation is a missing value. And in that case, Grid-
Stat won't
>> use those matched pairs - it'll toss them out, as it should.
>>
>> Generally, speaking when Point-Stat and Grid-Stat are run, the
first
>> step is to compute a bunch of forecast/observation matched pairs.
And
>> the next step is to throw out any matched pairs where either the
>> forecast or observation contains bad data. Then statistics are
>> computed over only those matched pairs with good data for both.
>>
>> That explanation is a long way of suggesting that when retrieving
RTMA
>> data, be sure it completely covers your WRF domain. And if you
have
>> an option on resolution of the RTMA data, choose one that most
closely
>> matches the resolution of your model run.
>>
>> Hope that helps.
>>
>> John
>>
>>
>>
>>
>> On 12/15/2011 10:50 AM, Raby, John W USA CIV via RT wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045 >
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> John -
>>>
>>> Steve Kirby implemented your solution below and it worked just as
you said!
>>> This information was invaluable for us to progress in our attempts
to
>>> use the RTMA product as a gridded observation data set.
>>>
>>> I have a question which came out of the testing I did this morning
>>> with Grid-Stat.
>>>
>>> I ran the Grid-Stat tests 2 ways which were both successful. The
>>> first was done assuming that the RTMA file was for a slightly
larger
>>> area than the Dugway, UT WRF forecast domain. I restricted the
>>> scoring to a subset of that area by using a mask_poly file to
define
>>> the geographic area according to the coordinates (lat/long
corners)
>>> of the Dugway WRF domain we have been using in the past. The
second
>>> test was done by removing the restriction and scoring over the
full
>>> area of the 2 grids.
>>>
>>> The TOTAL # of forecast-observation pairs for the first test was
>>> 10207 and for the second test was 10404. So it appears that by
>>> allowing Grid-Stat to score over the entire grid it actually
scored
>>> over a slightly larger area than was the case in the first test.
>>>
>>> I checked the User's Guide and it says that when you use a value
of
>>> "FULL" in the mask_grid variable it scores over the "entire grid
on
>>> which the data resides". Which grid are you talking about? I would
>>> assume that since you are trying to verify the forecast, that the
>>> grid used is the forecast grid, but I wanted to be sure.
>>>
>>> The implication is that if I specify the use of "FULL" vice using
a
>>> mask_poly file, that Grid-Stat will always score over that subset
of
>>> the gridded observation field and as long as you ensure that the
>>> gridded observation field is a larger area than you need, you will
>>> always get results.
>>>
>>> What would happen if the gridded observation dataset was over a
>>> smaller area than the forecast field and you specified "FULL" for
scoring?
>>>
>>> What I'm getting at is a way to decide what geographic size of
RTMA
>>> file I should download to make sure that I can just use the "FULL"
>>> scoring in the mask_grid variable and not worry about having to
>>> "guess" the actual size where scoring will occur unless I have a
>>> specific reason to focus in on a particular subset of the region.
>>>
>>> Thanks for all your help. This service is very helpful for MET
users.
>>> We rely on this service frequently for assistance in answering
>>> questions and resolving issues and have found it to be very
efficient
>>> and accurate with a high level of responsiveness.
>>>
>>> R/
>>> John
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> Sent: Wednesday, December 14, 2011 3:28 PM
>>> To: Raby, John W USA CIV (US)
>>> Cc: Kirby, Stephen F USA CIV (US)
>>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>>> (UNCLASSIFIED)
>>>
>>> John,
>>>
>>> I ran the following two wgrib commands on the data you sent to see
>>> what the grids are. I've included the grid definition information
>>> output from wgrib:
>>>
>>> % wgrib -d 1 -V WRFPRS_d02.00
>>> ...
>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
>>> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode
8 ...
>>>
>>> % wgrib -V -d 1 rtma_1km.grb1
>>> ...
>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.488000
>>> Latin1 25.000000 Latin2 25.000000 LatSP 0.000000 LonSP
0.000000
>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode
8 ...
>>>
>>> As you can see, while the grid dimensions are both 102x102, the
grid
>>> definition parameters differ a lot. So the arguments you're using
in
>>> your call to copygb need to be modified to make the rtma grid
exactly
>>> the same as the WRF grid.
>>>
>>> There is an example of doing this in the MET online tutorial here:
>>>
>>>
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.0/cop
>>> y
>>> gb/run3.php
>>>
>>> Using that website as an example, here's the grid definition
argument
>>> you should be using in your call to copygb:
>>> "255 3 NX NY STARTLAT STARTLON 8 CENLON DX DY 0 64
TRUELAT1
>>> TRUELAT2"
>>> "255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64 40135
>>> 40135"
>>>
>>> Next I ran the rtma file through copygb like this:
>>> % copygb -xg"255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64
>>> 40135 40135" rtma_1km.grb1 rtma_1km_regrid.grb1
>>>
>>> And checked to make sure that the grids match now:
>>> % wgrib -d 1 -V rtma_1km_regrid.grb1 ...
>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
>>> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode
8 ...
>>>
>>> And they do. So that should solve your problem.
>>>
>>> Thanks,
>>> John
>>>
>>>
>>> On 12/14/2011 03:04 PM, Raby, John W USA CIV via RT wrote:
>>>>
>>>> Wed Dec 14 15:04:57 2011: Request 52045 was acted upon.
>>>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>>>> Queue: met_help
>>>> Subject: Request for assistance (UNCLASSIFIED)
>>>> Owner: Nobody
>>>> Requestors: john.w.raby2.civ at mail.mil
>>>> Status: new
>>>> Ticket <URL:
>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045
>>>>>
>>>>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>> We have been trying to run Grid-Stat using a 1km resolution WRF
>>>> forecast GRIB1 file (WRFPRS_d02.00)and an RTMA file
(rtma_1km.grb)
>>>> which we converted from GRIB2 to GRIB1 and then used copygb to
>>>> re-grid it to match the grid of the WRF.
>>>>
>>>> We are running into an ERROR which states that the forecast and
>>>> observation grids do not match.
>>>>
>>>> Could you take a look at the attached files to see if you can
>>>> diagnose the problem?
>>>>
>>>> Some details on how we are running Grid-Stat follow:
>>>>
>>>> grid_stat ../MET_WRFpostprd/${Start_Date}/WRFPRS_d02.00
>>>> ../MET_obs/RTMA/rtma_1km.grb1 ./GridStatConfig_m2o2_rtma -outdir
>>>> ./results_m2o2/${Start_Date} -v 2
>>>>
>>>> User specifies the Start_Date at the keyboard.
>>>>
>>>> The config file (GridStatConfig_m2o2_rtma) is attached. I use a
>>>> mask_poly file (DUGd02.poly, also attached) to make sure that the
>>>> scoring is done over the same geographic area as the WRF grid.
>>>>
>>>> The valid times/dates do not match, but this is just for testing.
>>>>
>>>> Thanks.
>>>>
>>>> R/
>>>> John
>>>>
>>>> Mr John W. Raby, Meteorologist
>>>> U.S. Army Research Laboratory
>>>> White Sands Missile Range, NM 88002
>>>> (575) 678-2004 DSN 258-2004
>>>> FAX (575) 678-1230 DSN 258-1230
>>>> Email: john.w.raby2.civ at mail.mil
>>>>
>>>>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>>
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>>
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
------------------------------------------------
Subject: Request for assistance (UNCLASSIFIED)
From: stephen.f.kirby.civ at mail.mil
Time: Tue Jan 03 11:12:19 2012
Classification: UNCLASSIFIED
Caveats: NONE
Hi John and the met_help folks,
One question. In support of John Raby here, with whom you've been
conversing,
I'm writing a script for re-gridding WRF from 1km resolution to 2.5km
resolution to match a RTMA gridded observation file. This output file
will be
utilized in Grid-Stat.
The RTMA file that I need to match has dimensions as follows:
[skirby at carson RTMA]$ wgrib2 -grid rtma2p5.t00z.2dvaranal_ndfd.grb2
1:0:grid_template=30:winds(grid):
Lambert Conformal: (38 x 31) input WE:SN output WE:SN res 8
Lat1 39.720561 Lon1 246.040860 LoV 265.000000
LatD 25.000000 Latin1 25.000000 Latin2 25.000000
LatSP -90.000000 LonSP 0.000000
North Pole (38 x 31) Dx 2539.703000 m Dy 2539.703000 m mode 8
But the problem I see is that, for example, the "Lat1" value has non-
zero
digits beyond the thousandth's place. And copygb only accepts integer
values,
so when you multiply by a thousand to get millidegrees you get
39720.561. At
this point, do you round this to 39721, or do you truncate it to
39720?
Neither one gives an exact match to the original RTMA dimensions which
makes
me think Grid-Stat will complain. What do you recommend?
Thanks for your advice,
Steve
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Friday, December 16, 2011 10:32 AM
To: Raby, John W USA CIV (US)
Cc: Kirby, Stephen F USA CIV (US)
Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
(UNCLASSIFIED)
That sounds great John.
I'll go ahead and resolve this ticket. Just let us know if more
questions/problems arise.
Thanks,
John
On 12/16/2011 10:14 AM, Raby, John W USA CIV via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045 >
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> John -
>
> Thanks for providing some answers to all my questions that last
couple of
> days. We see this a breakthrough for us as we are trying to verify
our high
> resolution WRF Nowcast model which has four dimensional data
assimilation
> (WRF/FDDA). We need to augment our verification process which, up to
now,
> has
> just the traditional statistics from Point-Stat and Stat-Analysis by
adding
> fuzzy and spatial verification techniques and have been stymied by
the lack
> of
> a gridded observation dataset until now.
>
> We hope to use the RTMA product to start using Grid-Stat for
neighborhood
> (fuzzy) verification statistics and MODE for spatial verification.
We want
> to
> focus on "objects" defined by thresholds we set within the
continuous met
> variable fields of temperature, dewpoint, and windspeed for now
since that
> is
> what the RTMA gives us. We want to see how well the model forecasts
these
> "objects" when compared to the same objects in the RTMA
observations.
>
> By adding Grid-Stat and MODE assessments to traditional evaluations
we want
> to
> be able to tell the complete story about the performance of the
WRF/FDDA.
>
> R/
> John
>
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Friday, December 16, 2011 9:24 AM
> To: Raby, John W USA CIV (US)
> Cc: Kirby, Stephen F USA CIV (US)
> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
(UNCLASSIFIED)
>
> John,
>
> Yes, I'd recommend doing exactly what you describe - request RTMA
data on a
> grid that fully encompasses your WRF domain. And you're correct to
realize
> that differences in projection may require an RTMA grid slightly
larger than
> your WRF grid. Just get the RTMA data and regrid it using copygb.
Then you
> could use the IDV tool to display that regridded RTMA data and make
sure
> there
> aren't any strips of missing data along the edges. Or if you don't
use IDV,
> you could just run the data through Grid-Stat, writing out the
matched pairs
> file, and look at the matched pair output using the ncview utility -
and
> check
> that there isn't any missing data along the edges.
>
> So the process we described is to regrid the RTMA analysis to your
WRF grid
> and verify over the model domain. Another option would be to go the
other
> way - regrid your model data to an RTMA grid and verify over the
RTMA
> domain.
> There are arguments for doing it both ways.
>
> Generally, if you have the option of verifying on the forecast
domain or the
> observation domain, you'd choose the one with the coarser
resolution. I
> assume in your case that the RTMA data is on a coarser grid than
your model
> data. When you interpolate from a coarser domain to a finer domain,
you're
> kind of inventing a lot of data points. That being said, most users
just
> want
> to verify on their model domain using whatever observations are
available.
> So
> that what is often done I believe. For further detail on that
issue, I'd
> refer you to Tressa.
>
> Thanks,
> John
>
> On 12/15/2011 12:52 PM, Raby, John W USA CIV via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045 >
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> John -
>>
>> Very interesting. I find that I learn something new about MET every
>> time we have these exchanges. Thanks.
>>
>> Let's assume I take the tact of requesting RTMA files for areas
larger
>> (slightly, but without a doubt, larger) than the WRF area because
the
>> user interface for the RTMA system only allows you to specify a
square
>> box (left lon, right lon, top lat, bottom lat) but the WRF domain
is
>> really not a true box in terms of lat/lon. By requesting the RTMA
for
>> a larger area, I ensure that my RTMA file will never be smaller
than
>> the WRF which is desirable for my purposes now and I don't have to
get
>> into the business of trying to guess at making a perfect match.
>>
>> Given the above: What would be the symptoms/problems of a situation
>> where I run Grid-Stat using an RTMA file for an area that was
slightly
>> larger than the WRF area? Would this be detrimental to good
practice?
>>
>> Thanks.
>>
>> R/
>> John
>>
>> -----Original Message-----
>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> Sent: Thursday, December 15, 2011 11:11 AM
>> To: Raby, John W USA CIV (US)
>> Cc: Kirby, Stephen F USA CIV (US)
>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>> (UNCLASSIFIED)
>>
>> John,
>>
>> Lots of questions in there!
>>
>> First, I'm glad you were able to get it working.
>>
>> Next, you mention that you ran Grid-Stat two times - once to score
>> over the full domain and a second time to score over a subset of
the
>> domain. I want to point out that you really only need to run
>> Grid-Stat once in this case. Just set up your config file with
something
>> like this:
>> mask_grid[] = [ "FULL" ];
>> mask_poly[] = [ "path/to/your/mask/poly" ];
>>
>> Each time you run Grid-Stat, it will compute statistics for *each*
of
>> the masking regions you specify. In this case, you'll see output
for
>> both the FULL domain and the polyline you've specified.
>>
>> Your next question - what does the FULL domain mean? Before
running
>> Grid-Stat, you have to put your forecast and observations onto a
common
>> grid.
>> When you tell the MET tools score over the "FULL"
>> domain, that means, just use all of those grid points on which the
>> data resides. Don't throw any of them out. The fact that you got
>> more matched pairs for the FULL domain than you got for the
polyline
>> subset makes complete sense.
>>
>> Because of the requirement that the data be on the same grid, every
>> time you run Grid-Stat, there will be values at each point in both
the
>> forecast and observation fields. But suppose that you started with
an
>> RTMA file whose domain did not fully cover your WRF domain. You'd
>> first need to run that RTMA file through copygb to put it onto the
WRF
>> grid. That step will result in a data file that have valid data in
>> the middle (where the RTMA was valid) surrounded by missing data
>> values around the edge (where there was no RTMA data). Now suppose
>> you run Grid-Stat to compare the RTMA to a WRF file, and tell it to
>> score over the FULL region. Grid-Stat will loop through the grid
>> looking at all the points (since we chose FULL), and it will get a
>> forecast/observation pair for each grid point. Because of the
missing
>> RTMA values around the edge, you'll end up with some matched pairs
>> where the observation is a missing value. And in that case, Grid-
Stat
>> won't
>> use those matched pairs - it'll toss them out, as it should.
>>
>> Generally, speaking when Point-Stat and Grid-Stat are run, the
first
>> step is to compute a bunch of forecast/observation matched pairs.
And
>> the next step is to throw out any matched pairs where either the
>> forecast or observation contains bad data. Then statistics are
>> computed over only those matched pairs with good data for both.
>>
>> That explanation is a long way of suggesting that when retrieving
RTMA
>> data, be sure it completely covers your WRF domain. And if you
have
>> an option on resolution of the RTMA data, choose one that most
closely
>> matches the resolution of your model run.
>>
>> Hope that helps.
>>
>> John
>>
>>
>>
>>
>> On 12/15/2011 10:50 AM, Raby, John W USA CIV via RT wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045 >
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> John -
>>>
>>> Steve Kirby implemented your solution below and it worked just as
you
>>> said!
>>> This information was invaluable for us to progress in our attempts
to
>>> use the RTMA product as a gridded observation data set.
>>>
>>> I have a question which came out of the testing I did this morning
>>> with Grid-Stat.
>>>
>>> I ran the Grid-Stat tests 2 ways which were both successful. The
>>> first was done assuming that the RTMA file was for a slightly
larger
>>> area than the Dugway, UT WRF forecast domain. I restricted the
>>> scoring to a subset of that area by using a mask_poly file to
define
>>> the geographic area according to the coordinates (lat/long
corners)
>>> of the Dugway WRF domain we have been using in the past. The
second
>>> test was done by removing the restriction and scoring over the
full
>>> area of the 2 grids.
>>>
>>> The TOTAL # of forecast-observation pairs for the first test was
>>> 10207 and for the second test was 10404. So it appears that by
>>> allowing Grid-Stat to score over the entire grid it actually
scored
>>> over a slightly larger area than was the case in the first test.
>>>
>>> I checked the User's Guide and it says that when you use a value
of
>>> "FULL" in the mask_grid variable it scores over the "entire grid
on
>>> which the data resides". Which grid are you talking about? I would
>>> assume that since you are trying to verify the forecast, that the
>>> grid used is the forecast grid, but I wanted to be sure.
>>>
>>> The implication is that if I specify the use of "FULL" vice using
a
>>> mask_poly file, that Grid-Stat will always score over that subset
of
>>> the gridded observation field and as long as you ensure that the
>>> gridded observation field is a larger area than you need, you will
>>> always get results.
>>>
>>> What would happen if the gridded observation dataset was over a
>>> smaller area than the forecast field and you specified "FULL" for
scoring?
>>>
>>> What I'm getting at is a way to decide what geographic size of
RTMA
>>> file I should download to make sure that I can just use the "FULL"
>>> scoring in the mask_grid variable and not worry about having to
>>> "guess" the actual size where scoring will occur unless I have a
>>> specific reason to focus in on a particular subset of the region.
>>>
>>> Thanks for all your help. This service is very helpful for MET
users.
>>> We rely on this service frequently for assistance in answering
>>> questions and resolving issues and have found it to be very
efficient
>>> and accurate with a high level of responsiveness.
>>>
>>> R/
>>> John
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> Sent: Wednesday, December 14, 2011 3:28 PM
>>> To: Raby, John W USA CIV (US)
>>> Cc: Kirby, Stephen F USA CIV (US)
>>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>>> (UNCLASSIFIED)
>>>
>>> John,
>>>
>>> I ran the following two wgrib commands on the data you sent to see
>>> what the grids are. I've included the grid definition information
>>> output from wgrib:
>>>
>>> % wgrib -d 1 -V WRFPRS_d02.00
>>> ...
>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
>>> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode
8 ...
>>>
>>> % wgrib -V -d 1 rtma_1km.grb1
>>> ...
>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.488000
>>> Latin1 25.000000 Latin2 25.000000 LatSP 0.000000 LonSP
0.000000
>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode
8 ...
>>>
>>> As you can see, while the grid dimensions are both 102x102, the
grid
>>> definition parameters differ a lot. So the arguments you're using
in
>>> your call to copygb need to be modified to make the rtma grid
exactly
>>> the same as the WRF grid.
>>>
>>> There is an example of doing this in the MET online tutorial here:
>>>
>>>
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.0/cop
>>> y
>>> gb/run3.php
>>>
>>> Using that website as an example, here's the grid definition
argument
>>> you should be using in your call to copygb:
>>> "255 3 NX NY STARTLAT STARTLON 8 CENLON DX DY 0 64
TRUELAT1
>>> TRUELAT2"
>>> "255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64 40135
>>> 40135"
>>>
>>> Next I ran the rtma file through copygb like this:
>>> % copygb -xg"255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64
>>> 40135 40135" rtma_1km.grb1 rtma_1km_regrid.grb1
>>>
>>> And checked to make sure that the grids match now:
>>> % wgrib -d 1 -V rtma_1km_regrid.grb1 ...
>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
>>> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64 mode
8 ...
>>>
>>> And they do. So that should solve your problem.
>>>
>>> Thanks,
>>> John
>>>
>>>
>>> On 12/14/2011 03:04 PM, Raby, John W USA CIV via RT wrote:
>>>>
>>>> Wed Dec 14 15:04:57 2011: Request 52045 was acted upon.
>>>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>>>> Queue: met_help
>>>> Subject: Request for assistance (UNCLASSIFIED)
>>>> Owner: Nobody
>>>> Requestors: john.w.raby2.civ at mail.mil
>>>> Status: new
>>>> Ticket <URL:
>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045
>>>>>
>>>>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>> We have been trying to run Grid-Stat using a 1km resolution WRF
>>>> forecast GRIB1 file (WRFPRS_d02.00)and an RTMA file
(rtma_1km.grb)
>>>> which we converted from GRIB2 to GRIB1 and then used copygb to
>>>> re-grid it to match the grid of the WRF.
>>>>
>>>> We are running into an ERROR which states that the forecast and
>>>> observation grids do not match.
>>>>
>>>> Could you take a look at the attached files to see if you can
>>>> diagnose the problem?
>>>>
>>>> Some details on how we are running Grid-Stat follow:
>>>>
>>>> grid_stat ../MET_WRFpostprd/${Start_Date}/WRFPRS_d02.00
>>>> ../MET_obs/RTMA/rtma_1km.grb1 ./GridStatConfig_m2o2_rtma -outdir
>>>> ./results_m2o2/${Start_Date} -v 2
>>>>
>>>> User specifies the Start_Date at the keyboard.
>>>>
>>>> The config file (GridStatConfig_m2o2_rtma) is attached. I use a
>>>> mask_poly file (DUGd02.poly, also attached) to make sure that the
>>>> scoring is done over the same geographic area as the WRF grid.
>>>>
>>>> The valid times/dates do not match, but this is just for testing.
>>>>
>>>> Thanks.
>>>>
>>>> R/
>>>> John
>>>>
>>>> Mr John W. Raby, Meteorologist
>>>> U.S. Army Research Laboratory
>>>> White Sands Missile Range, NM 88002
>>>> (575) 678-2004 DSN 258-2004
>>>> FAX (575) 678-1230 DSN 258-1230
>>>> Email: john.w.raby2.civ at mail.mil
>>>>
>>>>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>>
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>>
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
Classification: UNCLASSIFIED
Caveats: NONE
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance (UNCLASSIFIED)
From: John Halley Gotway
Time: Tue Jan 03 11:26:37 2012
Steve,
Yes, I would guess that would cause a problem as well. This is the
first grid definition I've seen that uses more precision than the
thousandths decimal place. I've always found the use on integers
in those grid definitions to be a bit awkward!
However, MET is still not able to read data in GRIB2 directly. It
must first be converted to GRIB1. We are working on GRIB2 support but
it is not ready yet. You may choose to convert the RTMA file
from GRIB2 to GRIB1 using the "cnvgrib" utility:
http://www.nco.ncep.noaa.gov/pmb/codes/GRIB2/
I would suggest first converting from GRIB2 to GRIB1, and then take a
look at the grid definition in the GRIB1 file. If it still uses more
than the thousandths place, you have a couple of options.
One option is to run that RTMA file through copygb to *slightly*
regrid the data to a grid definition that would work. Another option
is to modify the logic within MET to not require *exact* matching
of grids - you could choose to only ensure that the grid dimensions
(Nx and Ny) are the same. That would enable you to compare data that
one grids that are slightly different.
If you decide you'd like to pursue the latter option, let me know and
I can point you to the code that would need to change.
Hope that helps.
John
On 01/03/2012 11:12 AM, stephen.f.kirby.civ at mail.mil via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Hi John and the met_help folks,
>
> One question. In support of John Raby here, with whom you've been
conversing,
> I'm writing a script for re-gridding WRF from 1km resolution to
2.5km
> resolution to match a RTMA gridded observation file. This output
file will be
> utilized in Grid-Stat.
>
> The RTMA file that I need to match has dimensions as follows:
>
> [skirby at carson RTMA]$ wgrib2 -grid rtma2p5.t00z.2dvaranal_ndfd.grb2
> 1:0:grid_template=30:winds(grid):
> Lambert Conformal: (38 x 31) input WE:SN output WE:SN res 8
> Lat1 39.720561 Lon1 246.040860 LoV 265.000000
> LatD 25.000000 Latin1 25.000000 Latin2 25.000000
> LatSP -90.000000 LonSP 0.000000
> North Pole (38 x 31) Dx 2539.703000 m Dy 2539.703000 m mode
8
>
> But the problem I see is that, for example, the "Lat1" value has
non-zero
> digits beyond the thousandth's place. And copygb only accepts
integer values,
> so when you multiply by a thousand to get millidegrees you get
39720.561. At
> this point, do you round this to 39721, or do you truncate it to
39720?
> Neither one gives an exact match to the original RTMA dimensions
which makes
> me think Grid-Stat will complain. What do you recommend?
>
> Thanks for your advice,
> Steve
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Friday, December 16, 2011 10:32 AM
> To: Raby, John W USA CIV (US)
> Cc: Kirby, Stephen F USA CIV (US)
> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
(UNCLASSIFIED)
>
> That sounds great John.
>
> I'll go ahead and resolve this ticket. Just let us know if more
> questions/problems arise.
>
> Thanks,
> John
>
> On 12/16/2011 10:14 AM, Raby, John W USA CIV via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> John -
>>
>> Thanks for providing some answers to all my questions that last
couple of
>> days. We see this a breakthrough for us as we are trying to verify
our high
>> resolution WRF Nowcast model which has four dimensional data
assimilation
>> (WRF/FDDA). We need to augment our verification process which, up
to now,
>> has
>> just the traditional statistics from Point-Stat and Stat-Analysis
by adding
>> fuzzy and spatial verification techniques and have been stymied by
the lack
>> of
>> a gridded observation dataset until now.
>>
>> We hope to use the RTMA product to start using Grid-Stat for
neighborhood
>> (fuzzy) verification statistics and MODE for spatial verification.
We want
>> to
>> focus on "objects" defined by thresholds we set within the
continuous met
>> variable fields of temperature, dewpoint, and windspeed for now
since that
>> is
>> what the RTMA gives us. We want to see how well the model forecasts
these
>> "objects" when compared to the same objects in the RTMA
observations.
>>
>> By adding Grid-Stat and MODE assessments to traditional evaluations
we want
>> to
>> be able to tell the complete story about the performance of the
WRF/FDDA.
>>
>> R/
>> John
>>
>>
>> -----Original Message-----
>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> Sent: Friday, December 16, 2011 9:24 AM
>> To: Raby, John W USA CIV (US)
>> Cc: Kirby, Stephen F USA CIV (US)
>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
(UNCLASSIFIED)
>>
>> John,
>>
>> Yes, I'd recommend doing exactly what you describe - request RTMA
data on a
>> grid that fully encompasses your WRF domain. And you're correct to
realize
>> that differences in projection may require an RTMA grid slightly
larger than
>> your WRF grid. Just get the RTMA data and regrid it using copygb.
Then you
>> could use the IDV tool to display that regridded RTMA data and make
sure
>> there
>> aren't any strips of missing data along the edges. Or if you don't
use IDV,
>> you could just run the data through Grid-Stat, writing out the
matched pairs
>> file, and look at the matched pair output using the ncview utility
- and
>> check
>> that there isn't any missing data along the edges.
>>
>> So the process we described is to regrid the RTMA analysis to your
WRF grid
>> and verify over the model domain. Another option would be to go
the other
>> way - regrid your model data to an RTMA grid and verify over the
RTMA
>> domain.
>> There are arguments for doing it both ways.
>>
>> Generally, if you have the option of verifying on the forecast
domain or the
>> observation domain, you'd choose the one with the coarser
resolution. I
>> assume in your case that the RTMA data is on a coarser grid than
your model
>> data. When you interpolate from a coarser domain to a finer
domain, you're
>> kind of inventing a lot of data points. That being said, most
users just
>> want
>> to verify on their model domain using whatever observations are
available.
>> So
>> that what is often done I believe. For further detail on that
issue, I'd
>> refer you to Tressa.
>>
>> Thanks,
>> John
>>
>> On 12/15/2011 12:52 PM, Raby, John W USA CIV via RT wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> John -
>>>
>>> Very interesting. I find that I learn something new about MET
every
>>> time we have these exchanges. Thanks.
>>>
>>> Let's assume I take the tact of requesting RTMA files for areas
larger
>>> (slightly, but without a doubt, larger) than the WRF area because
the
>>> user interface for the RTMA system only allows you to specify a
square
>>> box (left lon, right lon, top lat, bottom lat) but the WRF domain
is
>>> really not a true box in terms of lat/lon. By requesting the RTMA
for
>>> a larger area, I ensure that my RTMA file will never be smaller
than
>>> the WRF which is desirable for my purposes now and I don't have to
get
>>> into the business of trying to guess at making a perfect match.
>>>
>>> Given the above: What would be the symptoms/problems of a
situation
>>> where I run Grid-Stat using an RTMA file for an area that was
slightly
>>> larger than the WRF area? Would this be detrimental to good
practice?
>>>
>>> Thanks.
>>>
>>> R/
>>> John
>>>
>>> -----Original Message-----
>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> Sent: Thursday, December 15, 2011 11:11 AM
>>> To: Raby, John W USA CIV (US)
>>> Cc: Kirby, Stephen F USA CIV (US)
>>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>>> (UNCLASSIFIED)
>>>
>>> John,
>>>
>>> Lots of questions in there!
>>>
>>> First, I'm glad you were able to get it working.
>>>
>>> Next, you mention that you ran Grid-Stat two times - once to score
>>> over the full domain and a second time to score over a subset of
the
>>> domain. I want to point out that you really only need to run
>>> Grid-Stat once in this case. Just set up your config file with
something
>>> like this:
>>> mask_grid[] = [ "FULL" ];
>>> mask_poly[] = [ "path/to/your/mask/poly" ];
>>>
>>> Each time you run Grid-Stat, it will compute statistics for *each*
of
>>> the masking regions you specify. In this case, you'll see output
for
>>> both the FULL domain and the polyline you've specified.
>>>
>>> Your next question - what does the FULL domain mean? Before
running
>>> Grid-Stat, you have to put your forecast and observations onto a
common
>>> grid.
>>> When you tell the MET tools score over the "FULL"
>>> domain, that means, just use all of those grid points on which the
>>> data resides. Don't throw any of them out. The fact that you got
>>> more matched pairs for the FULL domain than you got for the
polyline
>>> subset makes complete sense.
>>>
>>> Because of the requirement that the data be on the same grid,
every
>>> time you run Grid-Stat, there will be values at each point in both
the
>>> forecast and observation fields. But suppose that you started
with an
>>> RTMA file whose domain did not fully cover your WRF domain. You'd
>>> first need to run that RTMA file through copygb to put it onto the
WRF
>>> grid. That step will result in a data file that have valid data
in
>>> the middle (where the RTMA was valid) surrounded by missing data
>>> values around the edge (where there was no RTMA data). Now
suppose
>>> you run Grid-Stat to compare the RTMA to a WRF file, and tell it
to
>>> score over the FULL region. Grid-Stat will loop through the grid
>>> looking at all the points (since we chose FULL), and it will get a
>>> forecast/observation pair for each grid point. Because of the
missing
>>> RTMA values around the edge, you'll end up with some matched pairs
>>> where the observation is a missing value. And in that case, Grid-
Stat
>>> won't
>>> use those matched pairs - it'll toss them out, as it should.
>>>
>>> Generally, speaking when Point-Stat and Grid-Stat are run, the
first
>>> step is to compute a bunch of forecast/observation matched pairs.
And
>>> the next step is to throw out any matched pairs where either the
>>> forecast or observation contains bad data. Then statistics are
>>> computed over only those matched pairs with good data for both.
>>>
>>> That explanation is a long way of suggesting that when retrieving
RTMA
>>> data, be sure it completely covers your WRF domain. And if you
have
>>> an option on resolution of the RTMA data, choose one that most
closely
>>> matches the resolution of your model run.
>>>
>>> Hope that helps.
>>>
>>> John
>>>
>>>
>>>
>>>
>>> On 12/15/2011 10:50 AM, Raby, John W USA CIV via RT wrote:
>>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>> John -
>>>>
>>>> Steve Kirby implemented your solution below and it worked just as
you
>>>> said!
>>>> This information was invaluable for us to progress in our
attempts to
>>>> use the RTMA product as a gridded observation data set.
>>>>
>>>> I have a question which came out of the testing I did this
morning
>>>> with Grid-Stat.
>>>>
>>>> I ran the Grid-Stat tests 2 ways which were both successful. The
>>>> first was done assuming that the RTMA file was for a slightly
larger
>>>> area than the Dugway, UT WRF forecast domain. I restricted the
>>>> scoring to a subset of that area by using a mask_poly file to
define
>>>> the geographic area according to the coordinates (lat/long
corners)
>>>> of the Dugway WRF domain we have been using in the past. The
second
>>>> test was done by removing the restriction and scoring over the
full
>>>> area of the 2 grids.
>>>>
>>>> The TOTAL # of forecast-observation pairs for the first test was
>>>> 10207 and for the second test was 10404. So it appears that by
>>>> allowing Grid-Stat to score over the entire grid it actually
scored
>>>> over a slightly larger area than was the case in the first test.
>>>>
>>>> I checked the User's Guide and it says that when you use a value
of
>>>> "FULL" in the mask_grid variable it scores over the "entire grid
on
>>>> which the data resides". Which grid are you talking about? I
would
>>>> assume that since you are trying to verify the forecast, that the
>>>> grid used is the forecast grid, but I wanted to be sure.
>>>>
>>>> The implication is that if I specify the use of "FULL" vice using
a
>>>> mask_poly file, that Grid-Stat will always score over that subset
of
>>>> the gridded observation field and as long as you ensure that the
>>>> gridded observation field is a larger area than you need, you
will
>>>> always get results.
>>>>
>>>> What would happen if the gridded observation dataset was over a
>>>> smaller area than the forecast field and you specified "FULL" for
scoring?
>>>>
>>>> What I'm getting at is a way to decide what geographic size of
RTMA
>>>> file I should download to make sure that I can just use the
"FULL"
>>>> scoring in the mask_grid variable and not worry about having to
>>>> "guess" the actual size where scoring will occur unless I have a
>>>> specific reason to focus in on a particular subset of the region.
>>>>
>>>> Thanks for all your help. This service is very helpful for MET
users.
>>>> We rely on this service frequently for assistance in answering
>>>> questions and resolving issues and have found it to be very
efficient
>>>> and accurate with a high level of responsiveness.
>>>>
>>>> R/
>>>> John
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>>> Sent: Wednesday, December 14, 2011 3:28 PM
>>>> To: Raby, John W USA CIV (US)
>>>> Cc: Kirby, Stephen F USA CIV (US)
>>>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>>>> (UNCLASSIFIED)
>>>>
>>>> John,
>>>>
>>>> I ran the following two wgrib commands on the data you sent to
see
>>>> what the grids are. I've included the grid definition
information
>>>> output from wgrib:
>>>>
>>>> % wgrib -d 1 -V WRFPRS_d02.00
>>>> ...
>>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
>>>> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
>>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64
mode 8 ...
>>>>
>>>> % wgrib -V -d 1 rtma_1km.grb1
>>>> ...
>>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.488000
>>>> Latin1 25.000000 Latin2 25.000000 LatSP 0.000000 LonSP
0.000000
>>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64
mode 8 ...
>>>>
>>>> As you can see, while the grid dimensions are both 102x102, the
grid
>>>> definition parameters differ a lot. So the arguments you're
using in
>>>> your call to copygb need to be modified to make the rtma grid
exactly
>>>> the same as the WRF grid.
>>>>
>>>> There is an example of doing this in the MET online tutorial
here:
>>>>
>>>>
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.0/cop
>>>> y
>>>> gb/run3.php
>>>>
>>>> Using that website as an example, here's the grid definition
argument
>>>> you should be using in your call to copygb:
>>>> "255 3 NX NY STARTLAT STARTLON 8 CENLON DX DY 0 64
TRUELAT1
>>>> TRUELAT2"
>>>> "255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64
40135
>>>> 40135"
>>>>
>>>> Next I ran the rtma file through copygb like this:
>>>> % copygb -xg"255 3 102 102 39679 -114032 8 -113442 1000 1000 0
64
>>>> 40135 40135" rtma_1km.grb1 rtma_1km_regrid.grb1
>>>>
>>>> And checked to make sure that the grids match now:
>>>> % wgrib -d 1 -V rtma_1km_regrid.grb1 ...
>>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
>>>> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
>>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64
mode 8 ...
>>>>
>>>> And they do. So that should solve your problem.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>> On 12/14/2011 03:04 PM, Raby, John W USA CIV via RT wrote:
>>>>>
>>>>> Wed Dec 14 15:04:57 2011: Request 52045 was acted upon.
>>>>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>>>>> Queue: met_help
>>>>> Subject: Request for assistance (UNCLASSIFIED)
>>>>> Owner: Nobody
>>>>> Requestors: john.w.raby2.civ at mail.mil
>>>>> Status: new
>>>>> Ticket<URL:
>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045
>>>>>>
>>>>>
>>>>>
>>>>> Classification: UNCLASSIFIED
>>>>> Caveats: NONE
>>>>>
>>>>> We have been trying to run Grid-Stat using a 1km resolution WRF
>>>>> forecast GRIB1 file (WRFPRS_d02.00)and an RTMA file
(rtma_1km.grb)
>>>>> which we converted from GRIB2 to GRIB1 and then used copygb to
>>>>> re-grid it to match the grid of the WRF.
>>>>>
>>>>> We are running into an ERROR which states that the forecast and
>>>>> observation grids do not match.
>>>>>
>>>>> Could you take a look at the attached files to see if you can
>>>>> diagnose the problem?
>>>>>
>>>>> Some details on how we are running Grid-Stat follow:
>>>>>
>>>>> grid_stat ../MET_WRFpostprd/${Start_Date}/WRFPRS_d02.00
>>>>> ../MET_obs/RTMA/rtma_1km.grb1 ./GridStatConfig_m2o2_rtma
-outdir
>>>>> ./results_m2o2/${Start_Date} -v 2
>>>>>
>>>>> User specifies the Start_Date at the keyboard.
>>>>>
>>>>> The config file (GridStatConfig_m2o2_rtma) is attached. I use a
>>>>> mask_poly file (DUGd02.poly, also attached) to make sure that
the
>>>>> scoring is done over the same geographic area as the WRF grid.
>>>>>
>>>>> The valid times/dates do not match, but this is just for
testing.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> R/
>>>>> John
>>>>>
>>>>> Mr John W. Raby, Meteorologist
>>>>> U.S. Army Research Laboratory
>>>>> White Sands Missile Range, NM 88002
>>>>> (575) 678-2004 DSN 258-2004
>>>>> FAX (575) 678-1230 DSN 258-1230
>>>>> Email: john.w.raby2.civ at mail.mil
>>>>>
>>>>>
>>>>>
>>>>> Classification: UNCLASSIFIED
>>>>> Caveats: NONE
>>>>>
>>>>>
>>>>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>>
>>>>
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>>
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
------------------------------------------------
Subject: Request for assistance (UNCLASSIFIED)
From: Raby, John W USA CIV
Time: Tue Jan 03 11:35:09 2012
Classification: UNCLASSIFIED
Caveats: NONE
John -
The coordinates I chose for requesting the RTMA data were pretty
arbitrary,
just to assure that the area was slightly smaller than the WRF area.
Would it
help to re-request the RTMA file using a different, more smartly
chosen set of
coordinates which would avoid the problem you are seeing yet still be
for an
area slightly smaller than the WRF area?
R/
John
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Tuesday, January 03, 2012 11:27 AM
To: Raby, John W CIV (US)
Cc: Kirby, Stephen F CIV (US)
Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
(UNCLASSIFIED)
Steve,
Yes, I would guess that would cause a problem as well. This is the
first grid
definition I've seen that uses more precision than the thousandths
decimal
place. I've always found the use on integers in those grid
definitions to be
a bit awkward!
However, MET is still not able to read data in GRIB2 directly. It
must first
be converted to GRIB1. We are working on GRIB2 support but it is not
ready
yet. You may choose to convert the RTMA file from GRIB2 to GRIB1
using the
"cnvgrib" utility:
http://www.nco.ncep.noaa.gov/pmb/codes/GRIB2/
I would suggest first converting from GRIB2 to GRIB1, and then take a
look at
the grid definition in the GRIB1 file. If it still uses more than the
thousandths place, you have a couple of options.
One option is to run that RTMA file through copygb to *slightly*
regrid the
data to a grid definition that would work. Another option is to
modify the
logic within MET to not require *exact* matching of grids - you could
choose
to only ensure that the grid dimensions (Nx and Ny) are the same.
That would
enable you to compare data that one grids that are slightly different.
If you decide you'd like to pursue the latter option, let me know and
I can
point you to the code that would need to change.
Hope that helps.
John
On 01/03/2012 11:12 AM, stephen.f.kirby.civ at mail.mil via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Hi John and the met_help folks,
>
> One question. In support of John Raby here, with whom you've been
> conversing, I'm writing a script for re-gridding WRF from 1km
> resolution to 2.5km resolution to match a RTMA gridded observation
> file. This output file will be utilized in Grid-Stat.
>
> The RTMA file that I need to match has dimensions as follows:
>
> [skirby at carson RTMA]$ wgrib2 -grid rtma2p5.t00z.2dvaranal_ndfd.grb2
> 1:0:grid_template=30:winds(grid):
> Lambert Conformal: (38 x 31) input WE:SN output WE:SN res 8
> Lat1 39.720561 Lon1 246.040860 LoV 265.000000
> LatD 25.000000 Latin1 25.000000 Latin2 25.000000
> LatSP -90.000000 LonSP 0.000000
> North Pole (38 x 31) Dx 2539.703000 m Dy 2539.703000 m mode
8
>
> But the problem I see is that, for example, the "Lat1" value has
> non-zero digits beyond the thousandth's place. And copygb only
> accepts integer values, so when you multiply by a thousand to get
> millidegrees you get 39720.561. At this point, do you round this to
39721,
> or do you truncate it to 39720?
> Neither one gives an exact match to the original RTMA dimensions
which
> makes me think Grid-Stat will complain. What do you recommend?
>
> Thanks for your advice,
> Steve
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Friday, December 16, 2011 10:32 AM
> To: Raby, John W USA CIV (US)
> Cc: Kirby, Stephen F USA CIV (US)
> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
> (UNCLASSIFIED)
>
> That sounds great John.
>
> I'll go ahead and resolve this ticket. Just let us know if more
> questions/problems arise.
>
> Thanks,
> John
>
> On 12/16/2011 10:14 AM, Raby, John W USA CIV via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> John -
>>
>> Thanks for providing some answers to all my questions that last
>> couple of days. We see this a breakthrough for us as we are trying
to
>> verify our high resolution WRF Nowcast model which has four
>> dimensional data assimilation (WRF/FDDA). We need to augment our
>> verification process which, up to now, has just the traditional
>> statistics from Point-Stat and Stat-Analysis by adding fuzzy and
>> spatial verification techniques and have been stymied by the lack
of
>> a gridded observation dataset until now.
>>
>> We hope to use the RTMA product to start using Grid-Stat for
>> neighborhood
>> (fuzzy) verification statistics and MODE for spatial verification.
We
>> want to focus on "objects" defined by thresholds we set within the
>> continuous met variable fields of temperature, dewpoint, and
>> windspeed for now since that is what the RTMA gives us. We want to
>> see how well the model forecasts these "objects" when compared to
the
>> same objects in the RTMA observations.
>>
>> By adding Grid-Stat and MODE assessments to traditional evaluations
>> we want to be able to tell the complete story about the performance
>> of the WRF/FDDA.
>>
>> R/
>> John
>>
>>
>> -----Original Message-----
>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> Sent: Friday, December 16, 2011 9:24 AM
>> To: Raby, John W USA CIV (US)
>> Cc: Kirby, Stephen F USA CIV (US)
>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>> (UNCLASSIFIED)
>>
>> John,
>>
>> Yes, I'd recommend doing exactly what you describe - request RTMA
>> data on a grid that fully encompasses your WRF domain. And you're
>> correct to realize that differences in projection may require an
RTMA
>> grid slightly larger than your WRF grid. Just get the RTMA data
and
>> regrid it using copygb. Then you could use the IDV tool to display
>> that regridded RTMA data and make sure there aren't any strips of
>> missing data along the edges. Or if you don't use IDV, you could
>> just run the data through Grid-Stat, writing out the matched pairs
>> file, and look at the matched pair output using the ncview utility
-
>> and check that there isn't any missing data along the edges.
>>
>> So the process we described is to regrid the RTMA analysis to your
>> WRF grid and verify over the model domain. Another option would be
>> to go the other way - regrid your model data to an RTMA grid and
>> verify over the RTMA domain.
>> There are arguments for doing it both ways.
>>
>> Generally, if you have the option of verifying on the forecast
domain
>> or the observation domain, you'd choose the one with the coarser
>> resolution. I assume in your case that the RTMA data is on a
coarser
>> grid than your model data. When you interpolate from a coarser
>> domain to a finer domain, you're kind of inventing a lot of data
>> points. That being said, most users just want to verify on their
>> model domain using whatever observations are available.
>> So
>> that what is often done I believe. For further detail on that
issue,
>> I'd refer you to Tressa.
>>
>> Thanks,
>> John
>>
>> On 12/15/2011 12:52 PM, Raby, John W USA CIV via RT wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> John -
>>>
>>> Very interesting. I find that I learn something new about MET
every
>>> time we have these exchanges. Thanks.
>>>
>>> Let's assume I take the tact of requesting RTMA files for areas
>>> larger (slightly, but without a doubt, larger) than the WRF area
>>> because the user interface for the RTMA system only allows you to
>>> specify a square box (left lon, right lon, top lat, bottom lat)
but
>>> the WRF domain is really not a true box in terms of lat/lon. By
>>> requesting the RTMA for a larger area, I ensure that my RTMA file
>>> will never be smaller than the WRF which is desirable for my
>>> purposes now and I don't have to get into the business of trying
to guess
>>> at making a perfect match.
>>>
>>> Given the above: What would be the symptoms/problems of a
situation
>>> where I run Grid-Stat using an RTMA file for an area that was
>>> slightly larger than the WRF area? Would this be detrimental to
good
>>> practice?
>>>
>>> Thanks.
>>>
>>> R/
>>> John
>>>
>>> -----Original Message-----
>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> Sent: Thursday, December 15, 2011 11:11 AM
>>> To: Raby, John W USA CIV (US)
>>> Cc: Kirby, Stephen F USA CIV (US)
>>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>>> (UNCLASSIFIED)
>>>
>>> John,
>>>
>>> Lots of questions in there!
>>>
>>> First, I'm glad you were able to get it working.
>>>
>>> Next, you mention that you ran Grid-Stat two times - once to score
>>> over the full domain and a second time to score over a subset of
the
>>> domain. I want to point out that you really only need to run
>>> Grid-Stat once in this case. Just set up your config file with
>>> something like this:
>>> mask_grid[] = [ "FULL" ];
>>> mask_poly[] = [ "path/to/your/mask/poly" ];
>>>
>>> Each time you run Grid-Stat, it will compute statistics for *each*
>>> of the masking regions you specify. In this case, you'll see
output
>>> for both the FULL domain and the polyline you've specified.
>>>
>>> Your next question - what does the FULL domain mean? Before
running
>>> Grid-Stat, you have to put your forecast and observations onto a
>>> common grid.
>>> When you tell the MET tools score over the "FULL"
>>> domain, that means, just use all of those grid points on which the
>>> data resides. Don't throw any of them out. The fact that you got
>>> more matched pairs for the FULL domain than you got for the
polyline
>>> subset makes complete sense.
>>>
>>> Because of the requirement that the data be on the same grid,
every
>>> time you run Grid-Stat, there will be values at each point in both
>>> the forecast and observation fields. But suppose that you started
>>> with an RTMA file whose domain did not fully cover your WRF
domain.
>>> You'd first need to run that RTMA file through copygb to put it
onto
>>> the WRF grid. That step will result in a data file that have
valid
>>> data in the middle (where the RTMA was valid) surrounded by
missing
>>> data values around the edge (where there was no RTMA data). Now
>>> suppose you run Grid-Stat to compare the RTMA to a WRF file, and
>>> tell it to score over the FULL region. Grid-Stat will loop
through
>>> the grid looking at all the points (since we chose FULL), and it
>>> will get a forecast/observation pair for each grid point. Because
>>> of the missing RTMA values around the edge, you'll end up with
some
>>> matched pairs where the observation is a missing value. And in
that
>>> case, Grid-Stat won't use those matched pairs - it'll toss them
out,
>>> as it should.
>>>
>>> Generally, speaking when Point-Stat and Grid-Stat are run, the
first
>>> step is to compute a bunch of forecast/observation matched pairs.
>>> And the next step is to throw out any matched pairs where either
the
>>> forecast or observation contains bad data. Then statistics are
>>> computed over only those matched pairs with good data for both.
>>>
>>> That explanation is a long way of suggesting that when retrieving
>>> RTMA data, be sure it completely covers your WRF domain. And if
you
>>> have an option on resolution of the RTMA data, choose one that
most
>>> closely matches the resolution of your model run.
>>>
>>> Hope that helps.
>>>
>>> John
>>>
>>>
>>>
>>>
>>> On 12/15/2011 10:50 AM, Raby, John W USA CIV via RT wrote:
>>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>> John -
>>>>
>>>> Steve Kirby implemented your solution below and it worked just as
>>>> you said!
>>>> This information was invaluable for us to progress in our
attempts
>>>> to use the RTMA product as a gridded observation data set.
>>>>
>>>> I have a question which came out of the testing I did this
morning
>>>> with Grid-Stat.
>>>>
>>>> I ran the Grid-Stat tests 2 ways which were both successful. The
>>>> first was done assuming that the RTMA file was for a slightly
>>>> larger area than the Dugway, UT WRF forecast domain. I restricted
>>>> the scoring to a subset of that area by using a mask_poly file to
>>>> define the geographic area according to the coordinates (lat/long
>>>> corners) of the Dugway WRF domain we have been using in the past.
>>>> The second test was done by removing the restriction and scoring
>>>> over the full area of the 2 grids.
>>>>
>>>> The TOTAL # of forecast-observation pairs for the first test was
>>>> 10207 and for the second test was 10404. So it appears that by
>>>> allowing Grid-Stat to score over the entire grid it actually
scored
>>>> over a slightly larger area than was the case in the first test.
>>>>
>>>> I checked the User's Guide and it says that when you use a value
of
>>>> "FULL" in the mask_grid variable it scores over the "entire grid
on
>>>> which the data resides". Which grid are you talking about? I
would
>>>> assume that since you are trying to verify the forecast, that the
>>>> grid used is the forecast grid, but I wanted to be sure.
>>>>
>>>> The implication is that if I specify the use of "FULL" vice using
a
>>>> mask_poly file, that Grid-Stat will always score over that subset
>>>> of the gridded observation field and as long as you ensure that
the
>>>> gridded observation field is a larger area than you need, you
will
>>>> always get results.
>>>>
>>>> What would happen if the gridded observation dataset was over a
>>>> smaller area than the forecast field and you specified "FULL" for
>>>> scoring?
>>>>
>>>> What I'm getting at is a way to decide what geographic size of
RTMA
>>>> file I should download to make sure that I can just use the
"FULL"
>>>> scoring in the mask_grid variable and not worry about having to
>>>> "guess" the actual size where scoring will occur unless I have a
>>>> specific reason to focus in on a particular subset of the region.
>>>>
>>>> Thanks for all your help. This service is very helpful for MET
users.
>>>> We rely on this service frequently for assistance in answering
>>>> questions and resolving issues and have found it to be very
>>>> efficient and accurate with a high level of responsiveness.
>>>>
>>>> R/
>>>> John
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>>> Sent: Wednesday, December 14, 2011 3:28 PM
>>>> To: Raby, John W USA CIV (US)
>>>> Cc: Kirby, Stephen F USA CIV (US)
>>>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>>>> (UNCLASSIFIED)
>>>>
>>>> John,
>>>>
>>>> I ran the following two wgrib commands on the data you sent to
see
>>>> what the grids are. I've included the grid definition
information
>>>> output from wgrib:
>>>>
>>>> % wgrib -d 1 -V WRFPRS_d02.00
>>>> ...
>>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
>>>> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
>>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64
mode 8 ...
>>>>
>>>> % wgrib -V -d 1 rtma_1km.grb1
>>>> ...
>>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.488000
>>>> Latin1 25.000000 Latin2 25.000000 LatSP 0.000000 LonSP
0.000000
>>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64
mode 8 ...
>>>>
>>>> As you can see, while the grid dimensions are both 102x102, the
>>>> grid definition parameters differ a lot. So the arguments you're
>>>> using in your call to copygb need to be modified to make the rtma
>>>> grid exactly the same as the WRF grid.
>>>>
>>>> There is an example of doing this in the MET online tutorial
here:
>>>>
>>>>
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.0/c
>>>> op
>>>> y
>>>> gb/run3.php
>>>>
>>>> Using that website as an example, here's the grid definition
>>>> argument you should be using in your call to copygb:
>>>> "255 3 NX NY STARTLAT STARTLON 8 CENLON DX DY 0 64
TRUELAT1
>>>> TRUELAT2"
>>>> "255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64
40135
>>>> 40135"
>>>>
>>>> Next I ran the rtma file through copygb like this:
>>>> % copygb -xg"255 3 102 102 39679 -114032 8 -113442 1000 1000 0
64
>>>> 40135 40135" rtma_1km.grb1 rtma_1km_regrid.grb1
>>>>
>>>> And checked to make sure that the grids match now:
>>>> % wgrib -d 1 -V rtma_1km_regrid.grb1 ...
>>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
>>>> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
>>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64
mode 8 ...
>>>>
>>>> And they do. So that should solve your problem.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>> On 12/14/2011 03:04 PM, Raby, John W USA CIV via RT wrote:
>>>>>
>>>>> Wed Dec 14 15:04:57 2011: Request 52045 was acted upon.
>>>>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>>>>> Queue: met_help
>>>>> Subject: Request for assistance (UNCLASSIFIED)
>>>>> Owner: Nobody
>>>>> Requestors: john.w.raby2.civ at mail.mil
>>>>> Status: new
>>>>> Ticket<URL:
>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045
>>>>>>
>>>>>
>>>>>
>>>>> Classification: UNCLASSIFIED
>>>>> Caveats: NONE
>>>>>
>>>>> We have been trying to run Grid-Stat using a 1km resolution WRF
>>>>> forecast GRIB1 file (WRFPRS_d02.00)and an RTMA file
(rtma_1km.grb)
>>>>> which we converted from GRIB2 to GRIB1 and then used copygb to
>>>>> re-grid it to match the grid of the WRF.
>>>>>
>>>>> We are running into an ERROR which states that the forecast and
>>>>> observation grids do not match.
>>>>>
>>>>> Could you take a look at the attached files to see if you can
>>>>> diagnose the problem?
>>>>>
>>>>> Some details on how we are running Grid-Stat follow:
>>>>>
>>>>> grid_stat ../MET_WRFpostprd/${Start_Date}/WRFPRS_d02.00
>>>>> ../MET_obs/RTMA/rtma_1km.grb1 ./GridStatConfig_m2o2_rtma
-outdir
>>>>> ./results_m2o2/${Start_Date} -v 2
>>>>>
>>>>> User specifies the Start_Date at the keyboard.
>>>>>
>>>>> The config file (GridStatConfig_m2o2_rtma) is attached. I use a
>>>>> mask_poly file (DUGd02.poly, also attached) to make sure that
the
>>>>> scoring is done over the same geographic area as the WRF grid.
>>>>>
>>>>> The valid times/dates do not match, but this is just for
testing.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> R/
>>>>> John
>>>>>
>>>>> Mr John W. Raby, Meteorologist
>>>>> U.S. Army Research Laboratory
>>>>> White Sands Missile Range, NM 88002
>>>>> (575) 678-2004 DSN 258-2004
>>>>> FAX (575) 678-1230 DSN 258-1230
>>>>> Email: john.w.raby2.civ at mail.mil
>>>>>
>>>>>
>>>>>
>>>>> Classification: UNCLASSIFIED
>>>>> Caveats: NONE
>>>>>
>>>>>
>>>>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>>
>>>>
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>>
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
Classification: UNCLASSIFIED
Caveats: NONE
------------------------------------------------
Subject: Request for assistance (UNCLASSIFIED)
From: stephen.f.kirby.civ at mail.mil
Time: Tue Jan 03 11:39:23 2012
Classification: UNCLASSIFIED
Caveats: NONE
John,
Indeed when you convert the data to GRIB1, it does eliminate the
problem of
digits beyond the thousandth's place. Thanks for pointing that out.
--Steve
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Tuesday, January 03, 2012 11:27 AM
To: Raby, John W CIV (US)
Cc: Kirby, Stephen F CIV (US)
Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
(UNCLASSIFIED)
Steve,
Yes, I would guess that would cause a problem as well. This is the
first grid
definition I've seen that uses more precision than the thousandths
decimal
place. I've always found the use on integers in those grid
definitions to be
a bit awkward!
However, MET is still not able to read data in GRIB2 directly. It
must first
be converted to GRIB1. We are working on GRIB2 support but it is not
ready
yet. You may choose to convert the RTMA file from GRIB2 to GRIB1
using the
"cnvgrib" utility:
http://www.nco.ncep.noaa.gov/pmb/codes/GRIB2/
I would suggest first converting from GRIB2 to GRIB1, and then take a
look at
the grid definition in the GRIB1 file. If it still uses more than the
thousandths place, you have a couple of options.
One option is to run that RTMA file through copygb to *slightly*
regrid the
data to a grid definition that would work. Another option is to
modify the
logic within MET to not require *exact* matching of grids - you could
choose
to only ensure that the grid dimensions (Nx and Ny) are the same.
That would
enable you to compare data that one grids that are slightly different.
If you decide you'd like to pursue the latter option, let me know and
I can
point you to the code that would need to change.
Hope that helps.
John
On 01/03/2012 11:12 AM, stephen.f.kirby.civ at mail.mil via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Hi John and the met_help folks,
>
> One question. In support of John Raby here, with whom you've been
> conversing, I'm writing a script for re-gridding WRF from 1km
> resolution to 2.5km resolution to match a RTMA gridded observation
> file. This output file will be utilized in Grid-Stat.
>
> The RTMA file that I need to match has dimensions as follows:
>
> [skirby at carson RTMA]$ wgrib2 -grid rtma2p5.t00z.2dvaranal_ndfd.grb2
> 1:0:grid_template=30:winds(grid):
> Lambert Conformal: (38 x 31) input WE:SN output WE:SN res 8
> Lat1 39.720561 Lon1 246.040860 LoV 265.000000
> LatD 25.000000 Latin1 25.000000 Latin2 25.000000
> LatSP -90.000000 LonSP 0.000000
> North Pole (38 x 31) Dx 2539.703000 m Dy 2539.703000 m mode
8
>
> But the problem I see is that, for example, the "Lat1" value has
> non-zero digits beyond the thousandth's place. And copygb only
> accepts integer values, so when you multiply by a thousand to get
> millidegrees you get 39720.561. At this point, do you round this to
39721,
> or do you truncate it to 39720?
> Neither one gives an exact match to the original RTMA dimensions
which
> makes me think Grid-Stat will complain. What do you recommend?
>
> Thanks for your advice,
> Steve
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Friday, December 16, 2011 10:32 AM
> To: Raby, John W USA CIV (US)
> Cc: Kirby, Stephen F USA CIV (US)
> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
> (UNCLASSIFIED)
>
> That sounds great John.
>
> I'll go ahead and resolve this ticket. Just let us know if more
> questions/problems arise.
>
> Thanks,
> John
>
> On 12/16/2011 10:14 AM, Raby, John W USA CIV via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> John -
>>
>> Thanks for providing some answers to all my questions that last
>> couple of days. We see this a breakthrough for us as we are trying
to
>> verify our high resolution WRF Nowcast model which has four
>> dimensional data assimilation (WRF/FDDA). We need to augment our
>> verification process which, up to now, has just the traditional
>> statistics from Point-Stat and Stat-Analysis by adding fuzzy and
>> spatial verification techniques and have been stymied by the lack
of
>> a gridded observation dataset until now.
>>
>> We hope to use the RTMA product to start using Grid-Stat for
>> neighborhood
>> (fuzzy) verification statistics and MODE for spatial verification.
We
>> want to focus on "objects" defined by thresholds we set within the
>> continuous met variable fields of temperature, dewpoint, and
>> windspeed for now since that is what the RTMA gives us. We want to
>> see how well the model forecasts these "objects" when compared to
the
>> same objects in the RTMA observations.
>>
>> By adding Grid-Stat and MODE assessments to traditional evaluations
>> we want to be able to tell the complete story about the performance
>> of the WRF/FDDA.
>>
>> R/
>> John
>>
>>
>> -----Original Message-----
>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> Sent: Friday, December 16, 2011 9:24 AM
>> To: Raby, John W USA CIV (US)
>> Cc: Kirby, Stephen F USA CIV (US)
>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>> (UNCLASSIFIED)
>>
>> John,
>>
>> Yes, I'd recommend doing exactly what you describe - request RTMA
>> data on a grid that fully encompasses your WRF domain. And you're
>> correct to realize that differences in projection may require an
RTMA
>> grid slightly larger than your WRF grid. Just get the RTMA data
and
>> regrid it using copygb. Then you could use the IDV tool to display
>> that regridded RTMA data and make sure there aren't any strips of
>> missing data along the edges. Or if you don't use IDV, you could
>> just run the data through Grid-Stat, writing out the matched pairs
>> file, and look at the matched pair output using the ncview utility
-
>> and check that there isn't any missing data along the edges.
>>
>> So the process we described is to regrid the RTMA analysis to your
>> WRF grid and verify over the model domain. Another option would be
>> to go the other way - regrid your model data to an RTMA grid and
>> verify over the RTMA domain.
>> There are arguments for doing it both ways.
>>
>> Generally, if you have the option of verifying on the forecast
domain
>> or the observation domain, you'd choose the one with the coarser
>> resolution. I assume in your case that the RTMA data is on a
coarser
>> grid than your model data. When you interpolate from a coarser
>> domain to a finer domain, you're kind of inventing a lot of data
>> points. That being said, most users just want to verify on their
>> model domain using whatever observations are available.
>> So
>> that what is often done I believe. For further detail on that
issue,
>> I'd refer you to Tressa.
>>
>> Thanks,
>> John
>>
>> On 12/15/2011 12:52 PM, Raby, John W USA CIV via RT wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> John -
>>>
>>> Very interesting. I find that I learn something new about MET
every
>>> time we have these exchanges. Thanks.
>>>
>>> Let's assume I take the tact of requesting RTMA files for areas
>>> larger (slightly, but without a doubt, larger) than the WRF area
>>> because the user interface for the RTMA system only allows you to
>>> specify a square box (left lon, right lon, top lat, bottom lat)
but
>>> the WRF domain is really not a true box in terms of lat/lon. By
>>> requesting the RTMA for a larger area, I ensure that my RTMA file
>>> will never be smaller than the WRF which is desirable for my
>>> purposes now and I don't have to get into the business of trying
to guess
>>> at making a perfect match.
>>>
>>> Given the above: What would be the symptoms/problems of a
situation
>>> where I run Grid-Stat using an RTMA file for an area that was
>>> slightly larger than the WRF area? Would this be detrimental to
good
>>> practice?
>>>
>>> Thanks.
>>>
>>> R/
>>> John
>>>
>>> -----Original Message-----
>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> Sent: Thursday, December 15, 2011 11:11 AM
>>> To: Raby, John W USA CIV (US)
>>> Cc: Kirby, Stephen F USA CIV (US)
>>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>>> (UNCLASSIFIED)
>>>
>>> John,
>>>
>>> Lots of questions in there!
>>>
>>> First, I'm glad you were able to get it working.
>>>
>>> Next, you mention that you ran Grid-Stat two times - once to score
>>> over the full domain and a second time to score over a subset of
the
>>> domain. I want to point out that you really only need to run
>>> Grid-Stat once in this case. Just set up your config file with
>>> something like this:
>>> mask_grid[] = [ "FULL" ];
>>> mask_poly[] = [ "path/to/your/mask/poly" ];
>>>
>>> Each time you run Grid-Stat, it will compute statistics for *each*
>>> of the masking regions you specify. In this case, you'll see
output
>>> for both the FULL domain and the polyline you've specified.
>>>
>>> Your next question - what does the FULL domain mean? Before
running
>>> Grid-Stat, you have to put your forecast and observations onto a
>>> common grid.
>>> When you tell the MET tools score over the "FULL"
>>> domain, that means, just use all of those grid points on which the
>>> data resides. Don't throw any of them out. The fact that you got
>>> more matched pairs for the FULL domain than you got for the
polyline
>>> subset makes complete sense.
>>>
>>> Because of the requirement that the data be on the same grid,
every
>>> time you run Grid-Stat, there will be values at each point in both
>>> the forecast and observation fields. But suppose that you started
>>> with an RTMA file whose domain did not fully cover your WRF
domain.
>>> You'd first need to run that RTMA file through copygb to put it
onto
>>> the WRF grid. That step will result in a data file that have
valid
>>> data in the middle (where the RTMA was valid) surrounded by
missing
>>> data values around the edge (where there was no RTMA data). Now
>>> suppose you run Grid-Stat to compare the RTMA to a WRF file, and
>>> tell it to score over the FULL region. Grid-Stat will loop
through
>>> the grid looking at all the points (since we chose FULL), and it
>>> will get a forecast/observation pair for each grid point. Because
>>> of the missing RTMA values around the edge, you'll end up with
some
>>> matched pairs where the observation is a missing value. And in
that
>>> case, Grid-Stat won't use those matched pairs - it'll toss them
out,
>>> as it should.
>>>
>>> Generally, speaking when Point-Stat and Grid-Stat are run, the
first
>>> step is to compute a bunch of forecast/observation matched pairs.
>>> And the next step is to throw out any matched pairs where either
the
>>> forecast or observation contains bad data. Then statistics are
>>> computed over only those matched pairs with good data for both.
>>>
>>> That explanation is a long way of suggesting that when retrieving
>>> RTMA data, be sure it completely covers your WRF domain. And if
you
>>> have an option on resolution of the RTMA data, choose one that
most
>>> closely matches the resolution of your model run.
>>>
>>> Hope that helps.
>>>
>>> John
>>>
>>>
>>>
>>>
>>> On 12/15/2011 10:50 AM, Raby, John W USA CIV via RT wrote:
>>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>> John -
>>>>
>>>> Steve Kirby implemented your solution below and it worked just as
>>>> you said!
>>>> This information was invaluable for us to progress in our
attempts
>>>> to use the RTMA product as a gridded observation data set.
>>>>
>>>> I have a question which came out of the testing I did this
morning
>>>> with Grid-Stat.
>>>>
>>>> I ran the Grid-Stat tests 2 ways which were both successful. The
>>>> first was done assuming that the RTMA file was for a slightly
>>>> larger area than the Dugway, UT WRF forecast domain. I restricted
>>>> the scoring to a subset of that area by using a mask_poly file to
>>>> define the geographic area according to the coordinates (lat/long
>>>> corners) of the Dugway WRF domain we have been using in the past.
>>>> The second test was done by removing the restriction and scoring
>>>> over the full area of the 2 grids.
>>>>
>>>> The TOTAL # of forecast-observation pairs for the first test was
>>>> 10207 and for the second test was 10404. So it appears that by
>>>> allowing Grid-Stat to score over the entire grid it actually
scored
>>>> over a slightly larger area than was the case in the first test.
>>>>
>>>> I checked the User's Guide and it says that when you use a value
of
>>>> "FULL" in the mask_grid variable it scores over the "entire grid
on
>>>> which the data resides". Which grid are you talking about? I
would
>>>> assume that since you are trying to verify the forecast, that the
>>>> grid used is the forecast grid, but I wanted to be sure.
>>>>
>>>> The implication is that if I specify the use of "FULL" vice using
a
>>>> mask_poly file, that Grid-Stat will always score over that subset
>>>> of the gridded observation field and as long as you ensure that
the
>>>> gridded observation field is a larger area than you need, you
will
>>>> always get results.
>>>>
>>>> What would happen if the gridded observation dataset was over a
>>>> smaller area than the forecast field and you specified "FULL" for
>>>> scoring?
>>>>
>>>> What I'm getting at is a way to decide what geographic size of
RTMA
>>>> file I should download to make sure that I can just use the
"FULL"
>>>> scoring in the mask_grid variable and not worry about having to
>>>> "guess" the actual size where scoring will occur unless I have a
>>>> specific reason to focus in on a particular subset of the region.
>>>>
>>>> Thanks for all your help. This service is very helpful for MET
users.
>>>> We rely on this service frequently for assistance in answering
>>>> questions and resolving issues and have found it to be very
>>>> efficient and accurate with a high level of responsiveness.
>>>>
>>>> R/
>>>> John
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>>> Sent: Wednesday, December 14, 2011 3:28 PM
>>>> To: Raby, John W USA CIV (US)
>>>> Cc: Kirby, Stephen F USA CIV (US)
>>>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>>>> (UNCLASSIFIED)
>>>>
>>>> John,
>>>>
>>>> I ran the following two wgrib commands on the data you sent to
see
>>>> what the grids are. I've included the grid definition
information
>>>> output from wgrib:
>>>>
>>>> % wgrib -d 1 -V WRFPRS_d02.00
>>>> ...
>>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
>>>> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
>>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64
mode 8 ...
>>>>
>>>> % wgrib -V -d 1 rtma_1km.grb1
>>>> ...
>>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.488000
>>>> Latin1 25.000000 Latin2 25.000000 LatSP 0.000000 LonSP
0.000000
>>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64
mode 8 ...
>>>>
>>>> As you can see, while the grid dimensions are both 102x102, the
>>>> grid definition parameters differ a lot. So the arguments you're
>>>> using in your call to copygb need to be modified to make the rtma
>>>> grid exactly the same as the WRF grid.
>>>>
>>>> There is an example of doing this in the MET online tutorial
here:
>>>>
>>>>
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.0/c
>>>> op
>>>> y
>>>> gb/run3.php
>>>>
>>>> Using that website as an example, here's the grid definition
>>>> argument you should be using in your call to copygb:
>>>> "255 3 NX NY STARTLAT STARTLON 8 CENLON DX DY 0 64
TRUELAT1
>>>> TRUELAT2"
>>>> "255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64
40135
>>>> 40135"
>>>>
>>>> Next I ran the rtma file through copygb like this:
>>>> % copygb -xg"255 3 102 102 39679 -114032 8 -113442 1000 1000 0
64
>>>> 40135 40135" rtma_1km.grb1 rtma_1km_regrid.grb1
>>>>
>>>> And checked to make sure that the grids match now:
>>>> % wgrib -d 1 -V rtma_1km_regrid.grb1 ...
>>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov -113.442000
>>>> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
>>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64
mode 8 ...
>>>>
>>>> And they do. So that should solve your problem.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>> On 12/14/2011 03:04 PM, Raby, John W USA CIV via RT wrote:
>>>>>
>>>>> Wed Dec 14 15:04:57 2011: Request 52045 was acted upon.
>>>>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>>>>> Queue: met_help
>>>>> Subject: Request for assistance (UNCLASSIFIED)
>>>>> Owner: Nobody
>>>>> Requestors: john.w.raby2.civ at mail.mil
>>>>> Status: new
>>>>> Ticket<URL:
>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045
>>>>>>
>>>>>
>>>>>
>>>>> Classification: UNCLASSIFIED
>>>>> Caveats: NONE
>>>>>
>>>>> We have been trying to run Grid-Stat using a 1km resolution WRF
>>>>> forecast GRIB1 file (WRFPRS_d02.00)and an RTMA file
(rtma_1km.grb)
>>>>> which we converted from GRIB2 to GRIB1 and then used copygb to
>>>>> re-grid it to match the grid of the WRF.
>>>>>
>>>>> We are running into an ERROR which states that the forecast and
>>>>> observation grids do not match.
>>>>>
>>>>> Could you take a look at the attached files to see if you can
>>>>> diagnose the problem?
>>>>>
>>>>> Some details on how we are running Grid-Stat follow:
>>>>>
>>>>> grid_stat ../MET_WRFpostprd/${Start_Date}/WRFPRS_d02.00
>>>>> ../MET_obs/RTMA/rtma_1km.grb1 ./GridStatConfig_m2o2_rtma
-outdir
>>>>> ./results_m2o2/${Start_Date} -v 2
>>>>>
>>>>> User specifies the Start_Date at the keyboard.
>>>>>
>>>>> The config file (GridStatConfig_m2o2_rtma) is attached. I use a
>>>>> mask_poly file (DUGd02.poly, also attached) to make sure that
the
>>>>> scoring is done over the same geographic area as the WRF grid.
>>>>>
>>>>> The valid times/dates do not match, but this is just for
testing.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> R/
>>>>> John
>>>>>
>>>>> Mr John W. Raby, Meteorologist
>>>>> U.S. Army Research Laboratory
>>>>> White Sands Missile Range, NM 88002
>>>>> (575) 678-2004 DSN 258-2004
>>>>> FAX (575) 678-1230 DSN 258-1230
>>>>> Email: john.w.raby2.civ at mail.mil
>>>>>
>>>>>
>>>>>
>>>>> Classification: UNCLASSIFIED
>>>>> Caveats: NONE
>>>>>
>>>>>
>>>>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>>
>>>>
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>>
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
Classification: UNCLASSIFIED
Caveats: NONE
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance (UNCLASSIFIED)
From: John Halley Gotway
Time: Tue Jan 03 11:43:42 2012
Steve,
Fair enough, that should do it. GRIB1 is very limited in how it
stores metadata. So I'm guessing it's not able to store a grid
definition more precise than the thousandths decimal place. I'm
really
not sure what it's doing though - rounding or truncating. Either way,
I would guess it'd have a minimal impact on the verification scores.
John Raby had also written suggesting that he could modify the
definition of the RTMA grid he's requesting. That would work as well
and avoid the question of rounding vs truncation. But it'd
probably take more work.
Good luck.
John
On 01/03/2012 11:39 AM, stephen.f.kirby.civ at mail.mil via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> John,
>
> Indeed when you convert the data to GRIB1, it does eliminate the
problem of
> digits beyond the thousandth's place. Thanks for pointing that out.
>
> --Steve
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Tuesday, January 03, 2012 11:27 AM
> To: Raby, John W CIV (US)
> Cc: Kirby, Stephen F CIV (US)
> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
(UNCLASSIFIED)
>
> Steve,
>
> Yes, I would guess that would cause a problem as well. This is the
first grid
> definition I've seen that uses more precision than the thousandths
decimal
> place. I've always found the use on integers in those grid
definitions to be
> a bit awkward!
>
> However, MET is still not able to read data in GRIB2 directly. It
must first
> be converted to GRIB1. We are working on GRIB2 support but it is
not ready
> yet. You may choose to convert the RTMA file from GRIB2 to GRIB1
using the
> "cnvgrib" utility:
> http://www.nco.ncep.noaa.gov/pmb/codes/GRIB2/
>
> I would suggest first converting from GRIB2 to GRIB1, and then take
a look at
> the grid definition in the GRIB1 file. If it still uses more than
the
> thousandths place, you have a couple of options.
> One option is to run that RTMA file through copygb to *slightly*
regrid the
> data to a grid definition that would work. Another option is to
modify the
> logic within MET to not require *exact* matching of grids - you
could choose
> to only ensure that the grid dimensions (Nx and Ny) are the same.
That would
> enable you to compare data that one grids that are slightly
different.
>
> If you decide you'd like to pursue the latter option, let me know
and I can
> point you to the code that would need to change.
>
> Hope that helps.
>
> John
>
>
> On 01/03/2012 11:12 AM, stephen.f.kirby.civ at mail.mil via RT wrote:
>>
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> Hi John and the met_help folks,
>>
>> One question. In support of John Raby here, with whom you've been
>> conversing, I'm writing a script for re-gridding WRF from 1km
>> resolution to 2.5km resolution to match a RTMA gridded observation
>> file. This output file will be utilized in Grid-Stat.
>>
>> The RTMA file that I need to match has dimensions as follows:
>>
>> [skirby at carson RTMA]$ wgrib2 -grid rtma2p5.t00z.2dvaranal_ndfd.grb2
>> 1:0:grid_template=30:winds(grid):
>> Lambert Conformal: (38 x 31) input WE:SN output WE:SN res
8
>> Lat1 39.720561 Lon1 246.040860 LoV 265.000000
>> LatD 25.000000 Latin1 25.000000 Latin2 25.000000
>> LatSP -90.000000 LonSP 0.000000
>> North Pole (38 x 31) Dx 2539.703000 m Dy 2539.703000 m
mode 8
>>
>> But the problem I see is that, for example, the "Lat1" value has
>> non-zero digits beyond the thousandth's place. And copygb only
>> accepts integer values, so when you multiply by a thousand to get
>> millidegrees you get 39720.561. At this point, do you round this
to 39721,
>> or do you truncate it to 39720?
>> Neither one gives an exact match to the original RTMA dimensions
which
>> makes me think Grid-Stat will complain. What do you recommend?
>>
>> Thanks for your advice,
>> Steve
>>
>> -----Original Message-----
>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>> Sent: Friday, December 16, 2011 10:32 AM
>> To: Raby, John W USA CIV (US)
>> Cc: Kirby, Stephen F USA CIV (US)
>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>> (UNCLASSIFIED)
>>
>> That sounds great John.
>>
>> I'll go ahead and resolve this ticket. Just let us know if more
>> questions/problems arise.
>>
>> Thanks,
>> John
>>
>> On 12/16/2011 10:14 AM, Raby, John W USA CIV via RT wrote:
>>>
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> John -
>>>
>>> Thanks for providing some answers to all my questions that last
>>> couple of days. We see this a breakthrough for us as we are trying
to
>>> verify our high resolution WRF Nowcast model which has four
>>> dimensional data assimilation (WRF/FDDA). We need to augment our
>>> verification process which, up to now, has just the traditional
>>> statistics from Point-Stat and Stat-Analysis by adding fuzzy and
>>> spatial verification techniques and have been stymied by the lack
of
>>> a gridded observation dataset until now.
>>>
>>> We hope to use the RTMA product to start using Grid-Stat for
>>> neighborhood
>>> (fuzzy) verification statistics and MODE for spatial verification.
We
>>> want to focus on "objects" defined by thresholds we set within the
>>> continuous met variable fields of temperature, dewpoint, and
>>> windspeed for now since that is what the RTMA gives us. We want to
>>> see how well the model forecasts these "objects" when compared to
the
>>> same objects in the RTMA observations.
>>>
>>> By adding Grid-Stat and MODE assessments to traditional
evaluations
>>> we want to be able to tell the complete story about the
performance
>>> of the WRF/FDDA.
>>>
>>> R/
>>> John
>>>
>>>
>>> -----Original Message-----
>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>> Sent: Friday, December 16, 2011 9:24 AM
>>> To: Raby, John W USA CIV (US)
>>> Cc: Kirby, Stephen F USA CIV (US)
>>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>>> (UNCLASSIFIED)
>>>
>>> John,
>>>
>>> Yes, I'd recommend doing exactly what you describe - request RTMA
>>> data on a grid that fully encompasses your WRF domain. And you're
>>> correct to realize that differences in projection may require an
RTMA
>>> grid slightly larger than your WRF grid. Just get the RTMA data
and
>>> regrid it using copygb. Then you could use the IDV tool to
display
>>> that regridded RTMA data and make sure there aren't any strips of
>>> missing data along the edges. Or if you don't use IDV, you could
>>> just run the data through Grid-Stat, writing out the matched pairs
>>> file, and look at the matched pair output using the ncview utility
-
>>> and check that there isn't any missing data along the edges.
>>>
>>> So the process we described is to regrid the RTMA analysis to your
>>> WRF grid and verify over the model domain. Another option would
be
>>> to go the other way - regrid your model data to an RTMA grid and
>>> verify over the RTMA domain.
>>> There are arguments for doing it both ways.
>>>
>>> Generally, if you have the option of verifying on the forecast
domain
>>> or the observation domain, you'd choose the one with the coarser
>>> resolution. I assume in your case that the RTMA data is on a
coarser
>>> grid than your model data. When you interpolate from a coarser
>>> domain to a finer domain, you're kind of inventing a lot of data
>>> points. That being said, most users just want to verify on their
>>> model domain using whatever observations are available.
>>> So
>>> that what is often done I believe. For further detail on that
issue,
>>> I'd refer you to Tressa.
>>>
>>> Thanks,
>>> John
>>>
>>> On 12/15/2011 12:52 PM, Raby, John W USA CIV via RT wrote:
>>>>
>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>> John -
>>>>
>>>> Very interesting. I find that I learn something new about MET
every
>>>> time we have these exchanges. Thanks.
>>>>
>>>> Let's assume I take the tact of requesting RTMA files for areas
>>>> larger (slightly, but without a doubt, larger) than the WRF area
>>>> because the user interface for the RTMA system only allows you to
>>>> specify a square box (left lon, right lon, top lat, bottom lat)
but
>>>> the WRF domain is really not a true box in terms of lat/lon. By
>>>> requesting the RTMA for a larger area, I ensure that my RTMA file
>>>> will never be smaller than the WRF which is desirable for my
>>>> purposes now and I don't have to get into the business of trying
to guess
>>>> at making a perfect match.
>>>>
>>>> Given the above: What would be the symptoms/problems of a
situation
>>>> where I run Grid-Stat using an RTMA file for an area that was
>>>> slightly larger than the WRF area? Would this be detrimental to
good
>>>> practice?
>>>>
>>>> Thanks.
>>>>
>>>> R/
>>>> John
>>>>
>>>> -----Original Message-----
>>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>>> Sent: Thursday, December 15, 2011 11:11 AM
>>>> To: Raby, John W USA CIV (US)
>>>> Cc: Kirby, Stephen F USA CIV (US)
>>>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>>>> (UNCLASSIFIED)
>>>>
>>>> John,
>>>>
>>>> Lots of questions in there!
>>>>
>>>> First, I'm glad you were able to get it working.
>>>>
>>>> Next, you mention that you ran Grid-Stat two times - once to
score
>>>> over the full domain and a second time to score over a subset of
the
>>>> domain. I want to point out that you really only need to run
>>>> Grid-Stat once in this case. Just set up your config file with
>>>> something like this:
>>>> mask_grid[] = [ "FULL" ];
>>>> mask_poly[] = [ "path/to/your/mask/poly" ];
>>>>
>>>> Each time you run Grid-Stat, it will compute statistics for
*each*
>>>> of the masking regions you specify. In this case, you'll see
output
>>>> for both the FULL domain and the polyline you've specified.
>>>>
>>>> Your next question - what does the FULL domain mean? Before
running
>>>> Grid-Stat, you have to put your forecast and observations onto a
>>>> common grid.
>>>> When you tell the MET tools score over the "FULL"
>>>> domain, that means, just use all of those grid points on which
the
>>>> data resides. Don't throw any of them out. The fact that you
got
>>>> more matched pairs for the FULL domain than you got for the
polyline
>>>> subset makes complete sense.
>>>>
>>>> Because of the requirement that the data be on the same grid,
every
>>>> time you run Grid-Stat, there will be values at each point in
both
>>>> the forecast and observation fields. But suppose that you
started
>>>> with an RTMA file whose domain did not fully cover your WRF
domain.
>>>> You'd first need to run that RTMA file through copygb to put it
onto
>>>> the WRF grid. That step will result in a data file that have
valid
>>>> data in the middle (where the RTMA was valid) surrounded by
missing
>>>> data values around the edge (where there was no RTMA data). Now
>>>> suppose you run Grid-Stat to compare the RTMA to a WRF file, and
>>>> tell it to score over the FULL region. Grid-Stat will loop
through
>>>> the grid looking at all the points (since we chose FULL), and it
>>>> will get a forecast/observation pair for each grid point.
Because
>>>> of the missing RTMA values around the edge, you'll end up with
some
>>>> matched pairs where the observation is a missing value. And in
that
>>>> case, Grid-Stat won't use those matched pairs - it'll toss them
out,
>>>> as it should.
>>>>
>>>> Generally, speaking when Point-Stat and Grid-Stat are run, the
first
>>>> step is to compute a bunch of forecast/observation matched pairs.
>>>> And the next step is to throw out any matched pairs where either
the
>>>> forecast or observation contains bad data. Then statistics are
>>>> computed over only those matched pairs with good data for both.
>>>>
>>>> That explanation is a long way of suggesting that when retrieving
>>>> RTMA data, be sure it completely covers your WRF domain. And if
you
>>>> have an option on resolution of the RTMA data, choose one that
most
>>>> closely matches the resolution of your model run.
>>>>
>>>> Hope that helps.
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>>
>>>> On 12/15/2011 10:50 AM, Raby, John W USA CIV via RT wrote:
>>>>>
>>>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045>
>>>>>
>>>>> Classification: UNCLASSIFIED
>>>>> Caveats: NONE
>>>>>
>>>>> John -
>>>>>
>>>>> Steve Kirby implemented your solution below and it worked just
as
>>>>> you said!
>>>>> This information was invaluable for us to progress in our
attempts
>>>>> to use the RTMA product as a gridded observation data set.
>>>>>
>>>>> I have a question which came out of the testing I did this
morning
>>>>> with Grid-Stat.
>>>>>
>>>>> I ran the Grid-Stat tests 2 ways which were both successful. The
>>>>> first was done assuming that the RTMA file was for a slightly
>>>>> larger area than the Dugway, UT WRF forecast domain. I
restricted
>>>>> the scoring to a subset of that area by using a mask_poly file
to
>>>>> define the geographic area according to the coordinates
(lat/long
>>>>> corners) of the Dugway WRF domain we have been using in the
past.
>>>>> The second test was done by removing the restriction and scoring
>>>>> over the full area of the 2 grids.
>>>>>
>>>>> The TOTAL # of forecast-observation pairs for the first test was
>>>>> 10207 and for the second test was 10404. So it appears that by
>>>>> allowing Grid-Stat to score over the entire grid it actually
scored
>>>>> over a slightly larger area than was the case in the first test.
>>>>>
>>>>> I checked the User's Guide and it says that when you use a value
of
>>>>> "FULL" in the mask_grid variable it scores over the "entire grid
on
>>>>> which the data resides". Which grid are you talking about? I
would
>>>>> assume that since you are trying to verify the forecast, that
the
>>>>> grid used is the forecast grid, but I wanted to be sure.
>>>>>
>>>>> The implication is that if I specify the use of "FULL" vice
using a
>>>>> mask_poly file, that Grid-Stat will always score over that
subset
>>>>> of the gridded observation field and as long as you ensure that
the
>>>>> gridded observation field is a larger area than you need, you
will
>>>>> always get results.
>>>>>
>>>>> What would happen if the gridded observation dataset was over a
>>>>> smaller area than the forecast field and you specified "FULL"
for
>>>>> scoring?
>>>>>
>>>>> What I'm getting at is a way to decide what geographic size of
RTMA
>>>>> file I should download to make sure that I can just use the
"FULL"
>>>>> scoring in the mask_grid variable and not worry about having to
>>>>> "guess" the actual size where scoring will occur unless I have a
>>>>> specific reason to focus in on a particular subset of the
region.
>>>>>
>>>>> Thanks for all your help. This service is very helpful for MET
users.
>>>>> We rely on this service frequently for assistance in answering
>>>>> questions and resolving issues and have found it to be very
>>>>> efficient and accurate with a high level of responsiveness.
>>>>>
>>>>> R/
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
>>>>> Sent: Wednesday, December 14, 2011 3:28 PM
>>>>> To: Raby, John W USA CIV (US)
>>>>> Cc: Kirby, Stephen F USA CIV (US)
>>>>> Subject: Re: [rt.rap.ucar.edu #52045] Request for assistance
>>>>> (UNCLASSIFIED)
>>>>>
>>>>> John,
>>>>>
>>>>> I ran the following two wgrib commands on the data you sent to
see
>>>>> what the grids are. I've included the grid definition
information
>>>>> output from wgrib:
>>>>>
>>>>> % wgrib -d 1 -V WRFPRS_d02.00
>>>>> ...
>>>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov
-113.442000
>>>>> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
>>>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64
mode 8 ...
>>>>>
>>>>> % wgrib -V -d 1 rtma_1km.grb1
>>>>> ...
>>>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov
-113.488000
>>>>> Latin1 25.000000 Latin2 25.000000 LatSP 0.000000 LonSP
0.000000
>>>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64
mode 8 ...
>>>>>
>>>>> As you can see, while the grid dimensions are both 102x102, the
>>>>> grid definition parameters differ a lot. So the arguments
you're
>>>>> using in your call to copygb need to be modified to make the
rtma
>>>>> grid exactly the same as the WRF grid.
>>>>>
>>>>> There is an example of doing this in the MET online tutorial
here:
>>>>>
>>>>>
http://www.dtcenter.org/met/users/support/online_tutorial/METv3.0/c
>>>>> op
>>>>> y
>>>>> gb/run3.php
>>>>>
>>>>> Using that website as an example, here's the grid definition
>>>>> argument you should be using in your call to copygb:
>>>>> "255 3 NX NY STARTLAT STARTLON 8 CENLON DX DY 0 64
TRUELAT1
>>>>> TRUELAT2"
>>>>> "255 3 102 102 39679 -114032 8 -113442 1000 1000 0 64
40135
>>>>> 40135"
>>>>>
>>>>> Next I ran the rtma file through copygb like this:
>>>>> % copygb -xg"255 3 102 102 39679 -114032 8 -113442 1000 1000
0 64
>>>>> 40135 40135" rtma_1km.grb1 rtma_1km_regrid.grb1
>>>>>
>>>>> And checked to make sure that the grids match now:
>>>>> % wgrib -d 1 -V rtma_1km_regrid.grb1 ...
>>>>> Lambert Conf: Lat1 39.679000 Lon1 -114.032000 Lov
-113.442000
>>>>> Latin1 40.135000 Latin2 40.135000 LatSP 0.000000 LonSP
0.000000
>>>>> North Pole (102 x 102) Dx 1.000000 Dy 1.000000 scan 64
mode 8 ...
>>>>>
>>>>> And they do. So that should solve your problem.
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>>
>>>>> On 12/14/2011 03:04 PM, Raby, John W USA CIV via RT wrote:
>>>>>>
>>>>>> Wed Dec 14 15:04:57 2011: Request 52045 was acted upon.
>>>>>> Transaction: Ticket created by john.w.raby2.civ at mail.mil
>>>>>> Queue: met_help
>>>>>> Subject: Request for assistance (UNCLASSIFIED)
>>>>>> Owner: Nobody
>>>>>> Requestors: john.w.raby2.civ at mail.mil
>>>>>> Status: new
>>>>>> Ticket<URL:
>>>>>> https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52045
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Classification: UNCLASSIFIED
>>>>>> Caveats: NONE
>>>>>>
>>>>>> We have been trying to run Grid-Stat using a 1km resolution WRF
>>>>>> forecast GRIB1 file (WRFPRS_d02.00)and an RTMA file
(rtma_1km.grb)
>>>>>> which we converted from GRIB2 to GRIB1 and then used copygb to
>>>>>> re-grid it to match the grid of the WRF.
>>>>>>
>>>>>> We are running into an ERROR which states that the forecast and
>>>>>> observation grids do not match.
>>>>>>
>>>>>> Could you take a look at the attached files to see if you can
>>>>>> diagnose the problem?
>>>>>>
>>>>>> Some details on how we are running Grid-Stat follow:
>>>>>>
>>>>>> grid_stat ../MET_WRFpostprd/${Start_Date}/WRFPRS_d02.00
>>>>>> ../MET_obs/RTMA/rtma_1km.grb1 ./GridStatConfig_m2o2_rtma
-outdir
>>>>>> ./results_m2o2/${Start_Date} -v 2
>>>>>>
>>>>>> User specifies the Start_Date at the keyboard.
>>>>>>
>>>>>> The config file (GridStatConfig_m2o2_rtma) is attached. I use a
>>>>>> mask_poly file (DUGd02.poly, also attached) to make sure that
the
>>>>>> scoring is done over the same geographic area as the WRF grid.
>>>>>>
>>>>>> The valid times/dates do not match, but this is just for
testing.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> R/
>>>>>> John
>>>>>>
>>>>>> Mr John W. Raby, Meteorologist
>>>>>> U.S. Army Research Laboratory
>>>>>> White Sands Missile Range, NM 88002
>>>>>> (575) 678-2004 DSN 258-2004
>>>>>> FAX (575) 678-1230 DSN 258-1230
>>>>>> Email: john.w.raby2.civ at mail.mil
>>>>>>
>>>>>>
>>>>>>
>>>>>> Classification: UNCLASSIFIED
>>>>>> Caveats: NONE
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> Classification: UNCLASSIFIED
>>>>> Caveats: NONE
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Classification: UNCLASSIFIED
>>>> Caveats: NONE
>>>>
>>>>
>>>>
>>>
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>>
>>>
>>
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
------------------------------------------------
More information about the Met_help
mailing list