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

19990501: mcidasx at stc

>From: address@hidden
>Organization: St. Cloud State
>Keywords: 199904091934.NAA23884 McIDAS-XCD

Alan,

re: changing number and size of frames
>I did decide to try this, (change -f flag) so just need the right 
>combination of LIN and ELE.  We have the 17 " gateway monitors.
>Will try your combination next.

It is not so much the size of the monitors, but, rather, what resolution
you are running them at.  If, for example, you were running the displays
in 600x800 mode, you would not want to try and start a McIDAS session
with frames larger than about 480x640.  The other thing is that a ratio
of lines to elements of about 0.75 seems to be most pleasing to the eye.
This is why you will see standard screen resolutions of 480x640, 600x800,
768x1024.

>Are there any specific actions that we should not do, so as to prevent 
>a crash or some other failure?

You should make sure that data scouring occurs every night.  I setup the
scouring from a cron entry in the 'mcidas' account, so you _shouldn't_
have to worry about things, but there are sites that have reported that
the scouring fails from time-to-time for no apparent reason.  After
you add gridded data to your XCD decoded set, this issue will be even
more important (since the gridded data sets are so large).

The other things you will have to play with are:

o how many sessions you want to be able to run off of a single machine
  This will be limited by system RAM, disk, and CPU speed.

o you will need pay attention to the ROUTE PostProcessing activities
  that are going on, but, for the most part, this is a pretty much
  hands off operation.  The thing to be aware of is if your machine's
  performance takes a dip, you will need to look for processes that
  have not terminated properly and are eating up your CPU.  Again,
  this is not something you have to worry about until it happens.

o you will have to pay attention to what applications are running at
  the same time since some take up a lot of the colors that are
  available to you.  You have already run into this with Netscape.
  When out of colors in McIDAS, you will need to EXIT out of it
  and close down applications that are using up your color table.

o as far as crashing goes, McIDAS, the LDM, and ldm-mcidas typically
  don't mess things up enough to cause the system to crash.

o you will need to stay on top of security patches for the operating
  system.  This has nothing to do with McIDAS, it is just one of those
  system administration jobs that can not be overlooked.

>Waldo has 256 MB ram with a 400 Mhz Pent. II processor and a 10GB
disk.  >the other 2 machines are the same, except only 128 MB of ram.

These sound like solid machines.

>The other terminals in our lab I think are all pentiums with 200 Mhz and 
>disks of at least 1 GB.  I think the ram on those is 64 MB.  

You may want to consider adding an additional 64 MB of RAM to these
machines if/when you upgrade them to Solaris x86.  They will run better
with more RAM, but, then again, this is a true comment no matter how
fast your machines are.  Also, RAM is cheap right now.

>Thanks

Here are some of the last tweaks to your LDM/ldm-mcidas/XCD setup:

o I turned off decoding of the MDXX products in the UW datastream
  to cut down on the processing waldo has to do and to cut the umbilical
  cord, so to speak.  The MD files being created by XCD have much more data
  than the MD files in the UW datastream, AND they provide the data to you
  in a lot more timely manner.  Again, since the MDXX files in the UW
  stream are going away on July 1, cutting your dependency on them now only
  makes sense.  While I was at it, I deleted the UW MDXX files in
  /var/data/mcidasd.
  
o since I stopped the decoding of MDXX files from the UW datastream,
  I edited /home/mcidas/workdata/mcscour.sh to remove the scouring of
  those files:

  changed:

lwu.k DEL ROUTEPP.LOG
batch.k \"BROADCAST.BAT
exit

  to:

lwu.k DEL ROUTEPP.LOG
# batch.k \"BROADCAST.BAT
exit

  (i.e. commented out the batch.k \"BROADCAST.BAT invocation)

o I changed the directory into which the GRID files from the UW datastream
  are decoded.  Previously, the files went into /var/data/mcidasd; now
  they are going into /var/data/mcidas.  My objective here is to get to
  a point where you have one directory containing McIDAS data products
  instead of two.  This change was made in /usr/local/ldm/etc/pqact.conf:

  changed:

MCIDAS  ^(GUNRV2 .*)
        PIPE    -close
        gunrv2 -d /var/data/mcidasd -v

  to:

MCIDAS  ^(GUNRV2 .*)
        PIPE    -close
        gunrv2 -d /var/data/mcidas -v

  These files too will be going away on July 1.

o I also changed the directory into which the UNIDATAS file from the
  UW stream is put from /var/data/mcidasd to /var/data/mcidas.  Again,
  this is force the use of one directory for McIDAS data files.

  UNIDATAS is another one of the files from the UW datastream that is
  going away on July 1.

o finally, I turned off verbose logging of ldm-mcidas decoders.  This
  was done by removing the '-v' flag on each of the ldm-mcidas decoder
  entries in /usr/local/ldm/etc/pqact.conf.

After making the various changes in the LDM pqact.conf file, as 'ldm' I
sent a HUP to the pqact process telling it to reread its configuration
file:

cd /user/local/ldm/etc
<make changes in pqact.conf>
ps -eaf | grep pqact
     ldm  8968  8876  0 21:22:59 pts/1    0:00 grep pqact
     ldm 22213 22209  0   Apr 29 ?        1:00 pqact
kill -HUP 22213
tail ~/logs/ldmd.log
May 01 21:21:03 waldo pqact[22213]: ReReading configuration file /usr/local/ldm/
etc/pqact.conf

I did the tail on the log file to make sure that there were no errors
in pqact.conf.  If there were, there would be a line (or lines) in ldmd.log
complaining about bad lines in pqact.conf.

The only things that I found strange when I was doing the cleanup this
afternoon were:

o the existence of the file STRTABLE in /var/data/mcidasd

o the existence of a core file from mcwish in /home/mcidas/workdata

We will have to watch for whatever process created the STRTABLE file in
/var/data/mcidasd.  It should NEVER exist in that directory.  As you
might recall, STRTABLE is the McIDAS string table.  It should exist in
the user's McIDAS working directory (/home/mcidas/workdata for
'mcidas'; ~user/mcidas/data for all other users). It does get created
automatically by the McIDAS startup process in a directory in each
user's (hidden) .mctmp directory, but that copy is not used since the
REDIRECTion specified in LOCAL.NAM (an edited copy of EXAMPLE.NAM;
edited to match your system setup) is for the user's McIDAS working
directory.  The existence of STRTABLE anywhere else could mean that
there is a problem somewhere or that someone incorrectly setup their
MCDATA environment variable to be there (/var/data/mcidad) instead of
their McIDAS working directory.  Anyway, I removed the file.

All that is left in your /var/data/mcidasd directory is ROUTE.SYS,
SYSKEY.TAB, and SCHEMA.  These files are actually hard links to the
copies in the /var/data/mcidas directory, so they are not taking up any
additional disk space.  In a couple of days, I think that we should
remove these files (links) and get rid of the /var/data/mcidasd
directory altogether.

Talk to you later...

Tom