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

20010813: dmgrid (cont.)



>From: "Molenar, Deb" <address@hidden>
>Organization: CSU/CIRA
>Keywords: 200108131538.f7DFcu123516 McIDAS-X 7.8 DMGRID

Deb,

>Back to gribdec (wahh!!!).  This is one of those endless loops from hell
>-- we tried gribdec last winter, and tried replacing the tables with the
>latest mcidas ones, but still found that it didn't produce output in the
>right resolution for some of the newer formats (AVN).

Well, gribdec is just a repackaging of the XCD grib decoding stuff.  The
difference -- as you note -- is that the gribdec bundle is not up to date.
I am disappointed to hear that simply using the newer grib definition
files did not help out.

>Then, someone said
>"Don Murray wrote a grib converter that should be up to date..." so that
>was my hope for dmgrid.

This is interesting and untrue as far as I can tell.  What did happen
quite some time ago was Don used Unidata code in replacement of some
SSEC code that made doing the grib decoding work on little endian
systems (in addition to big endian systems, that is).  This work was
incorporated into XCD at least two years ago.

I ran into grib messages that both the XCD stuff and gribdec could not
decode.  I _think_ that this was the exact same stuff that you are
running into now:  high resolution AVN model output.  It seems to me
that dmgrid/gribdec need to be updated to handle these grib messages.
I think that the person in SSEC that is now charged with looking after
XCD is Todd Smith, who you obviously know since he was at CIRA before
moving over to SSEC.

>HOWEVER, I did not personally try the modified
>gribdec and am relying on the word of someone from met staff
>(notoriously unreliable those mets) and so will give it a try to be
>sure.  If it does not work, I will investigate other options & might be
>getting back to you.

OK.  I think that we both have the same objective here: having a decoder
that can handle the high resolution model files that one can grab from the
NIC.

>Thanks!  Hope you can relax now that you're training is over, and enjoy
>what's left of the summer!

Well, I have to finish some of the web stuff related to my 7.8 distribution
and actually announce it.  I don't know if you tried it out, but I have
the first _real_ stab at a GUI for McIDAS.  This GUI is hardwired for
ADDE datasets that are in general use in the Unidata community.  The GUI
will be generalized as I get comments back from non-Unidata sites.
If you get a chance and have the inclination, do the following when starting
a Unidata McIDAS-X session:

o delete (save a copy of) your ~/.mcidasrc file
o start Unidata McIDAS as follows:

  mcidas config

o specify that you want to start the MCGUI interface when 'mcidas' is run
  (i.e., click the MCGUI radiobutton near the bottom of the interface)

o specify that you want to save the changes you are making.  At this point
  you are working off of .mcidasrc defaults, but no .mcidasrc file exists.
  Selecting the save option will write a new .mcidasrc file for you

You may need to set/change a file REDIRECTion for SYSKEY.TAB.  Everything
should work OK if you do not have a REDIRECTion for SYSKEY.TAB, since the
copy installed in the ~mcidas/data directory should be found by virtue
of your MCPATH.

After the GUI is up, you will need to click on the funky icon at the
top of the GUI; the one that is one computer over the other connected
by arrows.  This widget will allow you to specify the name(s) of the
ADDE server(s) that will provide access to the datasets that the GUI
will currently work with.  Each entry in the GUI has a number of options
for which server to use.  These are exposed by clicking on the arrow
at the right of the entry.  I would suggest pointing at ADDE.UCAR.EDU
to begin with for everything.  You can then use the GUI to look at
a variety of data; do loops of imagery; etc.  Again, if you have the
time and the inclination give the GUI a whirl and let me know what
you think.

Tom