>From: Pepo Juega <address@hidden> >Organization: Instituto Nacional de Meteorologia >Keywords: 200008311046.e7VAk3N24792 ldm-mcidas pnga2area Pepo, re: Aug 31 09:21:00 area2png[22532]: doPNG:: 105419756 4696473 0.0446 This is pretty good compression! >No wonder, I think the file is empty. (See below) That would account for the incredible compression! re: You could try changing 'alarm_timeout' to something like 120, 180, >I don't think that will be necessary, but nice to know. OK. re: Another possibility is that pnga2area is not getting an EOF indication from the LDM's pqact routine. >I don't quite understand that. But let me explain first. >While I was waiting for your answer, >I found out that the Wisconsin GVAR SDI ingestor issues a mail >message to the ldm account as soon as it detects a new image is >arriving (At the very first line scanned!) in contrast with other >SDI ingestors like meteosat for example, which e-mail when the >last image line is already down. This means that my IMGCOPY command >for GVAR is issued when only a few lines have been sent down. The AREA >file is fully allocated, but mostly empty! I was only passing over a >few lines all the time. OK, this is makes some sense now. The AREA directory would be created and would most likely indicate a certain size even though there are only a few lines. My area2png compression routine uses the shape of the image (lines and elements/line) to prep the PNG compression routines. I do not do extensive checks to make sure that the AREA file being compressed is complete. I will have to review this design decision in the light of your problem. >So, I changed the action on the feeder side to just cron the appropiate >IMGCOPY command 25 minutes after I get mail, and it then passes >a complete image to area2png. (25 minutes is about what a full disc >image takes to get downloaded) PROBLEM SOLVED You are saying that the IMGCOPY will transfer empty lines from the ingestor? If this is true, the resulting AREA file should be viable (although empty) and area2png should work correctly. pnga2area on the receiving side should also work correctly even though the image will not be of much good. >Now on the requester side I get: >pnga2area[27222]: unPNG:: 42758475 113927188 2.6644 This looks more like it. The question remains whether or not the process completes correctly. I am assuming that it does since you did not include lines indicating a timeout condition. re: not having a -close on the PIPE action >That was not it for sure. I do both, close and flush. OK. Please let me know if there is any residual problem with pnga2area. >Txs, You are welcome. 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.