20010531: decoding model output data in McIDAS (cont.)

>From: "Wayne Bresky" <address@hidden>
>Organization: Cornell
>Keywords: 200105161402.f4GE2Jp07535 ADDE

Wayne,

>Unfortunately, I'm still having a problem decoding the
>GRIB data for McIDAS.

OK.

>McIDAS-XCD is installed
>on the system and I see the various decoders/data monitors
>running (see below).

>ldm       5474  5453  0 May29 ?        00:00:51 ingebin.k HRS
>ldm       5475  5452  0 May29 ?        00:02:43 ingetext.k DDS
>ldm       5415  5476  0 06:51 ?        00:00:14 DMSFC
>ldm      11240  5476  0 08:59 ?        00:00:00 DMMISC
>ldm      11543  5476  0 09:02 ?        00:00:01 DMRAOB
>ldm      11596  5476  0 09:10 ?        00:00:02 DMSYN
>ldm      13917  5476  0 09:49 ?        00:00:00 [dmgrid.k <defunct>]

This list tells me that you have correctly setup the 'xcd_run' entries
in the LDM's pqact.conf file (otherwise ingebin.k would not be running
unless you started it by hand).  This is good, but I am disturbed by
the defunct dmgrid.k process and the lack of the startxcd.k process.
startxcd.k is the supervisory routine whose job it is to (re)start the
various data monitors.  It is in a continuous loop of sleeping followed
by reading the decoder start/stop information (controlled by DECINFO
(decinfo.k), starting and stopping data monitors that should or
shouldn't be running, and then sleeping again.  startxcd.k is started
at LDM startup by the script xcd_run from an entry in the LDM's
ldmd.conf file.

>I manually started the GRIB decoder
>and data monitor by typing in the DECINFO commands
>listed on the web page, but the only DMGRID process I
>see running (or not running) is listed as defunct.

Just so I am sure that we are on the same page, I take your comment to
mean that you:

logged on as 'mcidas'
cd workdata
decinfo.k SET DMGRID ACTIVE

and then waited for startxcd.k to start DMGRID (dmgrid.k).

>I must
>be overlooking something, but I don't know what it could be.

Assuming that startxcd.k did actually try to start DMGRID (dmgrid.k),
I would begin looking at several things:

o is the dmgrid.k executable (located in ~mcidas/bin) viable (e.g., non
  zero in length; can find all needed shared libraries; etc)

o does the user 'mcidas' have file REDIRECTions for files named GRID5* 
  and GRID6000 pointed at a directory in which both 'ldm' and 'mcidas'
  have read/write privileges

o is there a valid REDIRECTion for the file HRS.SPL; this is the spool
  file that contains raw model data.  It is written to by ingebin.k
  and read by dmgrid.k.  HRS.SPL will be 32 MB in size, so it should
  most likely live in the same directory in which you will be creating
  your output GRID files

o has the file GRIBDEC.PRO been created.  This will typically end up
  in the ~mcidas/workdata directory.

o what does the DMGRID.ERR (~mcidas/workdata) file show.  Is it listing
  a succesion of datamonitor restarts.

Is there a possibility that I could get a login as 'mcidas' and 'ldm'
on the machine you are running XCD on.  If yes, please send the machine
name info to support and the password info to me personally
(address@hidden) or leave the information on my voicemail
(303.497.8642).

>BTW, the NNEXRAD data you helped me set up is coming in beautifully.
>And the prune_nexrad script is working just fine.  :-)

Super.  Glad to hear it.  Have you successfully setup ADDE access to
the data?

Tom

>From: "Wayne Bresky" <address@hidden>
>Keywords: 200105161402.f4GE2Jp07535 ADDE

Wayne,

re: is startxcd.k running

>I did not send the entire process list.  The startxcd  process
>is indeed running.

OK.

re: how did you activate DMGRID

>That is correct.  Actually, I typed two commands:
>
>DECINFO EDIT DMGRID GRIB ACTIVE CONFIG=GRIBDEC.CFG
>DECINFO SET  DMGRID ACTIVE

The first DECINFO above was not necessary, but it should have done no
harm.

>One other thing I neglected to mention.  The following line was
>commented out in HRS.CFG and I uncommented the line:
>
>PORT=/dev/ttyC3
>
>Should this line be commented or uncommented?

This should be commented out.  The first three entries in HRS.CFG should
look like:

FILE=STDIN           # Standard in; used for feed from Unidata LDM

#PORT=/dev/ttyC3      # port tty name
SPOOLENG=32          # size of the spool file to use in megabytes

All of XCD was designed to read from serial ports.  This suites sites
that have NOAAPORT data ingestion systems that can be accessed by
serial ports for the various services.  The _great_ majority of Unidata
sites are getting their data through our IDD via an LDM.  In this case,
the binary ingester process ingebin.k will be fed model data through
STDIN, not through a serial port.

Your umcommenting of the PORT= line in HRS.CFG may, in fact, be your
only problem in ingesting/decoding model data.

re: turn on GRID decoding with DECINFO and then let startxcd.k start DMGRID

>correct

Good.  I just wanted to make sure that I understood exactly where you were.

re: is the dmgrid.k executable (located in ~mcidas/bin) viable (e.g., non
zero in length; can find all needed shared libraries; etc)

>Yes, it is.
>-rwxrwxr-x    2 mcidas   unidata    215132 Feb 14 14:49 dmgrid.k*

OK.

re: do you have a REDIRECT for GRID5* and GRID6000

>The GRID5* redirect exists
>GRID5* /var/data/xcd
>but I do not see one for GRID6000.  Is this critical?

It is needed because of the change in AVN grids that occurred in April.
The 7.705 addendum has an updated EXAMPLE.NAM that included this REDIRECTion.

If you do not have a REDIRECTion for GRID6000, it will be written into the
first writable directory in the user 'mcidas' MCPATH.  If things are setup
as I say they should be, this would be $HOME/workdata (where HOME is the
home directory for the user 'mcidas').

re: is there a valid REDIRECTion for HRS.SPL

>Yes, I see the redirection for HRS.SPL
>HRS.SPL /var/data/xcd
>but, the file doesn't exist
>ls: /var/data/xcd/HRS.SPL: No such file or directory

I am betting that this is due to your uncommenting the PORT= line in HRS.CFG.

re: what about GRIBDEC.PRO

>I see the GRIBDEC.PRO file but all it has in it is the following
>
>more GRIBDEC.PRO
>Ryº

It will only have one 4-byte integer word in it.  By the way, the way
to list out contents of binary files in McIDAS is to use LWU:

LWU LIST GRIBDEC.PRO

The output is like a combination of 'od -d', 'od -x', and 'od -c'.  This
is a very useful command for power McIDAS users.

re: what does the contents of DMGRID.ERR look like

>I've been looking at this file for a few days.  Here's a partial listing
>
>01151  065344 DMGRID       Starting: GRIB decoder
>01151  065414 DMGRID       Starting: GRIB decoder
>01151  065444 DMGRID       Starting: GRIB decoder
>01151  065514 DMGRID       Starting: GRIB decoder
>01151  065544 DMGRID       Starting: GRIB decoder
>01151  065614 DMGRID       Starting: GRIB decoder

OK, the decoder is being restarted often.  This is due to it exiting
probably because of the PORT= line issue.

re: logins

>At the present time, I only know the root password (recall I am taking
>over for Jim Marco).  So I've just been using su mcidas and su ldm to
>become those users.  I should probably change the passwords, but I haven't
>done it just yet.

OK, the login may not be necessary after all.  Try changing HRS.CFG back
to what it was in the distribution and see what happens.

re: successfully setup ADDE access to the NEXRAD Level III products

>Yes, I have.

Very good.

Tom

>From address@hidden Thu May 31 14:05:15 2001
>Subject: 20010531: decoding model output data in McIDAS (cont.) 

>I commented out the PORT line in HRS.CFG and restarted the
>LDM server (I wasn't sure if I needed to restart the server, but
>I figured it couldn't hurt), but the problem is persisting.

OK (and you didn't have to restart the LDM, but you are right, it couldn't
hurt).

>Ironically enough, I only made the change in HRS.CFG because
>everything else appeared to be ok.  I thought maybe Jim had commented
>out the line because he didn't want to decode the GRIB data.

OK.

>Anyway, the dmgrid.k process is still showing up as defunct:
>
>ldm      24973 24095  0 13:33 ?        00:00:00 [dmgrid.k <defunct>]
>
>If you still feel like poking around on the machine, I wouldn't object to
>it.  :-)  Do you have secure shell?

Yes, we use ssh.

>And what IP would you be coming in from?
>I'll have to add it to the hosts.allow file.

XXX.XXX.XXX.XXX

Again, send the machine information and passwords to two different accounts
or put them on my voicemail.

Tom