>From: Michael Keables <address@hidden> >Organization: Geography Dept, University of Denver >Keywords: 200101102035.f0AKZPo29393 McIDAS-X 7.7x Mike, >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: DSSERVE LIST RTIMAGES ... 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.....> Done 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> PERM SIZE LAST CHANGED FILENAME DIRECTORY ---- --------- ------------ -------- --------- -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> PERM SIZE LAST CHANGED FILENAME DIRECTORY ---- --------- ------------ -------- --------- -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 should. 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 more LWPATH.NAM 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 LWPATH.NAM . 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 below). Also, there should _never_ be a copy of LWPATH.NAM in ~mcidas/data, so I deleted it: cd ~mcidas/data rm LWPATH.NAM 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 binary get AREA9000 quit 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 received. >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! Tom
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.