20011118: McIDAS vis-a-via Solaris 7/8 (cont.)

>From: "James R. Frysinger" <address@hidden>
>Organization: College of Charleston
>Keywords: 200111061842.fA6Igt112242 McIDAS platfomrs

Jim,

>I installed McIDAS 7.8 on my machine at home last night. In fact I did 
>it twice because it was so easy. Alright, I did it the second time 
>becaues I goobered up the first installaion by inadvertantly running 
>make uninstall instead of make install in the wrong directory. BOB 
>needs new eyeglasses or something....

All the uninstall does is delete the links that are made between the
executables (and help, and man, etc.) in the ~mcidas/mcidas7.8/src
directory and the installation bin (and help, man, tcl, data, etc.)
directory.  A simple 'make install' will reinstall McIDAS-X (
'make install.all to install McIDAS-X and McIDAS-XCD).

>Both installations were done using the f2c and gcc that came with my 
>distribution (SuSE 7.2 with the 2.4.4 kernal). I had to put symbollic 
>links in those three /usr/local/--- files to link to the correct 
>locations for f2c, f2c.h, and libf2c.a. Both times make all ran in a 
>bit under 19 minutes (as compared with 63.5 minutes on the Sun Ultra 10 
>down on the campus, even though I was the only user logged in).

19 minutes is not bad at all.  The speed record, however, was sety by
Plymouth State College on their dual 1 Ghz P4 machine running FreeBSD.
The build for both -X and -XCD on that box took 7 minutes!

>The 
>first time I did it, I revised VENDOR in the makefile to -gcc but the 
second time I left it as -vendor. The f2c version I have onboard from 
>the distribution is 0.11-338 and the gcc is 2.95.3-52.

For systems that are not expected to have a VENDOR compiler, gcc/f2c
is considered to be the VENDOR compiler.  So, you really didn't have
to much with the VENDOR definition in makefile for your SuSE system.

>One possible problem I had at the start is that relating to shared 
>memory. (Why do we need that for single-cpu systems not involved in 
>parallel computing?)

McIDAS is composed of a large set of applications that "talk" to each
other (share information) through shared memory.  In particular, the
contents of frames (images and graphics) is stored in shared memory.
One does not need to even have X running in order to run McIDAS
applications.  This allows one to easily script McIDAS functionality
in Unix shell scripts run from cron.  This is why both of the following
work:

<from the Unix command line as 'mcidas'>
cd ~/workdata
te.k XCDDATA \"/export/home/mcdata

<from the McIDAS text and command window 'mcidas'>
cd ~/workdata
TE XCDDATA "/export/home/mcdata

>I inserted a line
>   echo 536870912 > /proc/sys/kernel/shmmax
>in /etc/init.d/boot.local (the SuSE version of Red Hat's rc.local) and 
>it gets read just before the run levels get set when the machine is 
>booting up. Yet, free shows zero bytes of shared memory, even though 
>I've rebooted the machine since then.

What does 'top' show?

>By the way, the original value 
>(from the kernel's build?) was ~32 MiB, though it too resulted in 
>showing zero shared memory on 'free'.

32 MB would have been plenty for your use at home.  The reason for
setting the shared memory to a large number is to accommodate multiple
concurrent sessions by multiple users.

>So far, that doesn't seem to have 
>created any problems. Here are a couple of lines from my boot.msg file:
>   Mount SHM FS on /dev/shmdone
>   ... [5 irrelevant lines]
>   doneRunning /etc/init.d/boot.local
>   ... [6 irrelevant lines]
>   Master Resource Control: previous runlevel: N, switching to 
>runlevel: 5
>
>       In case it's useful to you, here's the bash scripting I did 
>line-at-a-time in the terminal window to test the installation with 
>mcidasx:
>   mcidas@metric:~ > export MCDATA=/home/mcidas/mcidas7.8/data
>   mcidas@metric:~ > export 
>MCPATH=/home/mcidas/mcidas7.8/data:/home/mcidas/mcidas7.8/src
>   mcidas@metric:~ > export MCGUI=/home/mcidas/mcidas7.8/src
>   mcidas@metric:~ > export PATH=/home/mcidas/mcidas7.8/src:${PATH}
>   mcidas@metric:~ > export DISPLAY=0:0
>   mcidas@metric:~ > mcidasx

OK, thanks!

>   WARNING: only run as the user 'mcidas' for supervisory tasks

This warning is to remind you that you should think of 'mcidas' as 'root'
for McIDAS activities.

>The above is from a cut and paste, so there should be no typos.

Got it.

>       As far as ADDE is concerned, SuSE still uses inetd, not xinetd. I see 
>that there is use already specified for ports 500 and 503 as described 
>in the mcidas instructions and I'll play with fixing that problem 
>later.

That _is_ a problem with the ports that SSEC chose for ADDE.  Ports 500
and 503 are registered for other routines (these are the entries in
/etc/system).  We have been pushing for a cahnge to port 112 since we
(Unidata) registered use of that port for McIDAS-related things several
years ago.  This will happen at some point, but I am not exactly sure
when.

>But Unidata LDM got nicely assigned where it should!

Right.  We also registered port 388 quite some time ago for LDM use.

re: changing default X color depth

>Hmmm. Any clues on how to change that?

Since your next note indicates that youfigured this one out, I will
not comment.

>I take it that it's my machine 
>at home that's throttling the pipeline since my installation of McIDAS 
>at home (on SuSE linux distribution) also gave me
>    mcimage: Using slow processing for Z-16 images.

The "slow processing" message is archaic given today's computers; ignore
it.

re: recommend that you run in 24-bit mode

>I'll have to take a look at that. I have it set for 16-bit color since 
>I run a "17-inch"  monitor at a fairly high resolution (1024x768). I 
>went for resolution in order to see finer detail on satellite images. 
>My card is an Nvidia RIVA TNT2 Model 64.

I was going to comment on this yesterday, but you discovered that you
could run in high resolution mode with 24-bit color.  I run on my lowly
ATI 8 MB video card in 1024x1280 in 24-bit mode, so I knew you would
be able to do at least that with your newer hardware.

re: why 'TE XCDDATA "/export/home/mcdata' failed

>No, I'm sure that BOB made a typo there. (I'm beginning to understand 
>why Dole always talked like that!) It had to have said
>   XCDDATA := /export/home/mcdata
>because I checked it against my command.

Looking good.

re: DATALOC ADD TOPO fails is not good/understood

>Right. Don't know what to do just now. If I get a few spare minutes 
>around my teaching tomorrow, I may try testing it again to see if that 
>still happens. Sometimes computers benefit from a good night's sleep, 
>I've found. Must be those CRONTABS that the computer doctors prescribe.

:-)

>Interestingly, I did not have that problem on my installation at home 
>on linux! Maybe I made fewer mistakes this time.

OK.

re: IMGLIST TOPO/ALL listing

>OK. I didn't list them explicitly. What I was seeing then were other 
>subcategories that were listed below TOPO/ALL on the output screen, not 
>as part of TOPO/ALL. Had that confused.

OK.

re: Hardcopy!?  How 19th century ;-)

>BOB reads slightly better from paper than from the screen. Not enough 
>better perhaps.... Those make a nice place to take notes, too. I'm 
>finding that when I white-out notes I have scribbled on the monitor, it 
>messes up other displays.  ;-)

:-o)

re: MCGUI

>Is it going to be what I present to my colleagues with McIDAS 7.8 when 
>I get it ready for them?

Yes.

>A couple have glanced at my two-volume set of 
>printouts for the McIDAS 7.7 commands and have run for the door.

Any large application will have lots of functionality.  McIDAS is no
different.  The good news is that you don't have to use all of the
functionality if you don't want to.

re: McIDAS on MacOS 10

>Don't rush on my account. I still say that the best use for 
>macintoshes is to make apple pies. PCs are cheaper and linux 
>distributions are even more so. Free if you're a home-brewer of 
>kernals, modules, and peripheral programs. (I am most definitely not 
>the latter and think that $70 for SuSE professional is a cost savings 
>over my time that would be spent on doing that instead of physics. 
>Cheapskates can get the $30 personal version and upgrade for free as 
>needed.)

MacOS 10 is FreeBSD underneath!  It combines the best of Unix and the
Mac interface.  I am a PC guy myself, so I appreciate your comment(s).


>>From address@hidden Sun Nov 18 16:50:20 2001
>>Subject: Re: 20011117: McIDAS vis-a-via Solaris 7/8 (cont.)

>Man! Am I glad you said something about that! That led me to doing 
>some digging around that I've been putting off. As a result, I found 
>that I was still using a generic video driver instead of the vendor's 
>driver for my CRT. That led me to installing (and then later doing 
>online updates to) two programs for the Nvidia TNT2 card then running 
>sax2 to adjust my settings. I'm now up to a resolution of 1200x1024 at 
>24-bit color.

Now, that _is_ more like it.

>BOB's really squinting now, but changing some font sizes is helping 
>there.

This is the main reason I run in 1024x1280 resolution. Getting older
sucks :-(

>In the meantime, I should get even better displays. I went back 
>and tested mcidas (my local installation) with midasx again and this 
>time I got the comment that it was using Z-32 colors and there was 
>nothing in there about slow processing. (I reckon the 8 LSBits are 
>thrown away.)

After 16-bit depths, McIDAS simply says 32.

>Best of all, my graphics, windows, etc. load a heck of a lot faster. 

I would expect that when using the proper driver.

>I'll bet that generic driver (OK, module) was using RAM to do its 
>calculations.

Maybe.  In any case, it was just wrong.

>       Yottathanks! (=10^24 thanks)

No worries!

Tom