matplotlib-users Mailing List for matplotlib (Page 6)

Zane Selvans wrote:
> Yep, looks like the trunk has fixed the contourf() issue.
> 
> Unfortunately there also seems to be some new incompatibility with the
> Basemap toolkit, even after re-installing Basemap from source.  I get:
> 
> AttributeError: Axes.frame was removed in favor of Axes.spines


It appears Basemap hasn't caught up with the new Axes.spines usage.

Can you change mpl_toolkits/basemap/__init__.py line 1265 from::

  ax.frame.set_linewidth(linewidth)

to::

  for spine in ax.spines.itervalues():
      spine.set_linewidth(linewidth)

There may be more issues, here -- this is just the first one and based
off your traceback.

Jeff: I had to drop the Axes.frame to implement spines that could be
moved relative to the Axes boundary. I made sure this worked with the
custom projection examples in the main MPL distribution, so I imagine it
won't take too much to convert basemap. Please see svn r7144, 7145, and
7170 for my changes to lib/matplotlib/projections/geo.py

-Andrew

Oops



-----Original Message-----
From: Sandro Tosi [mailto:mat...@gm...] 
Sent: Tuesday, June 16, 2009 12:41 PM
To: Yeates, Mathew C
Cc: mat...@li...
Subject: Re: [Matplotlib-users] trying to plot polar data

Hi Mathew,

On Tue, Jun 16, 2009 at 21:20, Yeates, Mathew
C<mat...@jp...> wrote:
> Hi
>
> I am running the following snippet
>
> ax = axes(polar=True)
>
> polar(angles,mag,'bo')

please include a full, working example: with this so few information
we can help a little.

> and I get the attached plot

no attached image.

> How do make the dashed lines  continue inward? How do choose the spacing?
> How do remove the ugly text?

could at least rgrids() thetagrids() help you in part of your questions?

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Tue, Jun 16, 2009 at 10:39 PM, John Hunter<jd...@gm...> wrote:
> On Tue, Jun 16, 2009 at 3:32 PM, Sebastian Haase<seb...@gm...>
> wrote:> On Tue, Jun 16, 2009 at 6:54 PM, John
> Hunter<jd...@gm...> wrote:
>
>> Is there a similar function (to im.set_array) for graph plots ?
>
> for lines you would use line.set_data (or set_ydata, set_xdata).  Eg
>
> http://matplotlib.sourceforge.net/examples/animation/simple_anim_tkagg.html
>
Thanks for the quick answer.
This is obviously related to my post a few days ago -- a plotting benchmark ...
What are the restrictions for the functions
line.set_data
or
(assumingly similar) im.set_array ?
E.g. must the size (shape) of the data remain unchanged ?
Also, is there a performance difference if interactive mode is on or off ?

- Sebastian

On Tue, Jun 16, 2009 at 3:32 PM, Sebastian Haase<seb...@gm...>
wrote:> On Tue, Jun 16, 2009 at 6:54 PM, John
Hunter<jd...@gm...> wrote:

> Is there a similar function (to im.set_array) for graph plots ?

for lines you would use line.set_data (or set_ydata, set_xdata).  Eg

http://matplotlib.sourceforge.net/examples/animation/simple_anim_tkagg.html

JDH

On Tue, Jun 16, 2009 at 6:54 PM, John Hunter<jd...@gm...> wrote:
> On Tue, Jun 16, 2009 at 11:42 AM, Randy Heiland<he...@in...> wrote:
>> Can someone point me to the "best" way to dynamically update a 2D
>> [image] array (think of cellular automata)?  E.g., this simple example
>> works, but gets sluggish after several iterations:
>
> Use im.set_array rather than making multiple calls to imshow.  See the
> "dynamic_image*" examples at
>
> http://matplotlib.sourceforge.net/examples/animation/index.html
>

Is there a similar function (to im.set_array) for graph plots ?

- Sebastian

Yep, looks like the trunk has fixed the contourf() issue.

Unfortunately there also seems to be some new incompatibility with the
Basemap toolkit, even after re-installing Basemap from source.  I get:

AttributeError: Axes.frame was removed in favor of Axes.spines

when I attempt to call:

drawmapboundary(fill_color="white")

Error output below:

/Users/zane/svn/googlecode/satstress/satstress/nsrhist.pyc in
makefigs(dbar_max, maps, hists, examples, stats, stress, tpw,
lindensity, all, save_format)
    774     if maps is True: #{{{2
    775         print("Plotting Mapped Lineaments, fit to NSR stresses")
--> 776         FitMap(nsrlins, nbins=9, titlestr="global lins, fit to
NSR", dbar_max=dbar_max, outfile=figure_outfiles['FitMap_Mapped'])
    777         print("Plotting Pre-TPW Lineaments, fit to NSR stresses")
    778         FitMap(tpwlins, nbins=9, titlestr="pre-TPW lins, fit
to NSR", dbar_max=dbar_max, outfile=figure_outfiles['FitMap_PreTPW'])

/Users/zane/svn/googlecode/satstress/satstress/nsrhist.pyc in
FitMap(lins, titlestr, lin_cm, nbins, stresscentric, outfile,
dbar_max, showbad, derotate)
   1005     linfitmap.drawmeridians(range(llcrnrlon,urcrnrlon+1,gridspace),
labels=[1,0,0,1])
   1006     linfitmap.drawparallels(range(llcrnrlat,urcrnrlat+1,gridspace),
labels=[1,0,0,1])
-> 1007     linfitmap.drawmapboundary(fill_color="white")
   1008     map_ax = fig.axes[0]
   1009

/Library/Python/2.5/site-packages/mpl_toolkits/basemap/__init__.pyc in
drawmapboundary(self, color, linewidth, fill_color, zorder, ax)
   1263         else: # all other projections are rectangular.
   1264             # use axesPatch for fill_color, frame for border line props.
-> 1265             ax.frame.set_linewidth(linewidth)
   1266             if self.projection not in ['geos','ortho']:
   1267                 if fill_color is not None:

/Library/Python/2.5/site-packages/matplotlib/axes.pyc in get_frame(self)
    984
    985     def get_frame(self):
--> 986         raise AttributeError('Axes.frame was removed in favor
of Axes.spines')
    987     frame = property(get_frame)
    988

AttributeError: Axes.frame was removed in favor of Axes.spines

In [3]: import mpl_toolkits.basemap

In [4]: mpl_toolkits.basemap.__version__
Out[4]: '0.99.4'


On Tue, Jun 16, 2009 at 7:29 AM, Michiel de Hoon<mjl...@ya...> wrote:
>
> I can't reproduce this error with the current code in SVN trunk, but I remember seeing this bug a while ago. So I'm guessing that this bug has already been fixed in SVN. Zane, could you try installing the latest matplotlib from trunk and see if you still see this bug?
>
> --Michiel
>
> --- On Mon, 6/15/09, Michael Droettboom <md...@st...> wrote:
>
>> From: Michael Droettboom <md...@st...>
>> Subject: Re: [Matplotlib-users] New contourf() drawing polygon boundaries for  some reason?
>> To: za...@am..., "matplotlib-users" <mat...@li...>, "Michiel de Hoon" <mjl...@ya...>
>> Date: Monday, June 15, 2009, 6:08 PM
>>
>>
>>
>>
>>
>>
>> Thanks for the thorough investigation.
>>
>>
>>
>> Michiel: can you look into why the macosx backend is
>> drawing the
>> strokes around the polygons?  Probably as simple as
>> inadvertently
>> ignoring an argument.
>>
>>
>>
>> I'll look into the path simplification-related issues.
>>
>>
>>
>> Cheers,
>>
>> Mike
>>
>>
>>
>> On 06/15/2009 03:29 PM, Zane Selvans wrote:
>>
>>   Yes.  By far the worst of these behaviors is the
>> macosx GUI output.  I
>> could see the other ones just being the way it's
>> supposed to look.
>> Here's a summary:
>>
>> backend: macosx; path.simplify: (false|true) GUI =>
>> black borders to
>> drawn polygons (incl. contour region crossing lines, very
>> bad)
>> http://zaneselvans.org/dropbox/contourf_backendmacosx.png
>>
>> backend: agg (PNG output) path.simplify: (true|false) =>
>> somewhat
>> visible borders between polygons (esp. adjacent to
>> contrasting colors)
>> http://zaneselvans.org/dropbox/contourf_simplifytrue.png
>> http://zaneselvans.org/dropbox/contourf_simplifyfalse.png
>>
>> backend: pdf (PDF output) path.simplify: true =>
>> reliably visible
>> irregularities (but probably this is somewhat expected with
>> SVG
>> output)
>> http://zaneselvans.org/dropbox/contourf_simplifytrue.pdf
>>
>> backend: pdf (PDF output) path.simplify: false =>
>> infinitessimally
>> thin lines of background color visible between contour
>> filled regions.
>> http://zaneselvans.org/dropbox/contourf_simplifyfalse.pdf
>>
>> And here's what I used to generate them:
>>
>> def broken_contourf():
>>     """
>>     Simple demonstration that filled contour plots are
>> broken.
>>
>>     Looking at the PDF and PNG output using the macosx
>> backend, everything is
>>     fine.  It's only the GUI output which is for some
>> reason outlining the
>>     polygons in the filled contours.
>>
>>     """
>>     from numpy.random import uniform, seed
>>     from matplotlib.mlab import griddata
>>     import matplotlib.pyplot as plt
>>     import numpy as np
>>     # make up data.
>>     #npts = int(raw_input('enter # of random points to
>> plot:'))
>>     seed(-1)
>>     npts = 200
>>     x = uniform(-2,2,npts)
>>     y = uniform(-2,2,npts)
>>     z = x*np.exp(-x**2-y**2)
>>     # define grid.
>>     xi = np.linspace(-2.1,2.1,100)
>>     yi = np.linspace(-2.1,2.1,100)
>>     # grid the data.
>>     zi = griddata(x,y,z,xi,yi)
>>     # contour the gridded data, plotting dots at the
>> nonuniform data points.
>>     CS = plt.contourf(xi,yi,zi,15,cmap=plt.cm.jet)
>>     # plot data points.
>>     plt.title('griddata() and contourf() test')
>>     plt.savefig('broken_contourf.pdf')
>>     plt.savefig('broken_contourf.png')
>>
>> On Fri, Jun 12, 2009 at 3:02 PM, Zane Selvans<za...@id...>
>> wrote:
>>
>>
>>     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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>



-- 
Zane A. Selvans
Amateur Earthling
http://zaneselvans.org
+1 303 815 6866

Hi Mathew,

On Tue, Jun 16, 2009 at 21:20, Yeates, Mathew
C<mat...@jp...> wrote:
> Hi
>
> I am running the following snippet
>
> ax = axes(polar=True)
>
> polar(angles,mag,'bo')

please include a full, working example: with this so few information
we can help a little.

> and I get the attached plot

no attached image.

> How do make the dashed lines  continue inward? How do choose the spacing?
> How do remove the ugly text?

could at least rgrids() thetagrids() help you in part of your questions?

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

I'm attempting to plot the distribution of bond angles in protein structures
(the best-known example: http://en.wikipedia.org/wiki/Ramachandran_plot).  I
have the raw data as a collection of x,y,z data, where x and y are integers
between -180 and 180, and z is a floating-point value.  (Right now, this
data is pure Python objects, but I can convert it to NumPy arrays if that
would be easier.)  I would like to plot this as a continuous color map
inside a wxPython window, and also overlay the discreet data points for a
separate protein.  It doesn't really matter what combination of colors I use
for this - there appear to be many built-in color maps that would be
suitable.  I'm pretty sure this is possible, based on looking at the
examples, but I have no clue how to go about this - it doesn't help that all
of the examples appear to use the pylab interface.  Any suggestions?
thanks,
Nat

Hi
I am running the following snippet
ax = axes(polar=True)
polar(angles,mag,'bo')

and I get the attached plot


How do make the dashed lines  continue inward? How do choose the spacing? How do remove the ugly text?


Mathew

On Tue, Jun 16, 2009 at 11:42 AM, Randy Heiland<he...@in...> wrote:
> Can someone point me to the "best" way to dynamically update a 2D
> [image] array (think of cellular automata)?  E.g., this simple example
> works, but gets sluggish after several iterations:

Use im.set_array rather than making multiple calls to imshow.  See the
"dynamic_image*" examples at

http://matplotlib.sourceforge.net/examples/animation/index.html

Can someone point me to the "best" way to dynamically update a 2D  
[image] array (think of cellular automata)?  E.g., this simple example  
works, but gets sluggish after several iterations:

import numpy as N
import pylab as P

nx = 20
ny = 20
c = N.zeros(nx*ny, dtype='int8')
c.resize(ny,nx)

iters = 50
for its in range(iters):
   ix0 = N.random.rand()*nx
   iy0 = N.random.rand()*ny
   c[iy0,ix0] = 1
   P.imshow(c,interpolation='nearest')
   P.draw()

I'm guessing I'll want to use the mpl's API, but unsure of the best  
approach.  I'm currently using mpl 0.98.5.

thanks, Randy

I can't reproduce this error with the current code in SVN trunk, but I remember seeing this bug a while ago. So I'm guessing that this bug has already been fixed in SVN. Zane, could you try installing the latest matplotlib from trunk and see if you still see this bug?

--Michiel 

--- On Mon, 6/15/09, Michael Droettboom <md...@st...> wrote:

> From: Michael Droettboom <md...@st...>
> Subject: Re: [Matplotlib-users] New contourf() drawing polygon boundaries for  some reason?
> To: za...@am..., "matplotlib-users" <mat...@li...>, "Michiel de Hoon" <mjl...@ya...>
> Date: Monday, June 15, 2009, 6:08 PM
> 
> 
> 
>   
> 
>  
> Thanks for the thorough investigation.
> 
> 
> 
> Michiel: can you look into why the macosx backend is
> drawing the
> strokes around the polygons?  Probably as simple as
> inadvertently
> ignoring an argument.
> 
> 
> 
> I'll look into the path simplification-related issues.
> 
> 
> 
> Cheers,
> 
> Mike
> 
> 
> 
> On 06/15/2009 03:29 PM, Zane Selvans wrote:
> 
>   Yes.  By far the worst of these behaviors is the
> macosx GUI output.  I
> could see the other ones just being the way it's
> supposed to look.
> Here's a summary:
> 
> backend: macosx; path.simplify: (false|true) GUI =>
> black borders to
> drawn polygons (incl. contour region crossing lines, very
> bad)
> http://zaneselvans.org/dropbox/contourf_backendmacosx.png
> 
> backend: agg (PNG output) path.simplify: (true|false) =>
> somewhat
> visible borders between polygons (esp. adjacent to
> contrasting colors)
> http://zaneselvans.org/dropbox/contourf_simplifytrue.png
> http://zaneselvans.org/dropbox/contourf_simplifyfalse.png
> 
> backend: pdf (PDF output) path.simplify: true =>
> reliably visible
> irregularities (but probably this is somewhat expected with
> SVG
> output)
> http://zaneselvans.org/dropbox/contourf_simplifytrue.pdf
> 
> backend: pdf (PDF output) path.simplify: false =>
> infinitessimally
> thin lines of background color visible between contour
> filled regions.
> http://zaneselvans.org/dropbox/contourf_simplifyfalse.pdf
> 
> And here's what I used to generate them:
> 
> def broken_contourf():
>     """
>     Simple demonstration that filled contour plots are
> broken.
> 
>     Looking at the PDF and PNG output using the macosx
> backend, everything is
>     fine.  It's only the GUI output which is for some
> reason outlining the
>     polygons in the filled contours.
> 
>     """
>     from numpy.random import uniform, seed
>     from matplotlib.mlab import griddata
>     import matplotlib.pyplot as plt
>     import numpy as np
>     # make up data.
>     #npts = int(raw_input('enter # of random points to
> plot:'))
>     seed(-1)
>     npts = 200
>     x = uniform(-2,2,npts)
>     y = uniform(-2,2,npts)
>     z = x*np.exp(-x**2-y**2)
>     # define grid.
>     xi = np.linspace(-2.1,2.1,100)
>     yi = np.linspace(-2.1,2.1,100)
>     # grid the data.
>     zi = griddata(x,y,z,xi,yi)
>     # contour the gridded data, plotting dots at the
> nonuniform data points.
>     CS = plt.contourf(xi,yi,zi,15,cmap=plt.cm.jet)
>     # plot data points.
>     plt.title('griddata() and contourf() test')
>     plt.savefig('broken_contourf.pdf')
>     plt.savefig('broken_contourf.png')
> 
> On Fri, Jun 12, 2009 at 3:02 PM, Zane Selvans<za...@id...>
> wrote:
>   
>   
>     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
> 
>     
>   
>   
> 
> 
>   
> 
> 
> 
>  
> 
> 


      

Okay, so in the "variables" section, what you've got is a list of things
which vary as a function of the "dimensions" listed in the previous section
(time, nsr_delta, lat, lon).  I don't remember which of the NetCDF file
reading libraries you're using, but using Jeff's older netCDF3 interface,
you could do something like:

nc_in = netCDF3.Dataset("outputfile.nc")

And then that nc_in thing contains all the data that's contained in the file
outputfile.nc, and you can read it into numpy arrays:

Ttt_D = nc_in.variables['Ttt_D'][:,:,:]
Tpt_D = nc_in.variables['Tpt_D'][:,:,:]
Tpp_D = nc_in.variables['Tpp_D'][:,:,:]

What that does is stick the north-south, shear, and east-west components of
the Diurnal stresses into the three arrays.  The [:,:,:] bit says "give me
the data for all values of time, latitude and longitude".

In order to turn those tensor components into the principal components, you
need to, for each (t,lat,lon) set, diagonalize the matrices composed of the
stress values:

[ [ Ttt(t,lat,lon), Tpt(t,lat,lon) ],
  [ Tpt(t,lat,lon), Tpp(t,lat,lon) ] ]

which you can do with np.eig()

The (unit length) eigenvectors it returns will tell you what direction the
principal components point, and the corresponding eigenvalues will tell you
their magnitudes... which then have to get fed in to quiver().

Hopefully that helps at least a little?


JPKay wrote:
> 
> Hello, 
> 
> Now that I have correctly imported the NetCDF file and set up the kind of
> projection I am interested in having the data displayed over I am having
> trouble plotting my data with the quiver function. I am interested in
> plotting the principal vectors of the stress field onto a Mercator
> projection. 
> My netcdf file is telling me the following after "ncdump -h"
> dimensions:
> 	nsr_delta = 20 ;
> 	time = 24 ;
> 	latitude = 37 ;
> 	longitude = 73 ;
> variables:
> 	float nsr_delta(nsr_delta) ;
> 		nsr_delta:units = "" ;
> 		nsr_delta:long_name = "NSR Surface Delta (mu/(eta*omega))" ;
> 	float time(time) ;
> 		time:units = "degrees" ;
> 		time:long_name = "degrees after periapse" ;
> 	float latitude(latitude) ;
> 		latitude:units = "degrees_north" ;
> 		latitude:long_name = "latitude" ;
> 	float longitude(longitude) ;
> 		longitude:units = "degrees_east" ;
> 		longitude:long_name = "longitude" ;
> 	float Ttt_D(time, latitude, longitude) ;
> 		Ttt_D:units = "Pa" ;
> 		Ttt_D:long_name = "north-south component stress of Diurnal stresses" ;
> 	float Tpt_D(time, latitude, longitude) ;
> 		Tpt_D:units = "Pa" ;
> 		Tpt_D:long_name = "shear component of Diurnal stresses" ;
> 	float Tpp_D(time, latitude, longitude) ;
> 		Tpp_D:units = "Pa" ;
> 		Tpp_D:long_name = "east-west component of Diurnal stresses" ;
> 	float Ttt_N(nsr_delta, latitude, longitude) ;
> 		Ttt_N:units = "Pa" ;
> 		Ttt_N:long_name = "north-south component of NSR stresses" ;
> 	float Tpt_N(nsr_delta, latitude, longitude) ;
> 		Tpt_N:units = "Pa" ;
> 		Tpt_N:long_name = "shear component of NSR stresses" ;
> 	float Tpp_N(nsr_delta, latitude, longitude) ;
> 		Tpp_N:units = "Pa" ;
> 		Tpp_N:long_name = "east-west component of NSR stresses" ;
> 
> // global attributes:
> 		:description = "Testing pySatStress on a regular grid" ;
> 		:history = "Created: Mon Jun 15 12:46:13 2009 using pySatStress" ;
> 		:Conventions = "COARDS" ;
> However, when I am strugglingto use the quiver_demo.py as a guide to
> making my quiver plot. 
> Thanks for any help you can offer. 
> Jon 
> 
> 

-- 
View this message in context: http://www.nabble.com/Quiver-plot-of-a-netcdf-file-tp23986313p24046177.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Thanks for the suggestion to look at the demo, I had missed it in my initial
look through. The quiver_demo seems to be broken up into three sections. The
first section initializes the information for the the two quiver plots
(sections two and three). This seems like the logical place to start for
importing the array information. The information in the quiver demo seems to
make sense, but I do not understand what needs to be modified and what does
not. Is there any location that contains more documentation about the quiver
function, or another demo that I could follow? Anyway, thanks for the help. 
Jon

I have done my best to comment out the first section.

Section 1:
# read in data.
file = open('fcover.dat','r') 
#I assume this section is not needed because because the netcdf file has
already been imported. 
ul=[];vl=[];pl=[]
#this seems to initiate the functions that are going to be imported and
plotted
nlons=73; nlats=73
#Not sure what this does
dellat = 2.5; dellon = 5.
#degrees that are displayed?
for line in file.readlines():
   l = line.replace('\n','').split()
   ul.append(float(l[0]))
   vl.append(float(l[1]))
   pl.append(float(l[2]))
u = np.reshape(np.array(ul,np.float32),(nlats,nlons))
v = np.reshape(np.array(vl,np.float32),(nlats,nlons))
p = np.reshape(np.array(pl,np.float32),(nlats,nlons))
lats1 = -90.+dellat*np.arange(nlats)
lons1 = -180.+dellon*np.arange(nlons)
lons, lats = np.meshgrid(lons1, lats1)



# read in data.
file = open('fcover.dat','r')
ul=[];vl=[];pl=[]
nlons=73; nlats=73
dellat = 2.5; dellon = 5.
for line in file.readlines():
   l = line.replace('\n','').split()
   ul.append(float(l[0]))
   vl.append(float(l[1]))
   pl.append(float(l[2]))
u = np.reshape(np.array(ul,np.float32),(nlats,nlons))
v = np.reshape(np.array(vl,np.float32),(nlats,nlons))
p = np.reshape(np.array(pl,np.float32),(nlats,nlons))
#equations calculating the magnitude of the vectors?
lats1 = -90.+dellat*np.arange(nlats)
lons1 = -180.+dellon*np.arange(nlons)
lons, lats = np.meshgrid(lons1, lats1)

-- 
View this message in context: http://www.nabble.com/Quiver-plot-of-a-netcdf-file-tp23986313p24045770.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Thanks for the thorough investigation.

Michiel: can you look into why the macosx backend is drawing the strokes 
around the polygons?  Probably as simple as inadvertently ignoring an 
argument.

I'll look into the path simplification-related issues.

Cheers,
Mike

On 06/15/2009 03:29 PM, Zane Selvans wrote:
> Yes.  By far the worst of these behaviors is the macosx GUI output.  I
> could see the other ones just being the way it's supposed to look.
> Here's a summary:
>
> backend: macosx; path.simplify: (false|true) GUI =>  black borders to
> drawn polygons (incl. contour region crossing lines, very bad)
> http://zaneselvans.org/dropbox/contourf_backendmacosx.png
>
> backend: agg (PNG output) path.simplify: (true|false) =>  somewhat
> visible borders between polygons (esp. adjacent to contrasting colors)
> http://zaneselvans.org/dropbox/contourf_simplifytrue.png
> http://zaneselvans.org/dropbox/contourf_simplifyfalse.png
>
> backend: pdf (PDF output) path.simplify: true =>  reliably visible
> irregularities (but probably this is somewhat expected with SVG
> output)
> http://zaneselvans.org/dropbox/contourf_simplifytrue.pdf
>
> backend: pdf (PDF output) path.simplify: false =>  infinitessimally
> thin lines of background color visible between contour filled regions.
> http://zaneselvans.org/dropbox/contourf_simplifyfalse.pdf
>
> And here's what I used to generate them:
>
> def broken_contourf():
>      """
>      Simple demonstration that filled contour plots are broken.
>
>      Looking at the PDF and PNG output using the macosx backend, everything is
>      fine.  It's only the GUI output which is for some reason outlining the
>      polygons in the filled contours.
>
>      """
>      from numpy.random import uniform, seed
>      from matplotlib.mlab import griddata
>      import matplotlib.pyplot as plt
>      import numpy as np
>      # make up data.
>      #npts = int(raw_input('enter # of random points to plot:'))
>      seed(-1)
>      npts = 200
>      x = uniform(-2,2,npts)
>      y = uniform(-2,2,npts)
>      z = x*np.exp(-x**2-y**2)
>      # define grid.
>      xi = np.linspace(-2.1,2.1,100)
>      yi = np.linspace(-2.1,2.1,100)
>      # grid the data.
>      zi = griddata(x,y,z,xi,yi)
>      # contour the gridded data, plotting dots at the nonuniform data points.
>      CS = plt.contourf(xi,yi,zi,15,cmap=plt.cm.jet)
>      # plot data points.
>      plt.title('griddata() and contourf() test')
>      plt.savefig('broken_contourf.pdf')
>      plt.savefig('broken_contourf.png')
>
> On Fri, Jun 12, 2009 at 3:02 PM, Zane Selvans<za...@id...>  wrote:
>    
>> 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
>>
>>      
>
>
>
>    

JPKay wrote:
> Hello, 
>
> Now that I have correctly imported the NetCDF file and set up the kind of
> projection I am interested in having the data displayed over I am having
> trouble plotting my data with the quiver function. I am interested in
> plotting the principal vectors of the stress field onto a Mercator
> projection. 
> My netcdf file is telling me the following after "ncdump -h"
> dimensions:
> 	nsr_delta = 20 ;
> 	time = 24 ;
> 	latitude = 37 ;
> 	longitude = 73 ;
> variables:
> 	float nsr_delta(nsr_delta) ;
> 		nsr_delta:units = "" ;
> 		nsr_delta:long_name = "NSR Surface Delta (mu/(eta*omega))" ;
> 	float time(time) ;
> 		time:units = "degrees" ;
> 		time:long_name = "degrees after periapse" ;
> 	float latitude(latitude) ;
> 		latitude:units = "degrees_north" ;
> 		latitude:long_name = "latitude" ;
> 	float longitude(longitude) ;
> 		longitude:units = "degrees_east" ;
> 		longitude:long_name = "longitude" ;
> 	float Ttt_D(time, latitude, longitude) ;
> 		Ttt_D:units = "Pa" ;
> 		Ttt_D:long_name = "north-south component stress of Diurnal stresses" ;
> 	float Tpt_D(time, latitude, longitude) ;
> 		Tpt_D:units = "Pa" ;
> 		Tpt_D:long_name = "shear component of Diurnal stresses" ;
> 	float Tpp_D(time, latitude, longitude) ;
> 		Tpp_D:units = "Pa" ;
> 		Tpp_D:long_name = "east-west component of Diurnal stresses" ;
> 	float Ttt_N(nsr_delta, latitude, longitude) ;
> 		Ttt_N:units = "Pa" ;
> 		Ttt_N:long_name = "north-south component of NSR stresses" ;
> 	float Tpt_N(nsr_delta, latitude, longitude) ;
> 		Tpt_N:units = "Pa" ;
> 		Tpt_N:long_name = "shear component of NSR stresses" ;
> 	float Tpp_N(nsr_delta, latitude, longitude) ;
> 		Tpp_N:units = "Pa" ;
> 		Tpp_N:long_name = "east-west component of NSR stresses" ;
>
> // global attributes:
> 		:description = "Testing pySatStress on a regular grid" ;
> 		:history = "Created: Mon Jun 15 12:46:13 2009 using pySatStress" ;
> 		:Conventions = "COARDS" ;
> However, when I am strugglingto use the quiver_demo.py as a guide to making
> my quiver plot. 
> Thanks for any help you can offer. 
> Jon 
>
>   
Jon:  Have you looked the quiver_demo.py in the basemap examples?  If 
so, what problems did you have adopting that code? 

As always, a simple script demonstrating your problem is most helpful.

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

Hello, 

Now that I have correctly imported the NetCDF file and set up the kind of
projection I am interested in having the data displayed over I am having
trouble plotting my data with the quiver function. I am interested in
plotting the principal vectors of the stress field onto a Mercator
projection. 
My netcdf file is telling me the following after "ncdump -h"
dimensions:
	nsr_delta = 20 ;
	time = 24 ;
	latitude = 37 ;
	longitude = 73 ;
variables:
	float nsr_delta(nsr_delta) ;
		nsr_delta:units = "" ;
		nsr_delta:long_name = "NSR Surface Delta (mu/(eta*omega))" ;
	float time(time) ;
		time:units = "degrees" ;
		time:long_name = "degrees after periapse" ;
	float latitude(latitude) ;
		latitude:units = "degrees_north" ;
		latitude:long_name = "latitude" ;
	float longitude(longitude) ;
		longitude:units = "degrees_east" ;
		longitude:long_name = "longitude" ;
	float Ttt_D(time, latitude, longitude) ;
		Ttt_D:units = "Pa" ;
		Ttt_D:long_name = "north-south component stress of Diurnal stresses" ;
	float Tpt_D(time, latitude, longitude) ;
		Tpt_D:units = "Pa" ;
		Tpt_D:long_name = "shear component of Diurnal stresses" ;
	float Tpp_D(time, latitude, longitude) ;
		Tpp_D:units = "Pa" ;
		Tpp_D:long_name = "east-west component of Diurnal stresses" ;
	float Ttt_N(nsr_delta, latitude, longitude) ;
		Ttt_N:units = "Pa" ;
		Ttt_N:long_name = "north-south component of NSR stresses" ;
	float Tpt_N(nsr_delta, latitude, longitude) ;
		Tpt_N:units = "Pa" ;
		Tpt_N:long_name = "shear component of NSR stresses" ;
	float Tpp_N(nsr_delta, latitude, longitude) ;
		Tpp_N:units = "Pa" ;
		Tpp_N:long_name = "east-west component of NSR stresses" ;

// global attributes:
		:description = "Testing pySatStress on a regular grid" ;
		:history = "Created: Mon Jun 15 12:46:13 2009 using pySatStress" ;
		:Conventions = "COARDS" ;
However, when I am strugglingto use the quiver_demo.py as a guide to making
my quiver plot. 
Thanks for any help you can offer. 
Jon 

-- 
View this message in context: http://www.nabble.com/Quiver-plot-of-a-netcdf-file-tp23986313p24041837.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Yes.  By far the worst of these behaviors is the macosx GUI output.  I
could see the other ones just being the way it's supposed to look.
Here's a summary:

backend: macosx; path.simplify: (false|true) GUI => black borders to
drawn polygons (incl. contour region crossing lines, very bad)
http://zaneselvans.org/dropbox/contourf_backendmacosx.png

backend: agg (PNG output) path.simplify: (true|false) => somewhat
visible borders between polygons (esp. adjacent to contrasting colors)
http://zaneselvans.org/dropbox/contourf_simplifytrue.png
http://zaneselvans.org/dropbox/contourf_simplifyfalse.png

backend: pdf (PDF output) path.simplify: true => reliably visible
irregularities (but probably this is somewhat expected with SVG
output)
http://zaneselvans.org/dropbox/contourf_simplifytrue.pdf

backend: pdf (PDF output) path.simplify: false => infinitessimally
thin lines of background color visible between contour filled regions.
http://zaneselvans.org/dropbox/contourf_simplifyfalse.pdf

And here's what I used to generate them:

def broken_contourf():
    """
    Simple demonstration that filled contour plots are broken.

    Looking at the PDF and PNG output using the macosx backend, everything is
    fine.  It's only the GUI output which is for some reason outlining the
    polygons in the filled contours.

    """
    from numpy.random import uniform, seed
    from matplotlib.mlab import griddata
    import matplotlib.pyplot as plt
    import numpy as np
    # make up data.
    #npts = int(raw_input('enter # of random points to plot:'))
    seed(-1)
    npts = 200
    x = uniform(-2,2,npts)
    y = uniform(-2,2,npts)
    z = x*np.exp(-x**2-y**2)
    # define grid.
    xi = np.linspace(-2.1,2.1,100)
    yi = np.linspace(-2.1,2.1,100)
    # grid the data.
    zi = griddata(x,y,z,xi,yi)
    # contour the gridded data, plotting dots at the nonuniform data points.
    CS = plt.contourf(xi,yi,zi,15,cmap=plt.cm.jet)
    # plot data points.
    plt.title('griddata() and contourf() test')
    plt.savefig('broken_contourf.pdf')
    plt.savefig('broken_contourf.png')

On Fri, Jun 12, 2009 at 3:02 PM, Zane Selvans<za...@id...> wrote:
> 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
>



-- 
Zane A. Selvans
Amateur Earthling
http://zaneselvans.org
+1 303 815 6866

On Mon, Jun 15, 2009 at 10:31 AM, Christoph Gohlke<cg...@uc...> wrote:
> Hi John,
>
> I rebuilt the installer and egg and confirmed that the distributed
> matplotlibrc file contains "backend: TkAgg".
>
> <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>

Great -- thanks a lot.  I have uploaded these to the sf site and
tested both the egg and exe and both are working out-of-the-box on my
system at least.

JDH

On Mon, Jun 15, 2009 at 10:12 AM, CaseyWeb<niw...@ho...> wrote:
>
> I do have wxPython 2.8 installed so I don't know why this would have caused
> the problem in the first place, but I changed the matplotlibrc to backend :
> TkAgg and I still get the windows crash.  Just to be clear, this isn't an
> import error or simple python exit; I'm actually getting the Windows crash
> dialog box whenever I import pylab.  Importing matplotlib doesn't seem to
> cause any problems, but I haven't tried to do anything with it yet.

make sure you have a clean installation by removing
site-packages/matplotlib and any associated eggs.  I tried the exe
installer and got the wxpython traceback.  I switched to tkagg and was
able to make plots, save pngs, etc.

JDH

I do have wxPython 2.8 installed so I don't know why this would have caused
the problem in the first place, but I changed the matplotlibrc to backend :
TkAgg and I still get the windows crash.  Just to be clear, this isn't an
import error or simple python exit; I'm actually getting the Windows crash
dialog box whenever I import pylab.  Importing matplotlib doesn't seem to
cause any problems, but I haven't tried to do anything with it yet.


John Hunter-4 wrote:
> 
> Apparently the binaries are fine but the default matplotlib rc is
> setting the backend to wxagg.  site-packages/matplotlib/mpl-data and
> set
> 
> backend : TkAgg
> 
> See also http://matplotlib.sourceforge.net/users/customizing.html
> 

-- 
View this message in context: http://www.nabble.com/matplotlib-0.98.5.3-windows-binaries-available-tp24023736p24036525.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Mon, Jun 15, 2009 at 16:36, TP<par...@fr...> wrote:
> Hi everybody,
>
> I want to modify a matplotlib.lines.Line2D and update the plot.
> I have used Line2D._y member to modify the line. It works. But by doing
> canvas.draw() (see example below), the line is not updated on the plot. To
> update it, I have to do autoscale_view(). But I do not want the x and y
> ranges of the plot to be changed.

I think you want the 'line.set_ydata' method, where you pass the new Y
data for your plot (there are also set_xdata and set_data to set,
respectively, the X data and the whole set of X/Y); then call a draw
on the canvas.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Mon, Jun 15, 2009 at 9:36 AM, TP<par...@fr...> wrote:
> Hi everybody,
>
> I want to modify a matplotlib.lines.Line2D and update the plot.
> I have used Line2D._y member to modify the line. It works. But by doing
> canvas.draw() (see example below), the line is not updated on the plot. To
> update it, I have to do autoscale_view(). But I do not want the x and y
> ranges of the plot to be changed.

Turn autoscaling off with

  ax.set_autoscale_on(False)

update the line with

  line.set_ydata(newdata)

draw the canvas with

  fig.canvas.draw()

JDH

Hi everybody,

I want to modify a matplotlib.lines.Line2D and update the plot.
I have used Line2D._y member to modify the line. It works. But by doing
canvas.draw() (see example below), the line is not updated on the plot. To
update it, I have to do autoscale_view(). But I do not want the x and y
ranges of the plot to be changed.

How to do this?

Thanks in advance,

Julien

###################
from pylab import *
import matplotlib

ion()
f = figure()
s = f.add_subplot("111")

X1 = arange( 0.0, 5.0, 0.1 )
# print X1, X1**2
line = matplotlib.lines.Line2D( X1, X1**2 )


s.add_line( line )

draw()

raw_input("\npress a key to transform y in y+10")
line._y += 10

raw_input("\npress a key to do canvas.draw()")
s.figure.canvas.draw()
draw()
print "The line y has not been updated in y+10"

raw_input("\npress a key to do relim, autoscale and canvas.draw()")
s.relim()
s.autoscale_view()
s.figure.canvas.draw()
draw()
print "The line y has been updated in y+10"
print "But the subplot x and y range has changed"
print "I want the line to be updated without changing x and y ranges"

raw_input("\npress a key to quit")
#################

-- 
python -c "print ''.join([chr(154 - ord(c)) for c in '*9(9&(18%.\
9&1+,\'Z4(55l4('])"

"When a distinguished but elderly scientist states that something is
possible, he is almost certainly right. When he states that something is
impossible, he is very probably wrong." (first law of AC Clarke)

On Mon, Jun 15, 2009 at 7:38 AM, CaseyWeb<niw...@ho...> wrote:

> I installed this on python 2.6.2 using the windows installer (the .exe) but
> it crashes even on something as
> simple as importing pylab from the interactive prompt.  To make sure it
> wasn't a conflict with other packages, I created a clean virtualenv
> directory and installed matplotlib from the 2.6 egg, but the results are the
> same.  Trying to run any matplotlib example immediately creates a windows
> exception dialog.

Apparently the binaries are fine but the default matplotlib rc is
setting the backend to wxagg.  site-packages/matplotlib/mpl-data and
set

backend : TkAgg

See also http://matplotlib.sourceforge.net/users/customizing.html

Christoph, would you be able to rebuild the installers using TkAgg as
the default backend?  Basically, at build time, you need to copy
setup.cfg.template to setup.cfg and set the line

backend = TkAgg

There are additional details at

  http://matplotlib.sourceforge.net/devel/release_guide.html#packaging

and

  http://matplotlib.sourceforge.net/faq/installing_faq.html#backends


Thanks!
JDH