[Met_help] Re: MET (MODE) problems

[John Halley Gotway]

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
>