matplotlib-users Mailing List for matplotlib

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.