matplotlib-devel Mailing List for matplotlib

Hi,

My research is in computational fluid dynamics (specifically, the
meteorologies of planetary atmospheres).  Working contour and vector plots
in matplotlib would make it possible for me to make 2D meteorological maps
of atmospheric layers, etc.

I noticed for the first time in the goals page that contour plots are
being worked on, apparently by STSci.  I have been considering
implementing these two plot types as sets of line collections, but now
that I know contour plots are being worked on, and vector plots are
simpler to implement (in 2D), I will work on making vector plots.  The
mathematics is fairly straightforward.  I just need to learn how to use
the class library.

About contour plots, however, I have a couple of questions.  How is it
being implemented?  I was about to try to write a marching squares
contouring routine, although it might have been painfully slow in Python.
Does anyone have experience with this?

Cheers,
Curtis

Hey John,

I've added code to ipython to wrap use() to prevent users from switching 
backends interactively, since this will instantly crash things badly.  It's a 
nice example of how python's dynamic nature allows you to tweak a module from 
the outside, without having to poke at its source.  I now see could have done 
this for the show() problem as well, since it's essentially the same logic, so 
I shouldn't really have bothered you with source changes to the backends. 
Well, at least it was done in a generic way and not slapping code all over 
many files...

With this safety in place, I tried running ALL the examples in 0.63 to see how 
we fare.  I compiled some notes along the way, here they are for your (and 
other user's) reference.

I think we're doing pretty good, except that people can always kill themselves 
by running true WX/GTK apps via @run.  IPython is really not made for this, it 
can only handle gracefully show() calls from pure matplotlib scripts, not 
full-blown GUI apps.  But I think we have a very reasonable environment at 
this point for most usage cases.

Cheers,

f

#############################################################################

matplotlib examples under iypthon -pylab
----------------------------------------

I ran all the examples in mpl 0.63 with ipython (CVS from Sept 29/04, post
0.6.4.rc1).  This was done using 'run foo.py', to see how robust this is.
Most examples run fine, and leave ipython usable afterwards.  Those listed
below had some type of problem.

Platform notes: Fedora core 2, python 2.3.3, Numeric 23.5, matplotlib 0.63
compiled only with Numeric (no numarray) support.

// These don't run with LANG==de_DE.UTF-8, but are OK with en_US.UTF-8
run date_demo_convert.py
run date_demo1.py
run date_demo2.py
run date_demo_rrule.py
run finance_demo.py

// these two run but segfault on exit under ipython.  They run OK from a cmd line.
run dynamic_demo_wx.py      # this one runs, segfaults on exit
run dynamic_image_wxagg.py  # this one runs, segfaults on exit

// OK with GTKAgg backend. It needs a use('GTKAgg') call to be safe for other
backends.
run dynamic_image_gtkagg.py #

// these are OK with gtkagg, but they segfault wxagg.  The segfault happens
from a normal command line as well (no ipython).

run system_monitor.py
run dynamic_demo.py

// these block ipython/pylab - any embedded true Wx/gtk stuff will kill 
ipython badly. What should we do here?

run print_stdout.py
run object_picker.py
run embedding_in_gtk2.py
run embedding_in_gtk.py
run embedding_in_tk.py
run embedding_in_wx.py
run embedding_in_wx2.py
run embedding_in_wx3.py
run embedding_in_wx4.py
run mpl_with_glade.py

// other errors (not ipython related)


****run ftface_props.py
---------------------------------------------------------------------------
SystemError                               Traceback (most recent call last)

/home/fperez/code/python/pylab/examples/ftface_props.py
      68 print 'Mult. masters :', font.style_flags & 
FT_FACE_FLAG_MULTIPLE_MASTERS != 0
      69 print 'Glyph names   :', font.style_flags & FT_FACE_FLAG_GLYPH_NAMES 
      != 0
      70
---> 71 font.jdh = 'hi'
      72 print dir(font)

SystemError: error return without exception set
WARNING: Failure executing file: <ftface_props.py>



****run movie_demo.py:
with WX backend it doesn't make the .png frames at all
with WXAgg, it runs fine but fails to make the movie:
...
Saving frame _tmp049.png
Making movie animation.mpg - this make take a while
sh: line 1: mpeg2encode: command not found
convert: Delegate failed (mpeg2encode "%i" "%o").
convert: Delegate failed (mpeg2encode "%i" "%o") [No such file or directory].

Symlinking mpeg2encode to mpeg2enc (the real binary) doesn't help, a different
error comes back.

I got it to work by commenting out the convert call and reverting to the
mencoder one.  Great!



****run vertical_ticklabels.py

---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)

/home/fperez/code/python/pylab/examples/vertical_ticklabels.py
       3
       4 plot([1,2,3,4], [1,4,9,16])
       5 xticks([1,2,3,4], ['Frogs', 'Hogs', 'Bogs', 'Slogs'])
----> 6 set(t, 'rotation', 'vertical')
       7 show()

NameError: name 't' is not defined
WARNING: Failure executing file: <vertical_ticklabels.py>

John Hunter schrieb:

> Are the levels indicated above sufficient to cover the spectrum?  

They sound reasonable, though I'd almost prefer a numerical value (0-4) 
instead of the names.  Minor nit, though, feel free to ignore.

> What should the default be (either error or helpful)?  

Error.  Good command line tools stay silent when successful (I'm paraphrasing 
some well-known unix quote I don't have at hand)

> Should we add a command line flag to allow the user to override the
> default level for easy access to debug info?

Yes.

Good job.

f

I added a Verbose class to matplotlib.__init__ and some verbose
options to rc.  Quoting from rc

    # Set the verbose flags.  This controls how much information
    # matplotlib gives you at runtime and where it goes.  Ther verbosity
    # levels are: silent, error, helpful, debug, debug-annoying.  At the
    # error level, you will only get error messages.  Any level is
    # inclusive of all the levels below it.  Ie, if your setting is
    # helpful, you'll also get all the error messages.  If you setting is
    # debug, you'll get all the error and helpful messages.  It is not
    # recommended to make your setting silent because you will not even
    # get error messages.  When submitting problems to the mailing-list,
    # please set verbose to helpful or debug and paste the output into
    # your report.
    #
    #
    # The fileo gives the destination for any calls to verbose.report.
    # The erro gives the destination for any calls to
    # verbose.report_error.  These objects can a filename, sys.stderr, or
    # sys.stdout.  
    #
    # You can access the verbose instance in your code
    #   from matplotlib import verbose.
    verbose.level  : helpful     # one of silent, error, helpful, debug, debug-annoying
    verbose.fileo  : sys.stdout  # a log filename, sys.stdout or sys.stderr
    verbose.erro   : sys.stderr  # a log filename, sys.stdout or sys.stderr

In matplotlib code, you should no longer print to stdout or stderr;
rather you should do

    verbose.report('some message')
    verbose.report_error('some error message')

    #only report at debug levels or higher
    verbose.report('some message', 'debug')  

I haven't migrated all the matplotlib code yet, but I've gotten a
start.  I've made some changes to the code base already so that
typical causes of user problems are reported in the helpful mode.  Eg,

    hunter:~/python/projects/matplotlib> python examples/simple_plot.py -dWXAgg
    loaded rc file /hunter/jdhunter/python/projects/matplotlib/.matplotlibrc
    verbose.level helpful
    interactive False
    matplotlib version 0.63.4
    numerix Numeric 23.5
    font search path ['/usr/local/share/matplotlib']
    loaded ttfcache file /home/jdhunter/.ttffont.cache
    matplotlib data path /usr/local/share/matplotlib
    backend WXAgg version 2.4.2.4u


Backend authors, please set the string backend_version.  The default
is 'unknown'.  Eg in wx

    backend_version = wx.VERSION_STRING

Are the levels indicated above sufficient to cover the spectrum?  

What should the default be (either error or helpful)?  

Should we add a command line flag to allow the user to override the
default level for easy access to debug info?

Let me know if you have any comments or problems with the design or
implementation.

JDH