>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:/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: address@hidden 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: address@hidden 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
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.