Scientific Libraries in Python
prabhu at aero.iitm.ernet.in
Fri Nov 16 08:45:09 CET 2001
>>>>> "FP" == fperez528 <Fernando> writes:
FP> Chris Barker wrote:
>> Nice Summary of the state of the art:
I'll second that. :)
Here is my take.
>> but you can also get access to all the properties of the plot,
>> so that you can customise things as much as you like. I think
>> all plots are created by a set of only three types of
>> primitives, a line, a patch (surface), and a text object. It
>> really works pretty well. I also believe that all plots are 3-d
>> with 2-d plots being a special casse, where z=0 everywhere, and
>> the view is from the top.
IMHO, its not a great idea to make the same package deal with 2d and
3d. The needs and requirements are simply not the same. I agree that
we need a plotting utility for both 2d and 3d. AFAIK, the scipy plt
and gplt interfaces provide a good start for 2d plots.
GracePlot is also very nice but as you say isnt tied close enough to
grace. So what we need is one tool that does 2d plots and provides
access to low level stuff (if you want) but also exposes a nice high
level and GUI Interface. We need a similar tool for 3d. Writing a
wrapper that combines these two is not hard but putting them both in
the same package is a pain on both sides -- the 2d person has to worry
about 3d and vice versa. So long as both 2d and 3d plots are
scriptable and useable there really is not a need to tie them all
together very tightly.
FP> I didn't mention graphite b/c it seems dead. I know Mayavi is
FP> active, it's based on a high caliber underlying toolkit (vtk)
FP> and it looks very nice. I think the underlying toolkit *has*
FP> to be written in C/C++. Volume rendering for large datasets is
FP> I tend to think mayavi has the right approach: OpenGl is too
FP> low-level. The vtk people have already done a lot of *very
FP> hard* work. It would be silly to ignore that, IMO. And from a
FP> recent post from mayavi's author, he seems to be working on
FP> providing full python access to the system (while also
FP> offering the gui). I don't want to seem biased, I don't even
FP> know the mayavi author and have only superficially looked at
FP> the stuff. I just have a hunch that he's going in the right
FP> direction, and that (perhaps with some modifications) that's
FP> the best bet for the graphical part at this point.
Thanks for all the positive comments and attention! I'm very glad
that MayaVi features in your Python for scientific tools so
prominently. :) Here are a few things I'd like to bring to your
attention about MayaVi:
(0) MayaVi will not do simple x vs y plots and stuff. While it does
support 2d data for contouring, streamlines, scalar/vector plots
etc. its simply not made for the things that grace does so well like
draw this line with these ticks, stack 4 graphs here, put this label
here, that legend there, etc. etc.
(1) The MayaVi CVS code is scriptable and is pending a release, I'm
still stuck on the web pages etc. Yes, its scriptable and provides
access to the internals but the internals are not so clean. This is
because it was not designed for scriptability and this feature is
new. Cleaning up the interface and making improvements is in my
TODO and hopefully will be seen in future releases.
(2) The biggest problem right now is that almost all of the MayaVi
stuff is pretty much a one man show currently. I have to write the
code, write the docs, answer questions, make the web pages, make the
announcements, basically do *everything*. I do receive very useful
patches and improvments from folks but I still have to do way too
To top it all VTK is a beast and not at all easy to get installed.
On a PIII 450 m/c its easily a 2+ hour build. To make it easier to
install I made rpms a couple of years back but the new VTK 4.0 tree
has changed many things. I also made experimental debs and Maitland
Bottoms is packaging VTK debs for the next Debian release. Mayavi
needs VTK to run and making VTK easier to install is an important
goal but one for which I am running out of time. This whole MayaVi,
VTK deal is simply my spare time project to give back to the OSS
community. It is now taking up alarming amounts of my time. I am
supposed to be doing my PhD in Aerospace Eng. and need to get back
to serious research. Apart from all this I also have other
In short, I need HELP! Its pretty much impossible for me to keep up
with my current schedule. It would be nice if someone could atleast
take care of the web pages and documentation. It would be truly
wonderful if I had more developers to help. I agree that finding a
person with a good knowledge of Python, Tkinter and VTK might be
hard but even if someone who is even good at one of these joins the
project and gives it a good shot I'll be very happy. Of course the
person has to be sincerely interested in visualization and MayaVi.
I obviously don't want someone to make a mess of things and give me
any more work. :)
(3) Due to the above, after the next release, I'm not going to be
very active with MayaVi for atleast a couple of months. :( Its not
that the project is going to die, but if I dont do this I run the
risk of dying. ;)
Since MayaVi seems to be so well received by the community I hope
someone decides to seriously help with its development. :) If that
does not happen the progress will definitely be slow since it will be
limited by my spare time.
FP> Well, let's keep it going. I don't like cross-posting and
FP> don't really know the Numeric and SciPy people, but if someone
FP> knows them and is willing to drop them a reference of this
FP> discussion it might be a good idea to hear what they think.
Yes, I know Eric (from SciPy) well. He usually does track c.l.py but
is busy. Have told him about this thread and plan to keep him posted.
Travis Oliphant also seems to be looking at this thread. So we
atleast have the scipy folks attention. I dont know if Konrad Hinsen
is following this though.
More information about the Python-list