matplotlib-users Mailing List for matplotlib

Is it currently possible to make contour plots using unstructured data 
with matplotlib?

By unstructured data I mean the typical data from a 2D finite element 
simulation that
uses an unstructured polygonal mesh.

As far as I can tell the "pylab.contourf(X, Y, Z)" command requires 
structured data with X, Y
and Z each having to be 2D gridded arrays.

I have previously used the gist package to do this type of plotting 
using the
"gist.plfp(Z, X, Y, F)"  command. This command allows plotting of 
polygonal data
specified by arrays Z, X, Y, F.

     - Z is the data value, shape(Z) = (NPolygons)
     - X is the vertex x coordinates, shape(X) = (NPolygons, NVertices).
     - Y is vertex y coordinates, shape(Y) = (NPolygons, NVertices)
     - F is the number of vertices for each cell, shape(F) = (NPolygons)

Is there a similar functionality in matplotlib?

Thanks

-------------------------------------
Daniel Wheeler

On Thu, 21 Apr 2005 08:27:41 -0700 (PDT), Michael Brady
<mb...@jp...> wrote :

> Hi Olive,
> 
> I've had similar problems on both Solaris 8 and 9.  By running python 
> under truss:
> 
>    truss python
> 
> I saw that the "illegal instruction" and core dump was happening in
> the freetype libraries.  I had built freetype 2.1.9 myself.  When I
> deleted my own libfreetype.* and instead used the prebuilt versions 
> /usr/sfw/lib/libfreetype.* my crashes went away.
> 
> (Note that /usr/sfw/lib is the Solaris 9 location.  I'm not sure if
> it's the Solaris 8 location or not).
> 
> I had built libfreetype.6.3.7 (freetype 2.1.9) and /usr/sfw/lib
> contained the earlier version libfreetype.6.3.1 . I don't whether this
> is a Solaris-only bug in later versions of freetype, or if the
> /usr/sfw/lib versions were built a different way than I built mine.
> 
> Anyway, that's how I solved the problem.
> 
> I would suggest that you try:
> 
> (1)  Finding the Sun-supplied libfreetype.so binaries and using those,
> or(2)  building the version of libfreetype that produces
> libfreetype.6.3.1.
> 
> Please let me know how you solve the problem.
> 
> Good luck!
> 

Hello Michael,

Like I said I solved temporarily the problem by editing the file
ft2font.cpp (from matplotlib !) at line 354 :
const char* ps_name = FT_Get_Postscript_Name(face );

I replaced it by :
const char* ps_name = NULL;

It's just a quick and dirty hack while waiting for a clean patch from
either matplotlib or freetype.
I still don't know wether it's a bug from matplotlib or freetype,
because I don't know what is the argument 'face' and what is inside...
I don't understand a thing in C++ so I can't be of much help here...

But I was working with freetype 2.1.7, I have also tried with 2.1.9 and
I also have a core dumped but no at the same place !
Don't know if my hack could work also with 2.1.9 ?
I can test if you're interested.

P.S. : I couldn't help noticing your email address, I'm also working on
space rockets but in France and also trying to promote matplotlib here !
;-)

I am trying to scale the y axis like this:

a = axes(gca())
a.set_ylim((-1.25, 1.25))

This works fine when yticks is non-empty. However, if I do

a.set_yticks([])

either before or after the set_ylim call, the y axis is not scaled.

I also tried to use

a.yaxis.set_major_locator(NullLocator())

instead of calling set_yticks([]), but to no avail.

Any suggestions are appreciated. 

Grig

Hi Olive,

I've had similar problems on both Solaris 8 and 9.  By running python 
under truss:

   truss python

I saw that the "illegal instruction" and core dump was happening in the 
freetype libraries.  I had built freetype 2.1.9 myself.  When I deleted my 
own libfreetype.* and instead used the prebuilt versions 
/usr/sfw/lib/libfreetype.* my crashes went away.

(Note that /usr/sfw/lib is the Solaris 9 location.  I'm not sure if it's 
the Solaris 8 location or not).

I had built libfreetype.6.3.7 (freetype 2.1.9) and /usr/sfw/lib contained 
the earlier version libfreetype.6.3.1 . I don't whether this is a 
Solaris-only bug in later versions of freetype, or if the /usr/sfw/lib 
versions were built a different way than I built mine.

Anyway, that's how I solved the problem.

I would suggest that you try:

(1)  Finding the Sun-supplied libfreetype.so binaries and using those, or
(2)  building the version of libfreetype that produces libfreetype.6.3.1.

Please let me know how you solve the problem.

Good luck!

--Michael Brady

Hello, I have been using Matplotlib lately for some
academic research. It seem to work just fine. The only
serious problem is a problem with memory. When I run
the following code, I get the memory increasing
linearly with the time. Soon (after around 20
generations, and 100 times is this part of the program
 called) I get beyond the limits of my laptop, and the
simulation ends. Considering that I need to do at
least 200 generations, you can see that it is a
serious problem.

If I comment the savefig line the memory does not
grow.
I tried to add a garbage collection but I got no
result.

Data is a list of list of data: i.e.
[[1,2,3][2,7,8][32,45,67]]
symbol2color a dictionary that for each list gives a
different color.


def fillstrip(lower,upper,color):
    reppu=upper[:]
    reppu.reverse()
    y=lower+reppu
    x1 = range(0, len(lower), 1)
    x2 = x1[:]
    x2.reverse()
    x=x1+x2
    fill(x, y, color)


def area(data,color):
    "like the area matlab function"
    lower=[0]*len(data[0])
    for (upper,c) in zip(data,color):
        upper=map((lambda x,y:x+y),lower,upper)
        fillstrip(lower,upper,c)
        lower=upper

def PlotAreaOrganization(data,filename):
    keys=symbol2color.keys()
    keys.sort()
    colors=[]
    for key in keys:  colors.append(symbol2color[key])
    fig=figure(dpi=75)
    area(data,colors)
    savefig(filename)
    close(fig)


Any suggestion? Is there any other way to save a
picture that might work better?

Pietro

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com