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

19990728: Grib Decoding (cont.)

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

Jennie,

>Well, I was premature in stating that we had solved the problem with
>reading grib files and decoding them with DMGRID into mcidas Grid files
>(recall, we are trying to work with grib files I got from COMET).  This
>pointer seems to be a problem, GRIBDEC.PRO is supposed to tell the
>datamonitor (DMGRID) the last byte read from the spool, however, when
>we try to continue from a spool that we think was read correctly, by
>just adding in new data (cat'ing new data to the spool with a pipe
>through xcd_run, which runs ingebin and makes the file HRS.SPL (or
>appends to HRS.SPL if it already exists), then we seem to have
>problems.

I am very suprised about this since this is exactly how decoding of
the data in the IDD works.  DMGRID can exit and be restarted by the
supervisory routine 'startxcd.k' and data gets added to the spool
whenever it comes in.  Can you see how this situation is different
from yours?

>I would like to try to deal with this by resetting the spool
>file each time, and then just resetting the pointer, but I don't know
>how to do this, is there a way to make GRIBDEC.PRO think that the last
>byte it read was '0', so it will start at the top of the spool?

Yes.

>It's a binary file, so I don't know how to do this....

DMGRID has a keyword called POINTER= that tells it where to start
reading in the spool file.  This is the override that you are looking
for.

You want to use POINTER= to tell DMGRID to start reading from the
beginning, which is word 1024 or byte 4096 (the pointer is in terms of
bytes from the beginning of the file):

DMGRID POINTER=4096

Since you need to run DMGRID in a non-default way to do this, you need
to NOT run 'xcd_run MONITOR' as this starts 'startxcd.k' which, in
turn, starts DMGRID but does NOT pass along the POINTER= keyword.  What
you would want to do is to:

either

o run everything from a McIDAS-X session (this is the easiest thing to do)
  so you can run DMGRID specifying the POINTER=4096 keyword sequence

or

o make a copy of 'xcd_run' into something else (to get the McIDAS environment
  setting stuff)
o replace 'exec startxcd.k' with 'dmgrid.k POINTER=4096'

If you don't want to do either of the above, you can change the pointer in
GRIBDEC.PRO by using the 'LWU POKE' command:

lwu.k POKE GRIBDEC.PRO 4096 0

BEFORE DMGRID starts to run.

The online help for LWU shows one how to change values in a file:

HELP LWU
LWU - LW file utility
  LWU COPY sfile dfile
  LWU DEL file
  LWU INFO file
  LWU LIST file bword eword
  LWU MAKE file
  LWU POKE file value word ASCII=
Parameters:
  COPY | copies a file
  DEL | deletes a file
  INFO | lists the file and its size in bytes
  LIST | list words in the file
  MAKE | creates a file
  POKE | pokes a value into a file
  sfile | source file name
  dfile | destination file name
  file | name of the file
  bword | beginning word number to list, range 0 to 8000000 (def=0)
  eword | ending word number to list range 0 to 8000000 (def=39)
  value | value to poke into the word (def=0)
  word  | number of the word to change (def=0)
Keyword:
  ASCII=YES | POKE the specifed "value" as ASCII characters; see the
              Remarks (def for all non-numeric values)


>If this question is confusing, or if you don't have the time to type an
>answer,

Well, I don't really have the time, but ...

>(or get clarification and then answer), let me know a good time
>and I will give you a quick call (trying not to abuse the "last resort"
>aspects of calling for help).

Phone calls take more time than email responses, not less.

>This is pretty frustrating.

I am still curious about why picking up where you left off doesn't work;
it should.

Tom