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

19990819: decoding grib by XCD

>From: "Jennie L. Moody" <address@hidden>
>Organization: UVa
>Keywords: 199907281535.JAA02200 McIDAS GRIB DMGRID

Jennie,

>Tom, hope you got some relaxing in (maybe you are still off
>relaxing)

Well, I did take several half days off after the workshop ended.
I am diving back into some fun stuff after I plow through some email
that has been building up.

re: GRIB decoding not working as per my previous assumption
>Well, not the way you said they should work.  For starters, the
>option to use POINTER= on the DMGRID command from within McIDAS
>didn't seem to work in resetting the pointer in GRIBDEC.PRO.

The POINTER= keyword on DMGRID doesn't change the value in GRIBDEC.PRO;
it supercedes the value that DMGRID reads from GRIBDEC.PRO.  The
sequence is that DMGRID reads GRIBDEC.PRO to get a value that is stored
and puts the value in a variable called 'reset'. It then checks to see
if this value is overridden on the command line by the POINTER=
keyword; if it is, the value specified by POINTER= is used.

>But
>when I remembered I was running this on aeolus which is still using
>code from McIDAS7.1, I decided to look at the source for the decoder
>dmgrid and I found that this was a change in the newer distribution,
>so, I guess we shouldn't have expected it to work (right?).

There are several changes between the 7.1 and 7.5 versions of dmgrid.pgm,
but the use of POINTER= has stayed the same.  I think that the misconception
was that specifying POINTER= would actually change the value in GRIBDEC.PRO;
it doesn't.

>But, I still thought I would be able to change the value of the pointer
>in GRIBDEC.PRO to read the "top" of a new spool file, so I tried to
>use the LWU POKE command which you recommended, but this gives an error:
>
>LWU POKE GRIBDEC.PRO 4096 0
>LWU: Word number specified is past end of file.
>LWU: Maximum word number for LW file GRIBDEC.PRO is:

This should have worked since the syntax is correct.

>I was able to list the value, but couldn't change it:
>
>LWU LIST GRIBDEC.PRO
>       0.    2222337 -2139062144 HEX: 0021E901 80808080 ASCII:  !
>       2.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>       4.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>       6.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>       8.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>      10.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>      12.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>      14.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>      16.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>      18.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>      20.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>      22.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>      24.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>      26.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>      28.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>      30.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>      32.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>      34.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>      36.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
>      38.-2139062144 -2139062144 HEX: 80808080 80808080 ASCII:
> --END OF LISTING
>
>I don't get it.

Was the file writable?

>However, if we play around with just copying the
>(er, catting through xcd_run is what I mean) the same file over and
>over again until the spool catches up with the pointer, then we 
>can keep it working....but its a pretty kludgie (sp?) way of
>doing things.

This doesn't make any sense to me.  I can manipulate any file that
'mcidas' owns from a McIDAS-X account running as the user 'mcidas'
using LWU POKE with no errors.  I suspect something is amiss premission
wise, or in a REDIRECTion or MCPATH that is being used to locate
GRIBDEC.PRO.

>Since we are continuing to access archived files
>for a number of different reasons, if you have any more solutions
>for changing the pointer, I would be happy to listen to them.

Let's find out why things that should be working are not before trying
to come up with different techniques.

>Is it safe (or stupid) to just copy the new dmgrid source code over
>and compile it on aeolus?  

I don't know if this would work or not.  If you really want to try it
out, then make a backup copy of the 7.1 version of dmgrid.pgm before
you copy over the new one.

>Maybe I should start working on a way to decode grib files on windfall
>in some way that will not interrupt the real-time data we are ingesting
>routinely??

How about you giving me the login to the exact environment in which
you are attempting to do the decoding.  That way I can go through the
steps that I think should work and see what fails.  Once things are
cleaned up, then we could probably "can" a procedure that is more
"pushbutton".

>Anyway, its working, but....

But sounds ugly!

Later...

Tom