Drawing a single contour line

Ah, I was a little confused by what you wrote John (I though I had to
access contour through the axes object and the meaning of R, F, dR was
a little unclear..) however using the 'levels' keyword now works. i.e.

plt.contour(x, y, z, levels=[0])

Incidentally, this keyword (levels) is not documented at
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.contour
and in fact the documentation implies that contour(kx, ky, z, [0])
should work when it does not.

Perhaps the docs could be updated to reflect this?

Brendan

···

On Tue, Nov 3, 2009 at 2:19 PM, Brendan Arnold <brendanarnold@...287...> wrote:

Hi again,

Thanks for the responses, however neither work, the error still
persists. Here are more details...

Traceback (most recent call last):
File "C:\Program Files\Python\2.5\lib\lib-tk\Tkinter.py", line 1403,
in __call__
return self.func(*args)
File "C:\Program
Files\Python\2.5\lib\site-packages\matplotlib\backends\backend_tkagg.py",
line 212, in resize
self.show()
File "C:\Program
Files\Python\2.5\lib\site-packages\matplotlib\backends\backend_tkagg.py",
line 215, in draw
FigureCanvasAgg.draw(self)
File "C:\Program
Files\Python\2.5\lib\site-packages\matplotlib\backends\backend_agg.py",
line 314, in draw
self.figure.draw(self.renderer)
File "C:\Program
Files\Python\2.5\lib\site-packages\matplotlib\artist.py", line 46, in
draw_wrapper
draw(artist, renderer, *kl)
File "C:\Program
Files\Python\2.5\lib\site-packages\matplotlib\figure.py", line 773, in
draw
for a in self.axes: a.draw(renderer)
File "C:\Program
Files\Python\2.5\lib\site-packages\matplotlib\artist.py", line 46, in
draw_wrapper
draw(artist, renderer, *kl)
File "C:\Program
Files\Python\2.5\lib\site-packages\matplotlib\axes.py", line 1735, in
draw
a.draw(renderer)
File "C:\Program
Files\Python\2.5\lib\site-packages\matplotlib\text.py", line 515, in
draw
bbox, info = self._get_layout(renderer)
File "C:\Program
Files\Python\2.5\lib\site-packages\matplotlib\text.py", line 257, in
_get_layout
if key in self.cached: return self.cached[key]
TypeError: unhashable type: 'numpy.ndarray'

matplotlib.__version__

'0.99.1'

numpy.__version__

'1.3.0'

Python version 2.5

the code in full is as follows,

import matplotlib
import numpy as np
import matplotlib.cm as cm
import matplotlib.mlab as mlab
import matplotlib.pyplot as plt

# Set some model parameters
model_points = 10000
t0 = 0.38
t1 = 0.32*t0
t2 = 0.5*t1

def energy(kx, ky):
'''Energy function, evetually this will be provided by raw data
from WIEN2k'''
return -2*t0*(np.cos(kx)+np.cos(ky)) \
+ 4*t1*np.cos(kx)*np.cos(ky) \
- 2*t2*(np.cos(2*kx)+np.cos(2*ky))

def shift_energy_up(energy_val, dE):
'''Shifts the energy according to a gap'''
return energy_val + np.sqrt(energy_val**2 + dE**2)

def shift_energy_dn(energy_val, dE):
'''Shifts the energy down according to an energy'''
return energy_val - np.sqrt(energy_val**2 + dE**2)

kx = np.arange(0, 2*np.pi, 2*np.pi/np.sqrt(model_points))
ky = np.arange(0, 2*np.pi, 2*np.pi/np.sqrt(model_points))
mgx, mgy = np.meshgrid(kx, ky)
z = energy(mgx, mgy)

# Set the ticks to go outwards
matplotlib.rcParams['xtick.direction'] = 'out'
matplotlib.rcParams['ytick.direction'] = 'out'

plt.figure()
CS = plt.contour(kx, ky, z, [0, 0])
plt.clabel(CS, inline=1, fontsize=10)
plt.title('Simplest default with labels')
plt.show()

kind regards,

Brendan

On Mon, Nov 2, 2009 at 9:33 PM, Pierre de Buyl <pdebuyl@...2144...> wrote:

From memory, you just need to make a length one list

contour(z, [i])

Pierre

Le 2 nov. 09 à 22:19, Brendan Arnold a écrit :

Hi there,

I can draw a single contour line in MATLAB using

contour(z, [i i])

however,

contour(z, [i, i])

using matplotlib gives an error. In fact any plot that plots a single
line (i.e. contour(z, 1)) also gives an error as follows,

TypeError: unhashable type: 'numpy.ndarray'

How do I draw a single contour line using matplotlib?

regards,

Brendan

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

Thanks for the heads up -- I updated the docstring in svn HEAD

Sorry the original example was confusing -- I cut and pasted from some
code I was working on, and forgot to import the mindreading module

JDH

···

On Wed, Nov 4, 2009 at 11:16 AM, Brendan Arnold <brendanarnold@...287...> wrote:

Ah, I was a little confused by what you wrote John (I though I had to
access contour through the axes object and the meaning of R, F, dR was
a little unclear..) however using the 'levels' keyword now works. i.e.

plt.contour(x, y, z, levels=[0])

Incidentally, this keyword (levels) is not documented at
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.contour
and in fact the documentation implies that contour(kx, ky, z, [0])
should work when it does not.

Perhaps the docs could be updated to reflect this?

John Hunter wrote:

Ah, I was a little confused by what you wrote John (I though I had to
access contour through the axes object and the meaning of R, F, dR was
a little unclear..) however using the 'levels' keyword now works. i.e.

plt.contour(x, y, z, levels=[0])

Incidentally, this keyword (levels) is not documented at
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.contour
and in fact the documentation implies that contour(kx, ky, z, [0])
should work when it does not.

But it does work, as it should:

x = arange(5)
y = arange(7)
X, Y = meshgrid(x,y)
z = X+Y
contour(X, Y, z, [5])

Drop the above into "ipython -pylab".

Eric

···

On Wed, Nov 4, 2009 at 11:16 AM, Brendan Arnold <brendanarnold@...287...> wrote:

Perhaps the docs could be updated to reflect this?

Thanks for the heads up -- I updated the docstring in svn HEAD

Sorry the original example was confusing -- I cut and pasted from some
code I was working on, and forgot to import the mindreading module

JDH

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

I've been using matplotlib and numpy happily and have gone to install basemap.

As part of the basemap 0.99.4 install, I've compiled geos-2.2.3 and installed into /usr/local/ - no apparent problems

I then ran >python setup.py install from the basemap directory. No issues that I could see.

However, when trying the import I get:

Python 2.6.3 (r263:75184, Oct 2 2009, 07:56:03)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from mpl_toolkits.basemap import Basemap
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/mpl_toolkits/basemap/__init__.py", line 43, in <module>
     import _geoslib, netcdftime
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/_geoslib.so, 2): Symbol not found: _GEOSArea
   Referenced from: /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/_geoslib.so
   Expected in: dynamic lookup

Does basemap build ok on OS X 10.6 or are there some gotcha's I'm not aware of?

Tim

Tim Burgess wrote:

I've been using matplotlib and numpy happily and have gone to install basemap.

As part of the basemap 0.99.4 install, I've compiled geos-2.2.3 and installed into /usr/local/ - no apparent problems

I then ran >python setup.py install from the basemap directory. No issues that I could see.

However, when trying the import I get:

Python 2.6.3 (r263:75184, Oct 2 2009, 07:56:03)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from mpl_toolkits.basemap import Basemap
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ python2.6/site-packages/mpl_toolkits/basemap/__init__.py", line 43, in <module>
     import _geoslib, netcdftime
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.6/ lib/python2.6/site-packages/_geoslib.so, 2): Symbol not found: _GEOSArea
   Referenced from: /Library/Frameworks/Python.framework/Versions/2.6/ lib/python2.6/site-packages/_geoslib.so
   Expected in: dynamic lookup

Does basemap build ok on OS X 10.6 or are there some gotcha's I'm not aware of?

It should be fine. It looks like a geoslib other than the one you installed in /usr/local is the one being found.

Eric

Tim Burgess wrote:

I've been using matplotlib and numpy happily and have gone to install basemap.

As part of the basemap 0.99.4 install, I've compiled geos-2.2.3 and installed into /usr/local/ - no apparent problems

I then ran >python setup.py install from the basemap directory. No issues that I could see.

However, when trying the import I get:

Python 2.6.3 (r263:75184, Oct 2 2009, 07:56:03)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from mpl_toolkits.basemap import Basemap
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ python2.6/site-packages/mpl_toolkits/basemap/__init__.py", line 43, in <module>
     import _geoslib, netcdftime
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.6/ lib/python2.6/site-packages/_geoslib.so, 2): Symbol not found: _GEOSArea
   Referenced from: /Library/Frameworks/Python.framework/Versions/2.6/ lib/python2.6/site-packages/_geoslib.so
   Expected in: dynamic lookup

Does basemap build ok on OS X 10.6 or are there some gotcha's I'm not aware of?

Tim

Tim: I don't have 10.6 yet, so I've never tried building there. I suspect that it's a 32/64 bit library mismatch problem. Since I believe OSX builds stuff 64 bit by default on OS X, my guess is you are using a 32 bit python, perhaps macpython? If so, perhaps building geos with CFLAGS="-m32" will fix it. Or, it could be that you have a 64 bit python and the lib was built 32 bit.

Maybe someone else with experience with 10.6 will chime in, I'm really just shooting in the dark here..

-Jeff

-Jeff

Eric Firing wrote:

Tim Burgess wrote:
  

I've been using matplotlib and numpy happily and have gone to install basemap.

As part of the basemap 0.99.4 install, I've compiled geos-2.2.3 and installed into /usr/local/ - no apparent problems

I then ran >python setup.py install from the basemap directory. No issues that I could see.

However, when trying the import I get:

Python 2.6.3 (r263:75184, Oct 2 2009, 07:56:03)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from mpl_toolkits.basemap import Basemap
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ python2.6/site-packages/mpl_toolkits/basemap/__init__.py", line 43, in <module>
     import _geoslib, netcdftime
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.6/ lib/python2.6/site-packages/_geoslib.so, 2): Symbol not found: _GEOSArea
   Referenced from: /Library/Frameworks/Python.framework/Versions/2.6/ lib/python2.6/site-packages/_geoslib.so
   Expected in: dynamic lookup

Does basemap build ok on OS X 10.6 or are there some gotcha's I'm not aware of?
    
It should be fine. It looks like a geoslib other than the one you installed in /usr/local is the one being found.

Eric

Tim: If that's the case, setting GEOS_DIR=/usr/local and building again (after deleting the build directory) should fix it.

-Jeff

Tim: I don’t have 10.6 yet, so I’ve never tried building there. I suspect that it’s a 32/64 bit library mismatch problem. Since I believe OSX builds stuff 64 bit by default on OS X, my guess is you are using a 32 bit python, perhaps macpython? If so, perhaps building geos with CFLAGS=“-m32” will fix it. Or, it could be that you have a 64 bit python and the lib was built 32 bit.

Maybe someone else with experience with 10.6 will chime in, I’m really just shooting in the dark here…

Thanks Jeff and Eric,

Problem is now (mostly) solved.

I was using 32bit Python 2.6.3 on OS X 10.5 - simply a python.org installation. A couple of days ago, with a bit of free time, I upgraded to OS X 10.6. Generally pretty smooth, but I suspect some of my Python changes got crushed as I had pointed /usr/bin/python* to my 2.6.3 install. After your emails, I checked and yes on 10.6, the compiler defaults to 64bit. So:

cd geos-2.2.3

export CFLAGS=“-m32”

export GEOS_DIR=/usr/local

./configure --prefix=$GEOS_DIR

make

sudo make install

Another complete build but unfortunately same library reference problem.

So…decided to go down the MacPorts path. Many automated downloads later, I now have a successful Basemap install (yay!)

Many thanks to the folks who have contributed to MacPorts and interestingly geos 3.1.1 is installed.

Only present worry is that wxWidgets port is not building on 10.6 - yet to resolve that.

And FYI, to check whether you have a 64bit Python install:

192-168-1-3:basemap-0.99.4 tim$ python

Python 2.6.4 (r264:75706, Nov 6 2009, 18:14:21)

[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin

Type “help”, “copyright”, “credits” or “license” for more information.

import sys; print sys.maxint

9223372036854775807

if you get a smaller number, you have a 32bit interpreter

P.S. Should simpletest.py not be called ‘hello_world.py’ :slight_smile:

Tim Burgess

Tim Burgess wrote:

So....decided to go down the MacPorts path. Many automated downloads later, I now have a successful Basemap install (yay!)
Many thanks to the folks who have contributed to MacPorts and interestingly geos 3.1.1 is installed.

Is it 64 bit now. If so...

Only present worry is that wxWidgets port is not building on 10.6 - yet to resolve that.

wxWidgets/wxPython can not be built (for the Mac) 64 bit. It is built on Carbon, which Apple has not and will not port to 64 bit. There is a Cocoa version of wxMac, but it's not done yet, and has not been wrapped for Python.

You may be able to get a 64bit GTK/X11 wxPython working with MacPorts -- I've never tried that.

And FYI, to check whether you have a 64bit Python install:
>>> import sys; print sys.maxint
9223372036854775807

So it looks like you are running 64 bit -- what a pain this all is.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...

Yes, I'm running all 64bit now. Can't say I'm seeing dramatic performance improvements as I haven't done much in basemap in 32bit to compare.

I did find a couple of problems with the current MacPort basemap. I could create a Basemap object with a resolution of 'c' but specifying a resolution of 'i' caused a program failure.
And the example 'warpimage.py' failed to run as well.

The error wasn't obvious to my eye so I simply did an svn checkout and built the code into an .egg and then did an /opt/local/bin/easy_install-2.6 basemap-0.99.5-py2.6-macosx-10.6-i386.egg

I can now use the higher resolution option and warpimage.py all runs fine.

As for wxWidgets, there is some pain there. Pierre GM (thanks!) made the suggestion of simply using the MacOSX matplotlib backend and so problem neatly side-stepped (for me at least).

···

On 10/11/2009, at 3:37 AM, Christopher Barker wrote:

Tim Burgess wrote:

So....decided to go down the MacPorts path. Many automated downloads later, I now have a successful Basemap install (yay!)
Many thanks to the folks who have contributed to MacPorts and interestingly geos 3.1.1 is installed.

Is it 64 bit now. If so...

Only present worry is that wxWidgets port is not building on 10.6 - yet to resolve that.

wxWidgets/wxPython can not be built (for the Mac) 64 bit. It is built on Carbon, which Apple has not and will not port to 64 bit. There is a Cocoa version of wxMac, but it's not done yet, and has not been wrapped for Python.

You may be able to get a 64bit GTK/X11 wxPython working with MacPorts -- I've never tried that.

And FYI, to check whether you have a 64bit Python install:
>>> import sys; print sys.maxint
9223372036854775807

So it looks like you are running 64 bit -- what a pain this all is.

-Chris

~~~~~~~~~~~~~~
Tim Burgess

Software Engineer - Coral Reef Watch
Satellite Applications and Research - NESDIS
National Oceanic and Atmospheric Administration
http://www.coralreefwatch.noaa.gov
675 Ross River Rd, Kirwan QLD Australia 4817
tim.burgess@...259...
Ph +61-7-47551811
Fax +61-7-47551822

Hmm, after a little more work it seems that the problem is actually
with the 'clabel' command. To expand on Eric's example,

x = arange(5)
y = arange(7)
X, Y = meshgrid(x,y)
z = X+Y
c=contour(X, Y, z, [5])
clabel(c, inline=1)

(causes exceptions in a fresh ipython session)

clabel causes problems if only a single contour level is specified and returned.

Maybe this is a bug?

Kind regards,

Brendan

···

On Wed, Nov 4, 2009 at 6:01 PM, Eric Firing <efiring@...202...> wrote:

John Hunter wrote:

On Wed, Nov 4, 2009 at 11:16 AM, Brendan Arnold <brendanarnold@...287...> >> wrote:

Ah, I was a little confused by what you wrote John (I though I had to
access contour through the axes object and the meaning of R, F, dR was
a little unclear..) however using the 'levels' keyword now works. i.e.

plt.contour(x, y, z, levels=[0])

Incidentally, this keyword (levels) is not documented at

http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.contour
and in fact the documentation implies that contour(kx, ky, z, [0])
should work when it does not.

But it does work, as it should:

x = arange(5)
y = arange(7)
X, Y = meshgrid(x,y)
z = X+Y
contour(X, Y, z, [5])

Drop the above into "ipython -pylab".

Eric

Perhaps the docs could be updated to reflect this?

Thanks for the heads up -- I updated the docstring in svn HEAD

Sorry the original example was confusing -- I cut and pasted from some
code I was working on, and forgot to import the mindreading module

JDH

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day trial. Simplify your report design, integration and deployment - and
focus on what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

Brendan Arnold wrote:

Hmm, after a little more work it seems that the problem is actually
with the 'clabel' command. To expand on Eric's example,

x = arange(5)
y = arange(7)
X, Y = meshgrid(x,y)
z = X+Y
c=contour(X, Y, z, [5])
clabel(c, inline=1)

(causes exceptions in a fresh ipython session)

clabel causes problems if only a single contour level is specified and returned.

Maybe this is a bug?

It certainly is. If no one comes up with a fix within a day or two, please file a ticket.

Eric

···

Kind regards,

Brendan

On Wed, Nov 4, 2009 at 6:01 PM, Eric Firing <efiring@...202...> wrote:

John Hunter wrote:

On Wed, Nov 4, 2009 at 11:16 AM, Brendan Arnold <brendanarnold@...287...> >>> wrote:

Ah, I was a little confused by what you wrote John (I though I had to
access contour through the axes object and the meaning of R, F, dR was
a little unclear..) however using the 'levels' keyword now works. i.e.

plt.contour(x, y, z, levels=[0])

Incidentally, this keyword (levels) is not documented at

http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.contour
and in fact the documentation implies that contour(kx, ky, z, [0])
should work when it does not.

But it does work, as it should:

x = arange(5)
y = arange(7)
X, Y = meshgrid(x,y)
z = X+Y
contour(X, Y, z, [5])

Drop the above into "ipython -pylab".

Eric

Perhaps the docs could be updated to reflect this?

Thanks for the heads up -- I updated the docstring in svn HEAD

Sorry the original example was confusing -- I cut and pasted from some
code I was working on, and forgot to import the mindreading module

JDH

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day trial. Simplify your report design, integration and deployment - and
focus on what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

Brendan Arnold wrote:

Hmm, after a little more work it seems that the problem is actually
with the 'clabel' command. To expand on Eric's example,

x = arange(5)
y = arange(7)
X, Y = meshgrid(x,y)
z = X+Y
c=contour(X, Y, z, [5])
clabel(c, inline=1)

(causes exceptions in a fresh ipython session)

clabel causes problems if only a single contour level is specified and returned.

Maybe this is a bug?

Fixed in svn 7970, 7971 (branch and trunk).

Eric