NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Is the rebuild a special process? Is there something different I need to do in order to incorporate these changes? Thank you Art and all for your help. Regards, Chris
From: Arthur A. Person [mailto:person@xxxxxxxxxxxxx] Sent: Tue 3/18/2008 10:36 AM To: Melick, Christopher J (UMC-Student) Cc: gembud@xxxxxxxxxxxxxxxx Subject: Re: [gembud] FW: Segmentation fault using gdedit Christopher, On Tue, 18 Mar 2008, Melick, Christopher J (UMC-Student) wrote:Dear gembud users, I don't want to take up all of Patrick's time. This is really for anyone that might be able to help. I still have this feeling it might be the LLMXTG parameter, currently set at 9 million in GEMPAK 5.11.1. My grid size is over 17 million grid points. Could someone take a look at my attached data file?Yep, that's big. I tried a gdcfil with those dimensions on our system (which I've already increased the size on) and it says: "WARNING: This grid is too large for GEMPAK programs." I assume that means you'll need to rebuild gempak with larger parametervalues as you suspect. When I do mine, I change the following parameterswhereever they occur in gemprm.h, MCHPRM.Linux and GEMPRM.PRM: LLMXGD=3D20000000 LLMDGG=3D80000000 -> 4 X LLMXGD LLMXTG=3D20000000 I set the above values to 20,000,000 thinking that will allow your 19,000,000 grid size... you might want to make it even a little bigger. I'm not an expert at this... so if anyone sees a problem with the above, please chime in! Hope that helps... Art
gembud archives: