John,<div><br><div>Thanks for offering to do this. Since I don't have an FTP or HTTP site for placing the files, I am attaching only a somewhat modified version of my original script. No control file used or needed. </div>
<div><br></div><div>Before running, I opened the latest GFS operational forecast, for example, <a href="http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd20101202/gfs_hd_06z">http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd20101202/gfs_hd_06z</a>. Script uses the "tmp2m" variable to set environment. Near top of script are sources for the three "boundaries" shapefiles (tar.gz format) used. I put extracted files in the SupportData folder where the "admin98" shapefile is. In script, edit the "outfile" variable as needed.</div>
<div><br></div><div>Stephen Mc<br><br><div class="gmail_quote">On Thu, Dec 2, 2010 at 10:29 AM, Huddleston, John <span dir="ltr"><<a href="mailto:Huddleston@cira.colostate.edu">Huddleston@cira.colostate.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Stephen</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">I build the Cygwin <a href="ftp://iges.org/grads/2.0/grads-2.0.a9-i686-pc-cygwin.tar" target="_blank">ftp://iges.org/grads/2.0/grads-2.0.a9-i686-pc-cygwin.tar</a> version of GrADS and would be willing to test your data.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Can you zip it up include CTL ans GS files and put it on a FTP or HTTP site to download?</span></p>
<div class="im"><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">John</span></p><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D">John Huddleston, PhD</span></p><p class="MsoNormal"><span style="font-size:10.0pt;color:#1F497D">Cooperative Institute for Research in the Atmosphere</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p></div><p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> <a href="mailto:gradsusr-bounces@gradsusr.org" target="_blank">gradsusr-bounces@gradsusr.org</a> [mailto:<a href="mailto:gradsusr-bounces@gradsusr.org" target="_blank">gradsusr-bounces@gradsusr.org</a>] <b>On Behalf Of </b>Stephen McMillan<br>
<b>Sent:</b> Thursday, December 02, 2010 8:22 AM<br><b>To:</b> GrADS Users Forum<br><b>Subject:</b> Re: [gradsusr] Memory Allocation Error When Using PRINTIM</span></p><div><div></div><div class="h5"><p class="MsoNormal">
</p><p class="MsoNormal">Arllindo, Jennifer,</p><div><p class="MsoNormal">Obviously the choice of shapefiles and output image dimensions play a critical part, not to mention the GrADS version you mentioned. Still using 2.0.a7.oga.3, by replacing one shapefile for just the Alaska portion, I was able to "printim" an image without the memory allocation error. In this case, I replaced the shapefile "ln_ak" with "admin98 2342" for AK. However, if I tried to output a higher-resolution image (say, x1440 y1080), GrADS simply crashed (I briefly saw an error about something being corrupted). I can do 960x720 or 1200x900 without a problem.</p>
</div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">I have win32 superpack 2.0.a9.oga.1 on my other machine at home, so I'll try the original script on that this evening. That could be interesting, since it's about a 10-years-old Windows XP laptop with much less RAM (500MB?). For now, I'd rather not attempt the COLA version 2.0.a9, since I ran into problems trying to install it several weeks ago. Perhaps someone else with a9 would like to give it a shot.</p>
</div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">Thanks for your comments and suggestions!</p></div><div><p class="MsoNormal" style="margin-bottom:12.0pt">Stephen</p><div><p class="MsoNormal">On Wed, Dec 1, 2010 at 8:07 PM, Arlindo da Silva <<a href="mailto:dasilva@alum.mit.edu" target="_blank">dasilva@alum.mit.edu</a>> wrote:</p>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p><div><div><p class="MsoNormal">On Wed, Dec 1, 2010 at 7:59 PM, Jennifer Adams <<a href="mailto:jma@cola.iges.org" target="_blank">jma@cola.iges.org</a>> wrote:</p>
<div><p class="MsoNormal">Hi, Stephen -- </p><div><p class="MsoNormal">The error message you're seeing occurs when the printim code tries to allocate an array that contains the vertices of a filled polygon. It may be that your shapefiles have single polygons with so many vertices (e.g. the one that fills in most of Canada) that your 3.2Gb of RAM is not enough, or maybe an integer isn't big enough to represent the number of elements in the array, so it passes malloc some junk and you get an error. To complicate things, you are also using a deprecated shapefile interface that I didn't write. </p>
</div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">See if you can reliably reproduce this error with the latest COLA version of GrADS. If so, then send me the simplest possible script and the required shapefiles, and I will try to reproduce the error on my own system that has lots and lots of available memory. </p>
</div></div><div><p class="MsoNormal"> </p></div></div><div><p class="MsoNormal">I agree, the new shapefile interface is the way to go. The latest win32 superpack 2.0.a9.oga.1 has exactly the same shapefile code that Jennifer wrote, you could try that as well.</p>
</div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal"> Arlindo</p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal"> </p></div></div><p class="MsoNormal" style="margin-bottom:12.0pt">-- <br>
Arlindo da Silva<br><a href="mailto:dasilva@alum.mit.edu" target="_blank">dasilva@alum.mit.edu</a><br><br>_______________________________________________<br>gradsusr mailing list<br><a href="mailto:gradsusr@gradsusr.org" target="_blank">gradsusr@gradsusr.org</a><br>
<a href="http://gradsusr.org/mailman/listinfo/gradsusr" target="_blank">http://gradsusr.org/mailman/listinfo/gradsusr</a></p></div><p class="MsoNormal"> </p></div></div></div><pre>***************************************************</pre>
<div class="im"><pre>The information contained in this e-mail message </pre><pre>is intended only for the use of the recipient(s) </pre><pre>named above and may contain information that is </pre><pre>privileged, confidential, and/or proprietary. </pre>
<pre>If you are not the intended recipient, you may not</pre><pre>review, copy or distribute this message. If you have</pre><pre>received this communication in error, please notify </pre><pre>the sender immediately by e-mail, and delete the original message.</pre>
<pre>***************************************************</pre><pre> </pre></div></div></div><br>_______________________________________________<br>
gradsusr mailing list<br>
<a href="mailto:gradsusr@gradsusr.org">gradsusr@gradsusr.org</a><br>
<a href="http://gradsusr.org/mailman/listinfo/gradsusr" target="_blank">http://gradsusr.org/mailman/listinfo/gradsusr</a><br>
<br></blockquote></div><br></div></div>
<pre>***************************************************
The information contained in this e-mail message
is intended only for the use of the recipient(s)
named above and may contain information that is
privileged, confidential, and/or proprietary.
If you are not the intended recipient, you may not
review, copy or distribute this message. If you have
received this communication in error, please notify
the sender immediately by e-mail, and delete the original message.
***************************************************