[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20010205: McIDAS-XCD MDXX decoding problems



>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:

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.