[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20020612: GRIBDEC tests for AMPS grib messages at the UPC (cont.)

>From:  Matthew Lazzara <address@hidden>
>Organization:  SSEC
>Keywords:  200206122001.g5CK1VJ19501 McIDAS GRIBDEC AMPS grib


I checked into why McIDAS is unable to plot decoded AMPS grib messages,
and I don't like what I found!

Two things:

1) McIDAS does not know how to deal with gridded data in Polar
   Stereographic projection that is not in the Northern Hemisphere!

2) the XCD grib decoder does not decode or store the hemisphere that
   PS grids lie in

This is incredible to me!!

So, what to do?  It seems that to use the AMPS grib data in McIDAS, two
code mods have to be made, one in the XCD decoding and one in the
navigation code for grids.  I will try and set aside the time to make
the mods so that they make it into my McIDAS V2002 release.  I will
also retrofit the mods to my 7.8x release.  Lastly, I will update the
SSEC CVS with the mods so that they can be incorporated in a
Fasttrack.  Exactly when I will be able to get to this is unknown,
because (like I said before) I am swamped.

Color me (once again) frustrated by McIDAS.


Previous email:

>>In checking further - it is worse that I describe...both latitude and
>>longitude aren't correct - everything is stuffed into -60s and -44s or
>>Just another tidbit for you.
>I downloaded the grib file from MMM myself so I could play around with
>gribdec.k.  I found the same thing as you which is discouraging.
>In order to see if the problem is in the AMPS grib output or in the
>McIDAS decoder/display routine, I asked Chiz to decode the grib
>messages in GEMPAK.  He could both decode and display the U and V grids
>with no problems.  He couldn't display the T grids, but that was
>because they had been written to the same grid file as the U and V
>grids AND the grid sizes are different (in GEMPAK, all grids in a grid
>file must be on the exact same grid (same nav; same number of points;
>The point is that GEMPAK did not have a problem with the AMPS model
>output, but McIDAS did.  Now the question is why McIDAS is having the
>problem.  This is something that I will have to investigate in detail.

* Tom Yoksas                                             UCAR Unidata Program *
* (303) 497-8642 (last resort)                                  P.O. Box 3000 *
* address@hidden                                   Boulder, CO 80307 *
* Unidata WWW Service                             http://www.unidata.ucar.edu/*

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.