19991007: Installing McIDAS and LDM on Irix 6.5 (cont.)

>From: Erick Lorenz (address@hidden) <address@hidden>
>Organization: UC Davis
>Keywords: 199910011836.MAA28054 McIDAS-X DEX OSF/1 4.0F Tcl

Erick,

>Since I wrote this last message a lot of things have gotten better.
>
>With the help of Devin Kramer at UCLA I was able to clear up some
>of my fuzziness about the way things work and managed to accomplish
>most of your suggestions.

OK, sounds good.

>This is the essence of my ldmd.conf now
>
>       exec    "pqexpire"
>       exec    "xcd_run MONITOR"
>       exec    "pqact"
>       exec    "pqbinstats"
>       #exec   "pqsurf
>
>       "request (DDPLUS|IDS|HRS) ".*" typhoon.atmos.ucla.edu 

What about MCIDAS?  You need MCIDAS for the Unidata-Wisconsin images.
I suggest that your request should look like:

request UNIDATA ".*" typhoon.atmos.ucla.edu

UNIDATA includes all of the above and MCIDAS.

>It still hangs when I start ldm but when I control-C all the necessary
>processes are running and I am getting data hand over fist.

This needs to be looked into further.

>I took out the reference to MCIDAS because on ATM12 it seemed to be
>cycling at 4 area files, eg 120,121,122,123 and back to 120 whereas
>ATM23 is still cycling at 10 area files, 120-129 so for the moment
>ATM23 is my AREA file retriever.

It does this when there is no copy of ROUTE.SYS in the output data directory.
The Unidata-Wisconsin broadcast is setup to keep 4 of all images except
Manually Digitized Radar.  For that one it keeps 6.

>In keeping with my modification to ldmd.cond I have commented out
>the MCIDAS line in pqact.conf.  I think one of my problems here
>was a blank where there shouldn't have been one.  After I 
>edited this section I started getting AREA files.

If you have no request for MCIDAS in ldmd.conf, you can't be getting
AREA files UNLESS you didn't stop and restart the LDM after making the
changes to ldmd.conf.  I assume, of course, that you don't have another
request line in ldmd.conf that relates to MCIDAS.

>I will send you a password tomorrow (Thursday).

I did not get one.

>Things are going much better now, ATM12 is suppling the XCD data
>and ATM23, the AREA data.  I had to mount
>
>atm23:/lore/data/mcidas as /home/data/mcidas on atm12
>atm23:/lore/data/xcd as    /home/data/xcd    on atm12
>
>because the only disk space I had available on ATM12 filled up and
>froze other processes.

OK, so you are using the different machine to get the images.  I would do
all on one machine if it is suitably configured and is fast enough.

>Since there is such a plentitude of data I am trying to find out
>whether we need it all or can I filter some of it out in
>pqact.conf.  I am not sure what the correspondance is between 
>each of the data types and the file names being produced by XCD.

XCD decodes everything it can if the data monitors are turned on.
If you have real space issues, you will want to:

o turn off AIREP/PIREP decoding
o possibly turn off SYNOPTIC decoding
o scour vigorously
o limit what data you ask for

>When we run MCGUI some of plots produce NO DATA or strange
>readings like surface temperatures of 43 degrees everywhere.

Sounds like the data is munged.  I suspect that the MD file is
corrupted.

>I am hoping that 24 hours of uninterupted data will fill in the
>blanks but I am also concerned that I may need to tinker
>with the ROUTE table or something like that

Right.  The routing table is needed to set how many images (i.e. AREA
files) of each type that you want to keep.  A copy of SYSKEY.TAB is
needed in the output directories for XCD and ldm-mcidas decoders.
This copy of SYSKEY.TAB needs to be findable by each user session that
will run McIDAS.  Findable means that you should have a REDIRECTion in
each user's environment that points to that copy of SYSKEY.TAB.

Now, since you have two different data directories, you will need to
put a copy of SYSKEY.TAB in to one and link it to the other.  This is
the only way that you can have the same file in two directories at once.

>In the morning I will try to compile a list of missing stuff

OK.

>After tomorrow may I introduce you to a student assistant who
>will be keeping the system going while take a vacation?

OK.

>Thanks

>From address@hidden  Thu Oct  7 16:41:34 1999
>
>Hi Tom, are you back yet?  I don't want to rush you but if you are
>available I would like to get the last few loose ends tied up.

I am back at Unidata now.

Tom