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