Triplot function problems

Hi,

I've been using mpl_tri package, from Ian Thomas, and recently the tri
module, from the svn repository.

When I use the triplot function with 100-1000 points it works well. The
problem is that in my work I often use grids with 30000-100000
  points. With those grids triplot takes a long time to compute (I never
wait for the results, it takes really a long time).
The matlab triplot function takes just a few seconds, with the same
grids). And when I was using mpl_tri package, I never had this problem
(the triplot function was faster!!!)

Does anyone have this problem?
How can I solve this?

Thank you in advace for any help,
Alberto

···

=======
E-mail verificado pelo Spyware Doctor � N�o foram encontrados v�rus ou spyware.
(Email Guard: 7.0.0.18, Base de dados de v�rus/spyware: 6.15350)
http://www.pctools.com/?cclick=EmailFooterClean_51

Hello again Alberto,

When I use the triplot function with 100-1000 points it works well. The

problem is that in my work I often use grids with 30000-100000

points. With those grids triplot takes a long time to compute (I never

wait for the results, it takes really a long time).

Yes, it does indeed take a long time for large grids. The bottleneck is line 51 in lib/matplotlib/tri/triplot - I use the plot command which creates a separate Line2D object for each edge in the triangulation, and there can be a lot of edges. There is an obvious improvement of replacing this with a single LineCollection object, but it would require some manipulation of the line styles, colours, etc that the plot command does and I don’t yet understand it sufficiently.

The matlab triplot function takes just a few seconds, with the same

grids).

It’s bad etiquette to indicate that matlab is faster when addressing people who give up their free time to improve matplotlib, and possibly counter-productive.

And when I was using mpl_tri package, I never had this problem

(the triplot function was faster!!!)

Not true, the final line in the now obsolete mpl_tri.triplot was exactly the same plot() command.

I’ll take a look at improving the performance, but it won’t for a few days.

Ian

···

On 4 July Alberto Azevedo wrote:

Hello Ian,

I’m really sorry for my comment, it was not my intention to offend
anyone.

You are absolutely right about that, therefore I would like to
apologize to all developers, in particular to you, for my comment
regarding the matlab comparison.

The only thing I can promise is that won’t happen again… sorry!!!

You said that the obsolete triplot has the same code lines. I don’t
know what has changed between the two versions, but the fact is that I
made many plots when I was using mpl_tri (yes, it take a while, but not
so long as with the new version).

Best regards,

Alberto

···

On 05-07-2010 9:17, Ian Thomas wrote:

Hello again Alberto,

On 4 July Alberto Azevedo > wrote:

When
I use the triplot function with 100-1000 points it works well. The

problem is that in my work I often use grids with 30000-100000

points. With those grids triplot takes a long time to compute (I never

wait for the results, it takes really a long time).

Yes, it does indeed take a long time for large grids. The bottleneck is
line 51 in lib/matplotlib/tri/triplot - I use the plot command which
creates a separate Line2D object for each edge in the triangulation,
and there can be a lot of edges. There is an obvious improvement of
replacing this with a single LineCollection object, but it would
require some manipulation of the line styles, colours, etc that the
plot command does and I don’t yet understand it sufficiently.

The
matlab triplot function takes just a few seconds, with the same

grids).

It’s bad etiquette to indicate that matlab is faster when addressing
people who give up their free time to improve matplotlib, and possibly
counter-productive.

And
when I was using mpl_tri package, I never had this problem

(the triplot function was faster!!!)

Not true, the final line in the now obsolete mpl_tri.triplot was
exactly the same plot() command.

I’ll take a look at improving the performance, but it won’t for a few
days.

Ian

=======
E-mail verificado pelo Spyware Doctor � N�o foram encontrados v�rus ou spyware.
(Email Guard: 7.0.0.18, Base de dados de v�rus/spyware: 6.15350)
http://www.pctools.com

Speaking for myself , I did not find your comment offensive. It is
true we are an all-volunteer organization and do not strive to
duplicate matlab, but I took your comment to mean that the plotting
could be done efficiently as evidenced by matlab, so there was no
algorithmic reason it should be as slow as it is. Those kinds of
comments, phrased gently and constructively, are generally welcome.
The tri functionality is quite new, not yet in any released versions
of mpl but that is soon to change, and often users have to pound on
new functionality for a while to shake out inefficiencies

As Ian noted, anywhere we use a long list of Line2D objects (or calls
to plot in a loop) is prone to be very slow, and we should be able to
get substantial performance improvements using a collection.

Cheers,
JDH

···

On Mon, Jul 5, 2010 at 4:36 AM, Alberto Azevedo <acoa@...866...> wrote:

I'm really sorry for my comment, it was not my intention to offend anyone.
You are absolutely right about that, therefore I would like to apologize to
all developers, in particular to you, for my comment regarding the matlab
comparison.
The only thing I can promise is that won't happen again... sorry!!!

This could be made much faster using a compound Path for the edges and
a single call to "plot" for the markers on the flattened array of
vertices. You would retain the generality of all the mpl markers in
this case, since you would be using "plot" for the verticies, but
might lose some of the generality of the line styles since we don't
have a class "LinePath" like we do in matplotlib.patches.PathPatch (eg
see http://matplotlib.sourceforge.net/examples/api/compound_path.html).
It would be nice to see an analogue or PathPatch
matplotlib.lines.LinePath that exposes the relevant bits of the Line2D
interface (set_linestyle) etc, but you can get most of this by setting
facecolor='None' in the PathPatch. In practice, you almost always
want a solid line for the edges I suspect.

In a nutshell, you could still support the plot format string but
manually pass it to Axes._process_plot_format. Use the returned
results to set the properties on a single call to plot for the
flattened array of vertex markers, and a single compound PathPatch
with no facecolor for the edges (or you could support the facecolor if
you want). Since PathPatch already supports linestyle, edgecolor and
linewidth, it should work. And Paths support masks, so you should be
able to integrate the masking but I am not sure about this part since
I haven't delved deeply enough into the tri code to see how masking is
applied.

JDH

···

On Mon, Jul 5, 2010 at 3:17 AM, Ian Thomas <ianthomas23@...564...> wrote:

Yes, it does indeed take a long time for large grids. The bottleneck is line
51 in lib/matplotlib/tri/triplot - I use the plot command which creates a
separate Line2D object for each edge in the triangulation, and there can be
a lot of edges. There is an obvious improvement of replacing this with a
single LineCollection object, but it would require some manipulation of the
line styles, colours, etc that the plot command does and I don't yet
understand it sufficiently.

With those grids triplot takes a long time to compute (I never

wait for the results, it takes really a long time).

Alberto, I’ve checked some triplot performance improvements into svn. Please can you try out the new version and see if it is OK for your needs.

···

On 4 July 2010 22:52, Alberto Azevedo wrote:

On 5 July 2010 17:40, John Hunter wrote:

Thanks for the guidance John; I’ve done exactly as you suggested.

Ian

Hello Ian and John,

It's perfect!!! Works very well!!!
Now it takes only 5 s to do the contour and triplot of a grid with 45000 nodes and 85000 elements/triangles.

Thank you very much for your support!!!

Best regards,
Alberto

···

=======
E-mail verificado pelo Spyware Doctor � N�o foram encontrados v�rus ou spyware.
(Email Guard: 7.0.0.18, Base de dados de v�rus/spyware: 6.15370)
http://www.pctools.com/?cclick=EmailFooterClean_51