Unknown projection '3d' even with svn version?

Hi,

I have just installed the svn version of matplotlib and basemap + numpy from the svn repository of
http://download.opensuse.org/repositories/home:/ocefpaf/openSUSE_11.3/x86_64/

When I do:

···

=======================================================
ipython -pylab
(matplotlib 1.0.0, backend GTKAgg version 2.17.0, openSuse 11.3 x86_64)

import numpy as np
from mpl_toolkits.mplot3d import Axes3D
import matplotlib.pyplot as plt

fig = plt.figure()
ax = fig.add_subplot(111, projection='3d')

I get a

ValueError: Unknown projection '3d'

I did the upgrade to the svn version because the previous one (which was already 1.0) gave me the same message...

what's wrong here?
(looked at the web and couldn't find out a good solution, beyond the upgrade I did)

thanks in advance
Eric

Eric,

Could you please execute the following:

import matplotlib
print matplotlib.version

and report back what it says? I suspect that when you installed the svn version, the original version of matplotlib is still getting loaded. The projection=‘3d’ feature is brand new to 1.0.0.

Ben Root

···

On Tue, Nov 16, 2010 at 10:48 AM, Eric Emsellem <eemselle@…3352…> wrote:

Hi,

I have just installed the svn version of matplotlib and basemap + numpy from the

svn repository of

http://download.opensuse.org/repositories/home:/ocefpaf/openSUSE_11.3/x86_64/

When I do:

=======================================================

ipython -pylab

(matplotlib 1.0.0, backend GTKAgg version 2.17.0, openSuse 11.3 x86_64)

import numpy as np

from mpl_toolkits.mplot3d import Axes3D

import matplotlib.pyplot as plt

fig = plt.figure()

ax = fig.add_subplot(111, projection=‘3d’)

========================================================

I get a

ValueError: Unknown projection ‘3d’

I did the upgrade to the svn version because the previous one (which was already

1.0) gave me the same message…

what’s wrong here?

(looked at the web and couldn’t find out a good solution, beyond the upgrade I did)

thanks in advance

Eric

Dear Ben

thanks a lot for the quick reply.

I did that (and read some posts on the web) but no luck, as it says:

1.0.0

I in fact just went back to my openSuse 11.3 (Science repo) version because it went really wrong with scipy etc and I didn't want to mess up my setup. But still the same message with the Unknown projection.

I have checked the axes3d.py in my mpl_toolkits and it has the "name = '3d'" at the beginning and the register at the end...

???

Eric

···

Could you please execute the following:

import matplotlib
print matplotlib.__version__

and report back what it says? I suspect that when you installed the svn
version, the original version of matplotlib is still getting loaded.
The projection='3d' feature is brand new to 1.0.0.

Ben Root

Strange indeed. Ok, what does matplotlib.file say? Does the filename match the path you are expecting? At this point, I would also try putting print statements in the register code at the end of axes3d.py to see if that code path gets executed (can’t see why not).

Ben Root

···

On Tue, Nov 16, 2010 at 11:24 AM, Eric Emsellem <eemselle@…3352…> wrote:

Dear Ben

thanks a lot for the quick reply.

I did that (and read some posts on the web) but no luck, as it says:

1.0.0

I in fact just went back to my openSuse 11.3 (Science repo) version because it went really wrong with scipy etc and I didn’t want to mess up my setup. But still the same message with the Unknown projection.

I have checked the axes3d.py in my mpl_toolkits and it has the “name = ‘3d’” at the beginning and the register at the end…

???

Eric

Could you please execute the following:

import matplotlib

print matplotlib.version

and report back what it says? I suspect that when you installed the svn

version, the original version of matplotlib is still getting loaded.

The projection=‘3d’ feature is brand new to 1.0.0.

Ben Root

yes, it looks like this is the right file (when I look at matplotlib.__file__)

Now tracing which routines are run when doing this, it looks like it looks for
projection in projections/__init__.py
after going through line 675 of figure.py

It looks like add_subplot of plt.figure() is not compatible in my matplotlib.

Eric

···

Strange indeed. Ok, what does matplotlib.__file__ say? Does the
filename match the path you are expecting? At this point, I would also
try putting print statements in the register code at the end of
axes3d.py to see if that code path gets executed (can't see why not).

Ben Root

No, that code path is correct. The problem has to be that the registration is not occurring correctly. I would double-check that the filepath for matplotlib.file and mpl_toolkits.mplot3d.file matches. I am still convinced that we have an installation issue. My bet is that – somehow – mplot3d is being loaded from one version, while matplotlib is being loaded from another version.

Another thing that might be complicating things is the use of ipython -pylab. If you aren’t using pylab, then there really isn’t much need to call that. Did you fully un-install matplotlib before building matplotlib from svn? If not, you might need to do a complete clean (package-wise and build-wise) before trying again.

I notice that you are using OpenSUSE. We have been having a number of reports of problems from OpenSUSE users in the past month. Almost all of them appear to be packaging issues and not problems with matplotlib itself. I don’t know if this is the case here, but who knows?

I find this error to be fairly odd given how simple and fundamental the algorithm is. It is essentially a python dictionary containing name/class pairs. Kinda hard to break that. If you can verify that the Axes3D object is registering itself, and then the projection can’t be found later, then there remains only two possibilities. First, that the dictionary being checked is different from the dictionary used to register the Axes3D class. Second, that the Axes3D entry got removed after being inserted.

Considering that I am unaware of any code that deregisters a projection, I am inclined to believe that somehow we have different dictionary objects being accessed. This is the basis for my theory that the matplotlib installation is wonky because the matplotlib.pyplot that you import from your script might – somehow – be different from the matplotlib that is imported from mplot3d.

Again, it makes little sense, but that is what is going through my mind right now. Anybody else have any thoughts?

Ben Root

···

On Wed, Nov 17, 2010 at 2:32 AM, Eric Emsellem <eemselle@…3246…> wrote:

yes, it looks like this is the right file (when I look at matplotlib.file)

Now tracing which routines are run when doing this, it looks like it looks for

projection in projections/init.py

after going through line 675 of figure.py

It looks like add_subplot of plt.figure() is not compatible in my matplotlib.

Eric

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?

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'

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....

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.

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).

···

On Wed, Nov 17, 2010 at 1:54 PM, Eric Emsellem <eemselle@…3246…> wrote:

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.

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

Glad to be of help. Most of the time, odd behaviors like this tend to be the result of conflicting installations. Digging through them tends to be difficult, but a very educating experience.

Ben Root

···

On Thu, Nov 18, 2010 at 2:30 AM, Eric Emsellem <eemselle@…3246…> wrote:

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