20050907: mcidasx problem (cont.)

>From: "John Hobbie" <address@hidden>
>Organization: NMSU/NSBF
>Keywords: 200509071943.j87Jh5jo012941 McIDAS build test install

Hi John,

>I hope you had a good vacation.

My short vacation was very nice, thanks!

>We had some power/AC problems here
>over the weekend and Tuesday that slowed this response to you.

No worries.

>As you recall, I tried to install the new mcidas program on a F3C
>machine and had troubles with Testing phase.

Yes, I remember that you said that you were doing a new/clean/fresh
installation.  The testing instructions on the McIDAS web pages
were designed for a site that already had a previous version of McIDAS
installed.  I believe that a number of the problems that you ran
into were a result of this being a new installation, so some of the
files that are needed to run the tests were not available.

>I suspected it had
>something to do with the route through the installations that I was
>following, or the omission of some critical step.  Below is a log of
>the steps I took and the URL's that I followed.

I have read this entire email, and will be addressing your request
at the end to work through the steps as you did them to see if I
can replicate your difficulties.  My comments are, therefore, geared
to what I would suggest be done at each step.

>I first opened this page:
>http://my.unidata.ucar.edu/
>
>and clicked on "mcidas"
>to get http://my.unidata.ucar.edu/content/software/mcidas/index.html
>
>I had already downloaded and saved back mcidasx2005.tar.gz and
>mcunpack, so I skipped down to and clicked on    Installing and
>Configuring McIDAS-X   in the   "getting started" section of the above
>page.

Sounds good.

>This brought me to url
>http://my.unidata.ucar.edu/content/software/mcidas/2005/users_guide/Installing
> andConfiguringMcIDAS-X.html
>that was labelled chapter 1 and I click on "Installing McIDAS-X on Unix
>or Mac OS X Workstations"   to arive at url:
>http://my.unidata.ucar.edu/content/software/mcidas/2005/users_guide/Installing
> McIDAS-XonUnixorMacOSXWorkstations.html#63755

OK.

>I read down to  "Preparing the Workstation" and clicked on it to get to url: 
>http://my.unidata.ucar.edu/content/software/mcidas/2005/users_guide/Preparingt
> heWorkstation.html#25760
>
>I read down to the link "See Shared Memory Configuration for more detailed
>information"  under "Allocating Sufficient Shared Memory" to get to url:
>http://my.unidata.ucar.edu/content/software/mcidas/2005/users_guide/workstatio
> n.html
>
>I went to the Linux instructions,  and as root,  modified /etc/rc.d/rc.local
>to include the line:

>echo 536870912 /proc/sys/kernel/shmmax

OK.  Here is my first comment:

Directing folks to increasing shared memory under Linux is not strictly
needed _if_ they run modest McIDAS sessions.  The reason I say to increase
shared memory is I don't know what any particular person will consider
as a modest session.

>I returned to the "Preparing the Workstation" web page and click the
>right arrow at the bottom of the page to get to the "Preparing the
>mcidas Acount" page, at url:
>http://my.unidata.ucar.edu/content/software/mcidas/2005/users_guide/Preparingt
> hemcidasAccount.html

OK.

>*********
>
>An aside here, at step four of this page, there are three bullets
>telling you to define the environmental variables in your config file,
>.cshrc.  In the last bullet, you say,  "for convienience, files with
>the settings described below are included in the Unidata McIDAS-X
>distribution in the $HOME/admin directory."

Yes.

>== Please note one has not unpacked the tar file yet so for a new install,
>there is no admin directory.

This is not a problem.  The code that one is instructed to include
in his/her shell-specific definition file (.cshrc in your case) has
a check to see if the file to be read in exists.

>Instead, I clicked on the
>"mcidas_env.csh" link and copied the long script into the .cshrc file.

This was a good thought, but could (and did in your case) end up
causing problems later.  I recommend that you add the code to .cshrc
as advised:

# McINST_ROOT and VENDOR non-conforming shell defines needed to build McIDAS
setenv McINST_ROOT $HOME
setenv VENDOR -g77
if ( -e $HOME/admin/mcidas_env.csh ) then
  source $HOME/admin/mcidas_env.csh
endif

>Also note, that in the second table, there is also a reference to the
>non-existent $HOME/admin directory.

Again, this is not a probelm given the 'if' clause in the code you
are advised to include in .cshrc.
>
>***************************

>I logged out and in again as mcidas to activate the script in .cshrc,
>and got the error message that
>
>           uname_s: Undefined variable

I am not sure why you got this since the contents of the mcidas_env.csh
link on the web page has the appropriate definition of 'uname_s' before
it is used:

 ...
else

  # VENDOR is '-vendor'
  set uname_s=`uname -s`
  switch ( $uname_s )
...

>I ignored it

At this point, something is wrong.

>and clicked on the right arrow at the bottom of the page
>to arrive at url
>http://my.unidata.ucar.edu/content/software/mcidas/2005/users_guide/ObtainingM
> cIDAS-X2005.html
>
>I follow the instructions (skip 4-6) and click on the right arrow at
>the bottom of the page to arrive at "Building, Testing and Installing
>MciDAS-X2005"  at url:
>http://my.unidata.ucar.edu/content/software/mcidas/2005/users_guide/Buildingan
> dInstallingMcIDAS-X2005.html
>
>I typed 'echo $McINST_ROOT'   and got /home/mcidas  in response.  I
>then typed  ./mcunpack and all the files seemed to be unpacked and
>distributed.

OK, you uncovered a missing step for a brand new installation:  In a new
installation, after unpacking the distribution, a user should either
logoff and then log back on or source .cshrc.  This comment assumes,
however, that the user followed the instructions to include:

# McINST_ROOT and VENDOR non-conforming shell defines needed to build McIDAS
setenv McINST_ROOT $HOME
setenv VENDOR -g77
if ( -e $HOME/admin/mcidas_env.csh ) then
  source $HOME/admin/mcidas_env.csh
endif

in his/her .cshrc file.

>I typed  cd mcidas2005/src   then typed   make all 
>I got the error message
> make: ERROR: unknown VENDOR compiler selection: intel
> make: *** [vend_var] Error 1

Since you copied mcidas_env.csh into your .cshrc file, you should not
have gotten this error _if_ you had defined McINST_ROOT and VENDOR
in .cshrc.

>==========
>I have had this problem before and typed setenv VENDOR -g77
>then typed make all    and the thing seems to compile with no error messages.

The code snippit to add to .cshrc should have defined VENDOR as 'g77' for
you:

# McINST_ROOT and VENDOR non-conforming shell defines needed to build McIDAS
setenv McINST_ROOT $HOME
setenv VENDOR -g77                                <- ******  VENDOR definition
if ( -e $HOME/admin/mcidas_env.csh ) then
  source $HOME/admin/mcidas_env.csh
endif

>The next step was "Testing the build"

Yes, but the advice on testing the build says the following:

The user mcidas should complete the steps below to test Unidata
McIDAS-X 2005 before installing it. Testing of the build is not needed
if you are committed to upgrading, or if the installation is new. The
example actions in the following all use C-Shell syntax.

I suppose I should be more forceful by saying:

Skip the testing step if this is a new installation.

>I verified that the line #-c
>MCGUI  was commented out in .mcidasrc
>
>I copied exactly the setenv definitions given in step 3 and 4.  At step
>5, I typed setenv DISPLAY psnldm:0
>
>When I typed mcidasx, I got the following error message
>-----
>WARNING: only run as the user 'mcidas' for supervisory tasks
>Running McIDAS configuration GUI...
>
> Application initialization failed: this isn't a Tk applicationcouldn't
>connect to display "psnldm:0"
>Error in startup script: can't read "tk_version": no such variable
>    while executing
>"if { $tk_version >= 8.1 } \
>    {
>        ::tk::unsupported::ExposePrivateCommand tk*
>     }"
>    (file "/home/mcidas/mcidas2005/src/config.gui" line 3483)
>---------
>
>I then typed setenv DISPLAY :0

If you were the user that had started X windows, this would not have
been necessary.  It seems that you became 'mcidas' from an xterm
that had been created by some other user.

>and upon typing mcidasx, I got the
>mcidas-x configuration window GUI.

You shouldn't have gotten the mcidas-x configuration window GUI.
Starting McIDAS using 'mcidasx' _should_ start a session using defaults
in the 'mcidasx' startup script.  The Unidata configuration GUI
should be started only if you type:

mcidas -config

The SSEC configuration GUI should be started only if you type:

mcidasx -config

>I clicked on the Save settings. I then clicked on Start Mcidas  and got
>the following error message:
>
>Error in startup script: invalid command name "fileToList"
>    while executing
>"fileToList $mcrcfile"
>    (procedure "readMcidasrc" line 139)
>    invoked from within
>"readMcidasrc "$home/.mcidasrc""
>    (file "/home/mcidas/mcidas2005/src/mcidas" line 667)
> 

Hmm...  OK, I found out why this is not working.   I changed the
v2005 distribution to not include the file needed by Tcl/Tk
routines to find Tcl procedures, tclIndex.  Instead, I generate the
file from the 'makefile', but I only do this after the 'make install'
step.  The lack of tclIndex will cause the startup script to fail
(like you see) since there is nothing to tell the startup script
where to find the procedure 'fileToList'.  This won't fail for
installation upgrades since there will be a tclIndex file that
can be found.

So, the moral here is that I need to be _very_ explicit in warning
users to go ahead and install v2005 ('make install.mcx') if this
is a brand new installation.

>----------------
>
>I then back tracked and erased all the installed mcidas files and
>directories and began at the top, and as I ran through the above steps,
>corrected the steps that were balked at.  Instead I entered, setenv
>VENDOR -g77, before I typed, make all; I typed   setenv DISPLAY :0   I
>then recall your email and typed   mcidas -config and got  a gui
>labelled "Unidata McIDAS-X Setup"

>I change none of the settings and click on Start and and application
>error window pops up with the message
>
>'error:invalid command name "runBusy" '    

This is caused by tclIndex not being installed yet.

>When I click on 'details'   I am allowed to save the errors to a log
>(listed below):
>
>invalid command name "runBusy"
>invalid command name "runBusy"
>    while executing
>"runBusy busy "Starting McIDAS-X; please wait""
>    (procedure "startMcidas" line 9)
>    invoked from within
>"startMcidas config"
>    invoked from within
>".f.ctrl.ok invoke"
>    ("uplevel" body line 1)
>    invoked from within
>"uplevel #0 [list $w invoke]"
>    (procedure "tk::ButtonUp" line 22)
>    invoked from within
>"tk::ButtonUp .f.ctrl.ok"
>    (command bound to event)

Yup.

>Since I can't seem to get beyond  the test of McIDAS,  I will send this
>to you at this time.

For a new installation, there is no downside to simply going ahead
with installing the newly built code.  The reason for this test section
was to give existing users the opportunity to test the new build _before_
they overwrote an old, presumably working distribution.

>However, after I sent you the request while you
>were on vacation, I fiddled with the process, and by taking different
>routes through the install instructions -- though at this time, I don't
>recall which route -- I was able to get past this point, but unable to
>have the decoders working properly.

Your other email referred to 'ldm-mcidas' decoders as follows:

  Another thing to consider is that there might be differences in the
  sequence of setting up various programs (gempak, mcidas,ldm,ldm-mcidas)
  that could affect the set up.  For example, ldm-mcidas installs SCHEMA
  and several other files into /data/ldm/mcidas.  Ldm-mcidas is an older
  program, and mcidas2005 also installs the same files.

Correct.

  If I install
  mcidas first, and then ldm-mcidas, do I get different results?

Perhaps.

  (I
  installed ldm-mcidas first this time.)

Good.  In this sequence the newer SCHEMA file contained in McIDAS-X v2005
will be copied to the output directory and so used.  When the new release
of ldm-mcidas comes out, it will contain the same SCHEMA file as McIDAS-X
v2005, so the order of installation will be of no consequence.

  If there is a proper sequence
  of installation on a new box, perhaps the unidata web page could
  include a list of what the proper sequence to install these programs is
  as a starting point for all installations or perhaps a "If you are new,
  start here" page.

I agree... for McIDAS users.

>Please see if you can duplicate
>these results following the route I took and let me know what I did
>wrong.

The majority of the problems you ran into were caused by my not being
firm enough about not running through the testing step before installing
McIDAS.  I will rewrite the testing section to be more clear on what
should be done.

>Thanks for your help now and for all the times in the past.  

I apologize for the documentation being misleading on more than one
point!

Cheers,

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.