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

20000918: McIDAS images via LDM; ldm-mcidas pnga2area decoder (cont.)

>From: Dave Dempsey <address@hidden>
>Organization: SFSU
>Subject: 20000918: McIDAS images via LDM; ldm-mcidas pnga2area decoder (con


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

>   (1) I now get all the images that I request, I can plot them using WXP, and
>  they look fine.


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


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.