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

[GEMPAK #MNO-602195]: [Fwd: Re: gdradr problem]

Mike and Chris,

Thanks for the update. I will be working more on cleaning this
up in the 5.10.3 release. The appended product
is definitely a problem since the zlib block check will fail
upon seeing uncompressed wmo header and thentry to
do something with the rest of the product.

Sounds like you have something working now....

Thanks,

Steve Chiswell
Unidata User Support



> The newest release fixed the problem with the "Image file not a
> supported format error". I have successfully made 1km radar grids on our
> production server, but it still doesn't work on my development box (same
> release of gempak,same dataset). If I get a chance I'll investigate
> further, but I'll leave that mystery for another day.
> 
> We were still having problems with double free() errors and gdradr seg
> faulting (same with nex2img). The files that trigger this were always
> much bigger than normal and I believe I found the problem from that clue
> since they were exactly twice the size. I used dd and split the file in
> half and gdradr ran without any problem. Checking the pqact entry for
> the NIDS data, I found it was not setup to overwrite an existing file
> and for some reason I'm receiving two NIDS files for a couple of
> stations that are for the same time. The ldm is seeing them as unique
> files and filing it twice and appending the second one onto the first.
> This was only happening for two or three stations, usually FWS and LZK,
> and only once in a while making it troublesome to track down. I've
> reconfigured the ldm on that machine and hopefully the problem will go away.
> 
> -Mike
> 
> Unidata GEMPAK Support wrote:
> 
> >Chris,
> >
> >The issues with the first 2 problems should be fixed by the May 9th rebuild 
> >of the linux binary which
> >addressed a Zlib change in the data stream where the expected Z_END code was 
> >replaced with
> >a Z_OK.The im_nidz routine now checks for either.
> >
> >I can't duplicate problems with the 3rd item here under the 10.2 release 
> >which
> >is built with 1 million points for calculations. The gdradr program itself 
> >does not
> >have a size limitation since it can malloc whatever size grid is needed and 
> >write
> >it to a GEMPAK file, and I do create a 14 million point gdradr composite and 
> >convert to grib2
> >for the data stream. Dcgrib2 will also be able to decode the 14 million 
> >point composite.
> >When displaying the large grids, you will need to set IJSKIP to yes in 
> >gdplot2
> >so that it can sub-sample the grids for calculation and display. What version
> >do you have installed?
> >
> >Steve Chiswell
> >Unidata User Support
> >
> >
> >
> >
> >>Hi guys,
> >>
> >>Here's some comments from Mike Masscotte on our occasional problems with
> >>gdradr.  I hope this gives more detail than I could provide yesterday.
> >>
> >>Cheers,
> >>CH
> >>
> >>-------- Original Message --------
> >>Subject:    Re: gdradr problem
> >>Date:       Thu, 17 May 2007 13:28:48 -0400
> >>From:       Mike Masscotte <address@hidden>
> >>To:         Chris Herbster <address@hidden>
> >>References:         <address@hidden>
> >>
> >>
> >>
> >>The one that causes gdradr to hang comes back with a double free() type
> >>error. This shows up on the 2.6 kernels because they changed the
> >>behavior of what is considered an event to stop processing with. I've
> >>worked around this and got it to seg fault so I can continue on, but
> >>this isn't the best solution since we lose a tile when that happens.
> >>The error looks like the below and when it happens, gdradr hangs and
> >>never comes back.
> >>
> >>glibc detected *** *double free* or corruption (!prev)
> >>
> >>
> >>The other problem we have is with NCR where gdradr, gdplot, garp, and
> >>nmap all think the file is corrupt, but when I open it with the nexrad
> >>reader I wrote, nothing seems to be wrong with it. The errors look like
> >>this and happen a lot:
> >>[IM -3]  Image file $RAD/NIDS/EWX/NCR/NCR_20070516_2324 not a supported
> >>format
> >>
> >>The last problem we have is doing really high numbers of grid points in
> >>gdradr. I thought this number was increased in the later releases, but
> >>when I try close to a million points, gdradr core dumps. I thought I saw
> >>that the folks at Unidata were doing 1km grib2 files of nexrad, but I
> >>looked around and couldn't find it. Could you ask if they are doing this
> >>and if so how? It could save a lot of time for us to not have to start
> >>from scratch on doing this.
> >>
> >>-Mike
> >>
> >>Chris Herbster wrote:
> >>
> >>
> >>
> >>>Can you send me a description of the gdradr issues?
> >>>
> >>>CH
> >>>
> >>>
> >>>
> >>--
> >>
> >>Dr. Christopher G. Herbster
> >>Associate Professor
> >>Director of Science and Technology
> >>for the ERAU Weather Center
> >>Applied Aviation Sciences
> >>Embry-Riddle Aeronautical Univ.
> >>600 S. Clyde Morris Blvd.
> >>Daytona Beach, FL 32114-3900
> >>
> >>386.226.6444 Office
> >>386.226.6446 Weather Center
> >>http://wx.erau.edu/
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >Ticket Details
> >===================
> >Ticket ID: MNO-602195
> >Department: Support GEMPAK
> >Priority: High
> >Status: Closed
> >
> >
> >
> >
> >
> 
> 


Ticket Details
===================
Ticket ID: MNO-602195
Department: Support GEMPAK
Priority: Urgent
Status: Closed