matplotlib-devel Mailing List for matplotlib (Page 2)

>>>>> "Glen" == Glen W Mabey <Gle...@sw...> writes:
 Glen> Hello, I've just switched to Python 2.5 and at the same time
 Glen> upgraded to numpy 1.0.1 with today's svn matplotlib, using
 Glen> the QtAgg backend (PyQt3 3.17). This is on an AMD64
 Glen> (Opteron) machine.
 Glen> I get a segfault after these operations:
 Glen> In [1]:import numpy as N In [2]:specgram( N.random.randn(
 Glen> 256*500 ) ) Segmentation fault (core dumped)
1) Are you sure that matplotlib's numerix setting is numpy?
2) Did you do a *clean* build of mpl: ie 
 > sudo rm -rf build
 > sudo python setup.py install
The latter is very important when upgrading Numeric/numpy/numarray
It could be an AMD64 bit problem, though...
JDH

Hello,
I've just switched to Python 2.5 and at the same time upgraded to numpy
1.0.1 with today's svn matplotlib, using the QtAgg backend (PyQt3 3.17).
This is on an AMD64 (Opteron) machine.
I get a segfault after these operations:
In [1]:import numpy as N
In [2]:specgram( N.random.randn( 256*500 ) )
Segmentation fault (core dumped)
I don't know if this will help, but here is the backtrace:
(gdb) bt
#0 0x00002aaab37e2ac8 in Image::flipud_out (this=0xf9bf10, args=@0x7fffffc5d200) at _image.cpp:110
#1 0x00002aaab3829df4 in RendererAgg::draw_image (this=0xf04980, args=@0x7fffffc5d350) at _ns_backend_agg.cpp:1994
#2 0x00002aaab3840367 in Py::PythonExtension<RendererAgg>::method_varargs_call_handler (_self_and_name_tuple=<value optimized out>, _args=0x2aaab397bdb8)
 at Extensions.hxx:683
#3 0x00002aaaaac826dc in PyEval_EvalFrameEx (f=0xf76550, throwflag=<value optimized out>) at ceval.c:3566
#4 0x00002aaaaac82e00 in PyEval_EvalCodeEx (co=0x2aaab34115d0, globals=<value optimized out>, locals=<value optimized out>, args=0xf764c8, argcount=2, kws=0xf764d8, 
 kwcount=0, defs=0x0, defcount=0, closure=0x0) at ceval.c:2833
#5 0x00002aaaaac81cdc in PyEval_EvalFrameEx (f=0xf762c0, throwflag=<value optimized out>) at ceval.c:3662
#6 0x00002aaaaac82e00 in PyEval_EvalCodeEx (co=0x2aaab2a35648, globals=<value optimized out>, locals=<value optimized out>, args=0x2, argcount=2, kws=0xf08a88, 
 kwcount=0, defs=0x2aaab3679068, defcount=2, closure=0x0) at ceval.c:2833
#7 0x00002aaaaac81cdc in PyEval_EvalFrameEx (f=0xf08880, throwflag=<value optimized out>) at ceval.c:3662
#8 0x00002aaaaac81d79 in PyEval_EvalFrameEx (f=0xf069f0, throwflag=<value optimized out>) at ceval.c:3652
#9 0x00002aaaaac82e00 in PyEval_EvalCodeEx (co=0x2aaab37a5a08, globals=<value optimized out>, locals=<value optimized out>, args=0x2aaab39641e8, argcount=1, kws=0x0, 
 kwcount=0, defs=0x0, defcount=0, closure=0x0) at ceval.c:2833
#10 0x00002aaaaac21779 in function_call (func=0x2aaab3708938, arg=0x2aaab39641d0, kw=0x0) at funcobject.c:517
#11 0x00002aaaaabff8c1 in PyObject_Call (func=<value optimized out>, arg=<value optimized out>, kw=<value optimized out>) at abstract.c:1860
#12 0x00002aaaaac08144 in instancemethod_call (func=<value optimized out>, arg=0x2aaab39641d0, kw=0x0) at classobject.c:2493
#13 0x00002aaaaabff8c1 in PyObject_Call (func=<value optimized out>, arg=<value optimized out>, kw=<value optimized out>) at abstract.c:1860
#14 0x00002aaaaac80f1e in PyEval_EvalFrameEx (f=0xf06620, throwflag=<value optimized out>) at ceval.c:3777
#15 0x00002aaaaac82e00 in PyEval_EvalCodeEx (co=0x2aaaad6e3c60, globals=<value optimized out>, locals=<value optimized out>, args=0x2aaab3715c38, argcount=2, kws=0x0, 
 kwcount=0, defs=0x0, defcount=0, closure=0x0) at ceval.c:2833
#16 0x00002aaaaac21779 in function_call (func=0x2aaab3728230, arg=0x2aaab3715c20, kw=0x0) at funcobject.c:517
#17 0x00002aaaaabff8c1 in PyObject_Call (func=<value optimized out>, arg=<value optimized out>, kw=<value optimized out>) at abstract.c:1860
#18 0x00002aaaaac08144 in instancemethod_call (func=<value optimized out>, arg=0x2aaab3715c20, kw=0x0) at classobject.c:2493
#19 0x00002aaaaabff8c1 in PyObject_Call (func=<value optimized out>, arg=<value optimized out>, kw=<value optimized out>) at abstract.c:1860
I don't get the same error on a P4 machine with the same setup except
using Python 2.4.
For some reason I thought that matplotlib supported 2.5, but then I
started looking and couldn't see that documented anywhere. Does it?
Thanks,
Glen Mabey

John, David,
The problem is indeed the patch boundaries; here is the workaround:
In [2]:bb = bar(arange(500), rand(500))
In [3]:for b in bb: b.set_linewidth(0)
 ...:
In [4]:draw()
We should probably do something like setting linewidth to zero 
automatically if edgecolor is None, so that the existing edgecolor kwarg 
can be used to achieve this result. And/or add a linewidth kwarg.
Eric
John Hunter wrote:
>>>>>> "David" == David Huard <dav...@gm...> writes:
> 
> David> Hi, When plotting a large amount of bars, like
> 
> >>>> bar(arange(500), rand(500))
> 
> David> the bars seem to overlap and it produces a weird effect.
> 
> David> My feeling is that the culprit is the contour line around
> David> each rectangle, who probably don't scale properly in this
> David> limit. In fact, the problem is maybe not so much that the
> David> contour width doesn't scale, but that the contour is drawn
> David> outside the rectangle.
> 
> David> I'd be glad to submit a patch, but I'd need some directions
> David> (where in the code is the contour drawn ?)
> 
> This is likely due to either antialising of the bar patch.Rectangle
> objects (does it help to turn the antialiased property off?) or
> subpixel rendering (does it help to comment out these lines in
> src/_backend_agg.cpp in the draw_polygon function?)
> 
> //snapto pixel centers
> x = (int)x + 0.5;
> y = (int)y + 0.5;
> 
> JDH
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

>>>>> "David" == David Huard <dav...@gm...> writes:
 David> Hi, When plotting a large amount of bars, like
 >>>> bar(arange(500), rand(500))
 David> the bars seem to overlap and it produces a weird effect.
 David> My feeling is that the culprit is the contour line around
 David> each rectangle, who probably don't scale properly in this
 David> limit. In fact, the problem is maybe not so much that the
 David> contour width doesn't scale, but that the contour is drawn
 David> outside the rectangle.
 David> I'd be glad to submit a patch, but I'd need some directions
 David> (where in the code is the contour drawn ?)
This is likely due to either antialising of the bar patch.Rectangle
objects (does it help to turn the antialiased property off?) or
subpixel rendering (does it help to comment out these lines in
src/_backend_agg.cpp in the draw_polygon function?)
 //snapto pixel centers
 x = (int)x + 0.5;
 y = (int)y + 0.5;
JDH
 

Hi,
When plotting a large amount of bars, like
>>> bar(arange(500), rand(500))
the bars seem to overlap and it produces a weird effect.
My feeling is that the culprit is the contour line around each rectangle,
who probably don't scale properly in this limit. In fact, the problem is
maybe not so much that the contour width doesn't scale, but that the contour
is drawn outside the rectangle.
I'd be glad to submit a patch, but I'd need some directions (where in the
code is the contour drawn ?)
Thanks for matplotlib !
David

Eric Firing schrieb:
> Norbert,
>
> Your change in commenting out almost everything in matplotlibrc was a 
> good one, but I think it had an unintended consequence: it changed the 
> way everything looks because the defaults in __init__.py were not the 
> same as the ones in matplotlibrc. To my eye and on my machine the 
> matplotlibrc defaults are better, and my guess is that this is because 
> over a period of time people tuned the matplotlibrc values but left the 
> __init__.py values alone--after all, they were normally not used. In 
> any case, I went ahead and changed __init__.py to match matplotlibrc.
> 
Thanks! I only did a spot check on some of the values and did not find
any differences. I agree that the values in the old matplotlibrc are
likely to be the more reasonable defaults. Furthermore, anybody who
didn't think about the issue would probably have used these values
anyway, so your changes should give the best backwards compatibility.

Hello,
I posted this description of a different type of spectrogram to the 
matplotlib-users list a while back, and today I am ready to start work 
on actually implementing it. 
There didn't seem to be a tremendous amount of interest in the idea
(only one reply), yet it is important to my work right now. Chris's
idea of storing the data separately and then generating the appropriate
image is what I had in mind. The only additional concept I plan to
throw in is to use a numpy.memmap instance as the container of the data.
So, I wonder if y'all have any suggestions for me as I start this
project.
The basic functionality is this:
* Display of an image (with the ability to specify the extents of the
 axes) along with other vector elements (most notably, rectangles).
* When the axes is re-sized, or when the toolbar is used to pan, zoom, 
 or rectangle-select a different view, a new image is created and 
 displayed with extents that are appropriate to the new region of 
 the axes that are displayed.
Any tips would be appreciated.
Best Regards,
Glen Mabey
On Tue, Oct 24, 2006 at 09:41:38AM -0700, Christopher Barker wrote:
> Glen W. Mabey wrote:
> >I have come
> >to conclude that the traditional method for generating spectrograms is
> >inherently flawed. That is, the MATLAB approach of generating a picture
> >based on the psd's and then display it using imshow is a hack.
> 
> I'm not very familiar with spectrograms, but I suspect you are correct. 
> Top get the best results, your computations should be tied to the actual 
> resolution that you are displaying.
> 
> However, what this says to me is that using MPL directly may not be the 
> best way to go. It is designed for scalable, vector drawing -- 
> illustrated by your difficulty in finding the exact pixel size of the 
> axes. You might want to consider creating and manipulating the image you 
> want directly. This might best be accomplished by storing image data in 
> a numpy array, manipulating it as you need, then converting that array 
> to a PIL image, or wxImage (or directly to an Agg image in MPL?).
On Tue, Oct 24, 2006 at 10:03:02AM -0500, Glen W. Mabey wrote:
> On Tue, Oct 24, 2006 at 08:49:19AM -0500, John Hunter wrote:
> > >>>>> "Glen" == Glen W Mabey <Gle...@sw...> writes:
> > 
> > Glen> Hello, I have been unable to discover in the docs a method
> > Glen> for discovering the exact size in pixels of an axes.
> > 
> > Glen> The only way I have thought of is to get the size of the
> > Glen> canvas via FigureCanvas.get_width_height() and then multiply
> > Glen> by the results of axes.get_position(), but really I want to
> > Glen> have the exact size in pixels.
> > 
> > In [1]: ax = subplot(111)
> > 
> > In [2]: left, bottom, width, height = ax.bbox.get_bounds()
> > 
> > In [3]: print left, bottom, width, height
> > 
> > 80.0 48.0 496.0 384.0
> > 
> > However, this question looks like one that would be better answered by
> > describing what you are trying to do. There may be a more elegant
> > solution using some of matplotlib's built-in coordinate systems which
> > would prevent you from having to do raw pixel calculations, which is
> > not usually what you want. So you may want to describe your actual
> > problem rather than your solution <wink>
> 
> Happy to do so, and I'm glad you asked.
> 
> I have recently been working on a project where I need to show a
> spectrogram of some large data sets (200 million complex samples).
> Directly using the specgram function is not a good idea, and I have come
> to conclude that the traditional method for generating spectrograms is
> inherently flawed. That is, the MATLAB approach of generating a picture
> based on the psd's and then display it using imshow is a hack.
> 
> I arrived at this conclusion through my work-around to generating
> spectrograms for these large files. What I did was to choose a number
> of "data slice" to use, extract those at regular intervals throughout
> the file, and then set overlap=0.
> 
> For example, if I wanted to use a 1024-point FFT, and if my axes is
> about 500 pixels wide, then I would seek() through the file reading 1024
> contiguous samples and then skipping 1./500-th of the total samples, and
> reading in another slice. I would end up with 500*1024 points, and pass
> this data to specgram() with overlap=0.
> 
> Now, of course, there is a lot of information that was discarded, but it
> made the implementation tractable.
> 
> I would propose that the loss associated with this method was comparable
> to what is lost when the entire data set is used and then an image
> resize algorithm (hardly appropriate for this type of thing, IMHO)
> averages out a tremendous amount of the computations that were
> performed.
> 
> As I started to think about it, I concluded that the other extreme
> applies. For short data sets, it is much more appropriate to have the
> overlap increase automatically than to use an image interpolation
> function. 
> 
> The case of operating on large data sets then corresponds to a negative
> overlap.
> 
> I recall one technical review I was in where the presenter was
> displaying a spectrogram in MATLAB. He pointed out a visible feature
> and then zoomed in on it. It was a large data set, and when it finished
> drawing, the feature was no longer visible -- very strange, and
> frustrating to the presenter! I then began to wonder about the
> appropriateness of treating a spectrogram like a picture.
> 
> Not to imply that there wouldn't be anomalies like this with this
> "auto-overlap" approach, but certainly it seems (to me) like a more 
> rational approach to this signal processing operation.
> 
> So, I'm hoping to find time on my current project to implement this type
> of functionality. In my mind the FFT size would still be selected as a
> parameter, so that power-of-2 implementations are used.. Granted, there 
> would be averaging going on along the vertical axis, I just propose that 
> better 1 than 2: the number of psd's performed would correspond exactly 
> to the horizontal dimension of the drawing area, so no resampling would 
> be required along that axis.
> 
> When the axes is resized, psd's would have to be recomputed, but what is
> displayed on the screen would more closely related to the result of the
> transforms performed.
> 
> Zooming would also necessitate recomputation of the psd's. My idea for
> smooth zooming (dragging with right mouse button in pylab) was to keep
> the existing functionality, until the mouse is released, at which time
> the psd's would be recomputed, but only for the segment of the data that
> corresponds to the visible portion of the horizontal axis. Same thing
> for panning around this zoomed image: don't recalculate anything until
> the user releases the mouse button. 
> 
> This would obviously be a more complicated implementation, and I'm not
> suggesting that the current specgram implementation is useless. This
> alternate approach has served me well so far, and being able to extract
> the size of the axes will make things more efficient.
> 
> Thanks for listening and for the tip.
> 
> Best Regards,
> Glen Mabey
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi,
I am using matplotlib with python to generate a bunch of charts. I use
IDLE, have numpy version 1.0, and pylab version 2.5 with TkAgg if that is
relavant. My
code works fine for a single iteration, which creates and saves 4
different charts. The trouble is that when I try to run it for the
entire set (about 200 items) it can run for 12 items at a time, generating
48 charts. On the
13th, I get an error from matplotlib that says it can't access data.
However, if I start the program at the point it just failed, it works
fine and will create the charts for the next 12 before failing. I
assume that I am not closing the files properly somehow or otherwise
misallocating memory. I tried just reimporting pylab each iteration,
but that didn't help. This is the function that creates a chart:
#create and save the figure
def CreateFigure(state, facility, unit, SO2, increment, year, P99):
 size = len(SO2)
 #Create Plot
 figure(1, figsize=(10,8))
 bar(range(1, size+2), SO2, width=0.1, color='k')
 grid(True)
 xlim(0,size)
 ylim(0, 1.1*SO2[-1])
 ylabel('SO2 [lb/hr]')
 heading = ConstructFigName(state, facility, unit, increment, year)
 title(heading)
 #set handles
 xticklines = getp(gca(), 'xticklines')
 xgridlines = getp(gca(), 'xgridlines')
 xticklabels = getp(gca(), 'xticklabels')
 yticklines = getp(gca(), 'yticklines')
 #set properties
 setp(xticklines, visible=False)
 setp(xgridlines, visible=False)
 setp(xticklabels, visible=False)
 setp(yticklines, visible=False)
 axhspan(P99, P99, lw=3, ec='r', fc='r')
 ax = gca()
 P99 = '%0.1f' % P99
 text(0.01, 0.95, '99th Percentile: '+P99+' lb/hr',
transform=ax.transAxes)
 figpath = ConstructFigPath(state, facility, unit, increment, year)
 savefig(figpath)
 close()
Can you see the problem? If there is nothing obviously wrong... I tried to
run the memory leak algorithm from the website, but the line:
a2 = os.popen('ps -p %d -o rss,sz' % pid).readlines()
generates an empty list rather than information about about memory, and I am
not clear on how to modify it to do something useful.
thanks,
-Lisa

Glad I'm not the only one...
well, I did some more investigation. I get that slowdown too, and it 
seems potentially related. the slowdown is happening in the call
 im.resize(int(widthDisplay+0.5), int(heightDisplay+0.5),
 norm=self._filternorm, radius=self._filterrad)
near line 162 in image.py
as you zoom, the time it takes to execute that line grows 
exponentially. this is where it heads into compiled dll land as resize 
is impemented in _image.cpp
see here:
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/src/_image.cpp?view=markup
I don't have a build setup for matplotlib, so I am holding off on doing 
some printf investigations on _image.cpp, but perhaps this can help 
track it down? Since it is independent of interpolation, shouldn't it 
be something going on between lines 328 and 445 of _image.cpp?
t
Eric Firing wrote:
> I have verified this behavior briefly on a Linux machine. In 
> addition, the redraw after zoom gets extremely slow. I have never 
> worked with the image internals and I don't have any idea where the 
> problem is coming from.
>
> Eric
>
> Tim Hirzel wrote:
>> To the fantastic matplotlib developers,
>> I am having a strange behavior when using zooming. I have tried it 
>> with WX, Wxagg, and TKagg, and with Numeric and numpy. It occurs in 
>> multiple interpolation types as well. The best way to see this 
>> behavior is to use the image_interp.py example. If you zoom in 
>> enough, the image starts to fade to white, and then turn completely 
>> white. If you zoom in to about where the zoom the axes area spans 
>> 0.1 units, it should still look fine, but then a span of 0.01 unit 
>> will be all white. If you zoom in slowly to where the color is 
>> starting to wash out to white, then resize the window, you will see 
>> more strange whitening behavior (the color fluctuates between white 
>> and the correct color as you change the window size). This is on a 
>> windows machine with Python 2.4.
>> Another clue. if I save the white appearing axes to a png, it looks 
>> fine.
>> the way it fades out almost seems like something going wrong with an 
>> alpha value somewhere...
>> any thoughts?
>>
>> thanks,
>> Tim
>
>

I have verified this behavior briefly on a Linux machine. In addition, 
the redraw after zoom gets extremely slow. I have never worked with the 
image internals and I don't have any idea where the problem is coming from.
Eric
Tim Hirzel wrote:
> To the fantastic matplotlib developers,
> I am having a strange behavior when using zooming. I have tried it with 
> WX, Wxagg, and TKagg, and with Numeric and numpy. It occurs in multiple 
> interpolation types as well. The best way to see this behavior is to 
> use the image_interp.py example. If you zoom in enough, the image 
> starts to fade to white, and then turn completely white. If you zoom in 
> to about where the zoom the axes area spans 0.1 units, it should still 
> look fine, but then a span of 0.01 unit will be all white. If you zoom 
> in slowly to where the color is starting to wash out to white, then 
> resize the window, you will see more strange whitening behavior (the 
> color fluctuates between white and the correct color as you change the 
> window size). This is on a windows machine with Python 2.4.
> Another clue. if I save the white appearing axes to a png, it looks fine.
> the way it fades out almost seems like something going wrong with an 
> alpha value somewhere...
> any thoughts?
> 
> thanks,
> Tim

To the fantastic matplotlib developers,
I am having a strange behavior when using zooming. I have tried it with 
WX, Wxagg, and TKagg, and with Numeric and numpy. It occurs in multiple 
interpolation types as well. The best way to see this behavior is to 
use the image_interp.py example. If you zoom in enough, the image 
starts to fade to white, and then turn completely white. If you zoom in 
to about where the zoom the axes area spans 0.1 units, it should still 
look fine, but then a span of 0.01 unit will be all white. If you zoom 
in slowly to where the color is starting to wash out to white, then 
resize the window, you will see more strange whitening behavior (the 
color fluctuates between white and the correct color as you change the 
window size). This is on a windows machine with Python 2.4.
Another clue. if I save the white appearing axes to a png, it looks fine.
the way it fades out almost seems like something going wrong with an 
alpha value somewhere...
any thoughts?
thanks,
Tim

Hi Eric,
> I have modified your LogNorm, added it to colors.py, made some changes
> to colorbar.py, and added a stripped-down version of your pcolor_log.py
> to the examples directory. If you update your mpl from svn, then I
> think you will find that pcolor_log now works the way you expected it to
> originally, with the colorbar automatically supporting the log color scale.
I just upgraded and it works great!
Thanks very much.
JIM
---

Is there any way to get the length (in pixels) of a particular axis?
 
More specifically I am trying to make a clean-looking Formatter object that spaces out the labels so that the text does not write on
top of each other, but in order to do so, I need to know the length of the Axis that the Formatter object is being applied to. Is
there any easy (or proper) way to do this?
 
While I am on the topic, are there any ways to get the pixel size of a string if it were to be rendered as text? I know that Qt can
do this, but I wasn't sure if the matplotlib backend system has this implemented to make it generic for all backends. Right now I
just have a hard-coded parameter for this, but it would be nice to make more automatic.
 
Thanks,
--James Evans

John,
Thanks. I have deleted it.
Eric
John Hunter wrote:
>>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
> 
> Eric> Despite the comment, I don't understand the purpose of the
> Eric> last line in the following excerpt from the Axes.plot()
> Eric> method:
> 
> Eric> lines = [] for line in self._get_lines(*args,
> Eric> **kwargs): self.add_line(line) lines.append(line) lines =
> Eric> [line for line in lines] # consume the generator
> 
> That looks like detritus. If I recall correctly, it used to be
> something like
> 
> lines = self._get_lines(*args, **kwargs):
> lines = [line for line in lines] # consume the generator
> 
> _get_lines is a generator and there was some part of the code that was
> having trouble with this so I just converted it to a list and that
> fixed the bug. Later it appears the code was rewritten to what you
> posted and lines is already a list, so yes, the list comprehension is
> redundant and should be removed.
> 
> JDH

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> Despite the comment, I don't understand the purpose of the
 Eric> last line in the following excerpt from the Axes.plot()
 Eric> method:
 Eric> lines = [] for line in self._get_lines(*args,
 Eric> **kwargs): self.add_line(line) lines.append(line) lines =
 Eric> [line for line in lines] # consume the generator
That looks like detritus. If I recall correctly, it used to be
something like
 lines = self._get_lines(*args, **kwargs):
 lines = [line for line in lines] # consume the generator
_get_lines is a generator and there was some part of the code that was
having trouble with this so I just converted it to a list and that
fixed the bug. Later it appears the code was rewritten to what you
posted and lines is already a list, so yes, the list comprehension is
redundant and should be removed.
JDH

Hello James
Essentially the qt event-loop will only be started by matplotlib if
> matplotlib was the one to create the qApp, if not then it is up
> to the creator of the Qt qApp to start the event-loop when they are ready
> for it. This allows for applications with embedded Qt
> event loops to work with matplotlib. I have run some test cases in a few
> different python environments (including the vanilla
> python) and all seem to be working. I have not, however tested this in
> the iPython environment (although I don't think that iPython
> uses Qt, does it?).
Yes, it does. There is a command-line switch to make iPython run the qt
mainloop in a separate thread.
Use "ipython -qthread".
Also, there is "ipython -pylab" that run default GUI toolkit (as defined in
matplotlibrc) mainloop in a thread.
-- 
Regards
Leandro Lameiro
Blog: http://lameiro.wordpress.com

Despite the comment, I don't understand the purpose of the last line in 
the following excerpt from the Axes.plot() method:
 lines = []
 for line in self._get_lines(*args, **kwargs):
 self.add_line(line)
 lines.append(line)
 lines = [line for line in lines] # consume the generator
Would someone enlighten me, please? Or is that line in fact as useless 
as it appears to me?
Thanks.
Eric

Jim,
I have modified your LogNorm, added it to colors.py, made some changes 
to colorbar.py, and added a stripped-down version of your pcolor_log.py 
to the examples directory. If you update your mpl from svn, then I 
think you will find that pcolor_log now works the way you expected it to 
originally, with the colorbar automatically supporting the log color scale.
Eric
JIM MacDonald wrote:
> Hi Eric,
> 
> Thanks for your reply. It made me realise a few things....
>> > But when I add a colorbar it goes wrong. The colorbar is labelled with
>> > the log of the values, rather
>> > than values, and the colour only fills the top third of the colorbar.
>>
>> In the absence of additional kwargs, colorbar uses norm.vmin and
>> norm.vmax to determine the limits of the colorbar, and it uses a default
>> formatter. It has no way of knowing that you have taken the log of your
>> original values.
> Yes of course there is in inconsistency in my LogNorm class. norm.vmax
> will return the log of the maximum, when logically it should return
> the max of the actual maximum. I've modified my example to take this
> into account. see attached (and updated version online).
> 
> 
>> Colorbar will need some kwargs, at the very least. The "format" kwarg,
>> for example, can be used to pass in a Formatter instance so that a label
>> is 10^-3 instead of -3.
> Ah I'd not discovered Formatters yet. But this does give a good solution.
> If I instead do a pcolor of the log of my data, and then use a
> FormatStrFormatter as you surgested:
> 
> pcolor(X,Y,log10(Z1),shading='flat')
> colorbar(format=FormatStrFormatter('10ドル^{%d}$'))
> 
> I get exactly what I want :-) Its not the most intuitive way to do it,
> but it works and I can't see any major drawbacks.
> 
>> I am not sure why only the top is colored in your example--it might be a
>> bug or it might be an indication that additional kwargs are needed. I
>> am reasonably sure there is a simple solution, but I can't look at it
>> any more right now--maybe I can get back to it this evening.
> 
> I'm pretty sure the reason only the top was coloured is to do in the
> inconsistency I described above. Once I fixed that the colorbar is
> fine except that it is not on a log scale. But of course it can't know
> that it is suppost to be on a log scale! I tried to do:
> 
> gca().axes[1].set_ylim((1e-5,1))
> gca().axes[1].set_yscale('log')
> 
> but that doesn't work. I get a load of errors :
> 
> exceptions.ValueError Traceback (most
> recent call last)
> 
> /usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py in
> expose_event(self, widget, event)
> 282 x, y, w, h = self.allocation
> 283 self._pixmap_prepare (w, h)
> --> 284 self._render_figure(self._pixmap, w, h)
> 285 self._need_redraw = False
> 286
> 
> /usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py
> in _render_figure(self, pixmap, width, height)
> 71 def _render_figure(self, pixmap, width, height):
> 72 if DEBUG: print 'FigureCanvasGTKAgg.render_figure'
> ---> 73 FigureCanvasAgg.draw(self)
> 74 if DEBUG: print 'FigureCanvasGTKAgg.render_figure
> pixmap', pixmap
> 75 #agg_to_gtk_drawable(pixmap, self.renderer._renderer, None)
> 
> /usr/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py in
> draw(self)
> 390
> 391 renderer = self.get_renderer()
> --> 392 self.figure.draw(renderer)
> 393
> 394 def get_renderer(self):
> 
> /usr/lib/python2.4/site-packages/matplotlib/figure.py in draw(self, 
> renderer)
> 542
> 543 # render the axes
> --> 544 for a in self.axes: a.draw(renderer)
> 545
> 546 # render the figure text
> 
> /usr/lib/python2.4/site-packages/matplotlib/axes.py in draw(self,
> renderer, inframe)
> 1061
> 1062 for zorder, i, a in dsu:
> -> 1063 a.draw(renderer)
> 1064
> 1065 self.transData.thaw() # release the lazy objects
> 
> /usr/lib/python2.4/site-packages/matplotlib/patches.py in draw(self, 
> renderer)
> 163
> 164 verts = self.get_verts()
> --> 165 tverts = self._transform.seq_xy_tups(verts)
> 166
> 167 renderer.draw_polygon(gc, rgbFace, tverts)
> 
> ValueError: Domain error on nonlinear Transformation::seq_xy_tups
> operator()(thisx, thisy)
> 
> As for how to solve the problem properly. Matlab allows one to set to
> caxis scale to log. Maybe colorbar could detect that the norm instance
> was an instance of LogNorm and scale the yaxis logarithmicly. Or would
> it be better to put a scale={'log','linear'} kwarg into colorbar()?
> 
> Thanks again for your help.
> 
> cheers
> 
> JIM
> ---

Norbert,
Your change in commenting out almost everything in matplotlibrc was a 
good one, but I think it had an unintended consequence: it changed the 
way everything looks because the defaults in __init__.py were not the 
same as the ones in matplotlibrc. To my eye and on my machine the 
matplotlibrc defaults are better, and my guess is that this is because 
over a period of time people tuned the matplotlibrc values but left the 
__init__.py values alone--after all, they were normally not used. In 
any case, I went ahead and changed __init__.py to match matplotlibrc.
Eric

Aalok kapoor wrote:
> After using numpy-1.0 the results are more bad. After 15 maps it is 
> reaching to 71% memory usage. I am working on freeBSD box.
>
> python memory_leak_map.py
> rss vsz %mem
> 0 47940 50636 9.8
> 1 75080 77700 15.4
> 2 94636 97380 19.4
> 3 114156 116776 23.4
> 4 133672 136416 27.4
> 5 153204 155832 31.4
> 6 172708 175216 35.5
> 7 192224 194872 39.5
> 8 211720 214248 43.5
> 9 231244 233916 47.5
> 10 250732 253280 51.5
> 11 270252 272688 55.5
> 12 289756 292332 59.5
> 13 309272 311728 63.5
> 14 328764 331108 67.5
> 15 347804 350760 71.4
>
>
>
> thanks,
> -Aalok
> */Aalok kapoor <aal...@ya...>/* wrote:
>
> Hi,
>
> Thanks for this direction. I am using Numpy-1.1. Do I not supposed
> to use this version? I will try to use older version and see what
> happens. I hope this will solve the problem.
>
> thanks
> -Aalok
>
> */Jeff Whitaker <js...@fa...>/* wrote:
>
> Aalok kapoor wrote:
> > Thanks for reply,
> >
> > This was just an example for mem leak in my application.
> Actually i
> > want maps with different data to be loaded each time and the
> map
> > objects taken once changees after ploting so i have to take
> different
> > object each time. After around 20 maps generation it gives
> memory
> > error to me.
> >
> > thanks,
> > -Aalok
> >
> > */Jeff Whitaker /* wrote:
> >
> > Aalok kapoor wrote:
> > > Hi all,
> > >
> > > I am using matplotlib-0.87.7, Basemap-0.9.3, Numpy-1.1 and agg
> > backend.
> > > I am facing memory leak problems after running following
> script -
> > >
> > >
> > > import os, sys, time
> > > import cStringIO
> > > import Image
> > > import matplotlib
> > > matplotlib.use('Agg')
> > >
> > > import matplotlib.pylab as p
> > > import matplotlib.numerix as nx
> > > from matplotlib.toolkits.basemap import Basemap
> > >
> > > def get_image_bytes(width_fig, height_fig, str_img):
> > > """Returns the bytes representing the image generated
> > >
> > > The createImage method should be called before calling
> this method.
> > >
> > > :Returns:
> > > Byte data.
> > > """
> > > # Get the actual image data
> > > f = cStringIO.StringIO()
> > > dims = (width_fig, height_fig)
> > > im = Image.fromstring("RGB", dims, str_img)
> > > im.save(f, "JPEG")
> > > return f.getvalue()
> > >
> > > def report_memory(i):
> > > pid = os.getpid()
> > > a2 = os.popen('ps -p %d -o rss,vsz,%%mem' % pid).readlines()
> > > print i, ' ', a2[1],
> > > return int(a2[1].split()[1])
> > >
> > >
> > >
> > > # take a memory snapshot on indStart and compare it with
> indEnd
> > > indStart, indEnd = 30, 150
> > > print ' rss vsz %mem'
> > > for i in range(indEnd):
> > > p.figure(figsize=(float(640)/80.0,float(480)/80.0),
> > > facecolor='w', edgecolor='w')
> > > p.axes([0.0, 0.0, 1.0, 1.0])
> > > map1 = Basemap(projection='cyl', lat_0=50, lon_0=-100,
> > > area_thresh=1000.)
> > > # draw coastlines, country boundaries, fill continents.
> > > map1.drawcoastlines(linewidth=.5)
> > > map1.drawcountries()
> > > map1.fillcontinents(color="#CEFFCE")
> > > # draw the edge of the map projection region (the
> projection limb)
> > > map1.drawmapboundary()
> > > # compute the native map projection coordinates for cities.
> > > lats, lons = ([18.728], [20.890])
> > > x,y = map1(lons,lats)
> > > # plot filled circles at the locations of the cities.
> > > map1.plot(x,y,'bo')
> > > canvas = p.get_current_fig_manager().canvas
> > > agg = canvas.switch_backends \
> > > (matplotlib.backends.backend_agg.FigureCanvasAgg)
> > > agg.draw() # Takes ~.9 seconds
> > > # get the image data
> > > str_img = agg.tostring_rgb()
> > > width_fig, height_fig = map(int,
> agg.figure.bbox.get_bounds()[2:])
> > > p.cla()
> > > p.close()
> > > bytes = get_image_bytes(width_fig, height_fig, str_img)
> > >
> > >
> > > val = report_memory(i)
> > > # wait a few cycles for memory usage to stabilize
> > > if i==indStart: start = val
> > >
> > > end = val
> > > print 'Average memory consumed per loop: %1.4fk bytes' % \
> > > ((end-start)/float(indEnd-indStart))
> > >
> > >
> > >
> > >
> > > Here is the O/P
> > >
> > > $python memory_leak_map.py
> > > rss vsz %mem
> > > 0 47272 50632 9.7
> > > 1 74412 77700 15.3
> > > 2 93960 97380 19.3
> > > 3 113308 116776 23.3
> > > 4 132824 136416 27.3
> > > 5 152352 155828 31.3
> > > 6 171860 175216 35.3
> > > 7 191372 194868 39.3
> > > 8 210872 214248 43.3
> > > 9 230336 233916 47.3
> > > 10 249732 253284 51.3
> > > 11 269252 272692 55.3
> > > 12 288680 292336 59.3
> > > 13 308108 311724 63.2
> > > 14 305160 331112 62.6
> > > 15 301096 350764 61.8
> > > 16 304884 370160 62.6
> > > 17 298276 389804 61.2
> > > 18 305876 409184 62.8
> > > 19 298316 428596 61.2
> > > 20 307856 448224 63.2
> > > 21 308004 467640 63.2
> > > 22 308844 487016 63.4
> > > 23 306260 506656 62.9
> > > 24 300612 526052 61.7
> > > Traceback (most recent call last):
> > > File "memory_leak_map.py", line 41, in ?
> > > area_thresh=1000.)
> > > File
> > >
> >
> "/usr/local/lib/python2.4/site-packages/matplotlib/toolkits/basemap/basemap.py",
> >
> > > line 815, in __init__
> > > self.riversegs = segments+segments2+segments3
> > > MemoryError
> > > Killed: 9
> > >
> > >
> > > Can someone please help me out solving this problem?
> > >
> > >
> > > Thanks
> > > -Aalok
> > >
> > Aaolk: All your plots use the same map projection, yet you are
> > initializing a new Basemap instance every time through the
> loop. Try
> > moving the line
> >
> > map1 = Basemap(projection='cyl', lat_0=50, lon_0=-100,
> > area_thresh=1000.)
> >
> > outside the loop.
> >
> > -Jeff
> >
>
> Aaolk: Here's what I get with matplotlib 0.87.7, basemap
> 0.9.4, numpy
> 1.0 on MacOS 10.4.9 with python 2.5 (python 2.4 gives the same
> result):
>
> [mac28:~/matplotlib/toolkits/basemap] jsw% python memleak.py
> rss vsz %mem
> 0 28248 153200 -1.3
> 1 34028 157316 -1.6
> 2 34908 158084 -1.7
> 3 35688 158852 -1.7
> 4 36200 159364 -1.7
> 5 36712 159876 -1.8
> 6 36456 159620 -1.7
> 7 36712 159876 -1.8
> 8 36712 159876 -1.8
> 9 36712 159876 -1.8
> 10 36712 159876 -1.8
> 11 36712 159876 -1.8
> 12 36456 159620 -1.7
> 13 36712 159876 -1.8
> 14 36712 159876 -1.8
> 15 36712 159876 -1.8
> 16 36712 159876 -1.8
> 17 36712 159876 -1.8
> 18 36712 159876 -1.8
> 19 36712 159876 -1.8
> 20 36712 159876 -1.8
> 21 36712 159876 -1.8
>
>
> The %mem flag doesn't appear to work right on MacOS X, but
> otherwise it
> looks fine - no memory leak. I see you are using a pre-release
> version
> of numpy - I wonder if that could be the problem?
>
> -Jeff
>
>
>
> -- 
> Jeffrey S. Whitaker Phone : (303)497-6313
> NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
> 325 Broadway Boulder, CO, USA 80305-3328
>
Aaolk: Since I can't reproduce your problem, I'm afraid I can't give 
you any concrete advice. It could be Basemap, matplotlib, numpy, PIL or 
even python itself. To narrow down the possibilities, you can try 
moving trimming your loop line by line and see if you can make it go 
away. The python garbage collector interface 
(http://www.python.org/doc/2.4/lib/module-gc.html) might be of some help 
also.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Jeff and Aalok,
 I am in central MO and it doesn't bother me but, for some unknown reason I'm recieving correspondense between you two. You might want to start a new email instead of replying to each other. Have a nice day. Curt Bridges 
Aalok kapoor <aal...@ya...> wrote:
 After using numpy-1.0 the results are more bad. After 15 maps it is reaching to 71% memory usage. I am working on freeBSD box.
python memory_leak_map.py
 rss vsz %mem
0 47940 50636 9.8
1 75080 77700 15.4
2 94636 97380 19.4
3 114156 116776 23.4
4 133672 136416 27.4
5 153204 155832 31.4
6 172708 175216 35.5
7 192224 194872 39.5
8 211720 214248 43.5
9 231244 233916 47.5
10 250732 253280 51.5
11 270252 272688 55.5
12 289756 292332 59.5
13 309272 311728 63.5
14 328764 331108 67.5
15 347804 350760 71.4
thanks,
-Aalok
Aalok kapoor <aal...@ya...> wrote: Hi,
Thanks for this direction. I am using Numpy-1.1. Do I not supposed to use this version? I will try to use older version and see what happens. I hope this will solve the problem.
thanks
-Aalok
Jeff Whitaker <js...@fa...> wrote: Aalok kapoor wrote:
> Thanks for reply,
>
> This was just an example for mem leak in my application. Actually i 
> want maps with different data to be loaded each time and the map 
> objects taken once changees after ploting so i have to take different 
> object each time. After around 20 maps generation it gives memory 
> error to me.
>
> thanks,
> -Aalok
>
> */Jeff Whitaker /* wrote:
>
> Aalok kapoor wrote:
> > Hi all,
> >
> > I am using matplotlib-0.87.7, Basemap-0.9.3, Numpy-1.1 and agg
> backend.
> > I am facing memory leak problems after running following script -
> >
> >
> > import os, sys, time
> > import cStringIO
> > import Image
> > import matplotlib
> > matplotlib.use('Agg')
> >
> > import matplotlib.pylab as p
> > import matplotlib.numerix as nx
> > from matplotlib.toolkits.basemap import Basemap
> >
> > def get_image_bytes(width_fig, height_fig, str_img):
> > """Returns the bytes representing the image generated
> >
> > The createImage method should be called before calling this method.
> >
> > :Returns:
> > Byte data.
> > """
> > # Get the actual image data
> > f = cStringIO.StringIO()
> > dims = (width_fig, height_fig)
> > im = Image.fromstring("RGB", dims, str_img)
> > im.save(f, "JPEG")
> > return f.getvalue()
> >
> > def report_memory(i):
> > pid = os.getpid()
> > a2 = os.popen('ps -p %d -o rss,vsz,%%mem' % pid).readlines()
> > print i, ' ', a2[1],
> > return int(a2[1].split()[1])
> >
> >
> >
> > # take a memory snapshot on indStart and compare it with indEnd
> > indStart, indEnd = 30, 150
> > print ' rss vsz %mem'
> > for i in range(indEnd):
> > p.figure(figsize=(float(640)/80.0,float(480)/80.0),
> > facecolor='w', edgecolor='w')
> > p.axes([0.0, 0.0, 1.0, 1.0])
> > map1 = Basemap(projection='cyl', lat_0=50, lon_0=-100,
> > area_thresh=1000.)
> > # draw coastlines, country boundaries, fill continents.
> > map1.drawcoastlines(linewidth=.5)
> > map1.drawcountries()
> > map1.fillcontinents(color="#CEFFCE")
> > # draw the edge of the map projection region (the projection limb)
> > map1.drawmapboundary()
> > # compute the native map projection coordinates for cities.
> > lats, lons = ([18.728], [20.890])
> > x,y = map1(lons,lats)
> > # plot filled circles at the locations of the cities.
> > map1.plot(x,y,'bo')
> > canvas = p.get_current_fig_manager().canvas
> > agg = canvas.switch_backends \
> > (matplotlib.backends.backend_agg.FigureCanvasAgg)
> > agg.draw() # Takes ~.9 seconds
> > # get the image data
> > str_img = agg.tostring_rgb()
> > width_fig, height_fig = map(int, agg.figure.bbox.get_bounds()[2:])
> > p.cla()
> > p.close()
> > bytes = get_image_bytes(width_fig, height_fig, str_img)
> >
> >
> > val = report_memory(i)
> > # wait a few cycles for memory usage to stabilize
> > if i==indStart: start = val
> >
> > end = val
> > print 'Average memory consumed per loop: %1.4fk bytes' % \
> > ((end-start)/float(indEnd-indStart))
> >
> >
> >
> >
> > Here is the O/P
> >
> > $python memory_leak_map.py
> > rss vsz %mem
> > 0 47272 50632 9.7
> > 1 74412 77700 15.3
> > 2 93960 97380 19.3
> > 3 113308 116776 23.3
> > 4 132824 136416 27.3
> > 5 152352 155828 31.3
> > 6 171860 175216 35.3
> > 7 191372 194868 39.3
> > 8 210872 214248 43.3
> > 9 230336 233916 47.3
> > 10 249732 253284 51.3
> > 11 269252 272692 55.3
> > 12 288680 292336 59.3
> > 13 308108 311724 63.2
> > 14 305160 331112 62.6
> > 15 301096 350764 61.8
> > 16 304884 370160 62.6
> > 17 298276 389804 61.2
> > 18 305876 409184 62.8
> > 19 298316 428596 61.2
> > 20 307856 448224 63.2
> > 21 308004 467640 63.2
> > 22 308844 487016 63.4
> > 23 306260 506656 62.9
> > 24 300612 526052 61.7
> > Traceback (most recent call last):
> > File "memory_leak_map.py", line 41, in ?
> > area_thresh=1000.)
> > File
> >
> "/usr/local/lib/python2.4/site-packages/matplotlib/toolkits/basemap/basemap.py",
>
> > line 815, in __init__
> > self.riversegs = segments+segments2+segments3
> > MemoryError
> > Killed: 9
> >
> >
> > Can someone please help me out solving this problem?
> >
> >
> > Thanks
> > -Aalok
> >
> Aaolk: All your plots use the same map projection, yet you are
> initializing a new Basemap instance every time through the loop. Try
> moving the line
>
> map1 = Basemap(projection='cyl', lat_0=50, lon_0=-100,
> area_thresh=1000.)
>
> outside the loop.
>
> -Jeff
>
Aaolk: Here's what I get with matplotlib 0.87.7, basemap 0.9.4, numpy 
1.0 on MacOS 10.4.9 with python 2.5 (python 2.4 gives the same result):
[mac28:~/matplotlib/toolkits/basemap] jsw% python memleak.py
rss vsz %mem
0 28248 153200 -1.3
1 34028 157316 -1.6
2 34908 158084 -1.7
3 35688 158852 -1.7
4 36200 159364 -1.7
5 36712 159876 -1.8
6 36456 159620 -1.7
7 36712 159876 -1.8
8 36712 159876 -1.8
9 36712 159876 -1.8
10 36712 159876 -1.8
11 36712 159876 -1.8
12 36456 159620 -1.7
13 36712 159876 -1.8
14 36712 159876 -1.8
15 36712 159876 -1.8
16 36712 159876 -1.8
17 36712 159876 -1.8
18 36712 159876 -1.8
19 36712 159876 -1.8
20 36712 159876 -1.8
21 36712 159876 -1.8
The %mem flag doesn't appear to work right on MacOS X, but otherwise it 
looks fine - no memory leak. I see you are using a pre-release version 
of numpy - I wonder if that could be the problem?
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328
 
 
---------------------------------
 Find out what India is talking about on - Yahoo! Answers India 
Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 
---------------------------------
 Find out what India is talking about on - Yahoo! Answers India 
Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 
---------------------------------
Want to start your own business? Learn how on Yahoo! Small Business.

After using numpy-1.0 the results are more bad. After 15 maps it is reaching to 71% memory usage. I am working on freeBSD box.
python memory_leak_map.py
 rss vsz %mem
0 47940 50636 9.8
1 75080 77700 15.4
2 94636 97380 19.4
3 114156 116776 23.4
4 133672 136416 27.4
5 153204 155832 31.4
6 172708 175216 35.5
7 192224 194872 39.5
8 211720 214248 43.5
9 231244 233916 47.5
10 250732 253280 51.5
11 270252 272688 55.5
12 289756 292332 59.5
13 309272 311728 63.5
14 328764 331108 67.5
15 347804 350760 71.4
thanks,
-Aalok
Aalok kapoor <aal...@ya...> wrote: Hi,
Thanks for this direction. I am using Numpy-1.1. Do I not supposed to use this version? I will try to use older version and see what happens. I hope this will solve the problem.
thanks
-Aalok
Jeff Whitaker <js...@fa...> wrote: Aalok kapoor wrote:
> Thanks for reply,
>
> This was just an example for mem leak in my application. Actually i 
> want maps with different data to be loaded each time and the map 
> objects taken once changees after ploting so i have to take different 
> object each time. After around 20 maps generation it gives memory 
> error to me.
>
> thanks,
> -Aalok
>
> */Jeff Whitaker /* wrote:
>
> Aalok kapoor wrote:
> > Hi all,
> >
> > I am using matplotlib-0.87.7, Basemap-0.9.3, Numpy-1.1 and agg
> backend.
> > I am facing memory leak problems after running following script -
> >
> >
> > import os, sys, time
> > import cStringIO
> > import Image
> > import matplotlib
> > matplotlib.use('Agg')
> >
> > import matplotlib.pylab as p
> > import matplotlib.numerix as nx
> > from matplotlib.toolkits.basemap import Basemap
> >
> > def get_image_bytes(width_fig, height_fig, str_img):
> > """Returns the bytes representing the image generated
> >
> > The createImage method should be called before calling this method.
> >
> > :Returns:
> > Byte data.
> > """
> > # Get the actual image data
> > f = cStringIO.StringIO()
> > dims = (width_fig, height_fig)
> > im = Image.fromstring("RGB", dims, str_img)
> > im.save(f, "JPEG")
> > return f.getvalue()
> >
> > def report_memory(i):
> > pid = os.getpid()
> > a2 = os.popen('ps -p %d -o rss,vsz,%%mem' % pid).readlines()
> > print i, ' ', a2[1],
> > return int(a2[1].split()[1])
> >
> >
> >
> > # take a memory snapshot on indStart and compare it with indEnd
> > indStart, indEnd = 30, 150
> > print ' rss vsz %mem'
> > for i in range(indEnd):
> > p.figure(figsize=(float(640)/80.0,float(480)/80.0),
> > facecolor='w', edgecolor='w')
> > p.axes([0.0, 0.0, 1.0, 1.0])
> > map1 = Basemap(projection='cyl', lat_0=50, lon_0=-100,
> > area_thresh=1000.)
> > # draw coastlines, country boundaries, fill continents.
> > map1.drawcoastlines(linewidth=.5)
> > map1.drawcountries()
> > map1.fillcontinents(color="#CEFFCE")
> > # draw the edge of the map projection region (the projection limb)
> > map1.drawmapboundary()
> > # compute the native map projection coordinates for cities.
> > lats, lons = ([18.728], [20.890])
> > x,y = map1(lons,lats)
> > # plot filled circles at the locations of the cities.
> > map1.plot(x,y,'bo')
> > canvas = p.get_current_fig_manager().canvas
> > agg = canvas.switch_backends \
> > (matplotlib.backends.backend_agg.FigureCanvasAgg)
> > agg.draw() # Takes ~.9 seconds
> > # get the image data
> > str_img = agg.tostring_rgb()
> > width_fig, height_fig = map(int, agg.figure.bbox.get_bounds()[2:])
> > p.cla()
> > p.close()
> > bytes = get_image_bytes(width_fig, height_fig, str_img)
> >
> >
> > val = report_memory(i)
> > # wait a few cycles for memory usage to stabilize
> > if i==indStart: start = val
> >
> > end = val
> > print 'Average memory consumed per loop: %1.4fk bytes' % \
> > ((end-start)/float(indEnd-indStart))
> >
> >
> >
> >
> > Here is the O/P
> >
> > $python memory_leak_map.py
> > rss vsz %mem
> > 0 47272 50632 9.7
> > 1 74412 77700 15.3
> > 2 93960 97380 19.3
> > 3 113308 116776 23.3
> > 4 132824 136416 27.3
> > 5 152352 155828 31.3
> > 6 171860 175216 35.3
> > 7 191372 194868 39.3
> > 8 210872 214248 43.3
> > 9 230336 233916 47.3
> > 10 249732 253284 51.3
> > 11 269252 272692 55.3
> > 12 288680 292336 59.3
> > 13 308108 311724 63.2
> > 14 305160 331112 62.6
> > 15 301096 350764 61.8
> > 16 304884 370160 62.6
> > 17 298276 389804 61.2
> > 18 305876 409184 62.8
> > 19 298316 428596 61.2
> > 20 307856 448224 63.2
> > 21 308004 467640 63.2
> > 22 308844 487016 63.4
> > 23 306260 506656 62.9
> > 24 300612 526052 61.7
> > Traceback (most recent call last):
> > File "memory_leak_map.py", line 41, in ?
> > area_thresh=1000.)
> > File
> >
> "/usr/local/lib/python2.4/site-packages/matplotlib/toolkits/basemap/basemap.py",
>
> > line 815, in __init__
> > self.riversegs = segments+segments2+segments3
> > MemoryError
> > Killed: 9
> >
> >
> > Can someone please help me out solving this problem?
> >
> >
> > Thanks
> > -Aalok
> >
> Aaolk: All your plots use the same map projection, yet you are
> initializing a new Basemap instance every time through the loop. Try
> moving the line
>
> map1 = Basemap(projection='cyl', lat_0=50, lon_0=-100,
> area_thresh=1000.)
>
> outside the loop.
>
> -Jeff
>
Aaolk: Here's what I get with matplotlib 0.87.7, basemap 0.9.4, numpy 
1.0 on MacOS 10.4.9 with python 2.5 (python 2.4 gives the same result):
[mac28:~/matplotlib/toolkits/basemap] jsw% python memleak.py
 rss vsz %mem
0 28248 153200 -1.3
1 34028 157316 -1.6
2 34908 158084 -1.7
3 35688 158852 -1.7
4 36200 159364 -1.7
5 36712 159876 -1.8
6 36456 159620 -1.7
7 36712 159876 -1.8
8 36712 159876 -1.8
9 36712 159876 -1.8
10 36712 159876 -1.8
11 36712 159876 -1.8
12 36456 159620 -1.7
13 36712 159876 -1.8
14 36712 159876 -1.8
15 36712 159876 -1.8
16 36712 159876 -1.8
17 36712 159876 -1.8
18 36712 159876 -1.8
19 36712 159876 -1.8
20 36712 159876 -1.8
21 36712 159876 -1.8
The %mem flag doesn't appear to work right on MacOS X, but otherwise it 
looks fine - no memory leak. I see you are using a pre-release version 
of numpy - I wonder if that could be the problem?
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328
 
---------------------------------
 Find out what India is talking about on - Yahoo! Answers India 
 Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 				
---------------------------------
 Find out what India is talking about on - Yahoo! Answers India 
 Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW

Hi,
Thanks for this direction. I am using Numpy-1.1. Do I not supposed to use this version? I will try to use older version and see what happens. I hope this will solve the problem.
thanks
-Aalok
Jeff Whitaker <js...@fa...> wrote: Aalok kapoor wrote:
> Thanks for reply,
>
> This was just an example for mem leak in my application. Actually i 
> want maps with different data to be loaded each time and the map 
> objects taken once changees after ploting so i have to take different 
> object each time. After around 20 maps generation it gives memory 
> error to me.
>
> thanks,
> -Aalok
>
> */Jeff Whitaker /* wrote:
>
> Aalok kapoor wrote:
> > Hi all,
> >
> > I am using matplotlib-0.87.7, Basemap-0.9.3, Numpy-1.1 and agg
> backend.
> > I am facing memory leak problems after running following script -
> >
> >
> > import os, sys, time
> > import cStringIO
> > import Image
> > import matplotlib
> > matplotlib.use('Agg')
> >
> > import matplotlib.pylab as p
> > import matplotlib.numerix as nx
> > from matplotlib.toolkits.basemap import Basemap
> >
> > def get_image_bytes(width_fig, height_fig, str_img):
> > """Returns the bytes representing the image generated
> >
> > The createImage method should be called before calling this method.
> >
> > :Returns:
> > Byte data.
> > """
> > # Get the actual image data
> > f = cStringIO.StringIO()
> > dims = (width_fig, height_fig)
> > im = Image.fromstring("RGB", dims, str_img)
> > im.save(f, "JPEG")
> > return f.getvalue()
> >
> > def report_memory(i):
> > pid = os.getpid()
> > a2 = os.popen('ps -p %d -o rss,vsz,%%mem' % pid).readlines()
> > print i, ' ', a2[1],
> > return int(a2[1].split()[1])
> >
> >
> >
> > # take a memory snapshot on indStart and compare it with indEnd
> > indStart, indEnd = 30, 150
> > print ' rss vsz %mem'
> > for i in range(indEnd):
> > p.figure(figsize=(float(640)/80.0,float(480)/80.0),
> > facecolor='w', edgecolor='w')
> > p.axes([0.0, 0.0, 1.0, 1.0])
> > map1 = Basemap(projection='cyl', lat_0=50, lon_0=-100,
> > area_thresh=1000.)
> > # draw coastlines, country boundaries, fill continents.
> > map1.drawcoastlines(linewidth=.5)
> > map1.drawcountries()
> > map1.fillcontinents(color="#CEFFCE")
> > # draw the edge of the map projection region (the projection limb)
> > map1.drawmapboundary()
> > # compute the native map projection coordinates for cities.
> > lats, lons = ([18.728], [20.890])
> > x,y = map1(lons,lats)
> > # plot filled circles at the locations of the cities.
> > map1.plot(x,y,'bo')
> > canvas = p.get_current_fig_manager().canvas
> > agg = canvas.switch_backends \
> > (matplotlib.backends.backend_agg.FigureCanvasAgg)
> > agg.draw() # Takes ~.9 seconds
> > # get the image data
> > str_img = agg.tostring_rgb()
> > width_fig, height_fig = map(int, agg.figure.bbox.get_bounds()[2:])
> > p.cla()
> > p.close()
> > bytes = get_image_bytes(width_fig, height_fig, str_img)
> >
> >
> > val = report_memory(i)
> > # wait a few cycles for memory usage to stabilize
> > if i==indStart: start = val
> >
> > end = val
> > print 'Average memory consumed per loop: %1.4fk bytes' % \
> > ((end-start)/float(indEnd-indStart))
> >
> >
> >
> >
> > Here is the O/P
> >
> > $python memory_leak_map.py
> > rss vsz %mem
> > 0 47272 50632 9.7
> > 1 74412 77700 15.3
> > 2 93960 97380 19.3
> > 3 113308 116776 23.3
> > 4 132824 136416 27.3
> > 5 152352 155828 31.3
> > 6 171860 175216 35.3
> > 7 191372 194868 39.3
> > 8 210872 214248 43.3
> > 9 230336 233916 47.3
> > 10 249732 253284 51.3
> > 11 269252 272692 55.3
> > 12 288680 292336 59.3
> > 13 308108 311724 63.2
> > 14 305160 331112 62.6
> > 15 301096 350764 61.8
> > 16 304884 370160 62.6
> > 17 298276 389804 61.2
> > 18 305876 409184 62.8
> > 19 298316 428596 61.2
> > 20 307856 448224 63.2
> > 21 308004 467640 63.2
> > 22 308844 487016 63.4
> > 23 306260 506656 62.9
> > 24 300612 526052 61.7
> > Traceback (most recent call last):
> > File "memory_leak_map.py", line 41, in ?
> > area_thresh=1000.)
> > File
> >
> "/usr/local/lib/python2.4/site-packages/matplotlib/toolkits/basemap/basemap.py",
>
> > line 815, in __init__
> > self.riversegs = segments+segments2+segments3
> > MemoryError
> > Killed: 9
> >
> >
> > Can someone please help me out solving this problem?
> >
> >
> > Thanks
> > -Aalok
> >
> Aaolk: All your plots use the same map projection, yet you are
> initializing a new Basemap instance every time through the loop. Try
> moving the line
>
> map1 = Basemap(projection='cyl', lat_0=50, lon_0=-100,
> area_thresh=1000.)
>
> outside the loop.
>
> -Jeff
>
Aaolk: Here's what I get with matplotlib 0.87.7, basemap 0.9.4, numpy 
1.0 on MacOS 10.4.9 with python 2.5 (python 2.4 gives the same result):
[mac28:~/matplotlib/toolkits/basemap] jsw% python memleak.py
 rss vsz %mem
0 28248 153200 -1.3
1 34028 157316 -1.6
2 34908 158084 -1.7
3 35688 158852 -1.7
4 36200 159364 -1.7
5 36712 159876 -1.8
6 36456 159620 -1.7
7 36712 159876 -1.8
8 36712 159876 -1.8
9 36712 159876 -1.8
10 36712 159876 -1.8
11 36712 159876 -1.8
12 36456 159620 -1.7
13 36712 159876 -1.8
14 36712 159876 -1.8
15 36712 159876 -1.8
16 36712 159876 -1.8
17 36712 159876 -1.8
18 36712 159876 -1.8
19 36712 159876 -1.8
20 36712 159876 -1.8
21 36712 159876 -1.8
The %mem flag doesn't appear to work right on MacOS X, but otherwise it 
looks fine - no memory leak. I see you are using a pre-release version 
of numpy - I wonder if that could be the problem?
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328
 				
---------------------------------
 Find out what India is talking about on - Yahoo! Answers India 
 Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW

Aalok kapoor wrote:
> Thanks for reply,
>
> This was just an example for mem leak in my application. Actually i 
> want maps with different data to be loaded each time and the map 
> objects taken once changees after ploting so i have to take different 
> object each time. After around 20 maps generation it gives memory 
> error to me.
>
> thanks,
> -Aalok
>
> */Jeff Whitaker <js...@fa...>/* wrote:
>
> Aalok kapoor wrote:
> > Hi all,
> >
> > I am using matplotlib-0.87.7, Basemap-0.9.3, Numpy-1.1 and agg
> backend.
> > I am facing memory leak problems after running following script -
> >
> >
> > import os, sys, time
> > import cStringIO
> > import Image
> > import matplotlib
> > matplotlib.use('Agg')
> >
> > import matplotlib.pylab as p
> > import matplotlib.numerix as nx
> > from matplotlib.toolkits.basemap import Basemap
> >
> > def get_image_bytes(width_fig, height_fig, str_img):
> > """Returns the bytes representing the image generated
> >
> > The createImage method should be called before calling this method.
> >
> > :Returns:
> > Byte data.
> > """
> > # Get the actual image data
> > f = cStringIO.StringIO()
> > dims = (width_fig, height_fig)
> > im = Image.fromstring("RGB", dims, str_img)
> > im.save(f, "JPEG")
> > return f.getvalue()
> >
> > def report_memory(i):
> > pid = os.getpid()
> > a2 = os.popen('ps -p %d -o rss,vsz,%%mem' % pid).readlines()
> > print i, ' ', a2[1],
> > return int(a2[1].split()[1])
> >
> >
> >
> > # take a memory snapshot on indStart and compare it with indEnd
> > indStart, indEnd = 30, 150
> > print ' rss vsz %mem'
> > for i in range(indEnd):
> > p.figure(figsize=(float(640)/80.0,float(480)/80.0),
> > facecolor='w', edgecolor='w')
> > p.axes([0.0, 0.0, 1.0, 1.0])
> > map1 = Basemap(projection='cyl', lat_0=50, lon_0=-100,
> > area_thresh=1000.)
> > # draw coastlines, country boundaries, fill continents.
> > map1.drawcoastlines(linewidth=.5)
> > map1.drawcountries()
> > map1.fillcontinents(color="#CEFFCE")
> > # draw the edge of the map projection region (the projection limb)
> > map1.drawmapboundary()
> > # compute the native map projection coordinates for cities.
> > lats, lons = ([18.728], [20.890])
> > x,y = map1(lons,lats)
> > # plot filled circles at the locations of the cities.
> > map1.plot(x,y,'bo')
> > canvas = p.get_current_fig_manager().canvas
> > agg = canvas.switch_backends \
> > (matplotlib.backends.backend_agg.FigureCanvasAgg)
> > agg.draw() # Takes ~.9 seconds
> > # get the image data
> > str_img = agg.tostring_rgb()
> > width_fig, height_fig = map(int, agg.figure.bbox.get_bounds()[2:])
> > p.cla()
> > p.close()
> > bytes = get_image_bytes(width_fig, height_fig, str_img)
> >
> >
> > val = report_memory(i)
> > # wait a few cycles for memory usage to stabilize
> > if i==indStart: start = val
> >
> > end = val
> > print 'Average memory consumed per loop: %1.4fk bytes' % \
> > ((end-start)/float(indEnd-indStart))
> >
> >
> >
> >
> > Here is the O/P
> >
> > $python memory_leak_map.py
> > rss vsz %mem
> > 0 47272 50632 9.7
> > 1 74412 77700 15.3
> > 2 93960 97380 19.3
> > 3 113308 116776 23.3
> > 4 132824 136416 27.3
> > 5 152352 155828 31.3
> > 6 171860 175216 35.3
> > 7 191372 194868 39.3
> > 8 210872 214248 43.3
> > 9 230336 233916 47.3
> > 10 249732 253284 51.3
> > 11 269252 272692 55.3
> > 12 288680 292336 59.3
> > 13 308108 311724 63.2
> > 14 305160 331112 62.6
> > 15 301096 350764 61.8
> > 16 304884 370160 62.6
> > 17 298276 389804 61.2
> > 18 305876 409184 62.8
> > 19 298316 428596 61.2
> > 20 307856 448224 63.2
> > 21 308004 467640 63.2
> > 22 308844 487016 63.4
> > 23 306260 506656 62.9
> > 24 300612 526052 61.7
> > Traceback (most recent call last):
> > File "memory_leak_map.py", line 41, in ?
> > area_thresh=1000.)
> > File
> >
> "/usr/local/lib/python2.4/site-packages/matplotlib/toolkits/basemap/basemap.py",
>
> > line 815, in __init__
> > self.riversegs = segments+segments2+segments3
> > MemoryError
> > Killed: 9
> >
> >
> > Can someone please help me out solving this problem?
> >
> >
> > Thanks
> > -Aalok
> >
> Aaolk: All your plots use the same map projection, yet you are
> initializing a new Basemap instance every time through the loop. Try
> moving the line
>
> map1 = Basemap(projection='cyl', lat_0=50, lon_0=-100,
> area_thresh=1000.)
>
> outside the loop.
>
> -Jeff
>
Aaolk: Here's what I get with matplotlib 0.87.7, basemap 0.9.4, numpy 
1.0 on MacOS 10.4.9 with python 2.5 (python 2.4 gives the same result):
[mac28:~/matplotlib/toolkits/basemap] jsw% python memleak.py
 rss vsz %mem
0 28248 153200 -1.3
1 34028 157316 -1.6
2 34908 158084 -1.7
3 35688 158852 -1.7
4 36200 159364 -1.7
5 36712 159876 -1.8
6 36456 159620 -1.7
7 36712 159876 -1.8
8 36712 159876 -1.8
9 36712 159876 -1.8
10 36712 159876 -1.8
11 36712 159876 -1.8
12 36456 159620 -1.7
13 36712 159876 -1.8
14 36712 159876 -1.8
15 36712 159876 -1.8
16 36712 159876 -1.8
17 36712 159876 -1.8
18 36712 159876 -1.8
19 36712 159876 -1.8
20 36712 159876 -1.8
21 36712 159876 -1.8
The %mem flag doesn't appear to work right on MacOS X, but otherwise it 
looks fine - no memory leak. I see you are using a pre-release version 
of numpy - I wonder if that could be the problem?
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

Thanks for reply,
This was just an example for mem leak in my application. Actually i want maps with different data to be loaded each time and the map objects taken once changees after ploting so i have to take different object each time. After around 20 maps generation it gives memory error to me.
thanks,
-Aalok
Jeff Whitaker <js...@fa...> wrote: Aalok kapoor wrote:
> Hi all,
>
> I am using matplotlib-0.87.7, Basemap-0.9.3, Numpy-1.1 and agg backend.
> I am facing memory leak problems after running following script -
>
>
> import os, sys, time
> import cStringIO
> import Image
> import matplotlib
> matplotlib.use('Agg')
>
> import matplotlib.pylab as p
> import matplotlib.numerix as nx
> from matplotlib.toolkits.basemap import Basemap
>
> def get_image_bytes(width_fig, height_fig, str_img):
> """Returns the bytes representing the image generated
>
> The createImage method should be called before calling this method.
>
> :Returns:
> Byte data.
> """
> # Get the actual image data
> f = cStringIO.StringIO()
> dims = (width_fig, height_fig)
> im = Image.fromstring("RGB", dims, str_img)
> im.save(f, "JPEG")
> return f.getvalue()
>
> def report_memory(i):
> pid = os.getpid()
> a2 = os.popen('ps -p %d -o rss,vsz,%%mem' % pid).readlines()
> print i, ' ', a2[1],
> return int(a2[1].split()[1])
>
>
>
> # take a memory snapshot on indStart and compare it with indEnd
> indStart, indEnd = 30, 150
> print ' rss vsz %mem'
> for i in range(indEnd):
> p.figure(figsize=(float(640)/80.0,float(480)/80.0),
> facecolor='w', edgecolor='w')
> p.axes([0.0, 0.0, 1.0, 1.0])
> map1 = Basemap(projection='cyl', lat_0=50, lon_0=-100,
> area_thresh=1000.)
> # draw coastlines, country boundaries, fill continents.
> map1.drawcoastlines(linewidth=.5)
> map1.drawcountries()
> map1.fillcontinents(color="#CEFFCE")
> # draw the edge of the map projection region (the projection limb)
> map1.drawmapboundary()
> # compute the native map projection coordinates for cities.
> lats, lons = ([18.728], [20.890])
> x,y = map1(lons,lats)
> # plot filled circles at the locations of the cities.
> map1.plot(x,y,'bo')
> canvas = p.get_current_fig_manager().canvas
> agg = canvas.switch_backends \
> (matplotlib.backends.backend_agg.FigureCanvasAgg)
> agg.draw() # Takes ~.9 seconds
> # get the image data
> str_img = agg.tostring_rgb()
> width_fig, height_fig = map(int, agg.figure.bbox.get_bounds()[2:])
> p.cla()
> p.close()
> bytes = get_image_bytes(width_fig, height_fig, str_img)
>
>
> val = report_memory(i)
> # wait a few cycles for memory usage to stabilize
> if i==indStart: start = val
>
> end = val
> print 'Average memory consumed per loop: %1.4fk bytes' % \
> ((end-start)/float(indEnd-indStart))
>
>
>
>
> Here is the O/P
>
> $python memory_leak_map.py
> rss vsz %mem
> 0 47272 50632 9.7
> 1 74412 77700 15.3
> 2 93960 97380 19.3
> 3 113308 116776 23.3
> 4 132824 136416 27.3
> 5 152352 155828 31.3
> 6 171860 175216 35.3
> 7 191372 194868 39.3
> 8 210872 214248 43.3
> 9 230336 233916 47.3
> 10 249732 253284 51.3
> 11 269252 272692 55.3
> 12 288680 292336 59.3
> 13 308108 311724 63.2
> 14 305160 331112 62.6
> 15 301096 350764 61.8
> 16 304884 370160 62.6
> 17 298276 389804 61.2
> 18 305876 409184 62.8
> 19 298316 428596 61.2
> 20 307856 448224 63.2
> 21 308004 467640 63.2
> 22 308844 487016 63.4
> 23 306260 506656 62.9
> 24 300612 526052 61.7
> Traceback (most recent call last):
> File "memory_leak_map.py", line 41, in ?
> area_thresh=1000.)
> File 
> "/usr/local/lib/python2.4/site-packages/matplotlib/toolkits/basemap/basemap.py", 
> line 815, in __init__
> self.riversegs = segments+segments2+segments3
> MemoryError
> Killed: 9
>
>
> Can someone please help me out solving this problem?
>
>
> Thanks
> -Aalok
>
Aaolk: All your plots use the same map projection, yet you are 
initializing a new Basemap instance every time through the loop. Try 
moving the line
 map1 = Basemap(projection='cyl', lat_0=50, lon_0=-100, 
area_thresh=1000.)
outside the loop.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
 				
---------------------------------
 Find out what India is talking about on - Yahoo! Answers India 
 Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW