[Met_help] [rt.rap.ucar.edu #52393] History for RTMA re-gridding question (UNCLASSIFIED)
John Halley Gotway via RT
met_help at ucar.edu
Thu Jan 5 09:35:41 MST 2012
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Classification: UNCLASSIFIED
Caveats: NONE
John,
In an earlier email discussion with John Raby here, you mention this:
"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."
Broadly speaking, it seems, interpolating the 1km resolution WRF to 2.5km and
comparing that to the 2.5km RTMA data is the way to go, since as you say, you
are not "inventing data". But as you imply above, one could argue going the
other way too: re-gridding the 2.5km RTMA down to 1km and compare that with
the WRF. I guess in the latter case you could argue that you would not be
massaging the WRF data in any way, thus preserving the physics that went into
it. But conversely, when you interpolate RTMA, you are "altering data" that
is built, at least partially, on model data (I saw a COMET tutorial from 2007
that said the RUC13 goes into RTMA, but that it would shift to rapid-refresh
WRF in 2009. Has that change occurred?).
I guess I'm wondering what your argument would be for going from coarse to
fine (i.e., interpolating RTMA from 2.5km to 1km, then comparing to 1km WRF).
Thanks much,
Steve
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Tuesday, January 03, 2012 11:44 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,
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
>
>
>
Classification: UNCLASSIFIED
Caveats: NONE
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #52393] RTMA re-gridding question (UNCLASSIFIED)
From: John Halley Gotway
Time: Thu Jan 05 09:17:12 2012
Steve,
If your forecast is on a 1km and your obs are on a 2.5 km grid, I
agree that putting both on the coarser, 2.5 km grid makes the most
sense - to prevent "inventing" new data points.
As for your question about the rapid-refresh - I have no idea - I
believe it's the folks over at NOAA in Boulder that produce that
product. Regarding larger interpolation questions, I'm not really
qualified to answer it. As a software engineer, I'm just happy the
MET tools are working well for you!
Sorry I can't be of more help.
John Halley Gotway
On 01/04/2012 06:28 PM, stephen.f.kirby.civ at mail.mil via RT wrote:
>
> Wed Jan 04 18:28:49 2012: Request 52393 was acted upon.
> Transaction: Ticket created by stephen.f.kirby.civ at mail.mil
> Queue: met_help
> Subject: RTMA re-gridding question (UNCLASSIFIED)
> Owner: Nobody
> Requestors: stephen.f.kirby.civ at mail.mil
> Status: new
> Ticket<URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52393>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> John,
>
> In an earlier email discussion with John Raby here, you mention
this:
>
> "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."
>
> Broadly speaking, it seems, interpolating the 1km resolution WRF to
2.5km and
> comparing that to the 2.5km RTMA data is the way to go, since as you
say, you
> are not "inventing data". But as you imply above, one could argue
going the
> other way too: re-gridding the 2.5km RTMA down to 1km and compare
that with
> the WRF. I guess in the latter case you could argue that you would
not be
> massaging the WRF data in any way, thus preserving the physics that
went into
> it. But conversely, when you interpolate RTMA, you are "altering
data" that
> is built, at least partially, on model data (I saw a COMET tutorial
from 2007
> that said the RUC13 goes into RTMA, but that it would shift to
rapid-refresh
> WRF in 2009. Has that change occurred?).
>
> I guess I'm wondering what your argument would be for going from
coarse to
> fine (i.e., interpolating RTMA from 2.5km to 1km, then comparing to
1km WRF).
>
> Thanks much,
> Steve
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Tuesday, January 03, 2012 11:44 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,
>
> 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
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
------------------------------------------------
Subject: RTMA re-gridding question (UNCLASSIFIED)
From: stephen.f.kirby.civ at mail.mil
Time: Thu Jan 05 09:30:35 2012
Classification: UNCLASSIFIED
Caveats: NONE
John,
No problem. Thanks for helping us get this working!
--Steve
-----Original Message-----
From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
Sent: Thursday, January 05, 2012 9:17 AM
To: Kirby, Stephen F CIV (US)
Subject: Re: [rt.rap.ucar.edu #52393] RTMA re-gridding question
(UNCLASSIFIED)
Steve,
If your forecast is on a 1km and your obs are on a 2.5 km grid, I
agree that
putting both on the coarser, 2.5 km grid makes the most sense - to
prevent
"inventing" new data points.
As for your question about the rapid-refresh - I have no idea - I
believe it's
the folks over at NOAA in Boulder that produce that product.
Regarding larger
interpolation questions, I'm not really
qualified to answer it. As a software engineer, I'm just happy the
MET tools
are working well for you!
Sorry I can't be of more help.
John Halley Gotway
On 01/04/2012 06:28 PM, stephen.f.kirby.civ at mail.mil via RT wrote:
>
> Wed Jan 04 18:28:49 2012: Request 52393 was acted upon.
> Transaction: Ticket created by stephen.f.kirby.civ at mail.mil
> Queue: met_help
> Subject: RTMA re-gridding question (UNCLASSIFIED)
> Owner: Nobody
> Requestors: stephen.f.kirby.civ at mail.mil
> Status: new
> Ticket<URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=52393>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> John,
>
> In an earlier email discussion with John Raby here, you mention
this:
>
> "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."
>
> Broadly speaking, it seems, interpolating the 1km resolution WRF to
2.5km
> and
> comparing that to the 2.5km RTMA data is the way to go, since as you
say,
> you
> are not "inventing data". But as you imply above, one could argue
going the
> other way too: re-gridding the 2.5km RTMA down to 1km and compare
that with
> the WRF. I guess in the latter case you could argue that you would
not be
> massaging the WRF data in any way, thus preserving the physics that
went
> into
> it. But conversely, when you interpolate RTMA, you are "altering
data" that
> is built, at least partially, on model data (I saw a COMET tutorial
from
> 2007
> that said the RUC13 goes into RTMA, but that it would shift to
rapid-refresh
> WRF in 2009. Has that change occurred?).
>
> I guess I'm wondering what your argument would be for going from
coarse to
> fine (i.e., interpolating RTMA from 2.5km to 1km, then comparing to
1km
> WRF).
>
> Thanks much,
> Steve
>
> -----Original Message-----
> From: John Halley Gotway via RT [mailto:met_help at ucar.edu]
> Sent: Tuesday, January 03, 2012 11:44 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,
>
> 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
>>
>>
>>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
Classification: UNCLASSIFIED
Caveats: NONE
------------------------------------------------
More information about the Met_help
mailing list