[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20010205: McIDAS: NEXRAD Config File Read Error (cont.)
- Subject: 20010205: McIDAS: NEXRAD Config File Read Error (cont.)
- Date: Mon, 05 Feb 2001 18:22:10 -0700
>From: Michael Keables <address@hidden>
>Organization: Geography Dept, University of Denver
>Keywords: 200102021959.f12JxiX16383 McIDAS-X NEXRAD DATALOC MCTABLE_READ
Mike,
>Still having problems with the mkeables account.
OK.
re: MCTABLE_WRITE="/home/user/mcidas/data/MCTABLE.TXT"
>Checked this out and modified the code in .cshrc to specify the directory as
>/export/home/mkeables/mcidas/data/MCTABLE.TXT
re: If this is how your MCTABLE_WRITE is setup, then you should CD to the
~mkeables/mcidas/data directory and see if the file MCTABLE.TXT exists.
>It does (and did before I changed the line in .cshrc).
Strange...
re: read/write permissions for ~mkeables/mcidas/data/MCTABLE_WRITE
>Checked this as well; I can read and write to it (permissions are u+rwxd,
>g+rw, o+r)
OK.
>I copied the CONEXRAD.CFG file to $MCDATA and can now display the images.
OK. This means that ADDE services will be provided "locally", i.e.,
by ADDE routines running in your session, not from the ADDE remote server.
>I
>don't think the ADDE server is behaving as it should, because DATALOC ADD
>RTNEXRAD LOCAL-DATA still shows no groups or server IP addresses.
This needs investigation.
re: the options
>> o access the RTNEXRAD data from a remote ADDE server; this would be
>> cyclone.natnet.du.edu in your case
>>
>> o setup your own account so that you can access the RTNEXRAD data as
>> LOCAL-DATA
>>
>> The first option is the easiest for the average user. It avoids that
>> user having to setup all of the supporting configurations in his/her
>> own account. Let's pursue this avenue. Given this, your problem now
>> boils down to the inability of your McIDAS-X session to write to
>> your MCTABLE.TXT file. Again, you should verify that you can write
>> the file in your mcidas/data subdirectory.
>I would prefer the first option as well (and want to set up additional
>accounts this way as well.) I want to be sure that things are configured
>properly before creating new user accounts, however.
Right. I understand and agree.
re: login access to your account denied
>Sorry about that. I changed the password for temporary access to my account
>for another issue down here and I guess I didn't reset the password to the
>same as the one I gave you (thought I did but guess not.)
>
>I'd appreciate it if you could look at the mkeables account and see what
>gives.
OK. I did just that. The following is rather lengthy, so hang in there.
There were a number of problems that needed to be corrected.
Here is the blow-by-blow of what I did and what I changed:
<login as you>
cd mcidas/data
ls
...
COUNTRY.DAT GW6.GIF KEITH9.GIF TERMCHAR.001
...
FRAMENH.001 GW9.GIF KJ2.GIF VIRT9001
...
GE8.GIF ISAAC26.GIF MCTABLE.TXT WV7.GIF
...
GEW10.GIF ISAAC29.GIF RESOLV.SRV WXADV.BAT
...
GEW6.GIF ISAAC6.GIF SAT4.GIF core
...
I noted the following problems:
o FRAMENH.001 and TERMCHAR.001 should only be found in a subdirectory
of ~/.mctmp; they are supposed to be created on a per session basis
and deleted when the session exits. I deleted these files.
The core file was caused by 'dsserv.k'. It undoubtedly was happening
because your MCTABLE_READ was setup incorrectly. -- See below --
Based on finding these, I then did the following:
dmap.k Frame
/export/home/mcidas/workdata% dmap.k Frame
PERM SIZE LAST CHANGED FILENAME DIRECTORY
---- --------- ------------ --------- ---------
-r-- 3072 Sep 30 1999 Frame1.0 /export/home/mcidas/help
-r-- 3072 Sep 30 1999 Frame10.0 /export/home/mcidas/help
-r-- 3072 Sep 30 1999 Frame11.0 /export/home/mcidas/help
-r-- 3072 Sep 30 1999 Frame12.0 /export/home/mcidas/help
-r-- 3072 Sep 30 1999 Frame13.0 /export/home/mcidas/help
-r-- 3072 Sep 30 1999 Frame14.0 /export/home/mcidas/help
-r-- 3072 Sep 30 1999 Frame15.0 /export/home/mcidas/help
-r-- 3072 Sep 30 1999 Frame16.0 /export/home/mcidas/help
-r-- 3072 Sep 30 1999 Frame17.0 /export/home/mcidas/help
-r-- 3072 Sep 30 1999 Frame2.0 /export/home/mcidas/help
-r-- 3072 Sep 30 1999 Frame3.0 /export/home/mcidas/help
-r-- 3072 Sep 30 1999 Frame4.0 /export/home/mcidas/help
-r-- 3072 Sep 30 1999 Frame5.0 /export/home/mcidas/help
-r-- 3072 Sep 30 1999 Frame6.0 /export/home/mcidas/help
-r-- 3072 Sep 30 1999 Frame7.0 /export/home/mcidas/help
-r-- 3072 Sep 30 1999 Frame8.0 /export/home/mcidas/help
-r-- 3072 Sep 30 1999 Frame9.0 /export/home/mcidas/help
52224 bytes in 17 files
These files, FrameN.M, are also supposed to be created on a per-session
basis in subdirectories of each user's ~/.mctmp directory. Notice
that the PERM on these files is read only. This would cause you
problems when trying to run McIDAS from your (and any other user's)
McIDAS session. Also note that these files are _old_!
Since the files need to be deleted, I logged in as 'mcidas' and basically
repeated the steps above. I also found copies of FRAMENH.001 and
TERMCHAR.001 in the ~mcidas/workdata directory which is also not
good.
As 'mcidas' I deleted FRAMENH.001 and TERMCHAR.001 from ~mcidas/workdata
and Frame*.* from ~mcidas/help.
I am amazed that I was able to run a McIDAS-X session even as McIDAS
and successfully display images and draw maps on them. The fact
that the FrameN.M files were read only should have prevented this.
I am at a total loss to explain this!!
after exiting the 'mcidas' Unix session, I went back to troublshooting
in your account.
o the next thing I did as you was list out the Unix environment:
> env
HOME=/export/home/mkeables
...
UMASK=077
MCHOME=/export/home/mcidas
MCDATA=/export/home/mkeables/mcidas/data
MCPATH=/export/home/mkeables/mcidas/data:/export/home/mcidas/data:/export/home/mcidas/help
MCGUI=/export/home/mcidas/bin
MCTABLE_READ=/export/home/mkeables/mcidas/data/MCTABLE.TXT:/export/home/mcidas/data/ADDESITE.TXT
MCTABLE_WRITE=/export/home/mkeables/data/MCTABLE.TXT
There are several problems here:
-> I recommend that umask be 002, but this is not crutial
-> MCTABLE_READ is incorrectly set. The problem is the colon separating:
/export/home/mkeables/mcidas/data/MCTABLE.TXT
from:
/export/home/mcidas/data/ADDESITE.TXT
This should be a semi-colon
-> MCTABLE_WRITE is incorrect. It should be
/export/home/mkeables/mcidas/data/MCTABLE.TXT
To correct the problems above, I edited ~mkeables/.cshrc and changed
the McIDAS definition block to:
# C-shell environment variable definitions for a general user
# MCHOME - the HOME directory of the user 'mcidas'
setenv MCHOME /export/home/mcidas
# NOTE: conditional definition is needed for C-shell users
if ( ! ${?MCPATH} ) then
setenv MCDATA $HOME/mcidas/data
setenv MCPATH ${MCDATA}:$MCHOME/data:$MCHOME/help
setenv MCGUI $MCHOME/bin
setenv MCTABLE_READ "$MCDATA/MCTABLE.TXT;$MCHOME/data/ADDESITE.TXT"
setenv MCTABLE_WRITE "$MCDATA/MCTABLE.TXT"
if ( ! ${?PATH} ) then
setenv PATH $MCGUI
else
setenv PATH ${MCGUI}:$PATH
endif
endif
# Limit ADDE transfers to compressed ones
#setenv MCCOMPRESS TRUE
Note that the colon in MCTABLE_READ has been replaced by a colon, and
MCTABLE_WRITE was changed to point at
/export/home/mkeables/mcidas/data/MCTABLE.TXT
One question, however. Why is the MCCOMPRESS line commented out? I
makes more sense to set MCCOMPRESS so that ADDE transfers be done in
compressed mode. This really helps speed things up when going out
to remote servers. Since I was already in the file, I uncommented
this setting.
To make the changes in .cshrc active, I then did:
unsetenv MCPATH
source ~/.cshrc
o after making the above changes, I went back to your ~/mcidas/data
directory to see if the DATALOC invocation would work correctly:
> cd mcidas/data
> dataloc.k LIST
Group Name Server IP Address
-------------------- ----------------------------------------
BLIZZARD 144.92.109.163
MYDATA <LOCAL-DATA>
RTGRIDS CYCLONE.NATNET.DU.EDU
RTIMAGES CYCLONE.NATNET.DU.EDU
RTNEXRAD <LOCAL-DATA>
RTNIDS CYCLONE.NATNET.DU.EDU
RTNOWRAD CYCLONE.NATNET.DU.EDU
RTPTSRC CYCLONE.NATNET.DU.EDU
RTWXTEXT CYCLONE.NATNET.DU.EDU
TOPO CYCLONE.NATNET.DU.EDU
<LOCAL-DATA> indicates that data will be accessed from the local data directory.
DATALOC -- done
As you can see, it does. Since you really want to access RTNEXRAD data
from your remote ADDE server, I then ran a DATALOC command to pint at it:
dataloc.k ADD RTNEXRAD cyclone.natnet.du.edu
Group Name Server IP Address
-------------------- ----------------------------------------
RTNEXRAD CYCLONE.NATNET.DU.EDU
<LOCAL-DATA> indicates that data will be accessed from the local data directory.
DATALOC -- done
Now, the output shows that the command worked. A full list verifies this:
> dataloc.k LIST
Group Name Server IP Address
-------------------- ----------------------------------------
BLIZZARD 144.92.109.163
MYDATA <LOCAL-DATA>
RTGRIDS CYCLONE.NATNET.DU.EDU
RTIMAGES CYCLONE.NATNET.DU.EDU
RTNEXRAD CYCLONE.NATNET.DU.EDU
RTNIDS CYCLONE.NATNET.DU.EDU
RTNOWRAD CYCLONE.NATNET.DU.EDU
RTPTSRC CYCLONE.NATNET.DU.EDU
RTWXTEXT CYCLONE.NATNET.DU.EDU
TOPO CYCLONE.NATNET.DU.EDU
<LOCAL-DATA> indicates that data will be accessed from the local data directory.
DATALOC -- done
o I tried exercising the remote server by issuing an IMGLIST asking for a
list of NEXRAD IDs:
> imglist.k RTNEXRAD/N0R ID=LIST
Image file directory listing for:RTNEXRAD/N0R
imglist.k: Image Directory READ failed -- Server Error
This is the same failure as you were reporting. This is puzzling since
I note that the VERSION.TXT file in ~mcidas/data shows that you are up
to addendum 7.704, the current update.
I decided to log back in as 'mcidas' and troubleshoot there. I found
the same problem with MCTABLE_READ in ~mcidas/.cshrc as I found
in ~mkeables/.cshrc. I made the same correction and made the
changes active by unsetting MCPATH and sourcing ~/.cshrc.
I then went into the workdata directory and checked out the DATALOCs
for 'mcidas'. They included access to the NEXRAD data as LOCAL-DATA:
/export/home/mcidas/workdata% dataloc.k LIST
Group Name Server IP Address
-------------------- ----------------------------------------
BLIZZARD 144.92.109.163
MYDATA <LOCAL-DATA>
RTGRIDS CYCLONE.NATNET.DU.EDU
RTIMAGES CYCLONE.NATNET.DU.EDU
RTNEXRAD <LOCAL-DATA>
RTNIDS CYCLONE.NATNET.DU.EDU
RTNOWRAD CYCLONE.NATNET.DU.EDU
RTPTSRC CYCLONE.NATNET.DU.EDU
RTWXTEXT CYCLONE.NATNET.DU.EDU
TOPO CYCLONE.NATNET.DU.EDU
<LOCAL-DATA> indicates that data will be accessed from the local data directory.
DATALOC -- done
I changed this to the remote server:
/export/home/mcidas/workdata% dataloc.k ADD RTNEXRAD cyclone.natnet.du.edu
Group Name Server IP Address
-------------------- ----------------------------------------
RTNEXRAD CYCLONE.NATNET.DU.EDU
<LOCAL-DATA> indicates that data will be accessed from the local data directory.
DATALOC -- done
/export/home/mcidas/workdata% dataloc.k LIST
And then tried to use the remote server for an IMGLIST:
/export/home/mcidas/workdata% imglist.k RTNEXRAD/N0R ID=LIST
Image file directory listing for:RTNEXRAD/N0R
imglist.k: TCP write failed
imglist.k: done
So, something _was_ incorrectly setup for ADDE remote services. I see
that the TCP/IP daemon wrapper package is installed, so I am suspicious
of it:
/export/home/mcidas/workdata% cat /etc/inetd.conf
#SEC #
#SEC #ident "@(#)inetd.conf 1.33 98/06/02 SMI" /* SVr4.0 1.5
*/
#SEC #
#SEC #
#SEC # Configuration file for inetd(1M). See inetd.conf(4).
# WVtcpd
# WVtcpd The 7.6 version of the TCP/IP daemon wrapper package is installed
# WVtcpd On this workstation.
# WVtcpd
# WVtcpd It was compilled with the Language extensions enable (See
hosts_options(5))
# WVtcpd
# WVtcpd Example of use:
# WVtcpd
# WVtcpd finger stream tcp nowait nobody /usr/bin/tcpd
in.fingerd
# WVtcpd smtp stream tcp nowait root /usr/bin/tcpd
/usr/lib/sendmail -bs
# WVtcpd tftp dgram udp wait root /usr/bin/tcpd in.tftpd -s /tftpboot
# WVtcpd
BUT, I do _not_ see it being used for McIDAS ADDE:
cat /etc/inetd.conf
...
mcserv stream tcp nowait mcadde /export/home/mcidas/bin/mcservsh
mcservsh -H /export/home/mcidas
mccompress stream tcp nowait mcadde
/export/home/mcidas/bin/mcservsh mcservsh -H /export/home/mcidas
While sniffing around, I did see one thing that I would change, but
this is not the cause of the TCP write failed error above. I would
change the default shell for 'mcadde' to /bin/false (it is now
/bin/csh). This must be done as 'root'. I made the change using
sudo.
After verifying that TCP wrappers are not being used for the McIDAS ADDE
services, I started looking for a problem in ~mcidas/.mcenv. What
I found was that MCDATA was being defined in terms of MCDATA:
MCDATA=$MCDATA/workdata
This should be:
MCDATA=$MCHOME/workdata
I changed that line, and then retested an imglist.k for RTNEXRAD
data from the 'mcidas' account:
/export/home/mcidas/workdata% imglist.k RTNEXRAD/N0R ID=LIST
Image file directory listing for:RTNEXRAD/N0R
Pos Satellite/ Date Time Center Band(s)
sensor Lat Lon
--- ------------- ------------ -------- ---- ---- ------------
1 RADAR 5 FEB 01036 23:47:00 FTG 1
2 RADAR 5 FEB 01036 23:50:00 GJX 1
3 RADAR 5 FEB 01036 23:56:00 PUX 1
imglist.k: done
OK, so the remote ADDE server is now working for 'mcidas'. Time to test it
out for you:
> imglist.k RTNEXRAD/N0R ID=LIST
Image file directory listing for:RTNEXRAD/N0R
Pos Satellite/ Date Time Center Band(s)
sensor Lat Lon
--- ------------- ------------ -------- ---- ---- ------------
1 RADAR 5 FEB 01036 23:50:00 GJX 1
2 RADAR 5 FEB 01036 23:56:00 PUX 1
3 RADAR 5 FEB 01036 23:57:00 FTG 1
imglist.k: done
Looking good!
Let's recap the changes that were made:
-- in the 'mkeables' account --
1) corrected MCTABLE_READ definition in ~/.cshrc
2) uncommented the setenv MCCOMPRESS TRUE line in ~/.cshrc
3) removed FRAMENH.001 and TERMCHAR.001 in ~/mcidas/data
4) removed core in ~/mcidas/data
5) pointed McIDAS-X sessions at the ADDE remote server on cyclone for
RTNEXRAD
-- in the 'mcidas' account --
1) removed FRAMENH.001 and TERMCHAR.001 in ~/workdata
2) removed Frame*.* in ~/help
3) pointed McIDAS-X sessions at the ADDE remote server on cyclone for
RTNEXRAD
4) found and fixed the MCDATA definition in ~/.mcenv
5) changed the default shell for 'mcadde' to /bin/false in /etc/passwd
>On a totally unrelated matter, how can I set the font color on FRMLABEL?
FRMLABEL draws labels in the image plane, not the graphics:
LEVel=text bg | brightness level for text and background (def=255 0)
If you want to annotate with text, then you need to use the ZA
command. ZA allows you to select change the FONT and label colors.
>I've got the NEXRAD images up on our weather server
>(http://cyclone.natnet.du.edu/) and would rather diplay the font in some
>color other than magenta.
The color being used is one of the colors from the image enhancement.
You need to look at that enhancement and see which level is most
pleasing for the FRMLABEL label. The image I see on your web page
shows that the enhancement has white at the upper range of brightness
levels. A listing of the CREF enhancement used:
EU TABLE CREF
Brightness Blue Green Red
min max min max min max min max
--- --- --- --- --- --- --- ---
0 15 0 0 0 0 0 0
16 31 196 196 196 196 196 196
32 47 118 118 118 118 118 118
48 63 170 170 170 170 255 255
64 79 140 140 140 140 238 238
80 95 112 112 112 112 201 201
96 111 144 144 251 251 0 0
112 127 0 0 187 187 0 0
128 143 112 112 255 255 255 255
144 159 96 96 208 208 208 208
160 175 96 96 96 96 255 255
176 191 0 0 0 0 218 218
192 207 0 0 0 0 174 174
208 223 255 255 0 0 0 0
224 239 255 255 255 255 255 255
240 255 255 255 0 0 231 231
EU: Done
shows that you will have to specify LEV= in the range of 224 - 239. This
would be something like:
FRMLABEL LEV=230 0 " DU CLIMATE LAB DENVER RADAR (ID) (DAY) (HHMM)Z
I displayed a Composite Reflectivity image from FTG in a McIDAS session
running in your account; drew a map; put up a data BAR; annotated it;
and saved it in frmlabel.gif as an example. You will find this file in
~mkeables/mcidas/data/frmlabel.gif. Please let me know if this is what
you had in mind.
>Thanks.
You are welcome.
One quick additional comment. I have been working on the next addendum
for 7.7, 7.705. In this addendum, I have updated the UWGRID program
and have fleshed out the GLOBAL.BAT file that can add grids to the
RTGRIDS/MRF-UW dataset files. By configuring the uwgrid.sh shell
script and running it from cron at the appropriate times, one can
generate GRID files that are exactly the same (or are enhanced
versions) as the ones that used to be sent in the Unidata-Wisconsin
datastream. This is useful since the Fkey menu was always geared for
using those files.
Additionally, I have updated the Fkey menu be about 100% ADDEized. One
thing that I have added is access to the NOAAPORT GINI imagery as long
as one can contact remote ADDE servers that will provide the data. I
setup GINI imagery access in your account for you to try:
DATALOC ADD GINIEAST PAPAGAYO.UNL.EDU
DATALOC ADD GINIWEST PAPAGAYO.UNL.EDU
DATALOC ADD GINICOMP STRATUS.AL.NOAA.GOV
DATALOC ADD RTGINI ADDE.UCAR.EDU
The datasets GINIEAST, GINIWEST, and GINICOMP are subsets of RTGINI.
The reason for splitting up the dataset was so that sites can point
at different ADDE servers for imagery from different parts of the
country.
I encourage you to give these data sets a whirl and let me know
what you think. Here are some sample IMGDISP invocations that should
be illustrative:
SF 1
EG B
IMGDISP GINIEAST/GE1KVIS STA=KBOS MAG=-3 REFRESH='EG;MAP H'
IMGDISP GINIEAST/GE1KVIS STA=KBOS MAG=1 REFRESH='EG;MAP VH'
IMGDISP GINIWEST/GW1KVIS STA=KASE MAG=-2 REFRESH='EG;MAP H'
IMGDISP GINICOMP/GSN8KIR STA=KTOP MAG=1 REFRESH='EG;MAP H'
DSINFO I GINIEAST
DSINFO I GINIWEST
DSINFO I GINICOMP
DSINFO I RTGINI
Tom
>From address@hidden Tue Feb 6 10:47:54 2001
Tom,
Thanks for everything that you did yesterday to straighten out the mess on
cyclone. I know where some of the problems came from (e.g. the : vs. ; was
my mistake), but I'm not sure about some of the others (I _KNOW_ I set UMASK
to 002 when I created the account, for example.) I appreciate you taking the
time to spell out exactly what was wrong and what you did to fix it.
Anyway, thanks for getting the ADDE back on track, and also for the advice
on FRMLABEL text colors.
--Mike
Michael J. Keables, Ph.D. email: address@hidden
Associate Professor voice: 303.871.2653
Director, Environmental Science fax: 303.871.2201
Department of Geography GPS: 39 40 28.3 N
University of Denver 104 57 47.7 W
Denver, CO 80208 aural: "Hey Mike!!"