matplotlib-users Mailing List for matplotlib

Here are the Windows installer and egg produced by "setup.py 
bdist_wininst" respectively "setupegg.py bdist_egg":
<http://www.lfd.uci.edu/~gohlke/download/matplotlib-0.98.5.3.win32-py2.6.exe.zip>
<http://www.lfd.uci.edu/~gohlke/download/matplotlib-0.98.5.3_r0-py2.6-win32.egg.zip>
The installer worked for me. I have not run the unit tests.
Here's the build output:
============================================================================
BUILDING MATPLOTLIB
 matplotlib: 0.98.5.3
 python: 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC
 v.1500 32 bit (Intel)]
 platform: win32
 Windows version: (6, 0, 6002, 2, 'Service Pack 2')
REQUIRED DEPENDENCIES
 numpy: 1.3.0
 freetype2: found, but unknown version (no pkg-config)
 * WARNING: Could not find 'freetype2' headers 
in any
 * of '.', '.\freetype2'.
OPTIONAL BACKEND DEPENDENCIES
 libpng: found, but unknown version (no pkg-config)
 * Could not find 'libpng' headers in any of '.'
 Tkinter: no
 * Tkinter present, but header files are not found.
 * You may need to install development packages.
 wxPython: 2.8.10.1
 * WxAgg extension not required for wxPython >= 2.8
 Gtk+: no
 * Building for Gtk+ requires pygtk; you must be 
able
 * to "import gtk" in your build/install environment
 Mac OS X native: no
 Qt: no
 Qt4: Qt: 4.5.1, PyQt4: 4.5
 Cairo: 1.4.12
OPTIONAL DATE/TIMEZONE DEPENDENCIES
 datetime: present, version unknown
 dateutil: matplotlib will provide
 pytz: 2009d
OPTIONAL USETEX DEPENDENCIES
 dvipng: no
 ghostscript: no
 latex: no
 pdftops: no
[Edit setup.cfg to suppress the above messages]
============================================================================
Hope it helps.
Christoph
On 06/12/2009 12:45, John Hunter wrote:
> Thanks for this link -- the problem I am experiencing is specific to
> the mingw compiler suite, so the visual studio build should work fine.
> Would you be willing to build a bdist installer and an egg for us
> while we are trying to sort the mingw problems out -- I think all you
> need to do is pass bdist_wininst and bdist_egg to your build command.
>
> JDH
>
>

I switched back to using the macosx backend, and it turns out that the
thin black lines surrounding the polygons (including crossing the
filled contour regions from one closed contour to another) only get
displayed in the GUI. PDF and PNG output look fine.
Zane
On Fri, Jun 12, 2009 at 2:27 PM, Zane Selvans<za...@id...> wrote:
> If I set path.simplify: False, the shape of the gaps between the
> filled polygons does change. Instead of being irregular, it becomes
> an infinitessimally thin gap of uniform width, allowing the (in this
> case white) background to show through.
>
> In both of these cases (path.simplify: True|False), the PNG version of
> the same figures also show representations of these gaps which are
> identical to those which appear in the PDF (though obviously
> pixelated), so I don't think it's something that's wrong in the vector
> graphics code per se.
>
> Zane
>
> On Fri, Jun 12, 2009 at 11:46 AM, Michael Droettboom<md...@st...> wrote:
>> Shot in the dark here, but what if you set the rcParam "path.simplify" to
>> False? There have been recent changes to that code.
>>
>> Also, since the Agg backend doesn't have an associated GUI, you need to use
>> the savefig() command and provide a filename, rather than using show().
>>
>> Cheers,
>> Mike
>>
>> Zane Selvans wrote:
>>>
>>> Um, yeah. So my response got bounced because of the attachment. Take 2:
>>>
>>> For some reason my script bombed when I switched to the Agg backend,
>>> trying to display to the screen (it said Figure has no method show())
>>>
>>> So I output the plot as both a PDF and a PNG (still having backend:
>>> agg in my rcfile) and in both of those cases, irregular gaps are
>>> visible between the polygons making up the filled contours. This
>>> wasn't the case with my previously installed setup. It looks as if
>>> for some reason the vertices of the filled polygons are being
>>> calculated differently from different sides of the same contour,
>>> leading to overlap in some places, and gaps in others. You can download
>>> the PDF version (in which the exact geometry is much clearer).
>>> from:
>>>
>>> http://zaneselvans.org/dropbox/LinDensity_Grid.pdf
>>>
>>> Zane
>>>
>>> On Fri, Jun 12, 2009 at 5:51 AM, Michael Droettboom<md...@st...>
>>> wrote:
>>>
>>>>
>>>> So you see this behavior if you switch to the Agg backend? That's the
>>>> backend used to generate the images in the gallery. If there's a
>>>> difference
>>>> there, that would seem to suggest some tweaking of the macosx backend
>>>> (which
>>>> is still relatively new) is in order.
>>>>
>>>> Mike
>>>>
>>>> Zane Selvans wrote:
>>>>
>>>>>
>>>>> I just installed the latest SciPy Superpack in order to get access to
>>>>> the scipy.spatial.KDTree class, and discovered that for some reason
>>>>> now when I use contourf() lines get drawn at the boundaries between
>>>>> the filled contours. Additionally, there is always a single vertical
>>>>> line crossing from each contour boundary to the next. I'm guessing
>>>>> that these are the edges of the filled polygons which are getting
>>>>> drawn. This behavior doesn't seem to be consistent with the
>>>>> contourf() documentation and when I run code in griddata_demo.py it
>>>>> doesn't come out looking like the picture in the documentation/example
>>>>> gallery...
>>>>>
>>>>> Is anyone else seeing this behavior? Is there a keyword I can use to
>>>>> force the edges of the polygons not to get drawn?
>>>>>
>>>>> This is on Mac OS X 10.5.7, with
>>>>> scipy.__version__ = 0.8.0.dev5635
>>>>> matplotlib.__version__ = 0.98.6svn
>>>>> numpy.__version__=1.4.0.dev6728
>>>>>
>>>>> As installed by superpack_2009年03月28日.sh
>>>>> from http://macinscience.org/?page_id=6
>>>>>
>>>>> using:
>>>>> backend: macosx
>>>>>
>>>>> Cheers,
>>>>> Zane
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Michael Droettboom
>>>> Science Software Branch
>>>> Operations and Engineering Division
>>>> Space Telescope Science Institute
>>>> Operated by AURA for NASA
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>
>
>
> --
> Zane A. Selvans
> Amateur Earthling
> http://zaneselvans.org
> +1 303 815 6866
>
-- 
Zane A. Selvans
Amateur Earthling
http://zaneselvans.org
+1 303 815 6866

If I set path.simplify: False, the shape of the gaps between the
filled polygons does change. Instead of being irregular, it becomes
an infinitessimally thin gap of uniform width, allowing the (in this
case white) background to show through.
In both of these cases (path.simplify: True|False), the PNG version of
the same figures also show representations of these gaps which are
identical to those which appear in the PDF (though obviously
pixelated), so I don't think it's something that's wrong in the vector
graphics code per se.
Zane
On Fri, Jun 12, 2009 at 11:46 AM, Michael Droettboom<md...@st...> wrote:
> Shot in the dark here, but what if you set the rcParam "path.simplify" to
> False? There have been recent changes to that code.
>
> Also, since the Agg backend doesn't have an associated GUI, you need to use
> the savefig() command and provide a filename, rather than using show().
>
> Cheers,
> Mike
>
> Zane Selvans wrote:
>>
>> Um, yeah. So my response got bounced because of the attachment. Take 2:
>>
>> For some reason my script bombed when I switched to the Agg backend,
>> trying to display to the screen (it said Figure has no method show())
>>
>> So I output the plot as both a PDF and a PNG (still having backend:
>> agg in my rcfile) and in both of those cases, irregular gaps are
>> visible between the polygons making up the filled contours. This
>> wasn't the case with my previously installed setup. It looks as if
>> for some reason the vertices of the filled polygons are being
>> calculated differently from different sides of the same contour,
>> leading to overlap in some places, and gaps in others. You can download
>> the PDF version (in which the exact geometry is much clearer).
>> from:
>>
>> http://zaneselvans.org/dropbox/LinDensity_Grid.pdf
>>
>> Zane
>>
>> On Fri, Jun 12, 2009 at 5:51 AM, Michael Droettboom<md...@st...>
>> wrote:
>>
>>>
>>> So you see this behavior if you switch to the Agg backend? That's the
>>> backend used to generate the images in the gallery. If there's a
>>> difference
>>> there, that would seem to suggest some tweaking of the macosx backend
>>> (which
>>> is still relatively new) is in order.
>>>
>>> Mike
>>>
>>> Zane Selvans wrote:
>>>
>>>>
>>>> I just installed the latest SciPy Superpack in order to get access to
>>>> the scipy.spatial.KDTree class, and discovered that for some reason
>>>> now when I use contourf() lines get drawn at the boundaries between
>>>> the filled contours. Additionally, there is always a single vertical
>>>> line crossing from each contour boundary to the next. I'm guessing
>>>> that these are the edges of the filled polygons which are getting
>>>> drawn. This behavior doesn't seem to be consistent with the
>>>> contourf() documentation and when I run code in griddata_demo.py it
>>>> doesn't come out looking like the picture in the documentation/example
>>>> gallery...
>>>>
>>>> Is anyone else seeing this behavior? Is there a keyword I can use to
>>>> force the edges of the polygons not to get drawn?
>>>>
>>>> This is on Mac OS X 10.5.7, with
>>>> scipy.__version__ = 0.8.0.dev5635
>>>> matplotlib.__version__ = 0.98.6svn
>>>> numpy.__version__=1.4.0.dev6728
>>>>
>>>> As installed by superpack_2009年03月28日.sh
>>>> from http://macinscience.org/?page_id=6
>>>>
>>>> using:
>>>> backend: macosx
>>>>
>>>> Cheers,
>>>> Zane
>>>>
>>>>
>>>>
>>>
>>> --
>>> Michael Droettboom
>>> Science Software Branch
>>> Operations and Engineering Division
>>> Space Telescope Science Institute
>>> Operated by AURA for NASA
>>>
>>>
>>>
>>
>>
>>
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
-- 
Zane A. Selvans
Amateur Earthling
http://zaneselvans.org
+1 303 815 6866

Hi,
I think you mean:
>  mpl_toolkits.basemap.NetCDFFile("output.nc", mode='r', maskandscale=True,
> cache=None, mmap=True, username=None, password=None, verbose=False)
Note quotes round filename... Sorry, I missed those out in my previous mail.
Best,
Matthew

Hello, 
First let me say thank you for all of the help it is very appreciated. Your
suggestion to use the command import "import mpl_toolkits.basemap" has
worked, but now a new problem has popped up. 
Does the Netcdf file need to be in the same directory as the script I am
running to retrieve the file? I have moved the netcdf file to the same
location as the script and I get the following error. 
Traceback (most recent call last):
 File "/Users/interpott/Documents/trial.py", line 7, in <module>
 mpl_toolkits.basemap.NetCDFFile(output.nc, mode='r', maskandscale=True,
cache=None, mmap=True, username=None, password=None, verbose=False)
NameError: name 'output' is not defined
Any thoughts?
Thanks, 
Jon
Matthew Brett wrote:
> 
> Hi,
> 
> On Fri, Jun 12, 2009 at 10:52 AM, JPKay<ka...@va...> wrote:
>> from mpl_toolkits.basemap import Basemap
> 
> You have not so far imported mpl_toolkits into the namespace, only
> Basemap. You could do:
> 
> import mpl_toolkits.basemap
> 
> as another import line, or:
> 
> from mpl_toolkits.basemap import Basemap, NetCDFFile
> 
> followed by:
> 
> ncfile = NetCDFFile(output.nc, ...)
> 
> Best,
> 
> Matthew
> 
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 
-- 
View this message in context: http://www.nabble.com/Quiver-plot-of-a-netcdf-file-tp23986313p24005790.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Fri, Jun 12, 2009 at 2:20 PM, Christoph Gohlke<cg...@uc...> wrote:
> Hello,
>
> I have compiled Matplotlib 0.98.5.3 for Python 2.6 for Windows 32-bit
> using Visual Studio 2008. The build process was straightforward and the
> produced binaries work for me, specifically there is no crash in
> _png.pyd when writing PNG files.
Thanks for this link -- the problem I am experiencing is specific to
the mingw compiler suite, so the visual studio build should work fine.
 Would you be willing to build a bdist installer and an egg for us
while we are trying to sort the mingw problems out -- I think all you
need to do is pass bdist_wininst and bdist_egg to your build command.
JDH

Hello,
I have compiled Matplotlib 0.98.5.3 for Python 2.6 for Windows 32-bit 
using Visual Studio 2008. The build process was straightforward and the 
produced binaries work for me, specifically there is no crash in 
_png.pyd when writing PNG files.
<http://www.lfd.uci.edu/~gohlke/download/matplotlib-0.98.5.3.win32-py2.6.zip>
Use at your own risk. To install, remove previous installations of 
matplotlib and unzip the file to C:\Python26\Lib\site-packages.
Sources used:
Matplotlib svn v0_98_5_maint rev 7211
Freetype 2.3.9
Libpng 1.2.37
Zlib 1.2.3
Python 2.6.2 from python.org
NumPy 1.3.0 from scipy.org
wxPython 2.8.10.1 from wxpython.org
Regards,
Christoph

jor...@ya... wrote:
> 
> 
> 
> 
> ----- Mensaje original ----
>> De: Eric Firing <ef...@ha...>
>>
>> import matplotlib.cbook as cbook
>>
>> def to_sequence(arg):
>> if cbook.is_iterable(arg):
I goofed. It should be cbook.iterable(arg).
Eric

Matthias Michler wrote:
> Hi Sebastian, Hi list,
> 
> I'm not the one to decide this, but I think it is worth to try to remove 
> matplotlib.mlab routines, if their numpy counterparts provide the same 
> functionality or do I miss anything? After doing this one additionally could 
We have been doing this via deprecations. If there is something we have 
missed--a function in mlab that is also in numpy and that is *not* 
deprecated in mlab--please be specific about what it is, and we will 
deprecate it.
The functions like log2 are historical, part of a set contributed by 
Fernando Perez a long time ago. We tend to be cautious about ripping 
out such things, because user code may be depending on them. Maybe some 
of them should be deprecated. It is often hard to decide where and how 
to compromise between cleaning things up and maintaining backwards 
compatibility, just in case someone's code is depending on something 
obscure that has been there from early days.
If there are *specific* recommendations about functions that should be 
deprecated or changed, we would be happy to consider those recommendations.
> clean up the imports in pylab in order to have only one call "from 
> matplotlib.mlab import" instead of 3.
Yes, I see now that the mlab imports in pylab are an incredibly ugly 
mess and desperately need to be cleaned up. Thanks for pointing that out.
Multiple calls to "from matplotlib.mlab import ..." are fine with me, 
but I hate backslash line continuations, and I see that some functions 
are imported more than once.
It looks like we must be importing nearly everything, in which case it 
would be better to simply import * and then delete a few things if we 
really don't want them. A more radical change, such as importing only a 
very few things, and/or breaking mlab up so as to separate out the parts 
that pylab needs to import, may be better.
Eric
> 
> kind regards Matthias 
> 
> On Friday 12 June 2009 14:41:28 Sebastian Haase wrote:
>> On Fri, Jun 12, 2009 at 2:01 PM, John Hunter<jd...@gm...> wrote:
>>> On Fri, Jun 12, 2009 at 6:10 AM, Sebastian Haase<seb...@gm...> 
> wrote:
>>>> On Fri, Jun 12, 2009 at 11:21 AM, Matthias
>>>>
>>>> Michler<Mat...@gm...> wrote:
>>>>> Hi Sebastian,
>>>>>
>>>>> You are right. A large number of numpy functions is part of pylab, but
>>>>> I think this problem was solved by introducing matplotlib.pyplot, which
>>>>> holds all plotting functions of matplotlib. The module pylab imports
>>>>> these plotting functions and all the numpy-stuff in order to offer
>>>>> plotting + numerical functions by one import.
>>>>>
>>>>> kind regards Matthias
>>>> Matthias,
>>>> thanks for the info. thats the info I was missing.
>>>>
>>>>>>> from matplotlib import pyplot
>>>>>>> len(pyplot.__dict__)
>>>> 191
>>>>
>>>> Now I'm somewhat wondering about the things in pylab that are not in
>>>> pyplot nor in numpy.
>>>> E.g.:
>>>> pyplot.log2 is not numpy.log2
>>>> or
>>>> pyplot.window_hanning vs. numpy.hanning
>>>> or
>>>> pyplot.chisquare (which however is in numpy.random)
>>> These symbols are not in svn:
>>>
>>>
>>> In [59]: plt.log2
>>> ------------------------------------------------------------
>>> Traceback (most recent call last):
>>> File "<ipython console>", line 1, in ?
>>> AttributeError: 'module' object has no attribute 'log2'
>>>
>>>
>>> In [60]: plt.window_hanning
>>> ------------------------------------------------------------
>>> Traceback (most recent call last):
>>> File "<ipython console>", line 1, in ?
>>> AttributeError: 'module' object has no attribute 'window_hanning'
>> Sorry - I meant pylab ! not pyplot ...
>> There are those symbols.
>>
>> -S.
> 
> 
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Shot in the dark here, but what if you set the rcParam "path.simplify" 
to False? There have been recent changes to that code.
Also, since the Agg backend doesn't have an associated GUI, you need to 
use the savefig() command and provide a filename, rather than using show().
Cheers,
Mike
Zane Selvans wrote:
> Um, yeah. So my response got bounced because of the attachment. Take 2:
>
> For some reason my script bombed when I switched to the Agg backend,
> trying to display to the screen (it said Figure has no method show())
>
> So I output the plot as both a PDF and a PNG (still having backend:
> agg in my rcfile) and in both of those cases, irregular gaps are
> visible between the polygons making up the filled contours. This
> wasn't the case with my previously installed setup. It looks as if
> for some reason the vertices of the filled polygons are being
> calculated differently from different sides of the same contour,
> leading to overlap in some places, and gaps in others. You can download
> the PDF version (in which the exact geometry is much clearer).
> from:
>
> http://zaneselvans.org/dropbox/LinDensity_Grid.pdf
>
> Zane
>
> On Fri, Jun 12, 2009 at 5:51 AM, Michael Droettboom<md...@st...> wrote:
> 
>> So you see this behavior if you switch to the Agg backend? That's the
>> backend used to generate the images in the gallery. If there's a difference
>> there, that would seem to suggest some tweaking of the macosx backend (which
>> is still relatively new) is in order.
>>
>> Mike
>>
>> Zane Selvans wrote:
>> 
>>> I just installed the latest SciPy Superpack in order to get access to
>>> the scipy.spatial.KDTree class, and discovered that for some reason
>>> now when I use contourf() lines get drawn at the boundaries between
>>> the filled contours. Additionally, there is always a single vertical
>>> line crossing from each contour boundary to the next. I'm guessing
>>> that these are the edges of the filled polygons which are getting
>>> drawn. This behavior doesn't seem to be consistent with the
>>> contourf() documentation and when I run code in griddata_demo.py it
>>> doesn't come out looking like the picture in the documentation/example
>>> gallery...
>>>
>>> Is anyone else seeing this behavior? Is there a keyword I can use to
>>> force the edges of the polygons not to get drawn?
>>>
>>> This is on Mac OS X 10.5.7, with
>>> scipy.__version__ = 0.8.0.dev5635
>>> matplotlib.__version__ = 0.98.6svn
>>> numpy.__version__=1.4.0.dev6728
>>>
>>> As installed by superpack_2009年03月28日.sh
>>> from http://macinscience.org/?page_id=6
>>>
>>> using:
>>> backend: macosx
>>>
>>> Cheers,
>>> Zane
>>>
>>>
>>> 
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>> 
>
>
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
On Fri, Jun 12, 2009 at 10:52 AM, JPKay<ka...@va...> wrote:
> from mpl_toolkits.basemap import Basemap
You have not so far imported mpl_toolkits into the namespace, only
Basemap. You could do:
import mpl_toolkits.basemap
as another import line, or:
from mpl_toolkits.basemap import Basemap, NetCDFFile
followed by:
ncfile = NetCDFFile(output.nc, ...)
Best,
Matthew

Um, yeah. So my response got bounced because of the attachment. Take 2:
For some reason my script bombed when I switched to the Agg backend,
trying to display to the screen (it said Figure has no method show())
So I output the plot as both a PDF and a PNG (still having backend:
agg in my rcfile) and in both of those cases, irregular gaps are
visible between the polygons making up the filled contours. This
wasn't the case with my previously installed setup. It looks as if
for some reason the vertices of the filled polygons are being
calculated differently from different sides of the same contour,
leading to overlap in some places, and gaps in others. You can download
the PDF version (in which the exact geometry is much clearer).
from:
http://zaneselvans.org/dropbox/LinDensity_Grid.pdf
Zane
On Fri, Jun 12, 2009 at 5:51 AM, Michael Droettboom<md...@st...> wrote:
> So you see this behavior if you switch to the Agg backend? That's the
> backend used to generate the images in the gallery. If there's a difference
> there, that would seem to suggest some tweaking of the macosx backend (which
> is still relatively new) is in order.
>
> Mike
>
> Zane Selvans wrote:
>>
>> I just installed the latest SciPy Superpack in order to get access to
>> the scipy.spatial.KDTree class, and discovered that for some reason
>> now when I use contourf() lines get drawn at the boundaries between
>> the filled contours. Additionally, there is always a single vertical
>> line crossing from each contour boundary to the next. I'm guessing
>> that these are the edges of the filled polygons which are getting
>> drawn. This behavior doesn't seem to be consistent with the
>> contourf() documentation and when I run code in griddata_demo.py it
>> doesn't come out looking like the picture in the documentation/example
>> gallery...
>>
>> Is anyone else seeing this behavior? Is there a keyword I can use to
>> force the edges of the polygons not to get drawn?
>>
>> This is on Mac OS X 10.5.7, with
>> scipy.__version__ = 0.8.0.dev5635
>> matplotlib.__version__ = 0.98.6svn
>> numpy.__version__=1.4.0.dev6728
>>
>> As installed by superpack_2009年03月28日.sh
>> from http://macinscience.org/?page_id=6
>>
>> using:
>> backend: macosx
>>
>> Cheers,
>> Zane
>>
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
-- 
Zane A. Selvans
Amateur Earthling
http://zaneselvans.org
+1 303 815 6866

Hello,
Is there a way to plot half-filled markers in matplotlib ?
For example, I would like to use a circle marker, lower half filled in black
while the upper half is white.
Thanks,
Eli

The suggestion to install matplotlib.basemap seems to be the right direction
to go. However, I have been unsuccessful in importing the file by this
method. This is what I have been trying. 
from mpl_toolkits.basemap import Basemap
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.mlab as mlab
mpl_toolkits.basemap.NetCDFFile(output.nc, mode='r', maskandscale=True,
cache=None, mmap=True, username=None, password=None, verbose=False)
I am getting the following error as a result. 
Traceback (most recent call last):
 File "/Users/interpott/Documents/trial.py", line 6, in <module>
 mpl_toolkits.basemap.NetCDFFile(output.nc, mode='r', maskandscale=True,
cache=None, mmap=True, username=None, password=None, verbose=False)
NameError: name 'mpl_toolkits' is not defined
How do I force the location of the Netcdf file? and Why am I getting that
mpl_toolkits are not defined? 
Thanks for the help, 
Jon 
Jeff Whitaker wrote:
> 
> Eric Firing wrote:
>> Gökhan SEVER wrote:
>> 
>>> On Thu, Jun 11, 2009 at 1:09 PM, JPKay <ka...@va... 
>>> <mailto:ka...@va...>> wrote:
>>>
>>>
>>> Hello,
>>> I am trying to use matplotlib to create a quiver plot of a NetCDF
>>> file with
>>> the extension .nc. The Netcdf file is a series of arrays that
>>> contain
>>> information about the stress tensors on a globe.
>>>
>>> I am struggling to import the file into python and having the quiver
>>> data
>>> show up.
>>> To import the file I have been using:
>>> "ncdump file.nc <http://file.nc>"
>>>
>>>
>>> Any thoughts would be appreciated.
>>> Thanks,
>>> Jon
>>> --
>>> View this message in context:
>>> 
>>> http://www.nabble.com/Quiver-plot-of-a-netcdf-file-tp23986313p23986313.html
>>> Sent from the matplotlib - users mailing list archive at Nabble.com.
>>>
>>>
>>> I recommend you to check netcdf4-python 
>>> (http://code.google.com/p/netcdf4-python/)
>>> You can load both netcdf3 and 4 files. Additionally, there are date 
>>> conversion utilities which help to do transforms between numbers and 
>>> dates and vice versa.
>>> 
>>
>> Caution: it's great, and I use it, but it is not trivial to build and 
>> install. I think the OP would do best to start with pupynere. The web 
>> site for download looks like it is working: 
>> http://pypi.python.org/pypi/pupynere/
>>
>> Eric
>>
>>
>> 
> Note that if the OP is using basemap, an interface to pupynere is 
> already included (see 
> http://matplotlib.sourceforge.net/basemap/doc/html/api/basemap_api.html#mpl_toolkits.basemap.NetCDFFile).
> 
> -Jeff
> 
> 
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 
-- 
View this message in context: http://www.nabble.com/Quiver-plot-of-a-netcdf-file-tp23986313p24003499.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

2009年6月12日 Virgil Stokes <vs...@it...>
> I am rather new to matplotlib and would appreciate help on how I can install
> matplotlib with Python 2.6.2 on a Windows Vista platform.
>
>
>
You have to build it manually. Assumed you have Visual Studio 2008
installed:
 1. install freetype (freetype-2.3.5-1-setup.exe)
 2. install libpng (libpng-1.2.35-setup.exe)
 3. install zlib (zlib-1.2.3.exe)
 4. download and unzip the matplotlib sources
 (matplotlib-0.98.5.2.tar.gz), I will refer to this folder as
 [matplotlib_home]
 5. download and unzip win32_static_vs.tar.gz into [matplotlib_home]
 6. read [matplotlib_home] /INSTALL
 7. type the install commands from the VisualStudio2008-Command-Shell in
 [matplotlib_home]
 - 7.1 python setup.py build
 - 7.2 python setup.py install
Regards
Magnus

The description of 'n' vs 'f' below doesn't seem to align with what the 
spec says: that 'n' is for in-use objects and 'f' is for free objects. 
However, the spec does say:
"The first entry in the table (object number 0) is always free and has a 
generation number of 65,535; it is the head of the linked list of free 
objects."
So it seems reasonable to make this change.
This has now been fixed in the SVN 0.98.x maintenance branch and trunk, 
but not tested against ReportLab's parser. Mike: are you able to check 
out from SVN and test this for us?
Mike
Michael Hearne wrote:
> All: I am using PDF files generated from matplotlib, and a PDF parser 
> from ReportLab, Inc. Their tool encountered a bug in the PDF 
> specification. The company's email to me follows:
>
>>
>> ...matplotlib is violating the PDF specification. There
>> is a structure near the end of the file shown below, and they have put
>> an 'n' instead of an 'f' which tells a (suitably pedantic) parser that
>> the first meaningful content is to be found at byte 0 in the file, not
>> byte 16 where it really lives.
>>
>> xref
>> 0 62
>> 0000000000 65535 n <---- should be 'f'
>> 0000000016 00000 n
>> 0000000065 00000 n
>> 0000000218 00000 n
>>
>> That row with the '00000000 65535' is present in all PDF files. I
>> change the 'n' to an 'f' in a good binary editor and it goes through
>> fine.
>>
>> I have also added a special case to our code to correct for this. I
>> suspect other PDF viewers just skip the first row so were not bitten.
>
> I was able to figure out which module contains the offending code, but 
> not which lines actually print out that data.
>
> I submitted a bug report here:
> https://sourceforge.net/tracker/?func=detail&aid=2805455&group_id=80706&atid=560720 
> <https://sourceforge.net/tracker/?func=detail&aid=2805455&group_id=80706&atid=560720>
>
> Thanks,
>
> Mike
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Jun 10, 2009 at 12:55 AM, Steve
Nicholes<ema...@ya...> wrote:
> Thanks John. I hope you aren't receiving this reply twice (my email kicked
> me out when I hit send). I actually am importing pylab so it isn't an
> entirely qt app. I didn't post all of the code originally b/c it is long
> (and it would reveal how poor of a programmer I am :) ), but here are the
> relevant sections. The problematic section is in blue. Please let me know
> if you need anything else.
Importing pylab or pyplot into a GUI app is simply not supported.
There is never a reason to do it, and it is fraught with perils. I
don't know if this has anything to do with the problem you are
experiencing, but you need to remove these imports before we can
proceed.
JDH

All: I am using PDF files generated from matplotlib, and a PDF parser 
from ReportLab, Inc. Their tool encountered a bug in the PDF 
specification. The company's email to me follows:
>
> ...matplotlib is violating the PDF specification. There
> is a structure near the end of the file shown below, and they have put
> an 'n' instead of an 'f' which tells a (suitably pedantic) parser that
> the first meaningful content is to be found at byte 0 in the file, not
> byte 16 where it really lives.
>
> xref
> 0 62
> 0000000000 65535 n <---- should be 'f'
> 0000000016 00000 n
> 0000000065 00000 n
> 0000000218 00000 n
>
> That row with the '00000000 65535' is present in all PDF files. I
> change the 'n' to an 'f' in a good binary editor and it goes through
> fine.
>
> I have also added a special case to our code to correct for this. I
> suspect other PDF viewers just skip the first row so were not bitten.
I was able to figure out which module contains the offending code, but 
not which lines actually print out that data.
I submitted a bug report here:
https://sourceforge.net/tracker/?func=detail&aid=2805455&group_id=80706&atid=560720
Thanks,
Mike

On Tue, Jun 9, 2009 at 6:17 PM, Steve Nicholes
<ema...@ya...>wrote:
> Hi,
>
> I am writing some code for automated testing via GPIB using MPL and PyQt.
> To simulate automated data collection while debugging the program, I have
> added a for loop (see below) after reading in a data file that plots each
> point one by one. When I run the program in Linux, I see each point appear
> on the canvas one by one as designed, but when I run the same code in
> Windows, nothing shows up on the canvas during the for loop. Instead, once
> the loop has completed, all points appear simulataneously. Is there any
> reason the why calls to canvas.draw() show nothing when run in Windows?
I have seen similar discrepancies between PyQt4 behavior on linux and
windows in a few situations. In my experience, a call to
PyQt4.QtGui.qApp.processEvents() is sufficient to force an update in your
view.
Darren

On Fri, Jun 12, 2009 at 2:01 PM, John Hunter<jd...@gm...> wrote:
> On Fri, Jun 12, 2009 at 6:10 AM, Sebastian Haase<seb...@gm...> wrote:
>> On Fri, Jun 12, 2009 at 11:21 AM, Matthias
>> Michler<Mat...@gm...> wrote:
>>> Hi Sebastian,
>>>
>>> You are right. A large number of numpy functions is part of pylab, but I think
>>> this problem was solved by introducing matplotlib.pyplot, which holds all
>>> plotting functions of matplotlib. The module pylab imports these plotting
>>> functions and all the numpy-stuff in order to offer plotting + numerical
>>> functions by one import.
>>>
>>> kind regards Matthias
>>>
>> Matthias,
>> thanks for the info. thats the info I was missing.
>>>>> from matplotlib import pyplot
>>>>> len(pyplot.__dict__)
>> 191
>>
>> Now I'm somewhat wondering about the things in pylab that are not in
>> pyplot nor in numpy.
>> E.g.:
>> pyplot.log2 is not numpy.log2
>> or
>> pyplot.window_hanning  vs. numpy.hanning
>> or
>> pyplot.chisquare (which however is in numpy.random)
>
>
> These symbols are not in svn:
>
>
> In [59]: plt.log2
> ------------------------------------------------------------
> Traceback (most recent call last):
> File "<ipython console>", line 1, in ?
> AttributeError: 'module' object has no attribute 'log2'
>
>
> In [60]: plt.window_hanning
> ------------------------------------------------------------
> Traceback (most recent call last):
> File "<ipython console>", line 1, in ?
> AttributeError: 'module' object has no attribute 'window_hanning'
>
Sorry - I meant pylab ! not pyplot ...
There are those symbols.
-S.

So you see this behavior if you switch to the Agg backend? That's the 
backend used to generate the images in the gallery. If there's a 
difference there, that would seem to suggest some tweaking of the macosx 
backend (which is still relatively new) is in order.
Mike
Zane Selvans wrote:
> I just installed the latest SciPy Superpack in order to get access to
> the scipy.spatial.KDTree class, and discovered that for some reason
> now when I use contourf() lines get drawn at the boundaries between
> the filled contours. Additionally, there is always a single vertical
> line crossing from each contour boundary to the next. I'm guessing
> that these are the edges of the filled polygons which are getting
> drawn. This behavior doesn't seem to be consistent with the
> contourf() documentation and when I run code in griddata_demo.py it
> doesn't come out looking like the picture in the documentation/example
> gallery...
>
> Is anyone else seeing this behavior? Is there a keyword I can use to
> force the edges of the polygons not to get drawn?
>
> This is on Mac OS X 10.5.7, with
> scipy.__version__ = 0.8.0.dev5635
> matplotlib.__version__ = 0.98.6svn
> numpy.__version__=1.4.0.dev6728
>
> As installed by superpack_2009年03月28日.sh
> from http://macinscience.org/?page_id=6
>
> using:
> backend: macosx
>
> Cheers,
> Zane
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Fri, Jun 12, 2009 at 6:10 AM, Sebastian Haase<seb...@gm...> wrote:
> On Fri, Jun 12, 2009 at 11:21 AM, Matthias
> Michler<Mat...@gm...> wrote:
>> Hi Sebastian,
>>
>> You are right. A large number of numpy functions is part of pylab, but I think
>> this problem was solved by introducing matplotlib.pyplot, which holds all
>> plotting functions of matplotlib. The module pylab imports these plotting
>> functions and all the numpy-stuff in order to offer plotting + numerical
>> functions by one import.
>>
>> kind regards Matthias
>>
> Matthias,
> thanks for the info. thats the info I was missing.
>>>> from matplotlib import pyplot
>>>> len(pyplot.__dict__)
> 191
>
> Now I'm somewhat wondering about the things in pylab that are not in
> pyplot nor in numpy.
> E.g.:
> pyplot.log2 is not numpy.log2
> or
> pyplot.window_hanning vs. numpy.hanning
> or
> pyplot.chisquare (which however is in numpy.random)
These symbols are not in svn:
In [59]: plt.log2
------------------------------------------------------------
Traceback (most recent call last):
 File "<ipython console>", line 1, in ?
AttributeError: 'module' object has no attribute 'log2'
In [60]: plt.window_hanning
------------------------------------------------------------
Traceback (most recent call last):
 File "<ipython console>", line 1, in ?
AttributeError: 'module' object has no attribute 'window_hanning'

On Fri, Jun 12, 2009 at 11:21 AM, Matthias
Michler<Mat...@gm...> wrote:
> Hi Sebastian,
>
> You are right. A large number of numpy functions is part of pylab, but I think
> this problem was solved by introducing matplotlib.pyplot, which holds all
> plotting functions of matplotlib. The module pylab imports these plotting
> functions and all the numpy-stuff in order to offer plotting + numerical
> functions by one import.
>
> kind regards Matthias
>
Matthias,
thanks for the info. thats the info I was missing.
>>> from matplotlib import pyplot
>>> len(pyplot.__dict__)
191
Now I'm somewhat wondering about the things in pylab that are not in
pyplot nor in numpy.
E.g.:
pyplot.log2 is not numpy.log2
or
pyplot.window_hanning vs. numpy.hanning
or
pyplot.chisquare (which however is in numpy.random)
In summary, could one say that some functions are "left" in pylab to
keep backwards- and/or Matlab- compatibility ?
But does window_hanning behave exactly like numpy.hanning ?
I remember that some functions where decidedly implemented differently
than in numpy -- (sqrt for sqrt(-1) => 1j -- or was this scipy vs.
numpy)
Cheers,
Sebastian
> On Friday 12 June 2009 10:49:52 Sebastian Haase wrote:
>> Hi,
>> long time ago there was a discussion on reducing the duplications of
>> functions / symbols between Numpy and Matplotlib.
>>
>> I think from this resulted the pylab module now having many fewer entries:
>> >>> import matplotlib
>> >>> matplotlib.__version__
>>
>> '0.98.5.2'
>>
>> >>> import pylab
>> >>> len(pylab.__dict__)
>>
>> 882
>>
>> However, I think these are still to many ! I wrote, already before
>> the cleanup, a "HACK"-cleanup routine, which makes a cut-down modules
>> (called P) like this:
>> # P = new.module("pylab_sparse","""pylab module minus stuff alreay in
>> numpy""") for k,v in pylab.__dict__.iteritems():
>>   try:
>>    if k[:2] == '__' or v is numpy.__dict__[k]:
>>      continue
>>   except KeyError:
>>    pass
>>   #P.__dict__[k] = v
>>   exec("%s = pylab.%s" % (k,k))
>>
>> ((the commented out lines did not work, but they might still
>> illustrate what I want to do -- now I have this code in a separate
>> module that I can import as "P"
>>
>> This way I get:
>> >>> len(P.__dict__)
>>
>> 395
>>
>> >>> numpy.__version__
>>
>> '1.3.0'
>>
>>
>> So why are there still that many -- more than half ! -- duplications
>> between pylab and numpy ?
>>
>> Regards,
>>
>> Sebastian Haase

On Fri, Jun 12, 2009 at 4:21 AM, Matthias
Michler<Mat...@gm...> wrote:
> You are right. A large number of numpy functions is part of pylab, but I think
> this problem was solved by introducing matplotlib.pyplot, which holds all
> plotting functions of matplotlib. The module pylab imports these plotting
> functions and all the numpy-stuff in order to offer plotting + numerical
> functions by one import.
See also http://matplotlib.sourceforge.net/faq/usage_faq.html#matplotlib-pylab-and-pyplot-how-are-they-related
JDH

On Fri, Jun 12, 2009 at 5:34 AM, Virgil Stokes<vs...@it...> wrote:
> I am rather new to matplotlib and would appreciate help on how I can
> install matplotlib with Python 2.6.2 on a Windows Vista platform.
The matplotlib installer is broken for python2.6 -- I have been
working on fixing it, but it is not an easy problem. A recent post on
the subject is here:
 http://www.nabble.com/binary-installers-for-python2.6--libpng-segfault%2C-MSVCR90.DLL-and-%09mingw-td23971661.html
if there is anyone out there who has time to spend on this problem,
that would be great.
JDH