20041104: McIDAS problem -- no map (cont.)

>From: David Ovens <address@hidden>
>Organization: University of Washington
>Keywords: 200411041914.iA4JEUvV018946 McIDAS mcenv environment

Hi David,

>I think you are right that we have a problem with variables being not
>quite correct.  
>
>We have these environment variables set for user 'ldm':
> 
> MCHOME [not set]

MCHOME is not actually needed.  I use MCHOME as the HOME directory of
the user 'mcidas' and then define other environment variables using
it.  Here is a for instance:

MCHOME=/home/mcidas

MCDATA=/usr/local/ldm/mcidas/data
MCPATH=${MCDATA}:$MCHOME/data:$MCHOME/help
 ...

> MCDATA=/home/disk/data/mcidas

If the HOME directory for the user 'ldm' is /usr/local/ldm, then MCDATA
should typically be /usr/local/ldm/mcidas/data.  I say typically since
someone who really understands McIDAS can pretty much do as s/he wants
as long as s/he is consistent and complete.

> MCPATH=/home/disk/data/mcidas:/usr/local/ldm/mcidas/data:/usr/local/ldm/mcida
> s/help

So, your /home/disk/data/mcidas directory is where you want McIDAS to
find data files...

> MCGUI=/usr/local/ldm/mcidas/bin

Are McIDAS executables installed under the ~mcidas/bin directory?  If
yes, this is non-standard.  I have create a McIDAS account as the user
'mcidas' that has a HOME directory of /home/mcidas.  This doesn't have
to be this way, but it helps when following along with the McIDAS web
pages.

> MCTABLE_READ=/home/disk/data/mcidas/MCTABLE.TXT;/usr/local/ldm/mcidas/data/AD
> DESITE.TXT
> MCTABLE_WRITE=/home/disk/data/mcidas/MCTABLE.TXT

OK, these are non-standard, but consistent.

>We have these set for user 'mcidas':
>
> MCHOME=/usr/local/ldm/mcidas  = ~mcidas
> MCDATA=/usr/local/ldm/mcidas/workdata
> MCPATH=/usr/local/ldm/mcidas/workdata:/usr/local/ldm/mcidas/data:/usr/local/l
> dm/mcidas/help
> MCGUI=/usr/local/ldm/mcidas/bin
> MCTABLE_READ=/usr/local/ldm/mcidas/workdata/MCTABLE.TXT;/usr/local/ldm/mcidas
> /data/ADDESITE.TXT
> MCTABLE_WRITE=/usr/local/ldm/mcidas/data/ADDESITE.TXT
> MCCOMPRESS=TRUE
>
>(Note, that I have substituted /usr/local/ldm for /home/disk/ldm in
>the 'ldm' setup.)

So, you installed McIDAS under the 'ldm' account.

>It looks to me like the confusion is that for user 'mcidas' its home
>directory, /usr/local/ldm/mcidas, is a subdirectory of another user's
>(ldm's) HOME directory.  These should be distinct, right?

The MCHOME directory should be the directory under which McIDAS was
installed.  If you really installed McIDAS under the
/usr/local/ldm/mcidas directory, these definitions should be OK.

>Also these instructions
>
>  # MCHOME - the HOME directory of the user 'mcidas'
>  setenv MCHOME /home/mcidas
>  setenv MCDATA $HOME/mcidas/data
>  setenv MCPATH ${MCDATA}:$MCHOME/data:$MCHOME/help
>
>from 
>
>  http://my.unidata.ucar.edu/content/software/mcidas/2004/users_guide/Configur
> ingaNewUserAccount.html#22412
>
>make me think that we're running into trouble because user 'ldm' has,
>essentially, 
>   setenv MCHOME $HOME/mcidas           [not a good location]
>   setenv MCDATA /home/disk/data/mcidas [not $HOME/mcidas/data]
>   setenv MCPATH ${MCDATA}:$MCHOME/data:$MCHOME/help

These are OK since they are consistent and complete.

>> The approach that I promote for my user community is to model scripts
>> after example ones I include in the Unidata McIDAS distribution:
>> 
>> ~mcidas/data/mcrun.sh
>
>Don't you have a typo in that file?  The first MCHOME note,
>
>#             MCHOME - the home directory for the user running mcrun.sh
>
>should really be HOME, right?

No, not really.  mcrun.sh is a shell script that is designed to be used
by any user, not just 'mcidas'.  If you installed McIDAS under the
'ldm' account in subdirectories of /usr/local/ldm/mcidas, then the
MCHOME in the script would be:

MCHOME=/usr/local/ldm/mcidas

>> - removal of files that should be transient from directories that
>>   get included in users' MCPATH definitions (i.e., ~mcidas/data and
>>   ~mcidas/help)
>
>All users have ldm's MCDATA, /home/disk/data/mcidas, in their MCPATH.
>Should ldm's MCDATA be local to itself, and thus have
>
>   setenv MCDATA /usr/local/ldm/mcidas/data
>   setenv MCPATH ${MCDATA}:/home/disk/data/mcidas:$MCHOME/help
>
>????

I recommend that each user running McIDAS has a working directory.
This will be the directory where certain files like LWPATH.NAM (the
persistent definition file for REDIRECTions) will be created and used.
By making the MCDATA directory one that will be shared by other users,
you insure that the settings for one user (like the 'ldm' running
McIDAS applications/scripts) will intefere with other users.  I tried
to paint an installation structure where the user 'mcidas' can act as a
super user for the package and so can do things for all users, but
where the user 'mcidas' has a directory that is not shared by other
users (the ~mcidas/workdata directory).  In my scheme, each user that
runs McIDAS has his/her own McIDAS working directory defined in
MCDATA.  The first path in each user's MCPATH is then $MCDATA, and that
directory is private to that user (including 'mcidas'):

user is 'mcidas':

MCHOME=/home/mcidas
MCDATA=/home/mcidas/workdata
MCPATH=${MCDATA}:$MCHOME/data:$MCHOME/help
 ...

Again, McIDAS can be setup in an uncountable number of different ways
and they will work as long as the person doing the setup knows enough
about how the package works to know what to do differently than is
spelled out in the Unidata McIDAS web pages.  It sounds like your or
Harry did the McIDAS installation at UW, so there is a lot of expertise
behind the installation.  I would guess, therefore, that the problem
you are seeing is related to the other thing I mentioned:  the
situation where files that should be created and destroyed on a per
session basis are being created in a directory that is _not_ a
subdirectory of ~/.mcenv.  In this case, you _will_ run into problems
that are hard to troubleshoot.

Please let me know if the above makes sense.

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.