This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
> Good morning, > > >> Thanks, will check for that. I need to build from source, since my > >> nex2img rasters are very large KXKY = 6000;2600 > > > > The nex2img program is independent of all precompiled grid sizes, and it > > will malloc the necessary grid (which was your problem in that it was > > malloc'ing almost 3 million points (MAXNEX 2984220 as below); however > > that really old first cut version I developed for you has a 1.4 million > > precompiled array size (which is probably why it could keep running even > > though the image was non-existent. > > I've always needed to modify GINISZ in > > /unidata/programs/nex2img/nex2img.cmn Ah....bummer. I pulled out the compile time limit in gdradr and other programs to malloc the space needed- and thought I had checked in the code for nex2img, but didn't. I'll make that an item in 5.10.3 so you don't have to do that job at least. Steve Chiswell Unidata User Support > > Otherwise I get an image size too large error or something like that... > > >> Geez, I didn't mean to create work for ya over the weekend :( I > >> appreciate the quick fix and help! I'm prolly the only one generating NET > >> composites :) > > > > Except the one I have in the FNEXRAD feed as a grib product ;-)...... > > Hehe, then there are only 2 of us :) > > > Let me know how things go,...... > > Works as expected. Thanks for the quick help! > > daryl > > Ticket Details =================== Ticket ID: MCN-335629 Department: Support GEMPAK Priority: High Status: Closed