>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
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.