[gradsusr] Memory Allocation Error When Using PRINTIM

Stephen McMillan smcmillan at planalytics.com
Thu Dec 2 12:22:21 EST 2010


John,
Interesting, but you left out some of the commands required to get the
desired image--commands which may or may not be crucial to my memory errors.
 In particular, the 'set clevs...' and 'set ccols...' commands before the
initial "tmp2m" display, as well as the 'set shpopts [color]' prior to the
first set of 'draw shp...' polyfill commands (since you're using the latest
version, I believe).

Thanks
Stephen

On Thu, Dec 2, 2010 at 11:55 AM, Huddleston, John <
Huddleston at cira.colostate.edu> wrote:

> Stephen
>
>
>
> After NOAA finally let me download the shapefiles, I used sdfopen, loaded
> the shapefiles, and attached is the result from printim. There was no memory
> error.
>
>
>
> NOW, having said that, the Cygwin build is like the pure Linux builds, and
> not like opengrads; so, the opengrads extensions do not work. Here is what I
> used.
>
>
>
> set mproj nps
>
> set mpdset mres
>
> set map 15
>
> set lat 10 85
>
> set lon -200 -20
>
> set mpdraw off
>
> set grads off
>
> set rgb 16 0 0 125
>
> set gxout shaded
>
> d tmp2m
>
> set line 7
>
> draw shp admin98
>
> set line 16
>
> draw recf 6.6 3.7 8.1 4.8
>
> set rgb 17 175 175 255
>
> set line 17
>
> draw shp ln_ca
>
> set line 11
>
> draw shp ln_us
>
> set line 11
>
> *shp_polyf admin98 2342
>
> draw shp ln_ak
>
> set line 1
>
> draw shp ln_ca
>
> set line 1
>
> draw shp ln_us
>
> set line 1
>
> *shp_lines admin98 2342
>
> draw shp ln_ak
>
> printim uscan.map.png x960 y720 white
>
>
>
> John Huddleston, PhD
>
> Cooperative Institute for Research in the Atmosphere
>
>
>
> *From:* gradsusr-bounces at gradsusr.org [mailto:
> gradsusr-bounces at gradsusr.org] *On Behalf Of *Stephen McMillan
> *Sent:* Thursday, December 02, 2010 9:10 AM
>
> *To:* GrADS Users Forum
> *Subject:* Re: [gradsusr] Memory Allocation Error When Using PRINTIM
>
>
>
> John,
>
>
>
> 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.
>
>
>
> Before running, I opened the latest GFS operational forecast, for example,
> http://nomads.ncep.noaa.gov:9090/dods/gfs_hd/gfs_hd20101202/gfs_hd_06z.
>  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.
>
>
>
> Stephen Mc
>
> On Thu, Dec 2, 2010 at 10:29 AM, Huddleston, John <
> Huddleston at cira.colostate.edu> wrote:
>
> Stephen
>
>
>
> I build the Cygwin
> ftp://iges.org/grads/2.0/grads-2.0.a9-i686-pc-cygwin.tar version of GrADS
> and would be willing to test your data.
>
>
>
> Can you zip it up include CTL ans GS files and put it on a FTP or HTTP site
> to download?
>
>
>
> John
>
>
>
> John Huddleston, PhD
>
> Cooperative Institute for Research in the Atmosphere
>
>
>
> *From:* gradsusr-bounces at gradsusr.org [mailto:
> gradsusr-bounces at gradsusr.org] *On Behalf Of *Stephen McMillan
> *Sent:* Thursday, December 02, 2010 8:22 AM
> *To:* GrADS Users Forum
> *Subject:* Re: [gradsusr] Memory Allocation Error When Using PRINTIM
>
>
>
> Arllindo, Jennifer,
>
> 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.
>
>
>
> 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.
>
>
>
> Thanks for your comments and suggestions!
>
> Stephen
>
> On Wed, Dec 1, 2010 at 8:07 PM, Arlindo da Silva <dasilva at alum.mit.edu>
> wrote:
>
>
>
> On Wed, Dec 1, 2010 at 7:59 PM, Jennifer Adams <jma at cola.iges.org> wrote:
>
> Hi, Stephen --
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
>    Arlindo
>
>
>
>
>
> --
> Arlindo da Silva
> dasilva at alum.mit.edu
>
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://gradsusr.org/mailman/listinfo/gradsusr
>
>
>
> ***************************************************
>
> 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.
>
> ***************************************************
>
>
>
>
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://gradsusr.org/mailman/listinfo/gradsusr
>
>
>
> ***************************************************
>
> 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.
>
> ***************************************************
>
>
>
>
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://gradsusr.org/mailman/listinfo/gradsusr
>
>

***************************************************
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.
***************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20101202/21ab07b4/attachment-0003.html 


More information about the gradsusr mailing list