PETSc for Python

[S V N Vishwanathan]

Hi!

Let me make a bit of our aims clear.

>> My bindings are rather mature, I am actually runing nontrivial FEM
>> problems in parallel with them.

For us wrapping PETSc in Python is just the first step. We basically
want to write a thin layer on top of it such that it is "natural" to use
PETSc as the backend while doing linear algebra computation in Python
very similar in spirit to numarray. Till now we have not paid much
attention to the parallel aspects but going forward we will. There is an
entire consortium of labs who are interested in developing this platform
(thin layer). Our ultimate goal is to have a stable mature platform on
which we can develop higher level machine learning algorithms. More
information about our efforts can be found at

http://sml.nicta.com.au/crest


We intend to release the numerical platform under the free BSD license
so that it can be adapted by a wider community. 

>> I understand you are a "Python guru" in your team. So I really want to
>> know if you are interested in something like that. It would be really
>> nice to have a 'official' interface for accesing PETSc from Python,
>> this will help a lot in comparing differente implementations (Matt
>> uses SIDL, I am using SWIG, Matt told me you use pyrex, perhaps other
>> guys can try boost libraries).

Simon> Not sure what to say here; it seems we have three competing
Simon> python wrappers. I started work on pypetsc because we also needed
Simon> a *complete* wrapper to PETSc. The pypetsc API is similar to the
Simon> C API, and to Matt's sidl wrapper (and petsc4py).  So as you say,
Simon> hopefully we can all converge to the same interface then it won't
Simon> matter which wrapper is used.

But I do agree that having three different python bindings is not the
optimal strategy. Maybe  we should think about merging the best aspects
of all three bindings into one gold standard.  

Matt:
        Is there a way we could do a phone conf or email thread
        discussion and converge on a gold standard? We intend to do an
        alpha release of our platform by the end of this month. So I
        would prefer this to happen sooner than later. 

I have another related but slightly tangential question. We would also
like to wrap TAO and other related optimization packages. My
understanding is that our method does not allow for this to happen
seamlessly since TAO relies very heavily on C++ and our wrapping scripts
have problems with that. Maybe when we converge on *the* standard we
will also take this into account.

Please let me know your thoughts.


vishy