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

20000211: McIDAS-X on Linux at MSFC (cont.)

>From: Paul Meyer <address@hidden>
>Organization: NASA/MSFC
>Keywords: 200002101928.MAA23536 McIDAS-X Linux


>Thank you very much for your help.  I got it compiled and installed,
>and am watching a 12 frame loop on a 486 120 MHz box!!!!!!

Man, a 486 box!?  This must be one old sucker :-)  I had figured that
you would have a 500+ Mhz Pentium III with > 128 MB of RAM to build
on.  These machines have gotten so cheap lately.  We have purchased a
number of dual processor 550 Mhz Pentium IIIs with 500 MB of RAM; 36 GB
of Ultra 2 SCSI disks (IBM no less); 52x CD-ROM; 21" KDS monitor; etc.
for just over $5000.  These are real workhorse machines to say the
least.  We have one decoding all of NOAAPORT (all 4 channels) into both
GEMPAK and McIDAS compatible formats and running a remote ADDE server
here in the office.  The majority of time this machine is idling.
By the way, the build under Linux on a machine like this takes on the
order of 15 minutes for our distribution, and our distribution is
about 40% bigger than SSECs (we bundle in XCD and lots of Unidata-
specific routines)!

>I went
>back to straight red hat 6.0 because I did not like how Mandrake 6.1.1
>was handling the Gnome window manager.

OK, good tip; thanks.

>Some issues I encountered.
>under netcdf/configure  within the Linux option -Df2cFortran is set as
>-Ff2cFortran  (F instead of D)

I will pass this along to the netCDF developers here.  SSEC simply bundles
our netCDF release with McIDAS so that users don't have to go out and
grab it separately.

>the following line of course needed to have ....fort77 changed to ....mcfc.

OK.  We used to have users use the Perl shell script, fort77.  This is
how the defaults for the netCDF are set.  McIDAS users, as of 7.5 (?)
can use the SSEC produced, Bourne shell script, mcfc.  Both this and
the f2cFortran things can be changed by setting environment variables:


These are the settings discussed in the Notes and Warnings URL that I
passed along before.

>in the file src/sends_.c it could not find stream.h  (a c++ include file) so,
>I just deleted that line and the surrounding ifdef lines.

Damn.  This is was my omission in the mclinux.tar.Z file.  I had modified
sends_.c to fix this.  In my distribution, sends_.c looks like:

 * Copyright(c) 1997, Space Science and Engineering Center, UW-Madison
 * Refer to "McIDAS Software Acquisition and Distribution Policies"
 * in the file  mcidas/data/license.txt

/**** $Id: sends_.c,v 1.16 1999/03/18 21:49:50 chadj Rel $ ****/

#include <errno.h>
#include <sys/types.h>
#include <sys/socket.h>                     /* <<<<< UPC moved 980204 >>>>> */
#ifndef __OPENNT
#if !defined(__linux__) && !defined(FREEBSD)/* <<<<< UPC mod 990731  >>>>> */
#include <sys/stream.h>
#ifndef __OPENNT
#include <sys/socketvar.h>
#include "mcidas.h"

/*  funcion sends is called by IMPORT, it sets up and calls send for TCP */

sends_(Fint *ns, char *buf, Fint *nr)
   int rc;
   rc = send(*ns,buf,*nr,0);
   if (rc < 0) perror ("problem with send");

I just included sends_.c in mclinux.tar.Z for the next site that wants to
build under Linux.  Sorry for the omission.

>One or two stupid things on my part like copying f2c.h to /usr/local/include
>when the include subdirectory did not exist.

Oops, :-)

>I discovered my biggest problem on the previous install was that Anthony had
>told me to use

>sh mcidas7.6.sh make  - that is what really hosed me royally -

Arg!  This is one of the most stupid things that SSEC does.  They are
attempting to protect their users from learning to:

o define McINST_ROOT
o unpack the distribution
o cd to the mcidas7.6/src directory
o type make

I personally think that running make by hand is much preferable to hiding
what is going on behind a numb shell script invocation; don't you?

>in addition to setting McINST_ROOT somewhere midstream.

Yes, that can be a killer.

>Best regards, Paul

Glad to hear that things worked out!


>From address@hidden  Fri Feb 11 15:47:44 2000
re: MSFC machine
>It may possibly be a 586 - but still!!!    The real issue is no boxes
>to be had except those to be excessed. All I'm doing now is proof of
>concept that we can do this, that we can compile, remap etc on the box,
>so when it comes time to replace our mcidas server probably within the
>year, I can save bundles.   I looked at an Indybox machine XM class
>yesterday (http://www.indybox.com ) and spec'ed it with dual 700 MHz
>pentium III, 512 MB, and 3 36 GB hotswappable U2W 10000 rpm drives in a
>RAID 5 config, a 10 GB EIDE drive for $9,770.   Try to do that in an
>SGI or SUN line!  WHen I added two more drives for a 5 channel RAID 5,
>and the appropriate controller, the box was $12,500.

re: tip on Mandrake Linux
>I'm told it likes KDE better than Gnome.  Will try RedHat Piglet (6.2 )
>hopefully in the next week or so.

re: setting environment variables for netCDF
>Yup, those are the guys.  I forgot to do that initially, and set it before make
>all got to it.

>Thanks again.  Paul
Paul J. Meyer
Global Hydrology and Climate Center
NASA/MSFC code SD60     |  address@hidden (SMTP)
Huntsville, AL 35812    |  address@hidden    (X.500)
     Voice: (256) 922-5892  Fax: (256) 922-5723

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.