[Met_help] Re: MET (MODE) problems
John Halley Gotway
johnhg at rap.ucar.edu
Wed May 7 13:28:11 MDT 2008
Luke,
Please copy the attached version of the file "read_grib.cc" into METv1.0/lib/vx_met_util/read_grib.cc. Then from the top level MET directory, do a "make clean" and rebuild MET.
Take a look in the attached file for your name, and you'll see where I've hard coded the "ydir" value. Please be sure to take a look at the data plots from MODE to make sure that the data is plotted
correctly, and shouldn't be flipped about the equator.
John
Luke Peffers wrote:
> John,
>
> Yes, I'm using LATS...I have searched high and low for a way to define the
> scan flag in the LATS configuration files but only found how to define the
> type of model level (earth's surface etc.). I would have no problem
> manipulation my MET code since this is the only reason I'm playing with the
> cmorph data to begin with. Please let me know what I need to do to my code.
>
> Thanks again.
>
> Luke
>
> On Wed, May 7, 2008 at 3:05 PM, John Halley Gotway <johnhg at rap.ucar.edu>
> wrote:
>
>> Luke,
>>
>> I actually didn't modify the file itself - I just modified the code that
>> reads it to hard-code the value for the scan flag.
>>
>> Is it correct that you're actually creating these cmorph files using LATS
>> (from GRADS)? If so, then there may be a problem with the LATS tool.
>>
>> I tried hunting around for info on LATS. Here's the page I found:
>> http://www-pcmdi.llnl.gov/software/lats
>>
>> Perhaps there's a way of configuring LATS to correct the way the scan flag
>> is written. You could try to contact someone with LATS for assistance.
>>
>> Also, I tried running the cmorph Grib file through copygb to see if it
>> writes out the data correctly.
>> Here's a copygb command I used to "replot" the data onto the same grid:
>> copygb -g "255 0 1440 480 -59875 125 128 60125 125 250 250 64" -x
>> cmorph_3h_20080405_f12.grb cmorph_new.grb
>>
>> Unfortunately, while copygb does seem to define the grid correctly, it
>> doesn't seem to retain the data itself! When I ran it through MODE, the map
>> looked correct, but all the data was gone.
>>
>> I don't know what tool you could use to edit the cmorph Grib files
>> directly. As a last resort, if you'd like to hard-code your version of MODE
>> to always assume the same value for the scan flag, let me know and I'll tell
>> you how to do it.
>>
>> Sorry I can't be of more help.
>>
>> John
>>
>>
>>
>> Luke Peffers wrote:
>>
>>> Ok John, that sounds right to me. I'm glad to hear that the problem can
>>> be
>>> easily fixed. The problem is I don't know how to manipulate grib files.
>>> Could you please tell me what you did to change the scan flag?
>>>
>>> Thanks for the help.
>>>
>>> Luke Peffers
>>>
>>> On Wed, May 7, 2008 at 12:16 PM, John Halley Gotway <johnhg at rap.ucar.edu
>>> wrote:
>>>
>>> Luke,
>>>> I ran the sample cmorph data through MODE and definitely see the
>>>> plotting
>>>> problem to which you're referring. I also ran that cmorph file
>>>> through
>>>> pcp_combine (using a beta version of METv1.1) to create a NetCDF
>>>> version of
>>>> it. I did this to see how MET is interpreting the projection
>>>> information
>>>> for this file. Here's the projection info that's dumped out in the
>>>> NetCDF
>>>> file:
>>>>
>>>> :Projection = "LatLon" ;
>>>> :lat_ll_deg = "59.875000 degrees_north" ;
>>>> :lon_ll_deg = "0.125000 degrees_east" ;
>>>> :delta_lat_deg = "0.250000 degrees" ;
>>>> :delta_lon_deg = "0.250000 degrees" ;
>>>> :Nlat = "480 grid_points" ;
>>>> :Nlon = "1440 grid_points" ;
>>>>
>>>> I'm guessing that when it says that the lower-left latitude
>>>> (lat_ll_deg)
>>>> is 59.875 degrees_north, we really intend it to be degrees_south!
>>>> Given the
>>>> values for delta_lat_deg and Nlat, that makes a lot more sense. And
>>>> that
>>>> would make the plot look a whole lot better.
>>>>
>>>> I ran the following wgrib command on that cmorph file:
>>>> wgrib cmorph_3h_20080405_f12.grb -GDS10
>>>>
>>>> Here's the GDS output:
>>>> GDS10= 0 0 32 0 255 0 5 160 1 224 128 233 227 0 0 125 128 0 233 227 5
>>>> 125
>>>> 195 0 250 0 250 2 32 50 48 48
>>>>
>>>> The scan flag (the 28th octet in this list) is currently set to a
>>>> value of
>>>> 2. Here's where the scan flag values are explained:
>>>> http://www.nco.ncep.noaa.gov/pmb/docs/on388/table8.html
>>>>
>>>> A value of 2 for the scan flag would mean that the 7th bit is turned
>>>> on -
>>>> which is a "reserved" bit according to the documentation. So that
>>>> doesn't
>>>> look correct.
>>>> Here's the logic for interpreting that:
>>>> 2 = 2^1. And 8-1 = 7... so the 7th bit is turned on.
>>>>
>>>> Now in your other file, WRF_TO_CMORPH_f12.grb, the scan flag is set to
>>>> a
>>>> value of 64, which I think is what you actually want.
>>>>
>>>> Here's the GDS output for that file:
>>>> GDS10= 0 0 32 0 255 0 5 160 1 224 128 233 227 0 0 125 128 0 234 221 0
>>>> 0
>>>> 125 0 250 0 250 64 0 0 0 0
>>>>
>>>> The 28th octet contains a value of 64. A value of 64 for the scan
>>>> flag
>>>> means that the 2nd bit is turned on, and that means that points scan
>>>> in the
>>>> +j direction.
>>>> Here's the logic for interpreting that:
>>>> 64 = 2^6. And 8-6 = 2... so that 2nd bit is turned on.
>>>>
>>>> I went in and manually changed the scan flag value to 64 in the
>>>> cmorph_3h_20080405_f12.grb file and ran it through MODE. And the plot
>>>> looked fine.
>>>>
>>>> So I'd say that there's an issue with how the scan flag is set in the
>>>> cmorph_3h_20080405_f12.grb file.
>>>>
>>>> Does that sound right to you? Grib files sure can be pretty
>>>> ridiculous
>>>> sometimes!
>>>>
>>>> Hope this helps
>>>> John
>>>>
>>>>
>>>> Luke Peffers wrote:
>>>>
>>>> Hello John:
>>>>> You may remember me from my previous emails...I have been working
>>>>> with
>>>>> MET
>>>>> for some time now. I had some problems using a near-global data set
>>>>> in
>>>>> the
>>>>> MODE application. The problem stems from the way I am creating GRIB
>>>>> files
>>>>> out of flat binary precipitation rate files. I only know one way to
>>>>> do
>>>>> that
>>>>> and that is using LATS, a GRADS program. The binary data is packed
>>>>> such
>>>>> that the meridional (lat) data is written in reverse order and when
>>>>> I
>>>>> make
>>>>> the grib files, that must be addressed so that MODE knows how to
>>>>> read
>>>>> the
>>>>> files. Now that I'm sure the grib files are packed correctly, it
>>>>> looks
>>>>> like
>>>>> I am having a problem with the map area that MODE uses. It seems
>>>>> that
>>>>> the
>>>>> data is in the correct order but the underlying map is not. I'll
>>>>> ftp my
>>>>> data to you so you can take a look at it. If you compare the cmorph
>>>>> data to
>>>>> itself using the MODE tool, you'll see the mapping problem in the PS
>>>>> images. The WRF_TO_CMORPH data works fine. I ultimately would like
>>>>> to
>>>>> compare the WRF_TO_CMORPH to the cmorph data.
>>>>>
>>>>> Please help.
>>>>>
>>>>> Thank you
>>>>>
>>>>> Luke Peffers
>>>>>
>>>>>
>>>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: read_grib.cc
Type: text/x-c++src
Size: 46475 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/met_help/attachments/20080507/767217ac/read_grib-0001.bin
More information about the Met_help
mailing list