matplotlib-devel Mailing List for matplotlib

> -----Original Message-----
> From: Michael Droettboom [mailto:md...@st...]
> Sent: 16 Jan 2009 1:31 PM
> To: Andrew Hawryluk
> Cc: mat...@li...
> Subject: Re: [matplotlib-devel] path simplification can decrease the
> smoothness of data plots
> 
> Michael Droettboom wrote:
...
> I've attached a patch that will only include points from the original
> data in the simplified path. I hesitate to commit it to SVN, as these
> things are very hard to get right -- and just because it appears to
> work better on this data doesn't mean it doesn't create a regression
on
> something else... ;) That said, it would be nice to confirm that this
> solution works, because it has the added benefit of being a little
> simpler computationally. Be sure to blitz your build directory when
> testing the patch -- distutils won't pick it up as a dependency.
> 
> I've attached two PDFs -- one with the original (current trunk)
> behavior, and one with the new behavior. I plotted the unsimplified
> plot in thick blue behind the simplified plot in green, so you can see
> how much deviation there is between the original data and the
> simplified line (you'll want to zoom way in with your PDF viewer to
see
> it.)
> 
> I've also included a new version of your test script which detects
> "new"
> data values in the simplified path, and also seeds the random number
> generator so that results are comparable. I also set the
> solid_joinstyle to "round", as it makes the wiggliness less
pronounced.
> (There was another thread on this list recently about making that the
> default setting).
> 
> Cheers,
> Mike
> 
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
Thanks for looking into this! The new plot is much improved, and the
simplified calculations are a pleasant surprise. I was also testing the
previous algorithm with solid_joinstyle set to "round" as it is the
default in my matplotlibrc.
I am probably not able to build your patch here, unless building
matplotlib from source on Windows is easier than I anticipate. May I
send you some data off the list for you to test?
Regards,
Andrew
NOVA Chemicals Research & Technology Centre
Calgary, Canada

Greetings,
This weekend I decided to try and build mpl for windows using python
2.6.1. I was able to build numpy and mpl and I thought things were
great. However, when I tried to run a script with a show() function,
nothing would happen. Looking into this, I discovered that mpl didn't
recognize Tkinter during it's building process. I checked the
setupext.py code and found that python 2.6 wast excluded in the
windows section, even though Tkinter at least imports using python2.6.
 I also noticed that there appears to be a hold over to a previous
version of mpl by including references to python 2.2, even though the
TCL/TK headers and libs for TCL/TK 8.3 aren't included in win32_static
version anymore. I decided to build TCL/TK 8.5 (which is what python
2.6 ships with) and dumped the appropriate libs in the lib directory
of win32_static and the header files into include/tcl85 directory. I
then changed references from python 2.2 to use python 2.6 (including
using TCL/TK 8.5 instead of 8.3), rebuilt mpl, and ran it. This time
the show window opens, however as the figure is being drawn an error
occurs and the figure window remains blank. Below is the traceback:
Exception in Tkinter callback
Traceback (most recent call last):
 File "D:\Python26\lib\lib-tk\Tkinter.py", line 1410, in __call__
 return self.func(*args)
 File "D:\Python26\lib\site-packages\matplotlib\backends\backend_tkagg.py",
line 212, in resize
 self.show()
 File "D:\Python26\lib\site-packages\matplotlib\backends\backend_tkagg.py",
line 216, in draw
 tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)
 File "D:\Python26\lib\site-packages\matplotlib\backends\tkagg.py",
line 19, in blit
 tk.call("PyAggImagePhoto", photoimage, id(aggimage), colormode,
id(bbox_array))
TclError
This is as far as I've been able to go (so far) in tracking down the
issue. I'll admit that I haven't looked much farther due to time
constraints, so if anyone else has suggestions as to where to go next,
I'm all ears. I'm not sure who the windows guru is for mpl, but if I
(we) can figure this problem out, I'll work with them in getting mpl
ready for 2.6 on windows.
Thanks,
-Patrick
-- 
Patrick Marsh
Graduate Research Assistant
School of Meteorology
University of Oklahoma
http://www.patricktmarsh.com

On Mon, Jan 19, 2009 at 6:33 AM, Michiel de Hoon <mjl...@ya...> wrote:
> I am also finding the continuing increase in memory usage, but this also occurs with other backends (I tried tkagg and pdf) and also without the call to savefig. One possibility is a circular reference in the quiver function that prevents data from being cleaned up.
I do not know how relevant this is to the problem at hand, but I have
observed memory leaks in the Delaunay code in matplotlib 0.98.3. I
hadn't had the chance to upgrade to 0.98.5.x yet, but judging from the
release notes the issue was not fixed. Since the leak happens from
inside Sage I need to find out what exactly causes those leaks before
poking around and fixing them.
> --Michiel
>
Cheers,
Michael

I am also finding the continuing increase in memory usage, but this also occurs with other backends (I tried tkagg and pdf) and also without the call to savefig. One possibility is a circular reference in the quiver function that prevents data from being cleaned up.
--Michiel
--- On Mon, 1/19/09, Damon McDougall <dam...@gm...> wrote:
> From: Damon McDougall <dam...@gm...>
> Subject: [matplotlib-devel] Memory leak using savefig with MacOSX backend?
> To: "matplotlib development list" <mat...@li...>
> Date: Monday, January 19, 2009, 6:09 AM
> I'm looping over several files (about 1000) to produce a
> vector field plot for each data file I have. Doing this with
> the MacOSX backend appears to chew memory. My guess as to
> the source of the problem is the 'savefig' function
> (or possibly the way the MacOSX backend handles the saving
> of plots).
> 
> I opened Activity Monitor to watch the usage of memory
> increase. Below is code that recreates the problem.
> 
> [start]
> 
> import matplotlib
> matplotlib.use('macosx')
> matplotlib.rc('font',**{'family':'serif','serif':['Computer
> Modern Roman']})
> matplotlib.rc('text', usetex=True)
> from pylab import *
> 
> i = 0
> x = []
> y = []
> v1 = []
> v2 = []
> 
> while(True):
> 	f = open("%dresults.dat"%i,"r")
> 	for line in f:
> 		x.append(float(line.split()[0]))
> 		y.append(float(line.split()[1]))
> 		v1.append(float(line.split()[2]))
> 		v2.append(float(line.split()[3]))
> 	f.close()
> 	hold(False)
> 	figure(1)
> 	quiver(x, y, v1, v2, color='b',
> units='width', scale=1.0)
> 	xlabel('$x$')
> 	ylabel('$y$')
> 	grid(True)
> 	print i
> 	savefig('graph-%05d.pdf'%i)
> 	close(1)
> 	x = []
> 	y = []
> 	v1 = []
> 	v2 = []
> 	i = i + 1
> 
> 
> [end]
> 
> Regards,
> --Damon
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 

I'm looping over several files (about 1000) to produce a vector field 
plot for each data file I have. Doing this with the MacOSX backend 
appears to chew memory. My guess as to the source of the problem is 
the 'savefig' function (or possibly the way the MacOSX backend handles 
the saving of plots).
I opened Activity Monitor to watch the usage of memory increase. Below 
is code that recreates the problem.
[start]
import matplotlib
matplotlib.use('macosx')
matplotlib.rc('font',**{'family':'serif','serif':['Computer Modern 
Roman']})
matplotlib.rc('text', usetex=True)
from pylab import *
i = 0
x = []
y = []
v1 = []
v2 = []
while(True):
	f = open("%dresults.dat"%i,"r")
	for line in f:
		x.append(float(line.split()[0]))
		y.append(float(line.split()[1]))
		v1.append(float(line.split()[2]))
		v2.append(float(line.split()[3]))
	f.close()
	hold(False)
	figure(1)
	quiver(x, y, v1, v2, color='b', units='width', scale=1.0)
	xlabel('$x$')
	ylabel('$y$')
	grid(True)
	print i
	savefig('graph-%05d.pdf'%i)
	close(1)
	x = []
	y = []
	v1 = []
	v2 = []
	i = i + 1
[end]
Regards,
--Damon