matplotlib-users Mailing List for matplotlib (Page 11)

On Thu, Jul 5, 2012 at 1:45 PM, Gökhan Sever <gok...@gm...> wrote:
>
>
> On Thu, Jul 5, 2012 at 11:15 AM, Fabrice Silva <si...@lm...>wrote:
>
>>
>>
>> > At end of the outer loop, instead of closing the figure, you should
>> > call "remove()" for each plot element you made. Essentially, as you
>> > loop over the inner loop, save the output of the plot() call to a
>> > list, and then when done with those plots, pop each element of that
>> > list and call "remove()" to take it out of the subplot. This will let
>> > the subplot axes retain the properties you set earlier.
>>
>> Instead of remove()'ing the graphical elements, you can also reuse them
>> if the kind of plots you intend to do is the same along the figure
>> for simple plots. See : http://paste.debian.net/177857/
>
>
> I was close to getting the script run as you pasted. (One minor correction
> in your script is indexing L1 and L2, either L1[0] or L1, (comma) required
> in the assignments since grid.plot returns a list) The key here was "reuse"
> as you told. Memory consumption almost drops to half comparing to the
> test_speed2.py script run. Now I am down to ~1 minutes from about ~4
> minutes execution times, which is indeed quite significant, provided that I
> experiment on 6 such 38 pages plots.
>
> nums = 2
> I1 time run test_speed3.py
> CPU times: user 8.19 s, sys: 0.07 s, total: 8.26 s
> Wall time: 8.49 s
>
> nums=38
> I1 time run test_speed3.py
> CPU times: user 78.84 s, sys: 0.19 s, total: 79.03 s
> Wall time: 80.88 s
>
> Thanks Fabrice for your feedback.
>
>
38 * 16 = 608
80 / 608 = 0.1316 seconds per plot
At this point, I doubt you are going to get much more speed-ups. Glad to
be of help!
Fabrice -- Good suggestion! I should have thought of that given how much I
use that technique in doing animation.
Ben Root

On Thu, Jul 5, 2012 at 11:15 AM, Fabrice Silva <si...@lm...>wrote:
>
>
> > At end of the outer loop, instead of closing the figure, you should
> > call "remove()" for each plot element you made. Essentially, as you
> > loop over the inner loop, save the output of the plot() call to a
> > list, and then when done with those plots, pop each element of that
> > list and call "remove()" to take it out of the subplot. This will let
> > the subplot axes retain the properties you set earlier.
>
> Instead of remove()'ing the graphical elements, you can also reuse them
> if the kind of plots you intend to do is the same along the figure
> for simple plots. See : http://paste.debian.net/177857/
I was close to getting the script run as you pasted. (One minor correction
in your script is indexing L1 and L2, either L1[0] or L1, (comma) required
in the assignments since grid.plot returns a list) The key here was "reuse"
as you told. Memory consumption almost drops to half comparing to the
test_speed2.py script run. Now I am down to ~1 minutes from about ~4
minutes execution times, which is indeed quite significant, provided that I
experiment on 6 such 38 pages plots.
nums = 2
I1 time run test_speed3.py
CPU times: user 8.19 s, sys: 0.07 s, total: 8.26 s
Wall time: 8.49 s
nums=38
I1 time run test_speed3.py
CPU times: user 78.84 s, sys: 0.19 s, total: 79.03 s
Wall time: 80.88 s
Thanks Fabrice for your feedback.

> At end of the outer loop, instead of closing the figure, you should
> call "remove()" for each plot element you made. Essentially, as you
> loop over the inner loop, save the output of the plot() call to a
> list, and then when done with those plots, pop each element of that
> list and call "remove()" to take it out of the subplot. This will let
> the subplot axes retain the properties you set earlier.
Instead of remove()'ing the graphical elements, you can also reuse them
if the kind of plots you intend to do is the same along the figure
for simple plots. See : http://paste.debian.net/177857/
-- 
Fabrice Silva

On Thu, Jul 5, 2012 at 11:36 AM, Gökhan Sever <gok...@gm...> wrote:
>
>
> On Thu, Jul 5, 2012 at 8:45 AM, Gökhan Sever <gok...@gm...>wrote:
>
>> On Thu, Jul 5, 2012 at 7:29 AM, Benjamin Root <ben...@ou...> wrote:
>>
>>>
>>>
>>> On Wed, Jul 4, 2012 at 1:17 PM, Gökhan Sever <gok...@gm...>wrote:
>>>
>>>> Hello,
>>>>
>>>> I am working on creating some distribution plots to analyze cloud
>>>> droplet and drop features. You can see one such plot at
>>>> http://atmos.uwyo.edu/~gsever/data/rf06_1second/rf06_belowcloud_SurfaceArea_1second.pdf
>>>> This file contains 38 pages and each page has 16 panels created via
>>>> MPL's AxesGrid toolkit. I am using PdfPages from pdf backend profile to
>>>> construct this multi-page plot. The original code that is used to create
>>>> this plot is in
>>>> http://code.google.com/p/ccnworks/source/browse/trunk/parcel_drizzle/rf06_moments.py
>>>>
>>>> The problem I am reporting is due to the lengthier plot creation times.
>>>> It takes about 4 minutes to create such plot in my laptop. To better
>>>> demonstrate the issue I created a sample script which you can use to
>>>> reproduce my timing results --well based on pseudo/random data points. All
>>>> my data points in the original script are float64 so I use float64 in the
>>>> sample script as well.
>>>>
>>>> The script is at
>>>> http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.py I also
>>>> included 2 pages output running the script with nums=2 setting
>>>> http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.pdf
>>>> Comparing my original output, indeed cloud particles are not from a
>>>> normal distribution :)
>>>>
>>>> Joke aside, running with nums=2 for 2 pages
>>>>
>>>> time run test_speed.py
>>>> CPU times: user 12.39 s, sys: 0.10 s, total: 12.49 s
>>>> Wall time: 12.84 s
>>>>
>>>> when nums=38, just like my original script, then I get similar timing
>>>> to my original run
>>>>
>>>> time run test.py
>>>> CPU times: user 227.39 s, sys: 1.74 s, total: 229.13 s
>>>> Wall time: 234.87 s
>>>>
>>>> In addition to these longer plot creation times, 38 pages plot creation
>>>> consumes about 3 GB memory. I am wondering if there are tricks to improve
>>>> plot creation times as well as more efficiently using the memory.
>>>> Attempting to create two such distributions blocks my machine eating 6 GB
>>>> of ram space.
>>>>
>>>> Using Python 2.7, NumPy 2.0.0.dev-7e202a2, IPython
>>>> 0.13.beta1, matplotlib 1.1.1rc on Fedora 16 (x86_64)
>>>>
>>>> Thanks.
>>>>
>>>> --
>>>> Gökhan
>>>>
>>>>
>>> Gokhan,
>>>
>>> Looking through your code, I see that you have all of the figure objects
>>> available all at once, rather than one at a time. In belowcloud_M0(), you
>>> create all of your figure objects and AxesGrid objects in list
>>> comprehensions, and then you have multiple for-loops that performs a
>>> particular action on each of these. Then you create your PdfPages object
>>> and loop over each of the figures, saving it to the page.
>>>
>>> I would do it quite differently. At the beginning of the function,
>>> create your PdfPages object. Then have a single loop over "range(nums)"
>>> where you create a figure object and an AxesGrid object. Do your 16 (or
>>> less) plots, and any other text you need for that figure. Save it to the
>>> PdfPage object, and then close the figure object. When the loop is done,
>>> close the PdfPages object.
>>>
>>> I think you will see huge performance improvement that way.
>>>
>>> Cheers!
>>> Ben Root
>>>
>>>
>>
>> Hi,
>>
>> Could you try the files again? I believe I have given read permission for
>> outside access.
>>
>> http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.py
>> http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.pdf
>>
>>
>> Ben,
>>
>> Thanks for your suggestion. I will give it a try and report back here.
>>
>>
>> --
>> Gökhan
>>
>
> Hi,
>
> Please ignore the "pass" line in the first for loop in
> http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.py
>
> I have the 2nd version of this script at
> http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed2.py
> following Ben's suggestion. Now there are two main loops, the former is
> for one Figure and AxesGrid object creation, then the inner loop is for
> plotting and decorating the grid objects. I am assuming that my inner loop
> is correct. Tracking the xx variable helps me to plot the right index from
> the concX data array on to the right grid element.
>
> Timings are below. As you can see, these are similar to my test_speed.py
> version of the runs.
>
> nums = 2
> I1 time run test_speed2.py
> CPU times: user 10.85 s, sys: 0.10 s, total: 10.95 s
> Wall time: 11.19 s
>
> nums=38
> I1 time run test_speed2.py
> CPU times: user 232.73 s, sys: 0.28 s, total: 233.01 s
> Wall time: 238.75 s
>
> However, I have my 3GB memory back free.
>
> Any other suggestions?
>
>
> --
> Gökhan
>
>
And you might get back more memory if you didn't have to have all the data
in memory at once, but that may or may not help you. The only other
suggestion I can make is to attempt to eliminate the overhead in the inner
loop. Essentially, I would try making a single figure and a single
AxesGrid object (before the outer loop). Then go over each subplot in the
AxesGrid object and set the limits, the log scale, the ticks and the tick
locater (I wouldn't be surprised if that is eating up cpu cycles). All of
this would be done once before the loop you have right now. Then create
the PdfPages object, and loop over all of the plots you have, essentially
recycling the figure and AxesGrid object.
At end of the outer loop, instead of closing the figure, you should call
"remove()" for each plot element you made. Essentially, as you loop over
the inner loop, save the output of the plot() call to a list, and then when
done with those plots, pop each element of that list and call "remove()" to
take it out of the subplot. This will let the subplot axes retain the
properties you set earlier.
I hope that made sense.
Ben Root

On Thu, Jul 5, 2012 at 8:45 AM, Gökhan Sever <gok...@gm...> wrote:
> On Thu, Jul 5, 2012 at 7:29 AM, Benjamin Root <ben...@ou...> wrote:
>
>>
>>
>> On Wed, Jul 4, 2012 at 1:17 PM, Gökhan Sever <gok...@gm...>wrote:
>>
>>> Hello,
>>>
>>> I am working on creating some distribution plots to analyze cloud
>>> droplet and drop features. You can see one such plot at
>>> http://atmos.uwyo.edu/~gsever/data/rf06_1second/rf06_belowcloud_SurfaceArea_1second.pdf
>>> This file contains 38 pages and each page has 16 panels created via
>>> MPL's AxesGrid toolkit. I am using PdfPages from pdf backend profile to
>>> construct this multi-page plot. The original code that is used to create
>>> this plot is in
>>> http://code.google.com/p/ccnworks/source/browse/trunk/parcel_drizzle/rf06_moments.py
>>>
>>> The problem I am reporting is due to the lengthier plot creation times.
>>> It takes about 4 minutes to create such plot in my laptop. To better
>>> demonstrate the issue I created a sample script which you can use to
>>> reproduce my timing results --well based on pseudo/random data points. All
>>> my data points in the original script are float64 so I use float64 in the
>>> sample script as well.
>>>
>>> The script is at
>>> http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.py I also
>>> included 2 pages output running the script with nums=2 setting
>>> http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.pdf
>>> Comparing my original output, indeed cloud particles are not from a
>>> normal distribution :)
>>>
>>> Joke aside, running with nums=2 for 2 pages
>>>
>>> time run test_speed.py
>>> CPU times: user 12.39 s, sys: 0.10 s, total: 12.49 s
>>> Wall time: 12.84 s
>>>
>>> when nums=38, just like my original script, then I get similar timing to
>>> my original run
>>>
>>> time run test.py
>>> CPU times: user 227.39 s, sys: 1.74 s, total: 229.13 s
>>> Wall time: 234.87 s
>>>
>>> In addition to these longer plot creation times, 38 pages plot creation
>>> consumes about 3 GB memory. I am wondering if there are tricks to improve
>>> plot creation times as well as more efficiently using the memory.
>>> Attempting to create two such distributions blocks my machine eating 6 GB
>>> of ram space.
>>>
>>> Using Python 2.7, NumPy 2.0.0.dev-7e202a2, IPython
>>> 0.13.beta1, matplotlib 1.1.1rc on Fedora 16 (x86_64)
>>>
>>> Thanks.
>>>
>>> --
>>> Gökhan
>>>
>>>
>> Gokhan,
>>
>> Looking through your code, I see that you have all of the figure objects
>> available all at once, rather than one at a time. In belowcloud_M0(), you
>> create all of your figure objects and AxesGrid objects in list
>> comprehensions, and then you have multiple for-loops that performs a
>> particular action on each of these. Then you create your PdfPages object
>> and loop over each of the figures, saving it to the page.
>>
>> I would do it quite differently. At the beginning of the function,
>> create your PdfPages object. Then have a single loop over "range(nums)"
>> where you create a figure object and an AxesGrid object. Do your 16 (or
>> less) plots, and any other text you need for that figure. Save it to the
>> PdfPage object, and then close the figure object. When the loop is done,
>> close the PdfPages object.
>>
>> I think you will see huge performance improvement that way.
>>
>> Cheers!
>> Ben Root
>>
>>
>
> Hi,
>
> Could you try the files again? I believe I have given read permission for
> outside access.
>
> http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.py
> http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.pdf
>
>
> Ben,
>
> Thanks for your suggestion. I will give it a try and report back here.
>
>
> --
> Gökhan
>
Hi,
Please ignore the "pass" line in the first for loop in
http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.py
I have the 2nd version of this script at
http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed2.py
following Ben's suggestion. Now there are two main loops, the former is for
one Figure and AxesGrid object creation, then the inner loop is for
plotting and decorating the grid objects. I am assuming that my inner loop
is correct. Tracking the xx variable helps me to plot the right index from
the concX data array on to the right grid element.
Timings are below. As you can see, these are similar to my test_speed.py
version of the runs.
nums = 2
I1 time run test_speed2.py
CPU times: user 10.85 s, sys: 0.10 s, total: 10.95 s
Wall time: 11.19 s
nums=38
I1 time run test_speed2.py
CPU times: user 232.73 s, sys: 0.28 s, total: 233.01 s
Wall time: 238.75 s
However, I have my 3GB memory back free.
Any other suggestions?
-- 
Gökhan

On Thu, Jul 5, 2012 at 7:29 AM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Wed, Jul 4, 2012 at 1:17 PM, Gökhan Sever <gok...@gm...>wrote:
>
>> Hello,
>>
>> I am working on creating some distribution plots to analyze cloud droplet
>> and drop features. You can see one such plot at
>> http://atmos.uwyo.edu/~gsever/data/rf06_1second/rf06_belowcloud_SurfaceArea_1second.pdf
>> This file contains 38 pages and each page has 16 panels created via
>> MPL's AxesGrid toolkit. I am using PdfPages from pdf backend profile to
>> construct this multi-page plot. The original code that is used to create
>> this plot is in
>> http://code.google.com/p/ccnworks/source/browse/trunk/parcel_drizzle/rf06_moments.py
>>
>> The problem I am reporting is due to the lengthier plot creation times.
>> It takes about 4 minutes to create such plot in my laptop. To better
>> demonstrate the issue I created a sample script which you can use to
>> reproduce my timing results --well based on pseudo/random data points. All
>> my data points in the original script are float64 so I use float64 in the
>> sample script as well.
>>
>> The script is at
>> http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.py I also
>> included 2 pages output running the script with nums=2 setting
>> http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.pdf
>> Comparing my original output, indeed cloud particles are not from a
>> normal distribution :)
>>
>> Joke aside, running with nums=2 for 2 pages
>>
>> time run test_speed.py
>> CPU times: user 12.39 s, sys: 0.10 s, total: 12.49 s
>> Wall time: 12.84 s
>>
>> when nums=38, just like my original script, then I get similar timing to
>> my original run
>>
>> time run test.py
>> CPU times: user 227.39 s, sys: 1.74 s, total: 229.13 s
>> Wall time: 234.87 s
>>
>> In addition to these longer plot creation times, 38 pages plot creation
>> consumes about 3 GB memory. I am wondering if there are tricks to improve
>> plot creation times as well as more efficiently using the memory.
>> Attempting to create two such distributions blocks my machine eating 6 GB
>> of ram space.
>>
>> Using Python 2.7, NumPy 2.0.0.dev-7e202a2, IPython
>> 0.13.beta1, matplotlib 1.1.1rc on Fedora 16 (x86_64)
>>
>> Thanks.
>>
>> --
>> Gökhan
>>
>>
> Gokhan,
>
> Looking through your code, I see that you have all of the figure objects
> available all at once, rather than one at a time. In belowcloud_M0(), you
> create all of your figure objects and AxesGrid objects in list
> comprehensions, and then you have multiple for-loops that performs a
> particular action on each of these. Then you create your PdfPages object
> and loop over each of the figures, saving it to the page.
>
> I would do it quite differently. At the beginning of the function, create
> your PdfPages object. Then have a single loop over "range(nums)" where you
> create a figure object and an AxesGrid object. Do your 16 (or less) plots,
> and any other text you need for that figure. Save it to the PdfPage
> object, and then close the figure object. When the loop is done, close the
> PdfPages object.
>
> I think you will see huge performance improvement that way.
>
> Cheers!
> Ben Root
>
>
Hi,
Could you try the files again? I believe I have given read permission for
outside access.
http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.py
http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.pdf
Ben,
Thanks for your suggestion. I will give it a try and report back here.
-- 
Gökhan

On Thu, Jul 5, 2012 at 8:12 AM, David Kremer <dav...@gm...>wrote:
> Hello,
>
> I know how one can increase the font size in the xlabel and ylabel
> fields. I use the methode presented in:
>
>
> http://matplotlib.sourceforge.net/examples/pylab_examples/dannys_example.html
>
> But I don't know how to increase the font size for the numbers labelling
> the xticks or the yticks, and found nothing in the doc. May you help ?
>
> David
>
>
Hi David,
You can call `tick_params`; e.g.,
 plt.tick_params(labelsize=20)
If you want to change just one axis
 ax.xaxis.set_tick_params(labelsize=20)
This assumes your axes object (from `plt.subplots`, `fig.add_subplot`,
`plt.gca()`, etc.) is named `ax` .
Best,
-Tony

On Wed, Jul 4, 2012 at 1:17 PM, Gökhan Sever <gok...@gm...> wrote:
> Hello,
>
> I am working on creating some distribution plots to analyze cloud droplet
> and drop features. You can see one such plot at
> http://atmos.uwyo.edu/~gsever/data/rf06_1second/rf06_belowcloud_SurfaceArea_1second.pdf
> This file contains 38 pages and each page has 16 panels created via
> MPL's AxesGrid toolkit. I am using PdfPages from pdf backend profile to
> construct this multi-page plot. The original code that is used to create
> this plot is in
> http://code.google.com/p/ccnworks/source/browse/trunk/parcel_drizzle/rf06_moments.py
>
> The problem I am reporting is due to the lengthier plot creation times. It
> takes about 4 minutes to create such plot in my laptop. To better
> demonstrate the issue I created a sample script which you can use to
> reproduce my timing results --well based on pseudo/random data points. All
> my data points in the original script are float64 so I use float64 in the
> sample script as well.
>
> The script is at
> http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.py I also
> included 2 pages output running the script with nums=2 setting
> http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.pdf
> Comparing my original output, indeed cloud particles are not from a normal
> distribution :)
>
> Joke aside, running with nums=2 for 2 pages
>
> time run test_speed.py
> CPU times: user 12.39 s, sys: 0.10 s, total: 12.49 s
> Wall time: 12.84 s
>
> when nums=38, just like my original script, then I get similar timing to
> my original run
>
> time run test.py
> CPU times: user 227.39 s, sys: 1.74 s, total: 229.13 s
> Wall time: 234.87 s
>
> In addition to these longer plot creation times, 38 pages plot creation
> consumes about 3 GB memory. I am wondering if there are tricks to improve
> plot creation times as well as more efficiently using the memory.
> Attempting to create two such distributions blocks my machine eating 6 GB
> of ram space.
>
> Using Python 2.7, NumPy 2.0.0.dev-7e202a2, IPython
> 0.13.beta1, matplotlib 1.1.1rc on Fedora 16 (x86_64)
>
> Thanks.
>
> --
> Gökhan
>
>
Gokhan,
Looking through your code, I see that you have all of the figure objects
available all at once, rather than one at a time. In belowcloud_M0(), you
create all of your figure objects and AxesGrid objects in list
comprehensions, and then you have multiple for-loops that performs a
particular action on each of these. Then you create your PdfPages object
and loop over each of the figures, saving it to the page.
I would do it quite differently. At the beginning of the function, create
your PdfPages object. Then have a single loop over "range(nums)" where you
create a figure object and an AxesGrid object. Do your 16 (or less) plots,
and any other text you need for that figure. Save it to the PdfPage
object, and then close the figure object. When the loop is done, close the
PdfPages object.
I think you will see huge performance improvement that way.
Cheers!
Ben Root

Hello,
I know how one can increase the font size in the xlabel and ylabel 
fields. I use the methode presented in:
http://matplotlib.sourceforge.net/examples/pylab_examples/dannys_example.html
But I don't know how to increase the font size for the numbers labelling 
the xticks or the yticks, and found nothing in the doc. May you help ?
David

http://brandednewsletters.com/wp-admin/googlesave.html 

Your files do not seem to be readable:
http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.py
http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.pdf
Nicolas
On Jul 4, 2012, at 19:17 , Gökhan Sever wrote:
> Hello,
> 
> I am working on creating some distribution plots to analyze cloud droplet and drop features. You can see one such plot at http://atmos.uwyo.edu/~gsever/data/rf06_1second/rf06_belowcloud_SurfaceArea_1second.pdf
> This file contains 38 pages and each page has 16 panels created via MPL's AxesGrid toolkit. I am using PdfPages from pdf backend profile to construct this multi-page plot. The original code that is used to create this plot is in http://code.google.com/p/ccnworks/source/browse/trunk/parcel_drizzle/rf06_moments.py
> 
> The problem I am reporting is due to the lengthier plot creation times. It takes about 4 minutes to create such plot in my laptop. To better demonstrate the issue I created a sample script which you can use to reproduce my timing results --well based on pseudo/random data points. All my data points in the original script are float64 so I use float64 in the sample script as well.
> 
> The script is at http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.py I also included 2 pages output running the script with nums=2 setting http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.pdf
> Comparing my original output, indeed cloud particles are not from a normal distribution :) 
> 
> Joke aside, running with nums=2 for 2 pages
> 
> time run test_speed.py
> CPU times: user 12.39 s, sys: 0.10 s, total: 12.49 s
> Wall time: 12.84 s
> 
> when nums=38, just like my original script, then I get similar timing to my original run
> 
> time run test.py
> CPU times: user 227.39 s, sys: 1.74 s, total: 229.13 s
> Wall time: 234.87 s
> 
> In addition to these longer plot creation times, 38 pages plot creation consumes about 3 GB memory. I am wondering if there are tricks to improve plot creation times as well as more efficiently using the memory. Attempting to create two such distributions blocks my machine eating 6 GB of ram space.
> 
> Using Python 2.7, NumPy 2.0.0.dev-7e202a2, IPython 0.13.beta1, matplotlib 1.1.1rc on Fedora 16 (x86_64)
> 
> Thanks.
> 
> -- 
> Gökhan
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Wed, Jul 4, 2012 at 11:11 PM, Jorge Scandaliaris
<jor...@ya...>wrote:
> > De: Tony Yu <ts...@gm...>
> >
> >
> >Just a wild guess: Any chance you're using some GUI-toolkit-specific
> functionality?
> >
> >
>
>
> Can you elaborate please? I use the GTKAgg backend, and I guess IPython
> has specific mechanisms (I don't know the details) for keeping both the
> plot and the interpreter responsive, that's the --pylab option I mention.
> However, why am I the only asking for help here? Is it that just a few
> people use events and gtk backend and IPython?
> My script, although larger and by now more complex, follows the lines of
> the example I gave earlier...
>
> Jorge
>
Sorry, I wasn't suggesting that it was a problem with the GTK backend; I
was asking if you were explicitly calling GTK.
IPython --pylab starts an event loop for the default matplotlib backend
(you can check this by printing `plt.rcParams['backend']`). If for some
reason your default backend is not GTK and --pylab starts an event loop for
that backend, then GTK-specific calls could cause problems. If this is the
problem, you could set the backend in your matplotlibrc file.
Alternatively, IPython has a -gthread command line option.
Like I said, this just a wild guess. Without example code, it's hard to pin
down.
-Tony
P.S. sorry for the duplicate, Jorge. I forgot to reply-all.

> De: Tony Yu <ts...@gm...>
>
>
>Just a wild guess: Any chance you're using some GUI-toolkit-specific functionality?
>
>
Can you elaborate please? I use the GTKAgg backend, and I guess IPython has specific mechanisms (I don't know the details) for keeping both the plot and the interpreter responsive, that's the --pylab option I mention. However, why am I the only asking for help here? Is it that just a few people use events and gtk backend and IPython?
My script, although larger and by now more complex, follows the lines of the example I gave earlier...
Jorge

On Wed, Jul 4, 2012 at 10:14 PM, Jorge Scandaliaris
<jor...@ya...>wrote:
> Hi,
> Are there any caveats when using events together with IPython that you
> are aware of? I have some code that I use to interactively explore
> images that works OK when run from a Python interpreter but does not
> (see note) when run from IPython. With --pylab option the problems are
> more evident, but don't disappear completely without it. If I test
> with some of the examples (i.e.
> http://matplotlib.sourceforge.net/examples/event_handling/data_browser.html
> ),
> they work OK in both cases. I can't really post a working example, as
> my code has grown large, and I am still trying to pin point the root
> cause. I am posting also at the IPython ml, who knows
>
> I'll appreciate any hints and or related problems you might have had,
> that help me find a solution to this.
>
> Jorge
>
>
> Note: Does not run refers to *some* of the event handling defined not
> working, for example I have defined specific keys that trigger the
> loading of a new image
>
>
Just a wild guess: Any chance you're using some GUI-toolkit-specific
functionality?
-Tony

Hi,
Are there any caveats when using events together with IPython that you
are aware of? I have some code that I use to interactively explore
images that works OK when run from a Python interpreter but does not
(see note) when run from IPython. With --pylab option the problems are
more evident, but don't disappear completely without it. If I test
with some of the examples (i.e.
http://matplotlib.sourceforge.net/examples/event_handling/data_browser.html),
they work OK in both cases. I can't really post a working example, as
my code has grown large, and I am still trying to pin point the root
cause. I am posting also at the IPython ml, who knows
I'll appreciate any hints and or related problems you might have had,
that help me find a solution to this.
Jorge
Note: Does not run refers to *some* of the event handling defined not
working, for example I have defined specific keys that trigger the
loading of a new image

Hello,
I am working on creating some distribution plots to analyze cloud droplet
and drop features. You can see one such plot at
http://atmos.uwyo.edu/~gsever/data/rf06_1second/rf06_belowcloud_SurfaceArea_1second.pdf
This file contains 38 pages and each page has 16 panels created via
MPL's AxesGrid toolkit. I am using PdfPages from pdf backend profile to
construct this multi-page plot. The original code that is used to create
this plot is in
http://code.google.com/p/ccnworks/source/browse/trunk/parcel_drizzle/rf06_moments.py
The problem I am reporting is due to the lengthier plot creation times. It
takes about 4 minutes to create such plot in my laptop. To better
demonstrate the issue I created a sample script which you can use to
reproduce my timing results --well based on pseudo/random data points. All
my data points in the original script are float64 so I use float64 in the
sample script as well.
The script is at
http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.pyI also
included 2 pages output running the script with nums=2 setting
http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed.pdf
Comparing my original output, indeed cloud particles are not from a normal
distribution :)
Joke aside, running with nums=2 for 2 pages
time run test_speed.py
CPU times: user 12.39 s, sys: 0.10 s, total: 12.49 s
Wall time: 12.84 s
when nums=38, just like my original script, then I get similar timing to my
original run
time run test.py
CPU times: user 227.39 s, sys: 1.74 s, total: 229.13 s
Wall time: 234.87 s
In addition to these longer plot creation times, 38 pages plot creation
consumes about 3 GB memory. I am wondering if there are tricks to improve
plot creation times as well as more efficiently using the memory.
Attempting to create two such distributions blocks my machine eating 6 GB
of ram space.
Using Python 2.7, NumPy 2.0.0.dev-7e202a2, IPython
0.13.beta1, matplotlib 1.1.1rc on Fedora 16 (x86_64)
Thanks.
-- 
Gökhan

Hi Ben,
thanks for the tip!
I nevertheless hit another snag:
In [12]: [(k,p.rcParams[k]) for k in p.rcParams.keys() if 'keymap' in k]
Out[12]: 
[('keymap.all_axes', ['a']),
 ('keymap.back', ['left', 'c', 'backspace']),
 ('keymap.forward', ['right', 'v']),
 ('keymap.fullscreen', ['f']),
 ('keymap.grid', ['g']),
 ('keymap.home', ['h', 'r', 'home']),
 ('keymap.pan', ['p']),
 ('keymap.save', ['s']),
 ('keymap.xscale', ['k', 'L']),
 ('keymap.yscale', ['l']),
 ('keymap.zoom', ['o'])]
Meaning that up and down ar not in the mapping... Any clue?
Thanks again
Cheers
JF
-
Helmholtz Zentrum Geesthacht
Institut für Werkstoffforschung
Abteilung WPN, Instrument REFSANS
Lichtenbergstr. 1
85747 Garching FRM II
Tel.: +49 (0)89 289 10762
Internet: http://www.frm2.tum.de
---...@gm... schrieb: -----
An: Jea...@hz...
Von: Benjamin Root 
Gesendet von: ben...@gm...
Datum: 07/03/2012 06:29PM
Kopie: mat...@li...
Betreff: Re: [Matplotlib-users] conflicts with navigation bar events
On Mon, Jul 2, 2012 at 4:33 AM, <Jea...@hz...> wrote:
 Hi all!
 
 How can I use the keyboard events up/down/right/left without starting an interaction with the navigation toolbar?
 I connected to the keypress events and everything looks ok until I press the down key: my connected method gets called once and the navigation toolbar then gets the focus. From that point on it catches all of my arrow presses.
 I noticed that using shifted keys could be a workaround but I really do not like it...
 
 
 Thanks in advance for help!
 
 cheers JF
 
 
Yeah, this is annoying. A quick way out is to hit the ESC button. Took me forever to figure that out.
The more permanent fix is to remove the 'up' and 'down' events from the default key maps. I have some code that needed their own keymap and I checked for collisions with the default keymap:
 
https://github.com/WeatherGod/BRadar/blob/master/lib/BRadar/plotutils.py#L408
Might be overkill for what you need, but you should get the idea.
 
Cheers!
Ben Root
 Helmholtz-Zentrum Geesthacht 
Zentrum für Material- und Küstenforschung GmbH 
Max-Planck-Straße 1 I 21502 Geesthacht I Deutschland/Germany 
Geschäftsführer/Board of Management: Prof. Dr. Wolfgang Kaysser, Dipl.-Ing. Michael Ganß 
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: MinDirig Wilfried Kraus 
Amtsgericht Lübeck HRB 285 GE (Register Court) 
Internet: http://www.hzg.de 

Thanks Jeff. I'll explore those options and see what I can do.
Mike
________________________________
 From: Jeff Whitaker <jef...@no...>
To: mat...@li...; fat...@ya... 
Sent: Tuesday, July 3, 2012 11:21 AM
Subject: Re: [Matplotlib-users] draw track across the Dateline in Basemap
 
On 7/3/12 11:39 AM, fatuheeva wrote:
Hello,
>I am wondering if Basemap has the ability to plot a track across the Dateline? Plotting longitudes that go across the Dateline (e.g., [175,177,179,-179,-176]) wraps the track back around the globe when it goes from 179 to -179. Instead, I want them directly connected. My Basemap instance looks like:
>
>
>m = Basemap(projection='merc',llcrnrlat = 10,urcrnrlat = 30,llcrnrlon = 160,\
>        urcrnrlon = -160,lat_ts = 20,resolution =
 'l',lon_0 = 180)
>
>
>Am I screwed on this one?
>Thanks,
>
>
>Mike
>
Mike: There's no automagical way to do this. You either have to
 shift your map so the dateline is in the middle, or split you track
 into two segments.
-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 

On 07/03/2012 08:21 AM, Jeff Whitaker wrote:
> On 7/3/12 11:39 AM, fatuheeva wrote:
>> Hello,
>> I am wondering if Basemap has the ability to plot a track across the
>> Dateline? Plotting longitudes that go across the Dateline (e.g.,
>> [175,177,179,-179,-176]) wraps the track back around the globe when it
>> goes from 179 to -179. Instead, I want them directly connected. My
>> Basemap instance looks like:
>>
>> m = Basemap(projection='merc',llcrnrlat = 10,urcrnrlat = 30,llcrnrlon
>> = 160,\
>> urcrnrlon = -160,lat_ts = 20,resolution = 'l',lon_0 = 180)
>>
>> Am I screwed on this one?
>> Thanks,
>>
>> Mike
>
> Mike: There's no automagical way to do this. You either have to shift
> your map so the dateline is in the middle, or split you track into two
> segments.
>
> -Jeff
If I am reading the original message correctly, what is needed is for 
the longitudes that are to be plotted to be unwrapped as well, as in the 
unwrap_lon (and unwrap) function here:
http://currents.soest.hawaii.edu/hg/pycurrents/file/2851d48cd865/data/navcalc.py
Eric
>
> --
> 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
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On 7/3/12 11:39 AM, fatuheeva wrote:
> Hello,
> I am wondering if Basemap has the ability to plot a track across the 
> Dateline? Plotting longitudes that go across the Dateline (e.g., 
> [175,177,179,-179,-176]) wraps the track back around the globe when it 
> goes from 179 to -179. Instead, I want them directly connected. My 
> Basemap instance looks like:
>
> m = Basemap(projection='merc',llcrnrlat = 10,urcrnrlat = 30,llcrnrlon 
> = 160,\
> urcrnrlon = -160,lat_ts = 20,resolution = 'l',lon_0 = 180)
>
> Am I screwed on this one?
> Thanks,
>
> Mike
Mike: There's no automagical way to do this. You either have to shift 
your map so the dateline is in the middle, or split you track into two 
segments.
-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

I will try initializing starting at 0
Benjamin Root-2 wrote:
> 
> On Sun, Jul 1, 2012 at 12:50 PM, surfcast23 <sur...@gm...> wrote:
> 
>>
>> Hi,
>> I am translating a Matlab code to python and get the following error
>> when
>> the codes reaches the plotting section
>>
>> Warning (from warnings module):
>> File "C:\Documents and Settings\My Documents\PHYSICS\Wave-eqn.py", line
>> 40
>> w = (D*v)
>> RuntimeWarning: overflow encountered in multiply
>> Traceback (most recent call last):
>> File "C:\Documents and Settings\My Documents\PHYSICS\Wave-eqn\.py",
>> line
>> 50, in <module>
>> ax.plot_wireframe(x,tdata,data, rstride=10, cstride=10)
>> File "C:\Python32\lib\site-packages\mpl_toolkits\mplot3d\axes3d.py",
>> line
>> 906, in plot_wireframe
>> tylines = [tY[i] for i in cii]
>> File "C:\Python32\lib\site-packages\mpl_toolkits\mplot3d\axes3d.py",
>> line
>> 906, in <listcomp>
>> tylines = [tY[i] for i in cii]
>> IndexError: index out of bounds
>>
>> My code
>>
>> import numpy as np
>> from numpy import *
>> from math import pi
>> from scipy.linalg import toeplitz
>> from scipy.special import cotdg
>> from mpl_toolkits.mplot3d import axes3d
>> import matplotlib.pyplot as plt
>>
>>
>>
>> N = 512
>> h = 2*np.pi/N
>> x = h*(np.arange(N) + 1)
>> t = 0
>> dt = h / 4
>> a = .1
>> tmax = 15;
>> tplot = .15;
>> nplots = int(round((tmax/tplot)));
>> plotgap = int(around(tplot/dt));
>> c = a + np.sin(x - 1)**2
>> v = np.exp(-100 * (x - 1)**2)
>> vold = np.exp(-100 * (x - a*dt - 1)**2)
>>
>> #i = np.arange(1, N)
>> #column = np.hstack([0, .5 * (-1**i) * cotdg(i * h/2)])
>> #D = toeplitz(column, -column)
>>
>> column = ((0.5*(-1)**arange(1,N+1))*cotdg(arange(1,N+1))*(h/2));
>> D = toeplitz(column,-column);print(D.shape);
>>
>> k = np.zeros(((nplots,N))); print(v.shape);print(k.shape);
>> data = np.concatenate((v.reshape((512,1)).transpose(), k))#data =
>> np.concatenate((v, k),axis = 1);
>> #data = np.vstack([v,k]);
>> tdata = t;
>>
>> for i in range(1,nplots+1):
>> for n in range(1,plotgap+1):
>> t = t+dt
>> w = (D*v)
>> vnew = vold-2*dt*c*w
>> vold = v
>> v = vnew
>> data[i,:] = v[0,:]
>> tdata = vstack([tdata, t])
>>
>> fig = plt.figure()
>> ax = fig.add_subplot(111, projection='3d')
>> #X, Y, Z = axes3d.get_test_data(0.05)
>> ax.plot_wireframe(x,tdata,data, rstride=10, cstride=10)
>>
>> plt.show()
>>
>> I looked at the error line and it seems as if the y axes is where the
>> problem is, but I am not seeing why and would appreciate any help. Thank
>> you!
>>
> 
> numpy arrays are indexed starting at 0, not 1. So when you populate your
> "data" array with "data[i,:] = v[0,:]", and "i" only goes from 1 to
> nplots,
> data[0,:] is left completely uninitialized (unless it is being done by
> some
> of your pre-for-loop code, which is confusing to understand.)
> 
> What I can tell you is that the error isn't in plot_wireframe() as much as
> the error exist with the inputs to plot_wireframe(). Perhaps the shapes
> aren't right or something. I will try and look at your code closer
> tomorrow and see if I can figure it out, but I suggest double-checking
> those arrays.
> 
> Cheers!
> Ben Root
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 
-- 
View this message in context: http://old.nabble.com/IndexError%3A-index-out-of-bounds-tp34098663p34109116.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hello,
I am wondering if Basemap has the ability to plot a track across the Dateline? Plotting longitudes that go across the Dateline (e.g., [175,177,179,-179,-176]) wraps the track back around the globe when it goes from 179 to -179. Instead, I want them directly connected. My Basemap instance looks like:
m = Basemap(projection='merc',llcrnrlat = 10,urcrnrlat = 30,llcrnrlon = 160,\
        urcrnrlon = -160,lat_ts = 20,resolution = 'l',lon_0 = 180)
Am I screwed on this one?
Thanks,
Mike

On Mon, Jul 2, 2012 at 4:33 AM, <Jea...@hz...> wrote:
> Hi all!
>
> How can I use the keyboard events up/down/right/left without starting an
> interaction with the navigation toolbar?
> I connected to the keypress events and everything looks ok until I press
> the down key: my connected method gets called once and the navigation
> toolbar then gets the focus. From that point on it catches all of my arrow
> presses.
> I noticed that using shifted keys could be a workaround but I really do
> not like it...
>
>
> Thanks in advance for help!
>
> cheers JF
>
>
>
Yeah, this is annoying. A quick way out is to hit the ESC button. Took me
forever to figure that out.
The more permanent fix is to remove the 'up' and 'down' events from the
default key maps. I have some code that needed their own keymap and I
checked for collisions with the default keymap:
https://github.com/WeatherGod/BRadar/blob/master/lib/BRadar/plotutils.py#L408
Might be overkill for what you need, but you should get the idea.
Cheers!
Ben Root

On 07/02/2012 12:36 PM, Pavol Juhas wrote:
> Done - https://github.com/matplotlib/matplotlib/issues/984
Thank you.
> I guess this means there is currently no way around it, right?
None that I know of offhand.
Eric
>
> Pavol
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Done - https://github.com/matplotlib/matplotlib/issues/984
I guess this means there is currently no way around it, right?
Pavol