matplotlib-users Mailing List for matplotlib (Page 4)

On 11/20/2010 09:05 PM, Garry Willgoose wrote:
> I want to control the ratio of the size of the x and y axes of contour/
> contourf() plot (in the same way that 'aspect' lets me control
> imgshow()). Is there any way to do this?

Yes, use the set_aspect() method of the Axes object:

http://matplotlib.sourceforge.net/api/axes_api.html?highlight=aspect#matplotlib.axes.Axes.set_aspect

Eric

I want to control the ratio of the size of the x and y axes of contour/ 
contourf() plot (in the same way that 'aspect' lets me control  
imgshow()). Is there any way to do this?

Hi Stan,

Seems numpy was the culprit. I upgraded to numpy-1.5.1 and now it works.
Python and runtime updates were not sufficient.

Thanks

Daniel

On Thu, Nov 18, 2010 at 4:50 PM, Benjamin Root <ben...@ou...> wrote:
>
> Caleb,
>
> Interesting analysis.  One possible source of a leak would be some sort of dangling reference that still hangs around even though the plot objects have been cleared.  By the time of the matplotlib 1.0.0 release, we did seem to clear out pretty much all of these, but it is possible there are still some lurking about.  We should probably run your script against the latest svn to see how the results compare.
>
> Another possibility might be related to numpy.  However this is the draw statement, so I don't know how much numpy is used in there. The latest refactor work in numpy has revealed some memory leaks that have existed, so who knows?
>
> Might be interesting to try making equivalent versions of this script using different backends, and different package versions to possibly isolate the source of the memory leak.
>
> Thanks for your observations,
> Ben Root
>

Sorry for the double post; it seems the first is not displaying
correctly on SourceForge.

I conducted a couple more experiments taking into consideration suggestions
made in responses to my original post (thanks for the response).

First, I ran my original test (as close to it as possible anyway) using the
Agg back end for 3 hours, plotting 16591 times (about 1.5Hz). Memory usage
increased by 86MB. That's about 5.3K per redraw. Very similar to my original
experiment. As suggested, I called gc.collect() after each iteration. It
returned 67 for every iteration (no increase), although len(gc.garbage)
reported 0 each iteration.

Second, I ran a test targeting TkAgg for 3 hours, plotting 21374 times. Memory
usage fluctuated over time, but essentially did not increase: starting at
32.54MB and ending at 32.79MB. gc.collect() reported 0 after each iteration
as did len(gc.garbage).

Attached are images of plots showing change in memory usage over time for each
experiment.

Any comments would be appreciated.

Following is the code for each experiment.

Agg
-----

from random import random
from datetime import datetime
import os
import gc
import time
import win32api
import win32con
import win32process

import numpy

import matplotlib
matplotlib.use("Agg")
from matplotlib.figure import Figure
from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas

def get_process_memory_info(process_id):
    memory = {}
    process = None
    try:
        process = win32api.OpenProcess(
            win32con.PROCESS_QUERY_INFORMATION|win32con.PROCESS_VM_READ,
            False, process_id);
        if process is not None:
            return win32process.GetProcessMemoryInfo(process)
    finally:
        if process:
            win32api.CloseHandle(process)
    return memory

meg = 1024.0 * 1024.0

figure = Figure(dpi=None)
canvas = FigureCanvas(figure)
axes = figure.add_subplot(1,1,1)

def draw(channel, seconds):
    axes.clear()
    axes.plot(channel, seconds)
    canvas.print_figure('test.png')

channel = numpy.sin(numpy.arange(1000) * random())
seconds = numpy.arange(len(channel))
testDuration = 60 * 60 * 3
startTime = time.time()

print "starting memory: ", \
    get_process_memory_info(os.getpid())["WorkingSetSize"]/meg

while (time.time() - startTime) < testDuration:
    draw(channel, seconds)

    t = datetime.now()
    memory = get_process_memory_info(os.getpid())
    print "time: {0}, working: {1:f}, collect: {2}, garbage: {3}".format(
        t,
        memory["WorkingSetSize"]/meg,
        gc.collect(),
        len(gc.garbage) )

    time.sleep(0.5)


TkAgg
---------
from random import random
from datetime import datetime
import sys
import os
import gc
import time
import win32api
import win32con
import win32process

import numpy

import matplotlib
matplotlib.use("TkAgg")
from matplotlib.figure import Figure
from matplotlib.backends.backend_tkagg import FigureCanvasTkAgg \
    as FigureCanvas

import Tkinter as tk

def get_process_memory_info(process_id):
    memory = {}
    process = None
    try:
        process = win32api.OpenProcess(
            win32con.PROCESS_QUERY_INFORMATION|win32con.PROCESS_VM_READ,
            False, process_id);
        if process is not None:
            return win32process.GetProcessMemoryInfo(process)
    finally:
        if process:
            win32api.CloseHandle(process)
    return memory

meg = 1024.0 * 1024.0

rootTk = tk.Tk()
rootTk.wm_title("TKAgg Memory Leak")

figure = Figure()
canvas = FigureCanvas(figure, master=rootTk)
axes = figure.add_subplot(1,1,1)

def draw(channel, seconds):
    axes.clear()
    axes.plot(channel, seconds)

channel = numpy.sin(numpy.arange(1000) * random())
seconds = numpy.arange(len(channel))

testDuration = 60 * 60 * 3
startTime = time.time()

print "starting memory: ", \
    get_process_memory_info(os.getpid())["WorkingSetSize"]/meg

draw(channel, seconds)
canvas.show()
canvas.get_tk_widget().pack(side=tk.TOP, fill=tk.BOTH, expand=1)

rate = 500

def on_tick():
    canvas.get_tk_widget().after(rate, on_tick)

    if (time.time() - startTime) >= testDuration:
        return

    draw(channel, seconds)

    t = datetime.now()
    memory = get_process_memory_info(os.getpid())
    print "time: {0}, working: {1:f}, collect: {2}, garbage: {3}".format(
        t,
        memory["WorkingSetSize"]/meg,
        gc.collect(),
        len(gc.garbage) )

canvas.get_tk_widget().after(rate, on_tick)
tk.mainloop()

> From: D [mailto:da...@gm...] 
> Sent: Friday, November 12, 2010 16:52
> 
> I am running Python 2.5.2 on win xp sp3 on an Intel Core2 Duo. After
> installation of matplotlib-1.0.0.win32-py2.5.exe I get a Windows crash
> on importing pylab.
> import pylab -> An unhandled win32 exception occured in 
> python.exe [5048]
> import matplotlib works
> 
> I did not add anything to the matplotlibrc. I uninstalled matplotlib
> and re-installed with the same problem.
> matplotlib-0.99.3.win32-py2.5.exe gives me the same problem.
> The older version I had installed before (forgot which one) 
> worked fine.

Can you 'import numpy' and 'import matplotlib.pyplot'?  What is your
numpy.__version__?

So I tried updating and rebuilding Matplotlib - no luck - something (at
least on my system) is goofy with the GTK(Agg),WX(Agg), and
Fltk(Agg) backends.  But the TkAgg backend works great.  So I will
stick with that, but if anyone else sees this problem and it becomes an
issue, I'd be happy to help debug it in any way I can.

-C

 On Wed, 17 Nov 2010 19:46:34 -0600
Benjamin Root <ben...@ou...> wrote:

> On Wed, Nov 17, 2010 at 7:38 PM, Collin Day <dcd...@gm...>
> wrote:
> 
> > On Wed, 17 Nov 2010 19:00:54 -0600
> > Benjamin Root <ben...@ou...> wrote:
> >
> > Another data point -
> >
> > I tried Qt4Agg - it also works interactively - ie it goes back to
> > the ipython cmd line.  I also noticed when I start ipython --pylab,
> > the following error messages occur:
> >
> > ** Message: pygobject_register_sinkfunc is deprecated (GtkWindow)
> > ** Message: pygobject_register_sinkfunc is deprecated (GtkInvisible)
> > ** Message: pygobject_register_sinkfunc is deprecated (GtkObject)
> >
> >
> Interesting.  It is possible that the gtk backend might have been
> compiled against gtk development libraries that do not match your
> current gtk library.  What have you updated recently, and how did you
> do it?
> 
> Ben Root

Hello,

I see that for a legend you can do the following:

ax = plt.scatter(x,y,label='test data')
p_leg = mpl.font_manager.FontProperties(size='8')
ax.legend(prop=p_leg)

But, how do you do set font properties for the colorbar tick labels?

Thanks!

On 11/18/10 5:05 PM, John Hunter wrote:
> On Thu, Nov 18, 2010 at 2:20 PM, Benjamin Root<ben...@ou...>  wrote:
>
>> Interesting analysis.  One possible source of a leak would be some sort of
>> dangling reference that still hangs around even though the plot objects have
>> been cleared.  By the time of the matplotlib 1.0.0 release, we did seem to
>> clear out pretty much all of these, but it is possible there are still some
>> lurking about.  We should probably run your script against the latest svn to
>> see how the results compare.
>
> In our experience, many of the GUI backends have some leak, and these
> are in the GUI and not in mpl.  Caleb, can you see if you can
> replicate the leak with your example code using the agg backend (no
> GUI).  If so, could you post the code that exposes the leak.  if not,
> I'm afraid it is in wx and you might need to deal with the wx
> developers.

Heh. Good timing! I just fixed a bug in Chaco involving a leaking cycle that the 
garbage collector could not clean up. The lesson of my tale of woe is that even 
if there is no leak when you run without wxPython, that doesn't mean that 
wxPython is the culprit.

If any object in the connected graph containing a cycle (even if it does not 
directly participate in the cycle) has an __del__ method in pure Python, then 
the garbage collector will not clean up that cycle for safety reasons. Read the 
docs for the gc module for details. We use SWIG to wrap Agg and SWIG adds 
__del__ methods for all of its classes. wxPython uses SWIG and has the same 
problems. If there is a cycle which can reach a wxPython object, the cycle will 
leak. The actual cycle may be created by matplotlib, though.

You can determine if this is the case pretty easily, though. Call gc.collect() 
then examine the list gc.garbage. This will contain all of those objects with a 
__del__ that prevented a cycle from being collected.

I recommend using objgraph to diagram the graph of references to those objects. 
It's invaluable to actually see what's going on.

   http://pypi.python.org/pypi/objgraph

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

On Thu, Nov 18, 2010 at 2:20 PM, Benjamin Root <ben...@ou...> wrote:

> Interesting analysis.  One possible source of a leak would be some sort of
> dangling reference that still hangs around even though the plot objects have
> been cleared.  By the time of the matplotlib 1.0.0 release, we did seem to
> clear out pretty much all of these, but it is possible there are still some
> lurking about.  We should probably run your script against the latest svn to
> see how the results compare.

In our experience, many of the GUI backends have some leak, and these
are in the GUI and not in mpl.  Caleb, can you see if you can
replicate the leak with your example code using the agg backend (no
GUI).  If so, could you post the code that exposes the leak.  if not,
I'm afraid it is in wx and you might need to deal with the wx
developers.

JDH

On Thu, Nov 18, 2010 at 1:11 PM, Caleb Constantine <cad...@gm...>wrote:

> Matplotlib Users:
>
> It seems matplotlib plotting has a relatively small memory leak. My
> experiments suggest it leaks between 5K and 8K bytes of RAM for ever plot
> redraw. For example, in one experiment, plotting the same buffer (so as to
> not
> allocate new memory) every second for a period of about 12 hours resulted
> in
> memory usage (physical RAM) increasing by approximately 223MB, which is
> about
> 5.3K per replot.  The plotting code is:
>
>     class PlotPanel(wx.Panel):
>         def __init__(self, parent):
>             wx.Panel.__init__(self, parent, wx.ID_ANY,
>                 style=wx.BORDER_THEME|wx.TAB_TRAVERSAL)
>             self._figure = MplFigure(dpi=None)
>             self._canvas = MplCanvas(self, -1, self._figure)
>             self._axes = self._figure.add_subplot(1,1,1)
>
>             sizer = wx.BoxSizer(wx.VERTICAL)
>             sizer.Add(self._canvas, 1, wx.EXPAND|wx.TOP, 5)
>             self.SetSizer(sizer)
>
>         def draw(self, channel, seconds):
>             self._axes.clear()
>             self._axes.plot(channel, seconds)
>             self._canvas.draw()
>
>
> `draw()` is called every second with the same `channels` and `seconds`
> numpy.array buffers.
>
> In my case, this leak, though relatively small, becomes a serious issue
> since
> my software often runs for long periods of time (days) plotting data
> streamed
> from a data acquisition unit.
>
> Any suggestions will help. Am I miss understanding something here? Maybe I
> need to call some obscure function to free memory, or something?
>
> My testing environment:
>
>   * Windws XP SP3, Intel Core 2 Duo @ 2.33GHz, 1.96 GB RAM
>   * Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit
>     (Intel)] on win32
>   * matplotlib version 1.0.0
>   * numpy 1.4.1
>   * wxPython version 2.8.11.0
>
> The complete test program follows.
>
> Thanks,
>
> Caleb
>
>
>  from random import random
> from datetime import datetime
> import os
> import time
> import win32api
> import win32con
> import win32process
>
> import wx
> import numpy
>
> import matplotlib as mpl
> from matplotlib.figure import Figure as MplFigure
> from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg as
> MplCanvas
>
> def get_process_memory_info(process_id):
>     memory = {}
>     process = None
>     try:
>         process = win32api.OpenProcess(
>             win32con.PROCESS_QUERY_INFORMATION|win32con.PROCESS_VM_READ,
>             False, process_id);
>         if process is not None:
>             return win32process.GetProcessMemoryInfo(process)
>     finally:
>         if process:
>             win32api.CloseHandle(process)
>     return memory
>
> meg = 1024.0 * 1024.0
>
> class PlotPanel(wx.Panel):
>     def __init__(self, parent):
>         wx.Panel.__init__(self, parent, wx.ID_ANY,
>             style=wx.BORDER_THEME|wx.TAB_TRAVERSAL)
>         self._figure = MplFigure(dpi=None)
>         self._canvas = MplCanvas(self, -1, self._figure)
>         self._axes = self._figure.add_subplot(1,1,1)
>
>         sizer = wx.BoxSizer(wx.VERTICAL)
>         sizer.Add(self._canvas, 1, wx.EXPAND|wx.TOP, 5)
>         self.SetSizer(sizer)
>
>     def draw(self, channel, seconds):
>         self._axes.clear()
>         self._axes.plot(channel, seconds)
>         self._canvas.draw()
>
> class TestFrame(wx.Frame):
>     def __init__(self, parent, id, title):
>         wx.Frame.__init__(
>             self, parent, id, title, wx.DefaultPosition, (600, 400))
>
>         self.testDuration = 60 * 60 * 24
>         self.startTime = 0
>
>         self.channel = numpy.sin(numpy.arange(1000) * random())
>         self.seconds = numpy.arange(len(self.channel))
>
>         self.plotPanel = PlotPanel(self)
>
>         sizer = wx.BoxSizer(wx.VERTICAL)
>         sizer.Add(self.plotPanel, 1 ,wx.EXPAND)
>         self.SetSizer(sizer)
>
>         self._timer = wx.Timer(self)
>          self.Bind(wx.EVT_TIMER, self._onTimer, self._timer)
>         self._timer.Start(1000)
>         print "starting memory: ",\
>             get_process_memory_info(os.getpid())["WorkingSetSize"]/meg
>
>     def _onTimer(self, evt):
>         if self.startTime == 0:
>             self.startTime = time.time()
>
>         if (time.time() - self.startTime) >= self.testDuration:
>             self._timer.Stop()
>
>         self.plotPanel.draw(self.channel, self.seconds)
>
>         t = datetime.now()
>         memory = get_process_memory_info(os.getpid())
>         print "time: {0}, working: {1:f}".format(
>             t, memory["WorkingSetSize"]/meg)
>
> class MyApp(wx.App):
>     def OnInit(self):
>         frame = TestFrame(None, wx.ID_ANY, "Memory Leak")
>         self.SetTopWindow(frame)
>         frame.Show(True)
>         return True
>
> if __name__ == '__main__':
>     app = MyApp(0)
>     app.MainLoop()
>
>
>
Caleb,

Interesting analysis.  One possible source of a leak would be some sort of
dangling reference that still hangs around even though the plot objects have
been cleared.  By the time of the matplotlib 1.0.0 release, we did seem to
clear out pretty much all of these, but it is possible there are still some
lurking about.  We should probably run your script against the latest svn to
see how the results compare.

Another possibility might be related to numpy.  However this is the draw
statement, so I don't know how much numpy is used in there. The latest
refactor work in numpy has revealed some memory leaks that have existed, so
who knows?

Might be interesting to try making equivalent versions of this script using
different backends, and different package versions to possibly isolate the
source of the memory leak.

Thanks for your observations,
Ben Root

Matplotlib Users:

It seems matplotlib plotting has a relatively small memory leak. My
experiments suggest it leaks between 5K and 8K bytes of RAM for ever plot
redraw. For example, in one experiment, plotting the same buffer (so as to
not
allocate new memory) every second for a period of about 12 hours resulted in
memory usage (physical RAM) increasing by approximately 223MB, which is
about
5.3K per replot.  The plotting code is:

    class PlotPanel(wx.Panel):
        def __init__(self, parent):
            wx.Panel.__init__(self, parent, wx.ID_ANY,
                style=wx.BORDER_THEME|wx.TAB_TRAVERSAL)
            self._figure = MplFigure(dpi=None)
            self._canvas = MplCanvas(self, -1, self._figure)
            self._axes = self._figure.add_subplot(1,1,1)

            sizer = wx.BoxSizer(wx.VERTICAL)
            sizer.Add(self._canvas, 1, wx.EXPAND|wx.TOP, 5)
            self.SetSizer(sizer)

        def draw(self, channel, seconds):
            self._axes.clear()
            self._axes.plot(channel, seconds)
            self._canvas.draw()


`draw()` is called every second with the same `channels` and `seconds`
numpy.array buffers.

In my case, this leak, though relatively small, becomes a serious issue
since
my software often runs for long periods of time (days) plotting data
streamed
from a data acquisition unit.

Any suggestions will help. Am I miss understanding something here? Maybe I
need to call some obscure function to free memory, or something?

My testing environment:

  * Windws XP SP3, Intel Core 2 Duo @ 2.33GHz, 1.96 GB RAM
  * Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit
    (Intel)] on win32
  * matplotlib version 1.0.0
  * numpy 1.4.1
  * wxPython version 2.8.11.0

The complete test program follows.

Thanks,

Caleb


from random import random
from datetime import datetime
import os
import time
import win32api
import win32con
import win32process

import wx
import numpy

import matplotlib as mpl
from matplotlib.figure import Figure as MplFigure
from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg as MplCanvas

def get_process_memory_info(process_id):
    memory = {}
    process = None
    try:
        process = win32api.OpenProcess(
            win32con.PROCESS_QUERY_INFORMATION|win32con.PROCESS_VM_READ,
            False, process_id);
        if process is not None:
            return win32process.GetProcessMemoryInfo(process)
    finally:
        if process:
            win32api.CloseHandle(process)
    return memory

meg = 1024.0 * 1024.0

class PlotPanel(wx.Panel):
    def __init__(self, parent):
        wx.Panel.__init__(self, parent, wx.ID_ANY,
            style=wx.BORDER_THEME|wx.TAB_TRAVERSAL)
        self._figure = MplFigure(dpi=None)
        self._canvas = MplCanvas(self, -1, self._figure)
        self._axes = self._figure.add_subplot(1,1,1)

        sizer = wx.BoxSizer(wx.VERTICAL)
        sizer.Add(self._canvas, 1, wx.EXPAND|wx.TOP, 5)
        self.SetSizer(sizer)

    def draw(self, channel, seconds):
        self._axes.clear()
        self._axes.plot(channel, seconds)
        self._canvas.draw()

class TestFrame(wx.Frame):
    def __init__(self, parent, id, title):
        wx.Frame.__init__(
            self, parent, id, title, wx.DefaultPosition, (600, 400))

        self.testDuration = 60 * 60 * 24
        self.startTime = 0

        self.channel = numpy.sin(numpy.arange(1000) * random())
        self.seconds = numpy.arange(len(self.channel))

        self.plotPanel = PlotPanel(self)

        sizer = wx.BoxSizer(wx.VERTICAL)
        sizer.Add(self.plotPanel, 1 ,wx.EXPAND)
        self.SetSizer(sizer)

        self._timer = wx.Timer(self)
        self.Bind(wx.EVT_TIMER, self._onTimer, self._timer)
        self._timer.Start(1000)
        print "starting memory: ",\
            get_process_memory_info(os.getpid())["WorkingSetSize"]/meg

    def _onTimer(self, evt):
        if self.startTime == 0:
            self.startTime = time.time()

        if (time.time() - self.startTime) >= self.testDuration:
            self._timer.Stop()

        self.plotPanel.draw(self.channel, self.seconds)

        t = datetime.now()
        memory = get_process_memory_info(os.getpid())
        print "time: {0}, working: {1:f}".format(
            t, memory["WorkingSetSize"]/meg)

class MyApp(wx.App):
    def OnInit(self):
        frame = TestFrame(None, wx.ID_ANY, "Memory Leak")
        self.SetTopWindow(frame)
        frame.Show(True)
        return True

if __name__ == '__main__':
    app = MyApp(0)
    app.MainLoop()

Goals:  date plot with two y axes (plotting completely different things)
            point picking and point labeling
            As many lines as user wants, all colored differently.

Having some problems with this.  (matplotlib 0.98.5)

1) There is a known bug with twinx() and plot_date:

http://sourceforge.net/tracker/index.php?func=detail&aid=3046812&group_id=80706&atid=560720

But I can get it to work if I change ONE OF the plot_date() calls (the
one for the values plotted to the right-hand y axis) to just plot().

Is that going to introduce problems?  Is there a better workaround?
(The ones on that page don't work for me).

2) How can I get the lines belonging to different axes to cycle
through colors such that the same color is not used for any lines
shown in the plot?  (that is, I don't want to hard code a color to any
line, I want it to auto-cycle).

3) My point picking is not working with the two axes.  In my routine,
I label  the picked point and to do that I have to make reference to
its axis and call plot_date().  How can I know which axis the picked
point came from, so that I can label it appropriately?

Sorry this is a little stirred together, but hoping I can get some
hints to allow me to work it into shape.

Thanks,
Che

Folks, I was trying to use an object oriented approach to creating
colorbars, but I could manage to make it work. Currently I have close
to what I am trying to achieve, but the last bits are missing. The
outstanding issues are:

1) I only need one colorbar, how would I create a single colorbar on
the right that spanned across all axes? (ie. same height as the stack)
2) is there a way to place the colorbar in the bottom middle of my
panels (if I end up with more than one)?
3) How can I customize the tick labels of the colorbar?
4) Is this a 'pythonic' approach to begin with?

Here's my code, and a fake class that should provide the data needed
to use the example:

#!/usr/bin/env python

"""
Demo to help understand plotting tools
"""
import numpy as np
import matplotlib as mpl
import matplotlib.pyplot as plt

class Fun(object):
    """ Dummy class for testing
    """

    class body:
        pass

    def __init__(self):

        body = Fun.body
        body.time = np.arange(1000)
        body.alt = np.sin(body.time)
        body.A = 360*np.random.random_sample(1000)-180
        body.B = 180*np.random.random_sample(1000)-90
        body.C = 90*np.random.random_sample(1000)-45


def plot_angles(F):
    """ Plots the angles of body """

    from mpl_toolkits.axes_grid1.inset_locator import inset_axes

    # Set up plotting environment colors
    Nc = np.arange(-180,181,1)
    norm = mpl.colors.normalize(Nc.min(),Nc.max())

    fig, (ax1, ax2, ax3) = plt.subplots(3, sharex=True, sharey=True)

    ax1.scatter(F.body.time,F.body.alt,c=F.body.A,norm=norm,label='A',edgecolor='none')

    ax2.scatter(F.body.time,F.body.alt,c=F.body.B,norm=norm,label='B',edgecolor='none')

    ax3.scatter(F.body.time,F.body.alt,c=F.body.C,norm=norm,label='C',edgecolor='none')

    # Fine-tune figure; make subplots close to each other and hide x ticks for
    # all but bottom plot.
    fig.subplots_adjust(hspace=0)
    plt.setp([a.get_xticklabels() for a in fig.axes[:-1]], visible=False)
    for a in fig.axes:
        ia = inset_axes(a,width="20%", height="5%", loc=4)
        a.set_xlim(F.body.time[0],F.body.time[-1])
        fig.add_subplot(a)
        plt.colorbar(a.collections[0],cax=ia,orientation='horizontal')
        ia.xaxis.set_ticks_position("top")

    plt.draw()

    return fig


def demo():

    F = Fun()
    plot_angles(F)

if __name__ == "__main__":
    fig = demo()
    plt.show()

Ok problem(s) solved, thanks a lot for the efficient help (this also taught me 
how to go through the code more thoroughly)

* for the record: I had a pylab.py in the site-packages directory, probably a 
left-over from some other installation, which was interfering with the pylab.py 
which should be the one under matplotlib/. I just removed it now and it works well.

* and you were right, the funny "try this" was a left over of many tests I had 
done to track down the problem (mea culpa on that one)

thanks again, all works beautifully (and consistently) now.

cheers
Eric

Am 17/11/10, schrieb Benjamin Root  <ben...@ou...>:

> On Wed, Nov 17, 2010 at 8:44 AM, Benjamin Root <ben...@ou... <ben...@ou...>> wrote:
> 
> > 
> > 
> > 
> > 
> > 
> > 
> > On Wed, Nov 17, 2010 at 5:45 AM, Matthias Plum <pl...@ph...(javascript:main.compose()> wrote:
> > 
> > 
> > 
> > > 
> > > Hi
> > > 
> > > 
> > > 
> > > I am trying to plot data on the sphere and use the hammer projection.
> > > 
> > > The data ploting works fine, but the angular grid isn't shown correctly.
> > > 
> > > In the attached picture you can see the error(mouse pointer is on the
> > > 
> > > position 60 E 30 S). Can anyone help me on this subject? Thanks.
> > > 
> > > 
> > > 
> > > Matthias
> > > 
> > > 
> > > 
> > 
> > 
> > Matthias,
> > 
> > Looking at the transform equation for Hammer, it looks like there might be a mistake in the calculation.  Can you include the script you used to make that figure so I can test the fix?
> > 
> > 
> > 
> > 
> > Thanks,
> > Ben Root
> > 
> > 
> > 
> 
> Nevermind about the example script, I tested it myself and verified the problem.  The fix was simple.  We were missing a square root for the denominator of the formula for x and y.  Before I submit this patch, can anybody with more knowledge about the hammer projection verify that the equations on the wikipedia page are correct?  I would like to verify the transformation before making this change.
> 
> 
> 
> Ben Root
> 
> 
> 


Hi Ben,

the patch works very good! Thank you! And the hammer projection equatations in wikipedea are correct.

kind regards
Matthias

Well, I am a Gentoo user, so I was doing the usual emerge -uavDN world
which updates everything, so I don't know what exactly has changed.
What I can tell you is that I have gtk 2.20.1 and wxGtk 2.8.11.  I
could try updating again (I update about every 1-2 weeks to keep
current and avoid issues that can arise when you update from older
stuff).  Also, I can just use TkAgg as it works.  If it is something
you are interested in, I don't mind trying some debug stuff if you let
me know what you need to debug.  Otherwise - tkAgg appears to be the
way to go:)  At least someone knows there is a potential problem.  How
about I try a system update and let you know if I still see problems?

-C



On Wed, 17 Nov 2010 19:46:34 -0600
Benjamin Root <ben...@ou...> wrote:

> On Wed, Nov 17, 2010 at 7:38 PM, Collin Day <dcd...@gm...>
> wrote:
> 
> > On Wed, 17 Nov 2010 19:00:54 -0600
> > Benjamin Root <ben...@ou...> wrote:
> >
> > Another data point -
> >
> > I tried Qt4Agg - it also works interactively - ie it goes back to
> > the ipython cmd line.  I also noticed when I start ipython --pylab,
> > the following error messages occur:
> >
> > ** Message: pygobject_register_sinkfunc is deprecated (GtkWindow)
> > ** Message: pygobject_register_sinkfunc is deprecated (GtkInvisible)
> > ** Message: pygobject_register_sinkfunc is deprecated (GtkObject)
> >
> >
> Interesting.  It is possible that the gtk backend might have been
> compiled against gtk development libraries that do not match your
> current gtk library.  What have you updated recently, and how did you
> do it?
> 
> Ben Root

On Wed, Nov 17, 2010 at 7:38 PM, Collin Day <dcd...@gm...> wrote:

> On Wed, 17 Nov 2010 19:00:54 -0600
> Benjamin Root <ben...@ou...> wrote:
>
> Another data point -
>
> I tried Qt4Agg - it also works interactively - ie it goes back to the
> ipython cmd line.  I also noticed when I start ipython --pylab, the
> following error messages occur:
>
> ** Message: pygobject_register_sinkfunc is deprecated (GtkWindow)
> ** Message: pygobject_register_sinkfunc is deprecated (GtkInvisible)
> ** Message: pygobject_register_sinkfunc is deprecated (GtkObject)
>
>
Interesting.  It is possible that the gtk backend might have been compiled
against gtk development libraries that do not match your current gtk
library.  What have you updated recently, and how did you do it?

Ben Root

On Wed, 17 Nov 2010 19:00:54 -0600
Benjamin Root <ben...@ou...> wrote:

Another data point - 

I tried Qt4Agg - it also works interactively - ie it goes back to the
ipython cmd line.  I also noticed when I start ipython --pylab, the
following error messages occur:

** Message: pygobject_register_sinkfunc is deprecated (GtkWindow)
** Message: pygobject_register_sinkfunc is deprecated (GtkInvisible)
** Message: pygobject_register_sinkfunc is deprecated (GtkObject)

-C
> On Wed, Nov 17, 2010 at 6:54 PM, Collin Day <dcd...@gm...>
> wrote:
> 
> > Either I updated something that changed Matplotlib's behavior or I
> > am missing something, but when I make a plot in ipython, control is
> > not returning to the prompt - I can't do anything until I close the
> > plot. Here is exactly what I am doing:
> >
> > ipython --pylab
> >
> > x=arange(10)
> > y=x**2
> >
> > figure()
> > plot(x,y)
> > show()
> >
> > Also, I am not sure if that is right.  In the past I remember just
> > being able to type plot() and the figure came up and control went
> > back to ipython to continue.  But I could be wrong.
> >
> > Then, if I want to do anything else, I have to close the window.
> > The backend I am using is WXAgg.  I also noticed that if I use the
> > GTKAgg backend, control does not return to the prompt even after
> > closing the plot.  I have to hit ctl-c to get the prompt back.  I
> > have tried this both with ion() and ioff().
> >
> > I don't ever remember having to close the plot or hit control-c to
> > keep working.  I googled and did not really see anything relevant.
> > Could anyone tell me what I am missing or what I need to do so that
> > I can plot in ipython, leave the plot up, and then continue working?
> >
> > I have matplotlib 1.0.0 and ipython 0.10.1
> >
> > Thanks for any help!
> >
> >
> Most likely, you were used to interactive mode being on.  A new
> installation of matplotlib might have over-written your matplotlibrc
> file, resetting the option to False.  Find your matplotlibrc file and
> change interactive to True to get the behavior you want.
> 
> I hope that helps!
> 
> Ben Root

Sorry - I should have replied to all to continue the thread on the
forum....

Begin forwarded message:

Date: Wed, 17 Nov 2010 18:22:25 -0700
From: Collin Day <dcd...@gm...>
To: Benjamin Root <ben...@ou...>
Subject: Re: [Matplotlib-users] Control of thread/program not returning
to ipython after creating a plot.


On Wed, 17 Nov 2010 19:00:54 -0600
Benjamin Root <ben...@ou...> wrote:

I tried that - same results.  I did continue to try different backends
- TkAgg lets me call figure(), pulls up an empty figure and then I call
  plot(x,y) and the plot appears as expected.  That backend is fine
  with me, but I am wondering if I have found a bug or some sort of
  interaction with GTK and / or wx.  Here are snippets
  from /etc/matplotlib/matplotlibrc (when it doesn't work)

backend      : WXAgg

# if you are runing pyplot inside a GUI and your backend choice
# conflicts, we will automatically try and find a compatible one for
# you if backend_fallback is True
#backend_fallback: True
interactive  : True 

so I have interactive set.

-C




> On Wed, Nov 17, 2010 at 6:54 PM, Collin Day <dcd...@gm...>
> wrote:
> 
> > Either I updated something that changed Matplotlib's behavior or I
> > am missing something, but when I make a plot in ipython, control is
> > not returning to the prompt - I can't do anything until I close the
> > plot. Here is exactly what I am doing:
> >
> > ipython --pylab
> >
> > x=arange(10)
> > y=x**2
> >
> > figure()
> > plot(x,y)
> > show()
> >
> > Also, I am not sure if that is right.  In the past I remember just
> > being able to type plot() and the figure came up and control went
> > back to ipython to continue.  But I could be wrong.
> >
> > Then, if I want to do anything else, I have to close the window.
> > The backend I am using is WXAgg.  I also noticed that if I use the
> > GTKAgg backend, control does not return to the prompt even after
> > closing the plot.  I have to hit ctl-c to get the prompt back.  I
> > have tried this both with ion() and ioff().
> >
> > I don't ever remember having to close the plot or hit control-c to
> > keep working.  I googled and did not really see anything relevant.
> > Could anyone tell me what I am missing or what I need to do so that
> > I can plot in ipython, leave the plot up, and then continue working?
> >
> > I have matplotlib 1.0.0 and ipython 0.10.1
> >
> > Thanks for any help!
> >
> >
> Most likely, you were used to interactive mode being on.  A new
> installation of matplotlib might have over-written your matplotlibrc
> file, resetting the option to False.  Find your matplotlibrc file and
> change interactive to True to get the behavior you want.
> 
> I hope that helps!
> 
> Ben Root

On Wed, Nov 17, 2010 at 6:54 PM, Collin Day <dcd...@gm...> wrote:

> Either I updated something that changed Matplotlib's behavior or I am
> missing something, but when I make a plot in ipython, control is not
> returning to the prompt - I can't do anything until I close the plot.
> Here is exactly what I am doing:
>
> ipython --pylab
>
> x=arange(10)
> y=x**2
>
> figure()
> plot(x,y)
> show()
>
> Also, I am not sure if that is right.  In the past I remember just being
> able to type plot() and the figure came up and control went back to
> ipython to continue.  But I could be wrong.
>
> Then, if I want to do anything else, I have to close the window.  The
> backend I am using is WXAgg.  I also noticed that if I use the GTKAgg
> backend, control does not return to the prompt even after closing the
> plot.  I have to hit ctl-c to get the prompt back.  I have tried this
> both with ion() and ioff().
>
> I don't ever remember having to close the plot or hit control-c to keep
> working.  I googled and did not really see anything relevant.  Could
> anyone tell me what I am missing or what I need to do so that I can
> plot in ipython, leave the plot up, and then continue working?
>
> I have matplotlib 1.0.0 and ipython 0.10.1
>
> Thanks for any help!
>
>
Most likely, you were used to interactive mode being on.  A new installation
of matplotlib might have over-written your matplotlibrc file, resetting the
option to False.  Find your matplotlibrc file and change interactive to True
to get the behavior you want.

I hope that helps!

Ben Root

Either I updated something that changed Matplotlib's behavior or I am
missing something, but when I make a plot in ipython, control is not
returning to the prompt - I can't do anything until I close the plot.
Here is exactly what I am doing:

ipython --pylab

x=arange(10)
y=x**2

figure()
plot(x,y)
show()

Also, I am not sure if that is right.  In the past I remember just being
able to type plot() and the figure came up and control went back to
ipython to continue.  But I could be wrong.

Then, if I want to do anything else, I have to close the window.  The
backend I am using is WXAgg.  I also noticed that if I use the GTKAgg
backend, control does not return to the prompt even after closing the
plot.  I have to hit ctl-c to get the prompt back.  I have tried this
both with ion() and ioff().

I don't ever remember having to close the plot or hit control-c to keep
working.  I googled and did not really see anything relevant.  Could
anyone tell me what I am missing or what I need to do so that I can
plot in ipython, leave the plot up, and then continue working?

I have matplotlib 1.0.0 and ipython 0.10.1

Thanks for any help!

On Wed, Nov 17, 2010 at 5:37 PM, Eric Firing <ef...@ha...> wrote:

> On 11/17/2010 01:28 PM, Ognjen Ilic wrote:
> > Thanks for the help. However, when I change the matplotlibrc file I
> > get the following message
> > "Bad key "path.simplify" on line 267 in
> > /HOME/.matplotlib/matplotlibrc.
> > You probably need to get an updated matplotlibrc file from
> > http://matplotlib.sf.net/matplotlibrc or from the matplotlib source
> > distribution"
> >
> > I'd do the update but I don't have root access on the server
>
> It sounds like you have an old enough version of mpl that it does not
> support rc configuration of the path simplification.  If so, your only
> option is to update mpl itself.  It should be possible to build and
> install a local copy without root access, and put its location in your
> PYTHONPATH.
>
> Eric
>
>
A really simple way to do this is (from the terminal in the matplotlib
directory):

python setupegg.py install --user

Everything gets installed to your .local directory and your python
installation should find it without problems.

Ben Root

On 11/17/2010 01:28 PM, Ognjen Ilic wrote:
> Thanks for the help. However, when I change the matplotlibrc file I
> get the following message
> "Bad key "path.simplify" on line 267 in
> /HOME/.matplotlib/matplotlibrc.
> You probably need to get an updated matplotlibrc file from
> http://matplotlib.sf.net/matplotlibrc or from the matplotlib source
> distribution"
>
> I'd do the update but I don't have root access on the server

It sounds like you have an old enough version of mpl that it does not 
support rc configuration of the path simplification.  If so, your only
option is to update mpl itself.  It should be possible to build and 
install a local copy without root access, and put its location in your 
PYTHONPATH.

Eric

>
>
> On Wed, Nov 17, 2010 at 1:20 PM, Eric Firing<ef...@ha...>  wrote:
>> On 11/17/2010 07:35 AM, Ognjen Ilic wrote:
>>> Hello all,
>>>
>>> I posted about this problem on another forum (with an image attachment)
>>> http://python-forum.org/pythonforum/viewtopic.php?f=18&t=21951&p=99290#p99290
>>>
>>> In the figure below white space that forms a trapezoid to the right
>>> (slope then constant) and tear-shape white space to the left (due to
>>> maxZ being too small) are expected and I have no issues with that.
>>> The weird things are the sharp white shapes to the left. They are very
>>> irregular and with a little different change in parameters they appear
>>> at different places.
>>
>> This looks like the path simplification bug that was fixed some time
>> before mpl 1.0.  You can upgrade, or as a workaround you can turn off
>> path simplification by putting
>>
>> path.simplify : False
>>
>> in your matplotlibrc file, or by using
>> matplotlib.rcParams['path.simplify'] = False
>> in your script.
>>
>> Eric
>>
>>>
>>> Below are the relevant pieces of code
>>>
>>> Code: Select all
>>>       import matplotlib.pyplot as plt
>>>       import matplotlib.colors as colors
>>>       ...
>>>       z = numpy.transpose(z)
>>>       z = numpy.ma.masked_where(z<=0, z)
>>>       levels = numpy.linspace(0,maxZ,50)
>>>       cset1=plt.contourf(x,y,z,levels,cmap=plt.get_cmap('jet',len(levels)-1))
>>>       plt.colorbar(cset1)
>>>       fname = 'pic.png'
>>>       plt.savefig(fname)
>>>
>>>
>>>
>>> Above, z is the 2D array of values for different x and y (both lists
>>> have 400 elements each).
>>> Ths is really really confusing me. Any help is greatly appreciated!

Thanks for the help. However, when I change the matplotlibrc file I
get the following message
"Bad key "path.simplify" on line 267 in
/HOME/.matplotlib/matplotlibrc.
You probably need to get an updated matplotlibrc file from
http://matplotlib.sf.net/matplotlibrc or from the matplotlib source
distribution"

I'd do the update but I don't have root access on the server


On Wed, Nov 17, 2010 at 1:20 PM, Eric Firing <ef...@ha...> wrote:
> On 11/17/2010 07:35 AM, Ognjen Ilic wrote:
>> Hello all,
>>
>> I posted about this problem on another forum (with an image attachment)
>> http://python-forum.org/pythonforum/viewtopic.php?f=18&t=21951&p=99290#p99290
>>
>> In the figure below white space that forms a trapezoid to the right
>> (slope then constant) and tear-shape white space to the left (due to
>> maxZ being too small) are expected and I have no issues with that.
>> The weird things are the sharp white shapes to the left. They are very
>> irregular and with a little different change in parameters they appear
>> at different places.
>
> This looks like the path simplification bug that was fixed some time
> before mpl 1.0.  You can upgrade, or as a workaround you can turn off
> path simplification by putting
>
> path.simplify : False
>
> in your matplotlibrc file, or by using
> matplotlib.rcParams['path.simplify'] = False
> in your script.
>
> Eric
>
>>
>> Below are the relevant pieces of code
>>
>> Code: Select all
>>      import matplotlib.pyplot as plt
>>      import matplotlib.colors as colors
>>      ...
>>      z = numpy.transpose(z)
>>      z = numpy.ma.masked_where(z<=0, z)
>>      levels = numpy.linspace(0,maxZ,50)
>>      cset1=plt.contourf(x,y,z,levels,cmap=plt.get_cmap('jet',len(levels)-1))
>>      plt.colorbar(cset1)
>>      fname = 'pic.png'
>>      plt.savefig(fname)
>>
>>
>>
>> Above, z is the 2D array of values for different x and y (both lists
>> have 400 elements each).
>> Ths is really really confusing me. Any help is greatly appreciated!
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Beautiful is writing same markup. Internet Explorer 9 supports
>> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2&  L3.
>> Spend less time writing and  rewriting code and more time creating great
>> experiences on the web. Be a part of the beta today
>> http://p.sf.net/sfu/msIE9-sfdev2dev
>>
>>
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Wed, Nov 17, 2010 at 1:54 PM, Eric Emsellem <eem...@es...> wrote:

> Dear Ben
> thanks a lot for this thoughful answer.
>
>
> When I use only "ipython" and not "ipython -pylab" IT WORKS!!!
>
> So this is a problem with "ipython -pylab" call...
> Any thought of why this is?
>
>
Possibly ipython is somehow configured to pull pylab from a different
location, thereby loading a different matplotlib (and under a different
name) from what mplot3d loads.  Remember, python loads modules only once
during an execution, regardless of the number of times an import statement
appears.  With ipython -pylab, it implicitly does these loads for you
(except for mplot3d because it is a separate toolkit).  If ipython was
explicitly configured to look elsewhere for pylab, and then you come along
and tell it to import mplot3d using the normal python search path, it
*might* be possible that different matplotlibs got loaded.  Again, though,
this is complete and utter speculation, and has little basis in fact nor
evidence.



> I provide more info below
>
> thanks for any help there.
>
> Eric
>
> P.S.: Here is the output of my setup:
>
> In [1]: matplotlib.__file__
> Out[1]: '/usr/lib64/python2.6/site-packages/matplotlib/__init__.pyc'
>
> In [6]: mpl_toolkits.mplot3d.__file__
> Out[6]:
> '/usr/lib64/python2.6/site-packages/mpl_toolkits/mplot3d/__init__.pyc'
>
>
Clarity is important here.  Was this the same regardless of using '-pylab'?
Also, if you run "ipython -pylab", what is the value of pylab.__file__ and
how does it compare to matplotlib.__file__ and
mpl_toolkits.mplot3d.__file__?


> A funny one is that I have to import mpl_toolkits first and then mplot3d,
> and
> when I do this I get:
> In [5]: from mpl_toolkits import mplot3d
> try this
>
> I am not sure the "try this" is meant to be there....
>
>
It isn't, but I can not find it anywhere in the source files.  I have
checked the source code for matplotlib from the OpenSUSE repos and from our
svn repos.  It does not exist.  That line must be coming from another
package or you may have forgotten you added it (this has happened to me
before).


>
> P.P.S.:
> Here is my detailed setup when I do ipython -pylab
>
> matplotlib data path /usr/lib64/python2.6/site-packages/matplotlib/mpl-data
> matplotlib version 1.0.0
> verbose.level helpful
> interactive is False
> units is False
> platform is linux2
> Your PyGtk has set_interactive(), so you can use the
> more stable single-threaded Gtk mode.
> See https://bugs.launchpad.net/ipython/+bug/270856
>
> backend GTKAgg version 2.17.0
> Python 2.6.5 (r265:79063, Jul  5 2010, 11:46:13)
>
>
> IPython 0.10 -- An enhanced Interactive Python.
>