[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

Matthew,

>Thanks for this too...ugh...I understand, it is frustrating....Mods will
>be needed by me (AMRC), and SPAWAR too. (I'm sponsering them to have
>McIDAS until they decide to join the MUG).

Right.  It might be easiest if SPAWAR gets the Unidata distribution
of McIDAS after the mods are made.  I put out updates as soon as they
are ready to go.

>I'll report this verbally to Dee and Dave...unless you'd rather I
>didn't.

On my way home I got to wondering if I was wrong about the support
for PS grids in the southern hemisphere.  It would seem to me that the
BoM folks would have run into this a long time ago and, at least, made
comments about it.  The first thing I did was to dump out the nav block
in the first grid that was decoded from the AMPS grib message file.  In
that grid, the two standard latitudes were both 60.  This seemed odd
since the grid is in the southern hemisphere.  I changed the values in
the file (using LWU POKE) so that the values were both -60 (actual
values in the nav block were -600000) thinking that that might be all
that was needed.  After making the change, I tried to plot the contours
of the modified grid, and I got a message that nothing could be plotted
since the field was a constant.  This led me to believe that the fix is
more complicated than simply determining the correct hemisphere for the
grids.

My first reading of the code in grddef.for left me with the impression
that the hemisphere for the data was not being taken into account.
A second reading of the code now makes me doubt my first conclusion:

      ELSE IF(ITYP.EQ.2) THEN
         XROWI=IGHD(35)/10000.
         XCOLI=IGHD(36)/10000.
         XSPACE=IGHD(37)/1000.
         XQLON=IGHD(38)/10000.
         XT1=IGHD(39)/10000.
         XT2=IGHD(40)/10000.
         XH=SIGN(1.,XT1)
         XT1=(90.-XH*XT1)*XRAD
         XT2=(90.-XH*XT2)*XRAD
         XFAC=1.0
         IF(XT1.NE.XT2) XFAC=(ALOG(SIN(XT1))-ALOG(SIN(XT2)))/
        &        (ALOG(TAN(.5*XT1))-ALOG(TAN(.5*XT2)))
         XFAC1=1.0/XFAC
         XBLAT=6370.*SIN(XT1)/(XSPACE*XFAC*TAN(XT1*.5)**XFAC)
         ASSIGN 20 TO NXA
         ASSIGN 25 TO NXB
         IF(JTYP.EQ.1) THEN
            X=XNR
            XNR=XNC
            XNC=X
            X=XCOLI
            XCOLI=XROWI
            XROWI=XNR-X+1.0
            XQLON=XQLON+90.
         ENDIF

The variable XH appears to set the hemisphere based on the first
standard latitude: if XT1 is less than zero, XH is set to a minus one.
This would make sense for PS grids since both standard latitudes would
be negative for grids in the southern hemisphere.  I now don't know why
simply changing the sign of the standard latitudes in the grid nav
block did not work.  I will have to revisit this first thing tomorrow.

So, why don't you wait before talking with Dave, or, if you do talk
to him, ask him if the intent of the XH code above in grddef.for is
for support of southern hemisphere grids.

>As for when you can get these fixes in, my hopes for getting this data
>flowing are sometime this summer...I don't know how fast SPAWAR wants
>this - I figured before WINFLY (that is late August).

I am aiming to have my V2002 release ready for download by the time of
my McIDAS workshops in late July/early August.  If the code mod 
needed is only in the XCD stuff, then the fix could be ready as early
as tomorrow sometime.  If the problem lies deeper, it will take longer.

>If it is o.k.
>with you, I'll keep the MMM and SPAWAR folks informed, and see what
>SPAWAR time is (I may call them up about tomorrow).

You could report back the fact that the grib data looks good (based on
the ability of GEMPAK to decode and plot the data correctly).  This,
after all, is really the information the folks from MMM are waiting
for.  With any luck, the mods to allow McIDAS to work will be ready
shortly, and could get into a quick Fasttrack that would be available
before the SPAWAR guys need to grab McIDAS.  The other option is that
they could grab the Unidata release since I will roll the fix in as
soon as it is implemented and found to work.

One question to ask the MMM folks: the size and location of the U and V
grids is slightly different than the size and location of the T grids.
Is this difference expected/correct, or is there some problem in the
creation of the grib messages?

>Let me know how you feel about this, and I'll proceed from there.

I would report:

o the grib output appears to work
o McIDAS will need to be tweaked to handle the grids

Its late.  Talk to you tomorrow (later today, that is)...

Tom