[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
20010205: McIDAS-XCD MDXX decoding problems
- Subject: 20010205: McIDAS-XCD MDXX decoding problems
- Date: Mon, 05 Feb 2001 20:07:24 -0700
>From: Leigh Orf <address@hidden>
>Organization: UNCA
>Keywords: 200102052335.f15NZkX27276 McIDAS-XCD
Leigh,
>This mcidas stuff is pretty frustrating. If it ain't one thing it's
>another.
This is not sounding good...
>After I sent my last message, one quirk that I noticed was that I
>couldn't view Skew-T soundings as a normal user; it always reported that
>no data was available, even though it was (I could draw upper air maps
>etc., MDX files were there and being updated).
You don't say how you were trying to display the Skew-T diagrams.
If through the MCGUI, the problem would be one of access to the
MDXX files directly. If through the Fkey menu, then the problem is
in an ADDE service/setup.
>Also, if I logged in as
>user mcidas, then I could see the soundings. Do you know what could
>explain this?
I suspect a problem in the ADDE setup for your normal user. Can you
tell me the user account name so I could check things out there?
>Anyway I tried to figure it out but couldn't. It was driving me
>nuts. So, thinking I screwed up a configuration option, I stopped the
>LDM, moved /data/mcidas/data to /data/mcidas/data.broken, made a new
>/data/mcidas/data directory with the correct permissions, and followed
>the steps to set up the mcidas-XCD stuff.
Wow! Talk about taking the bull by the horns!
>Now the problem is I am not getting any MDX files being written in
>/data/mcidas/data! The routing and redirection tables look good. I
>finally have to give up.
>Sorry to be such a pain, but could you log into storm2.atms.unca.edu,
>which is running the LDM and holds the /data/mcidas/data files and poke
>around.
I took you up on your offer and logged in and became 'mcidas'. A quick
check shows that MDXX files _are_ being written to /data/mcidas/data:
storm2[631]:/data/mcidas/data% ls -alt MDXX*
-rw-rw-r-- 1 ldm ldmadmin 4984780 Feb 5 20:27 MDXX0037
-rw-rw-r-- 1 ldm ldmadmin 1215552 Feb 5 20:27 MDXX0057
-rw-rw-r-- 1 ldm ldmadmin 698040 Feb 5 20:27 MDXX0017
-rw-rw-r-- 1 ldm ldmadmin 176672 Feb 5 20:27 MDXX0027
-rw-rw-r-- 1 ldm ldmadmin 3612936 Feb 5 20:27 MDXX0007
-rw-rw-r-- 1 ldm ldmadmin 5010160 Feb 5 20:27 MDXX0036
-rw-rw-r-- 1 ldm ldmadmin 8487936 Feb 5 20:24 MDXX0056
-rw-rw-r-- 1 ldm ldmadmin 157872 Feb 5 20:06 MDXX0018
-rw-rw-r-- 1 ldm ldmadmin 5682808 Feb 5 19:54 MDXX0016
-rw-rw-r-- 1 ldm ldmadmin 187392 Feb 5 19:39 MDXX0058
-rw-rw-r-- 1 ldm ldmadmin 42707836 Feb 5 19:35 MDXX0006
-rw-rw-r-- 1 ldm ldmadmin 16640 Feb 5 19:24 MDXX0028
-rw-rw-r-- 1 ldm ldmadmin 1458848 Feb 5 19:05 MDXX0026
I decided to start a McIDAS session with display back here to Unidata
so I could see the output from things like UAPLOT.
After the session came up, I find that I am able to do the expected kind
of things using ADDE commands:
UAPLOT 72469 0
SF 2
MAP NACONF
RAOBPLOT T 700 OLAY 0
RAOBCON Z 500 OLAY 0
SFCMG KDEN
The display from the SFCMG invocation showed me that the surface decoding
started working right at 0Z. This must be a clue as to why you weren't
seeing MDXX files being created during the day. I will have to ponder
this one.
While I was on your machine, I decided to update the McIDAS installation
to the latest bugfix revision, 7.704. To do this, I:
cd mcidas7.7/update
rm mcupdate.tar.Z upcnidz.tar
ftp ftp.unidata.ucar.edu
<user>
<pass>
cd unix/770/bugfix
binary
get mcupdate.tar.Z
quit
./mcunpack
cd ../src
make all
<as ldm>
ldmadmin stop
<as mcidas>
cd ~mcidas/workdata
cp GINI.CFG GINI.CFG.BAK
cp NNEXRAD.CFG NNEXRAD.CFG.BAK
cp STRTABLE STRTABLE.BAK
cp WNEXRAD.CFG WNEXRAD.CFG.BAK
cp mcscour.sh mcscour.sh.bak
cp uwgrid.sh uwgrid.sh.bak
make install.all
cd ~mcidas/workdata
cp GINI.CFG.BAK GINI.CFG
cp NNEXRAD.CFG.BAK NNEXRAD.CFG
cp STRTABLE.BAK STRTABLE
cp WNEXRAD.CFG.BAK WNEXRAD.CFG
cp mcscour.sh.bak mcscour.sh
cp uwgrid.sh.bak uwgrid.sh
<as ldm>
ldmadmin start
When I did an 'ipcs', however, I saw LOTS of shared memory segments
in use by 'ldm'. It may take a reboot to clear this up as 'ipcrm's
didn't seem to clear them.
Also, a listing in ~ldm/.mctmp showed LOTS of directories left over by
abortive mini-mcidas sessions run by the LDM; I removed these. These
sessions would be run as ROUTE PostProcess BATCH invocations from
ldm-mcidas decoders. We will need to keep an eye on this.
What I really want to do, however, is figure out what was going on
in the user account that you were fighting.
Guessing that the account might be 'unca-mcidas', I logged into it.
What I found was that this account is "pointed" at vortex for its
data:
[unca-mcidas@storm2 data]$ dataloc.k LIST
Group Name Server IP Address
-------------------- ----------------------------------------
BLIZZARD ADDE.UCAR.EDU
CIMSS VORTEX.ATMS.UNCA.EDU
MYDATA <LOCAL-DATA>
RTGINI VORTEX.ATMS.UNCA.EDU
RTGRIDS VORTEX.ATMS.UNCA.EDU
RTIMAGES VORTEX.ATMS.UNCA.EDU
RTNIDS VORTEX.ATMS.UNCA.EDU
RTNOWRAD VORTEX.ATMS.UNCA.EDU
RTPTSRC VORTEX.ATMS.UNCA.EDU
RTWXTEXT VORTEX.ATMS.UNCA.EDU
TOPO VORTEX.ATMS.UNCA.EDU
WSINIDS <LOCAL-DATA>
<LOCAL-DATA> indicates that data will be accessed from the local data directory.
DATALOC -- done
Since you have moved your LDM/XCD processing off of vortex, it is likely
that it no longer has any data files. This is confirmed by a PTLIST
from the 'unca-mcidas' account:
[unca-mcidas@storm2 data]$ ptlist.k RTPTSRC/PTSRCS.ALL FORM=FILE
ptlist.k: No MD files found
ptlist.k: Done
This would explain why this account would not be able to do any point
source plots. The problem is that you said that the normal account was
able to do certain plots, but it could not do Skew-Ts. Perhaps
the 'unca-mcidas' account is not the one you were referring to?
To test things out, I did the following:
o as 'root' add the file mccompress to /etc/xinetd.d. This will allow
compressed ADDE transactions from storm2
o as 'unca-mcidas', I did the following:
cd ~/mcidas/data
dataloc.k ADD RTPTSRC storm2.atms.unca.edu
ptlist.k RTPTSRC/PTSRCS.ALL FORM=FILE
Pos Description Schema NRows NCols Date
------ -------------------------------- ------ ----- ----- -------
6 SAO/METAR data for 05 FEB 2001 ISFC 72 6000 2001036
7 SAO/METAR data for 06 FEB 2001 ISFC 72 6000 2001037
16 Mand. Level RAOB for 05 FEB 2001 IRAB 8 1300 2001036
17 Mand. Level RAOB for 06 FEB 2001 IRAB 8 1300 2001037
18 Mand. Level RAOB for 07 FEB 2001 IRAB 8 1300 2001038
26 Sig. Level RAOB for 05 FEB 2001 IRSG 16 6000 2001036
27 Sig. Level RAOB for 06 FEB 2001 IRSG 16 6000 2001037
28 Sig. Level RAOB for 07 FEB 2001 IRSG 16 6000 2001038
36 SHIP/BUOY data for 05 FEB 2001 ISHP 24 2000 2001036
37 SHIP/BUOY data for 06 FEB 2001 ISHP 24 2000 2001037
56 SYNOPTIC data for 05 FEB 2001 SYN 8 6200 2001036
57 SYNOPTIC data for 06 FEB 2001 SYN 8 6200 2001037
58 SYNOPTIC data for 07 FEB 2001 SYN 8 6200 2001038
66 PIREP/AIREP data for 05 FEB 2001 PIRP 24 1500 2001036
67 PIREP/AIREP data for 06 FEB 2001 PIRP 24 1500 2001037
ptlist.k: Done
You can see that this account now is getting ADDE services for RTPTSRC
data from the storm2 remote ADDE server. Given this, I decided to
setup DATALOCs for all relevant datasets to storm2.
After issuing several DATALOC commands as 'unca-mcidas':
cd ~/mcidas/data
dataloc.k ADD RTGINI adde.ucar.edu
dataloc.k ADD GINIEAST papagayo.unl.edu
dataloc.k ADD GINIWEST papagayo.unl.edu
dataloc.k ADD GINICOMP stratus.al.noaa.gov
dataloc.k ADD CIMSS STORM2.ATMS.UNCA.EDU
dataloc.k ADD RTWXTEXT STORM2.ATMS.UNCA.EDU
dataloc.k ADD TOPO STORM2.ATMS.UNCA.EDU
dataloc.k ADD RTNEXRAD STORM2.ATMS.UNCA.EDU
dataloc.k ADD RTNIDS STORM2.ATMS.UNCA.EDU
dataloc.k ADD RTNOWRAD STORM2.ATMS.UNCA.EDU
dataloc.k ADD RTIMAGES STORM2.ATMS.UNCA.EDU
dataloc.k ADD RTGRIDS STORM2.ATMS.UNCA.EDU
The following set of DATALOCations are now active:
dataloc.k LIST
Group Name Server IP Address
-------------------- ----------------------------------------
BLIZZARD ADDE.UCAR.EDU
CIMSS STORM2.ATMS.UNCA.EDU
GINICOMP STRATUS.AL.NOAA.GOV
GINIEAST PAPAGAYO.UNL.EDU
GINIWEST PAPAGAYO.UNL.EDU
MYDATA <LOCAL-DATA>
RTGINI ADDE.UCAR.EDU
RTGRIDS STORM2.ATMS.UNCA.EDU
RTIMAGES STORM2.ATMS.UNCA.EDU
RTNEXRAD STORM2.ATMS.UNCA.EDU
RTNIDS STORM2.ATMS.UNCA.EDU
RTNOWRAD STORM2.ATMS.UNCA.EDU
RTPTSRC STORM2.ATMS.UNCA.EDU
RTWXTEXT STORM2.ATMS.UNCA.EDU
TOPO STORM2.ATMS.UNCA.EDU
WSINIDS <LOCAL-DATA>
<LOCAL-DATA> indicates that data will be accessed from the local data directory.
DATALOC -- done
This account is now setup to process data from storm2. I tested it out
by starting a 1 frame session and issuing several data display commands:
IMGLIST RTIMAGES/GE-IR.ALL
Image file directory listing for:RTIMAGES/GE-IR
Pos Satellite/ Date Time Center Band(s)
sensor Lat Lon
--- ------------- ------------ -------- ---- ---- ------------
1 G-8 IMG 5 FEB 01036 22:15:00 23 71 4
2 G-8 IMG 5 FEB 01036 23:15:00 23 71 4
3 G-8 IMG 6 FEB 01037 00:15:00 23 71 4
4 G-8 IMG 6 FEB 01037 01:15:00 23 71 4
5 G-8 IMG 6 FEB 01037 02:15:00 23 71 4
IMGLIST: done
IMGDISP RTIMAGES/GE-IR LAT=32 82 MAG=-2 REFRESH='EG;MAP H'
Beginning Image Data transfer, bytes= 310256
IMGDISP: loaded frame 1
EG;MAP H
IMGDISP: done
Erased graphic frame(s) 1-1
MAP: Completed frame 1
SFCPLOT T OLAY FRAME
SFCCON PRE OLAY FRAME
Accessing Dataset Name = RTPTSRC/SFCHOURLY.ALL
Number of data points input to objective analysis: 916
PTCON: Done
SFCCON - Done
FRNTDISP OLAY FRAME
FRNTDISP - Begin
FRNTDISP - Done
EG B
Erased image and graphic frame(s) 1-1
SFCMG KDEN
SFCMG: done
EG B
Erased image and graphic frame(s) 1-1
UAPLOT 72469 0
All commands worked with no hitches. I feel reasonably safe saying
that things are working correctly on storm2.
One recommendation: set MCCOMPRESS=TRUE as an environment setting for
each user who will be running McIDAS-X. It will really help when
you access remote datasets.
>I did search through the mailing list archives and still didn't come up
>with any answers. My guess is this has to do with the mcidas account not
>being properly set up, but the environment variables seem to be right,
>and redirections and routing looks good.
OK, thanks for trying.
>I really want to be able to do this stuff on my own but it is beginning
>to consume way too much of my time and energy. Chances are you can
>figure this out quickly.
No problem, that is what I am here for after all.
>Please let me know whatever you did to fix things. I figure at some
>point I'll figure this out. I did notice that there are some files
>in /data/mcidas/data.broken which aren't in /data/mcidas/data; for
>instance, is XCD.NAM and XCDDEC.NAM supposed to be there?
No, those files should end up in the ~mcidas/workdata directory. They
are created during the XCD setup phase.
>Thanks for your help. This stuff consumes me and I have to just stop
>after not getting anywhere!
No worries.
One last request. Please let me know if the account that you were trying
to work from was 'unca-mcidas'. If it wasn't, then there still might be
some troubleshooting to do in that account.
Tom
>From address@hidden Mon Feb 5 18:40:49 2001
>Subject: MDX files appear, but original problem remains
OK, I guess it takes a while for the MDX files to appear. I thought
since they are always being updated that they would appear immediately
after I started the ldm.
Now I'm back to my original problem. When I am a "normal user" and try
to view an upper air sounding such as a skewt, I get:
UAPLOT 72317 0 DAY=2001037 GRA=13 FORM=SKEWT SF=YES
No observations found for selection conditions
SNDSKEWT: A sounding is not available in the dataset
UAPLOT: Done
However, as user mcidas on the same machine I *can* view the
soundings. This sounds a lot like a permissions problem....? but I can't
figure it out.
When you have a few minutes, please check it and let me know what you
find.
Leigh
