[McIDAS #WAZ-899768]: migrating to goes-13

Hi Ed,

Thanks for providing me the info to login to your account on metofis.  This
allowed me to quickly figure out the problem you were experiencing.  Here
goes:

1) you defined MCDATA in ~eryan/.cshrc to be a colon-separated list of 
directories.
   If you are explicitly defining MCDATA, it should be the single directory
   ~eryan/mcidas/data.  But, read more...

2) you had setup a DATALOC for RTIMAGES that pointed at the external
   ADDE interface on metofis, but this interface does not yet exist

3) here is the real cause of your heartburn:

   - you correctly included in ~eryan/.cshrc the snippit that sources
     the user_env.csh file contained in the Unidata McIDAS distribution:

     ## McIDAS
     setenv MCHOME /home/mcidas
     if( -e $MCHOME/admin/user_env.csh ) then
       source $MCHOME/admin/user_env.csh
     endif

   - you incorrectly followed the snippit above with explicit declarations
     of MCHOME, MCDATA, MCPATH, etc.  The problem with doing this is that
     your .cshrc file will get sourced whenever you start a McIDAS session
     (and running a McIDAS script starts a session in much the same way
     that running an interactive session does).  This has the effect of
     rewriting the value of MCPATH.  The problem is that MCPATH gets rewritten
     by the McIDAS module that manages shared memory, mcenv, and the rewritten
     value contains the ~/.mcenv/$MCENV_POSUC directory at the end.  This is
     the directory in which numerous session-specific files are created, 
accessed
     and then deleted when the session exits.  The error messages that we
     were seeing from your previous script runs were complaining that some
     of the files created in the hidden directory were missing.  This is
     not surprising since the sourcing of ~/.cshrc replaced the value
     of the extended MCPATH with the hardwired one.  The reason that this does
     not happen when only using the sourcing snippit above is that user_env.csh
     makes a check to see if MCPATH is defined, and if it is, it does not
     get reset.

     This is real obscure McIDAS stuff, so I don't expect you to fully
     grasp the nuances.

So, the solution to your problem was simple:

1) comment out all of the lines in ~eryan/.cshrc that explicitly
   defined McIDAS environment variables while leaving the snippit:

   ## McIDAS
   setenv MCHOME /home/mcidas
   if( -e $MCHOME/admin/user_env.csh ) then
     source $MCHOME/admin/user_env.csh
   endif

   This is all you need.

2) remove the DATALOC for RTIMAGES that pointed to metofis:

   <as 'eryan'>
   cd $MCDATA
   dataloc.k ADD RTIMAGES LOCAL-DATA

After doing this, I exercised McIDAS from the command line to
verify that things are working correctly:

<as 'eryan'>
cd $MCDATA
mcenv -f 1@800x1024 -i 128
imgdisp.k RTIMAGES/GE-IR LAT=0 72 MAG=-2 EU=IMAGE
map.k FILE=OUTVHPOL
frmsave.k 1 rtimages_ge4kir.gif
exit

This created the GIF ~eryan/mcidas/data/rtimages_ge4kir.gif.  When you
look at the image, you will see proper labeling at the bottom as expected.

Now, on to your scripts....

I suggest that you do not need to try and set McIDAS environment variables
twice:

   source /home2/eryan/mcidas/user_env.csh
#  diff /home/mcidas/admin/user_env.csh /home2/eryan/mcidas/user_env.csh
   source /home2/eryan/.cshrc

After my modifications to ~eryan/.cshrc, the two source lines will do
the exact same thing.  I would suggest, therefore, that doing the first
is all you need to do:

   source /home2/eryan/mcidas/user_env.csh

Please let me know if you have questions on what I have outlined above.

FYI: I took the liberty of updating McIDAS to the latest bugfix addendum,
v2009d (not 2009e as I previously said).  This updated some code needed
to access new Nexrad Level III images now being sent in the IDD NEXRAD3
(aka NNEXRAD) datastream.  Your 'mcidas' setup of RTIMAGES datasets, however,
needs to be updated if you want to access these images from metofis (I
didn't check to see if the LDM is ingesting and FILEing these images,
so this new capability may be of no interest to you).

Also, I still think that it is a good idea to setup remote ADDE serving
on metofis.  'root' has to do this, and I know that Angel is busy with
other things at the moment, so it can wait.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: WAZ-899768
Department: Support McIDAS
Priority: Normal
Status: Closed