[Met_help] Re: MET -- grid conversion on GFS
John Halley Gotway
johnhg at rap.ucar.edu
Tue Nov 13 13:48:20 MST 2007
Luke,
I did speak with the statisticians in our group about re-gridding the coarser observations to the finer scale forecasts prior to running MET. And they both think that that's a reasonable thing to do.
You may end up with observations objects that look slightly more "blocky" than the forecast objects. Also, the distribution of intensity values within the observation objects may look a little
different than for the forecast objects. But it's a fine thing to do.
However, I should mention that within MODE, distances are defined in terms of grid squares rather than real distances like miles or kilometers. So in the WrfModeConfig configuration file, you should
set the "grid_res" (for grid resolution) to the nominal grid spacing that you're actually using for the forecast grid (looks like it's 48 km). The grid_res parameter is used later in the
configuration file for defining other distance based parameters. I'd also suggest playing around with the values for the "fcst_conv_radius" and "obs_conv_radius" which control how much smoothing you
do prior to defining objects.
Many options are included in the configuration file for MODE. If you have any questions about what they mean or how modifying them might affect the results, don't hesitate to ask.
John
Luke Peffers wrote:
> Thank you John,
>
> This really helps! I will use the grid you defined for my current projects
> and will apply this method of defining my grid when defining a domain
> outside the CONUS.
>
> You had mentioned in a previous email that it may not be as important to
> avoid obs file regridding when using object oriented methods (i.e. MODE),
> since individual grid points are not being compared. I would like to
> continue to regrid my obs files to my forecast files since the image is more
> aesthetically appealing, it just looks better (i.e. less pixelized) doing
> this. I will however be sure to regrid my forecast file to the obs file
> configuration when using grid_stat to avoid comparing interpolated or "fake"
> data points. The last I heard, you were waiting for a reply from the folks
> in the MODE department as to weather this was advisable.
>
> As far as the floating point exception when using copygb, I have encountered
> this error each time I regrid my WRF files. I have however temporarily
> ignored this problem since it didn't seem to hinder my progress. I have not
> mentioned this problem until now but if you have a solution or know who may,
> I will address the problem before I continue any further.
>
> Thank you for your prompt assistance, as usual.
>
> Regards,
>
> Luke Peffers
> FSU Meteorology Department
>
>
>
> On Nov 12, 2007 1:45 PM, John Halley Gotway <johnhg at rap.ucar.edu> wrote:
>
>> Luke,
>>
>> I'd suggest something like the following 2 copygb commands:
>> copygb -g"255 0 36 31 25000 -125000 128 50000 -90000 1000 1000 64" -x
>> WRFPRS_d01.96 WRFPRS_d01.96_new
>> copygb -g"255 0 36 31 25000 -125000 128 50000 -90000 1000 1000 64" -x
>> fnl_071019_00_00 fnl_071019_00_00_new
>>
>> Attached you'll find the postscript output of running MODE on these two
>> files for 2 meter temperature.
>>
>> Here's the (long-winded) steps I went through...
>>
>> Determine the forecast valid time using the "wgrib" tool:
>> wgrib WRFPRS_d01.96 -verf
>> It's valid on 10/19/2007 at 00Z.
>>
>> Determine the definition of the model forecast grid using "pcp_combine":
>> Conveniently, "pcp_combine" writes the grid information to the netCDF
>> output file.
>> pcp_combine 0000-00-00_00:00:00 96 2007-10-19_00:00:00 96
>> for_peffers/WRFPRS_d01.96.nc -pcpdir ./ -pcprx WRFPRS
>> (Alternatively, you could just using the "wgrib" tool to dump the Grid
>> Description Section of the grib files directly. But then you'd have to
>> decode the GDS using the Grib Documentation.)
>> I used the "ncdump" tool to view the netCDF files.
>> Your model grid is defined as follows:
>> :Projection = "Lambert Conformal" ;
>> :p1_deg = "35.000000 degrees_north" ;
>> :p2_deg = "46.000000 degrees_north" ;
>> :p0_deg = "25.082000 degrees_north" ;
>> :l0_deg = "-120.500000 degrees_east" ;
>> :lcen_deg = "-108.200000 degrees_east" ;
>> :d_km = "48.000000 km" ;
>> :r_km = "6367.470000 km" ;
>> :nx = "54 grid_points" ;
>> :ny = "54 grid_points" ;
>>
>> I tried to use the same method to extract the observation grid info. But
>> there were no precip records in the grib file. So pcp_combine didn't work.
>>
>> So instead, I ran the observation file through grid_stat by comparing it
>> to itself. And I set the verbosity logging level very high using the "-v"
>> command line option. That dumps out a bunch of grib
>> record information, such as:
>> length: 32
>> nv: 0
>> pvpl: 255
>> type: 0
>> nx: 360
>> ny: 181
>> lat1: 90000
>> lon1: 0
>> res_flag: 128
>> lat2: 8478608
>> lon2: 8389608
>> di: 1000
>> dj: 1000
>> scan_flag: 0
>>
>> I know that a "type" value of 0 means that the grid is Lat/Lon. That's
>> fortunate because taking a subset of a lat/lon grid is pretty easy, whereas
>> taking a subset of a polar stereographic or lambert
>> conformal would take some more work.
>>
>> So the observation grid goes from a (lat, lon) of (90.0, 0.0) in 1 degree
>> increments around the globe.
>>
>> We'll just want to define a new lat/lon grid with 1 degree steps that
>> contains your forecast domain. I plotted your forecast grid, by just
>> running the sample forecast file (comparing it to itself)
>> through the "mode" tool. Looking at the output, looks like it's the
>> Western US.
>>
>> I tried having the latitudes vary from 25N to 50N and longitudes vary from
>> 90W to 125W in 1 degree increments.
>>
>> Here's an example of defining a lat/lon grid for copygb (taken from
>> http://www.cpc.ncep.noaa.gov/products/wesley/copygb.html):
>> copygb -g"255 0 NX NY LAT0 LON0 128 LAT1 LAT2 DX DY 64" -x in.grb out.grb
>>
>> So in my case, I ran the following commands:
>> copygb -g"255 0 36 31 25000 -125000 128 50000 -90000 1000 1000 64" -x
>> WRFPRS_d01.96 WRFPRS_d01.96_new
>> copygb -g"255 0 36 31 25000 -125000 128 50000 -90000 1000 1000 64" -x
>> fnl_071019_00_00 fnl_071019_00_00_new
>>
>> For some reason I did encounter a floating point exception when running
>> your WRFPRS file through copygb. I remember hearing about a WRFHELP
>> question regarding the same sort of issue. Was it you who
>> submitted that question? And if so, was it resolved?
>>
>> Please let me know if you have any more questions.
>>
>> John
>>
>> Luke Peffers wrote:
>>> Thanks John,
>>>
>>> Until the new version of MET comes out, I would like to be able to
>> regrid my
>>> obs and forecast data to a similar GFS subset, which is valid for a
>> domain
>>> similar to my forecast domain (your option 2). I'll ftp my obs and
>> forecast
>>> files to your directory shortly. I would like to know how you do this
>>> (extract the grid info from the files) so I will be able to do the same
>> in
>>> the future since I'll be running many different grid configurations.
>>>
>>> Thanks again!!
>>>
>>> Regards,
>>>
>>> Luke Peffers
>>> FSU Meteorology Department
>>>
>>> On Nov 5, 2007 3:11 PM, John Halley Gotway <johnhg at rap.ucar.edu> wrote:
>>>
>>>> Luke,
>>>>
>>>> You have a few options...
>>>>
>>>> (1) You could continue re-gridding your forecasts to the GFS grid and
>>>> compare them directly. If you do so, I'd recommend setting the
>>>> "mask_missing_flag" in the MODE config file to a value of 3.
>>>> Then, prior to defining objects, MODE will mask out data in both the
>>>> forecast and observation fields where at least one of the fields has
>> missing
>>>> data. So you'll end with objects only where there's
>>>> valid data in both fields.
>>>>
>>>> However, you'll still end up with plots that don't look very nice. The
>>>> whole domain will be plotted, so the region of valid data will be
>> relatively
>>>> small. We've addressed this issue in the next
>>>> release with the "plot_valid_flag". Turning on this flag tells MODE to
>>>> zoom the plot up to only the valid region of data. So you could use
>> that
>>>> when the next release comes out.
>>>>
>>>> (2) You could define a new grid that's a subset of the GFS domain but
>>>> similar to your forecast domain, and re-grid both the forecast and
>>>> observation files to that new grid. You mentioned having
>>>> difficulty defining such a grid. I'd be happy to help you figure out
>> the
>>>> arguments for "copygb" to define such a grid. I'd just need you to
>> send me
>>>> one of your forecast grib files and one of the GFS
>>>> observation grib files. I'll pull out the grid definition information
>>>> from the files and see what I can come up with.
>>>>
>>>> (3) You could continue re-gridding the observations to your forecast
>>>> domain. I doubt the issue of putting the forecasts onto the
>> observation
>>>> grid is as big of an issue with an "object-based" approach
>>>> like MODE as it is with a traditional point-based or grid-based
>>>> verification approach. I wrote a couple of the statisticians in our
>> group
>>>> about this issue but haven't heard back from them yet. I'll
>>>> let you know what I find out.
>>>>
>>>> Please let me know which route you'd like to go. Whichever you choose,
>>>> I'd still recommend using the "mask_missing_flag" in the MODE config
>> file.
>>>> It only really makes sense to define objects where
>>>> you have valid data in both fields.
>>>>
>>>> And if you'd like help defining a new grid, just send me those sample
>>>> files and I'll see what I can do.
>>>>
>>>> John
>>>>
>>>> Luke Peffers wrote:
>>>>> Hello John:
>>>>>
>>>>> I am have some difficulty verifying my WRF model run with GFS gridded
>>>> date.
>>>>> I would like to follow the general rule that when comparing two
>> gridded
>>>>> files, one should regrid the forecast file to the obs grid, in my case
>>>> GFS.
>>>>> When I do that, mode compares my relatively small domain to the entire
>>>> GFS
>>>>> (global) domain.
>>>>>
>>>>> I am, of course, running my WRF output through WRF Post Processor. I
>>>>> regrid my files using COPYGB.
>>>>>
>>>>> I have no problem regridding the GFS data to my forecast grid since I
>>>> know
>>>>> the exact grid dimensions for the user defined grid from WRF. I
>> don't,
>>>>> however, know the exact grid codes for a GFS-like grid that is of the
>>>> exact
>>>>> domain size of my forecast file. Thus, I continue to use MET with obs
>>>> files
>>>>> regridded to match my WRF output grid file.
>>>>>
>>>>> Do you know how I can resolve this problem?
>>>>>
>>>>> Thank you!!
>>>>>
>>>>> Luke Peffers
>>>>> FSU Meteorology Department
>>>>>
>
More information about the Met_help
mailing list