>From: Dave Dempsey <address@hidden> >Organization: SFSU >Subject: 20000918: McIDAS images via LDM; ldm-mcidas pnga2area decoder (con Dave, >I didn't get the ldm-mcidas binaries because I am sometimes a creature of >habit, and I habitually get the source code and compile/install locally, and >the alternative didn't even occur to me. This doesn't always make a lot of >sense, since I don't speak C or C++ and can read only parts of Makefiles >anyway. > >Having wised up, I got the latest ldm-mcidas binaries, OK, I see from the FTP logs that this was for Solaris SPARC 5.6. >installed them, and inserted the pqact.conf commands for MCIDAS images that >you outlined (adjusted for local realities). Sounds good up to this point. >Results: > > (1) I now get all the images that I request, I can plot them using WXP, and > they look fine. OK. > (2) Upon receipt of each image, LDM dumps a 400KB core file (which I don't > know how to read). A 'file core' will tell you what process the core file was created from. > (3) The image files are 50-200% larger than they used to be (a few days ago > ), which means my disks will fill up in a few days unless I rearrange my file > system. > >Any guesses about (2) and (3)? (2) is the bothersome one to me. We must determine which process is dumping core and then find out why. The 'file core' will tell what but not why. (3) numbers seem to indicate that the process you were running before was not converting images into their native AREA file format. If this is the case, you are going to have to either cut down on the number of images you are keeping; find more disk; or cut out some of the images. I must remind you that one of the objectives of the switch to PNG compression was the eventual addition of more satellite imagery to the Unidata-Wisconsin datastream. The new images will be taking the same amount of disk space as the ones you are currently receiving, so your disk dilema will grow to be even worse. This was the topic of numerous User Committee discussions... >[On (3), since I wasn't decoding the image files using lwtoa3 before, perhaps >WXP was able to read and plot the compressed image files. I do know that WXP was able to read the delta-encoded files directly. What I do not know is whether mc2area is filing the delta encoded images or if it was doing something else to them. >Now I'm storing the uncompressed image files, which are--ta da!--bigger.] Right. The AREA files can be large. The GOES-East/West VIS and IR images should be about 2.4 MB each. The water vapors are smaller since they are one half the resolution. Back to what is dumping core. The fact that the core file is only 400 KB hints to me that it shouldn't be from pnga2area (but the 'file core' will tell us). The other thing that would be very useful would be to see the log output from pnga2area since it will tell us if decoding completed and what the compression ratios are. Verbose log output from pnga2area will look something like (the output file name will be different): Sep 18 23:17:04 pnga2area[8188]: Starting Up Sep 18 23:17:04 pnga2area[8188]: output file pathname: /data/ldm/gempak/images/sat/GOES-10/8km/WV/WV_20000918_2300 Sep 18 23:17:04 pnga2area[8188]: unPNG:: 150702 613456 4.0707 Sep 18 23:17:04 pnga2area[8188]: Exiting The numbers on the 'unPNG::' line are the compressed image size; the uncompressed image size; and the compression ratio. The 'Exiting' line will tell us whether or not pnga2area finishes cleanly (i.e., does not dump core). Don asked me if you are still using SPARC clone machines; are you? This may be relevant. If so, there is a possibility that the ldm-mcidas binaries may not work like they should (others with Sun SPARC 5.6 machines are running with no problems). In this case, we should pursue building pnga2area and area2png on your machine. We can do this without building McIDAS-X since neither of these routines need the McIDAS library. Let's see if we can discern if the problem is with pnga2area first, and then investigate the local build of area2png/pnga2area afterwards. 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.