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

20010111: McIDAS 7.7 Upgrade Problem (cont.)

>From: Michael Keables <address@hidden>
>Organization: Geography Dept, University of Denver
>Keywords: 200101102035.f0AKZPo29393 McIDAS-X 7.7x


>Still having problems...

>I issue the command IMGDISP RTIMAGES/GEW-IRTOPO (or any other image
>dataset). When logged in as 'mcidas', I get the image from 19Z Jan 09 image.

OK, I just logged onto cyclone as 'mcidas' and am running a McIDAS-X
session.  I verified your experience in running the IMGDISP command
above.  I then did a listing of the RTIMAGES/GEW-IRTOPO set of images:

IMGLIST RTIMAGES/GEW-IRTOPO.ALL                                        
Image file directory listing for:RTIMAGES/GEW-IRTOPO                   
 Pos Satellite/         Date       Time      Center   Band(s)          
     sensor                                 Lat  Lon                   
 --- -------------  ------------  --------  ---- ---- ------------     
   1  COMPOSITE      9 JAN 01009  02:15:00    26  100 4                
   2  COMPOSITE      9 JAN 01009  03:15:00    26  100 4                
   3  COMPOSITE      9 JAN 01009  04:00:00    26  100 4                
   4  COMPOSITE      8 JAN 01008  19:15:00    26  100 4                
   5  COMPOSITE      9 JAN 01009  14:15:00    26  100 4                
   6  COMPOSITE      9 JAN 01009  16:15:00    26  100 4                
   7  COMPOSITE      9 JAN 01009  17:15:00    26  100 4                
   8  COMPOSITE      9 JAN 01009  18:15:00    26  100 4                
IMGLIST: Nominal start date is out of range  -2139062144               
   9  COMPOSITE      9 JAN 01009  19:00:00    26  100 4                
  10                44 JAN 62144  06:21:44            8,16,24,32       
IMGLIST: done 

This listing shows us two important things:

The images are apparently not being updated, and there is a major problem
with two of the images in the set or in the listing program itself.

To check to see if there is a problem in either IMGLIST or in hte
ADDE serving of the data, I did the following:

RTIMAGES/GEW-IRTOPO      IMAGE AREA 280-289          GOES-East/West IR>

This told me what AREA files I could find the GEW-IRTOPO files in on
your machine.  I then used the LA command to list them again:

LA 280 289                                                             
  area  ss  yyyddd hhmmss  lcor  ecor lr er zr  lsiz  esiz z    bands  
  ---- ---- ------ ------ ----- ----- -- -- -- ----- ----- -    -----  
   280  10  101009  21500    91    89  4  4  1   592  1204 1 ...4.....>
   281  10  101009  31500    91    89  4  4  1   592  1204 1 ...4.....>
   282  10  101009  40000    91    89  4  4  1   592  1204 1 ...4.....>
   283  10  101008 191500    91    89  4  4  1   592  1204 1 ...4.....>
   284  10  101009 141500    91    89  4  4  1   592  1204 1 ...4.....>
   285  10  101009 161500    91    89  4  4  1   592  1204 1 ...4.....>
   286  10  101009 171500    91    89  4  4  1   592  1204 1 ...4.....>
   287  10  101009 181500    91    89  4  4  1   592  1204 1 ...4.....>
   288  10  101009 190000    91    89  4  4  1   592  1204 1 ...4.....>

This listing looks "better" that the IMGLIST listing, but it is missing
an entry for AREA0289.  The next thing to look at is the actual files
AREA0280 - AREA0289:

DMAP AREA028                                                           
WARNING: cannot examine directory /home/mcidas/data: No such file or d>
WARNING: cannot examine directory ~mcidas/data: No such file or direct>
---- --------- ------------ -------- ---------                         
-rw-    714128 Jan 08 19:36 AREA0280 /data/ldm/mcidas                  
-rw-    714128 Jan 08 20:38 AREA0281 /data/ldm/mcidas                  
-rw-    714128 Jan 08 21:17 AREA0282 /data/ldm/mcidas                  
-rw-    714128 Jan 08 12:37 AREA0283 /data/ldm/mcidas                  
-rw-    714128 Jan 09 08:16 AREA0284 /data/ldm/mcidas                  
-rw-    714128 Jan 09 09:37 AREA0285 /data/ldm/mcidas                  
-rw-    714128 Jan 09 10:36 AREA0286 /data/ldm/mcidas                  
-rw-    714128 Jan 09 11:36 AREA0287 /data/ldm/mcidas                  
-rw-    714048 Jan 09 12:23 AREA0288 /data/ldm/mcidas                  
-rw-         1 Jan 11 13:36 AREA0289 /data/ldm/mcidas                  
6427073 bytes in 10 files 

You can see from this list that AREA file 289 is hosed (file size is '1'),
but it looks like it is getting updated (time is more current than the
other ones).

Armed with this information, I decided to check on some of the other
products that should be created on your machine:

DMAP AREA027                                                           
WARNING: cannot examine directory /home/mcidas/data: No such file or d>
WARNING: cannot examine directory ~mcidas/data: No such file or direct>
---- --------- ------------ -------- ---------                         
-rw-    897280 Jan 08 12:30 AREA0270 /data/ldm/mcidas                  
-rw-    897280 Jan 08 15:29 AREA0271 /data/ldm/mcidas                  
-rw-    897280 Jan 08 18:29 AREA0272 /data/ldm/mcidas                  
-rw-    897280 Jan 09 09:29 AREA0273 /data/ldm/mcidas                  
-rw-    897280 Dec 19 06:29 AREA0274 /data/ldm/mcidas                  
-rw-    897280 Dec 19 09:29 AREA0275 /data/ldm/mcidas                  
-rw-    897280 Dec 19 12:29 AREA0276 /data/ldm/mcidas                  
-rw-    897280 Dec 19 15:30 AREA0277 /data/ldm/mcidas                  
-rw-    897280 Dec 19 18:29 AREA0278 /data/ldm/mcidas                  
-rw-    897280 Dec 26 09:31 AREA0279 /data/ldm/mcidas                  
8972800 bytes in 10 files 

These files (RTIMAGES/MOLL-IRTOPO) are also not getting updated as they

I checked ~ldm/decoders/batch.k and xcd_run to make sure that the
McIDAS environment variables were set OK, and they are.

My next best guess is that there is something amiss in the routing
table that is causing problems in the decoding of data by the ldm-mcidas
decoder, pnga2area.

Before acting on that, however, I decided to check out the REDIRECTions
that are active in the 'mcidas' account.  I did this by brute force:

cd ~mcidas/workdata

Here are some lines that need changing:

AREA901*     /home/mcidas/data
LWPATH.NAM ~mcidas/data

They should be (and I changed them):

AREA90*     /export/home/mcidas/data

The improper REDIRECTion for AREA90* (pointing to the non-existent
/home/mcidas/data directory) would prevent the topographic compositing
from working.  I also changed the redirection so that the global
topographic image AREA9000 could be found (more on this a couple lines

Also, there should _never_ be a copy of LWPATH.NAM in ~mcidas/data, so
I deleted it:

cd ~mcidas/data

While I was muching around in ~mcidas/data, I decided to FTP the global
topography file that is not sent out with the McIDAS distribution:

cd ~mcidas/data
ftp ftp.unidata.ucar.edu
  <user> anonymous
  <pass> email adddress
  cd pub/mcidas
  get AREA9000

So, after these changes, the 'mcidas' account should now have a correct
set of file REDIRECTions and the image compositing should start working
correctly.  We will know if this is true after some new images are

>When logged in as 'mkeables' I get a blank window (no error message,
>though.) When using GUI as 'mcidas' I don't get a listing of current
>imagery; the only image that is listed and displayed is the 19Z Jan 09
>image. When using GUI as 'mkeables' I get no images listed in the image list
>nor displayed in the graphics window.

I am afraid that your login as you might be using the LWPATH.NAM file
that was incorrectly located in the ~mcidas/data directory.  Each user
should end up with his/her own LWPATH.NAM file, and that file should
be located in his/her mcidas/data directory (~mkeables/mcidas/data/LWPATH.NAM
for you).

While waiting for new image data to arrive, I decided to remove all of
the bad AREA files from /data/ldm/mcidas (bad indicated by their being
really small like the example above).

I found two such files:

     11412 -rw-rw-rw-   1 ldmgroup       1 Jan 11 13:36 AREA0299
     11422 -rw-rw-rw-   1 ldmgroup       1 Jan 11 13:36 AREA0289

I deleted those.

Right after deleting those bad files, I did a quick long list in
/data/ldm/mcidas and saw that a new GEW-IRTOPO file had been created:

     11422 -rw-rw-r--   1 ldmgroup  714048 Jan 11 14:16 AREA0289

so it looks like compositing is once again working.  To verify this, 
I restarted the McIDAS-X session and took a look:

IMGDISP RTIMAGES/GEW-IRTOPO EU=TOPOSAT                                 
Beginning Image Data transfer, bytes= 308480                           
IMGDISP: loaded frame  1                                               
IMGDISP: done                                                          
EU: Restoring TOPOSAT.ET   to frame(s)=   1                            
EU: Done 

This time, the newly created image (21Z for Jan 11) was displayed, so
it really does look like the problem has been solved.

As a recap, the problem was caused by the bad REDIRECTion for the AREA901*
in ~mcidas/workdata/LWPATH.NAM and the incorrect REDIRECTion for
LWPATH.NAM to ~mcidas/data.

re: running example redirect.k from previous email

>I tried the above verbatim as user 'mkeables' and kept getting a "need path
>statement" error.

If the 'mkeables' account also has an incorrect REDIRECtion for LWPATH.NAM,
it should be changed:

<login as 'mkeables'>
cd mcidas/data
redirect.k ADD LWPATH.NAM \".

>I tried the above as user 'mcidas' to be sure I wasn't
>messing up the command line and now I get an OS error (can't write to
>/export/home/mcidasmcidas/data ... not clear to me why the path has the
>second 'mcidas' added to it. I've shut down the system and rebooted but
>still get the same error.)

I don't understand the /export/home/mcidasmcidas/data listing either.
I might guess that McIDAS was choking on the REDIRECTion that contained
~mcidas/data.  The REDIRECTion code does not understand the '~' syntax.

>I had the same problem under user 'mcidas' as well as user 'mkeables'.

OK, both should be gone now.

>I'm afraid that I've confused the file redirects for both 'mcidas' and
>'mkeables' at this point. ARG!!!

No problem.  The solution is listed above, and things appear to be working
correctly now.  Please let me know if I am wrong in this assumption.

Another comment.  I just put out a new addendum compressed tar file (have
not yet updated web pages) that contains a new UNIDATA.MNU Fkey menu
template file that has support for NOAAPORT NIDS products.  I advise
you to grab and install this update so that you can start looking at
the _free_ NOAAPORT NIDS products!


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.