[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[McIDAS #EXQ-796373]: McIDAS install
- Subject: [McIDAS #EXQ-796373]: McIDAS install
- Date: Sat, 10 Jan 2009 15:11:50 -0700
Hi Gilbert,
re:
> I just saw this:
>
> The ADDE server definitely needs to be reinstalled. I just tried
> ./kickoff UPPER.BAT and saw this:
>
> Done
> FRMSAVE 2 /home/apache/weather/data/mcimages/hodos/apxhodo.gif
> Frame saved in /home/apache/weather/data/mcimages/hodos/apxhodo.gif
> HODO 72768 X X GRA=2 PRA=250 1050 INT=20
> RAOBCON: Cannot contact server (connect() failed)
> RAOBCON - Done
> RAOBCON failed, RC=1
> RAOBCON SPD 850 OLAY COLOR=3 GRA=2 CINT= H8SPD DASH=ALL
> Accessing Dataset Name = RTPTSRC/UPPERMAND.ALL
> HODO: Cannot contact server (connect() failed)
I don't know why this happened (don't have _all_ of the details of what has
been done lately on climate).
I just logged onto climate as 'mcidas' and did the following:
1) renamed .bashrc to bashrc.sav
Reason:
Someone evidently copied ~mcidas/admin/mcidas_env.sh to .bashrc. This is
not needed nor is it desired when .bash_profile has been modified to
read in settings in $HOME/admin/mcidas_env.sh. Now, .bashrc does not
exist, so the environment variables needed by McIDAS are being set by
the construct:
if [ -e $HOME/admin/mcidas_env.sh ]; then
. $HOME/admin/mcidas_env.sh
fi
Before I made this change, the MCDATA environment variable was being set
to /workdata instead of /home/mcidas/workdata.
2) After correcting .bashrc, I logged off and then back on. Now MCDATA is
correctly being set.
I then did the following:
cd $MCDATA
dataloc.k LIST
After doing this, I noticed that several ADDE datasets were to be accessed
from idd.unidata.ucar.edu. Since this was incorrect (idd.unidata.ucar.edu
is an IDD relay cluster, not an ADDE server), I changed the settings in
/home/mcidas/data/LOCDATA.BAT from idd.unidata.ucar.edu to adde.ucar.edu.
I then made the new settings active:
<still as 'mcidas'>
cd $MCDATA
batch.k LOCDATA.BAT
Now the client routing table entries are correct.
3) I verified that the ADDE remote server is working:
<still as 'mcidas'>
cd $MCDATA
dataloc.k LIST RTPTSRC
Group Name Server IP Address
-------------------- ----------------------------------------
RTPTSRC CLIMATE.COD.EDU
<LOCAL-DATA> indicates that data will be accessed from the local data
directory.
DATALOC -- done
Then:
ptlist.k RTPTSRC/PTSRCS FORM=FILE ALL
Pos Description Schema NRows NCols Proj#
Created DataDate
------ -------------------------------- ------ ----- ----- -----
------- --------
8 SAO/METAR data for 08 JAN 2009 ISFC 72 7000 0
2009007 2009008
9 SAO/METAR data for 09 JAN 2009 ISFC 72 7000 0
2009008 2009009
10 SAO/METAR data for 10 JAN 2009 ISFC 72 7000 0
2009010 2009010
18 Mand. Level RAOB for 08 JAN 2009 IRAB 8 1500 0
2009007 2009008
19 Mand. Level RAOB for 09 JAN 2009 IRAB 8 1500 0
2009008 2009009
20 Mand. Level RAOB for 10 JAN 2009 IRAB 8 1500 0
2009010 2009010
28 Sig. Level RAOB for 08 JAN 2009 IRSG 16 6000 0
2009007 2009008
29 Sig. Level RAOB for 09 JAN 2009 IRSG 16 6000 0
2009008 2009009
...
This shows that the various datasets can be accessed, so the ADDE remote
server
does not need to be reinstalled.
> I am assuming that the ADDE server needs to be reinstalled?
I do not think so.
> Since McIDAS
> got wiped out and we started over, I am assuming this is a yes. It will be
> done later this afternoon or evening anyway.
No need.
> Also, COD/Tyler, take note: due to the mounting of the system, the
> McIDAS images weren't writing to the /home/apache/weather/data due to
> insufficient permissions. Images are now being written.
As far as I can see without spending too much time poking around, things
are working correctly in the 'mcidas' account. If problems exist in the
script generation, then the problem is with the scripts.
I made a small adjustment to each *kickoff script on climate:
- remove the '-f' flag from the #!/bin/sh line. This is not
needed/used/correct.
- added:
SHELL=sh
export SHELL
To each script. This insures that the Bourne shell will be used to evaluate
the script. NB: this shouldn't be needed, but I have found that it was needed
on some systems, and it does not harm.
Please let me know if you see any weirdnesses going forward...
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: EXQ-796373
Department: Support McIDAS
Priority: Normal
Status: Closed