dolfin team mailing list archive

["Garth N. Wells" <g.n.wells@xxxxxxxxxx>]

On Thu, 2006-07-13 at 16:54 +0200, Johan Jansson wrote: 
> On Thu, Jul 13, 2006 at 01:02:29PM +0200, Garth N. Wells wrote:
> 
> ...
> 
> > Johan, any news on wrapping the uBlas functions? It would be good to
> > sort this out before proceeding too far with the linear algebra clean
> > up. We could change uBlasMatrix to look like
> > 
> >   template<class Mat>
> >   class uBlasMatrix : public Variable, public GenericMatrix, 
> >                       public uBlasKrylovMatrix
> >   {
> >     public:
> >       .
> >       .
> > 
> >     private:
> >       Mat* mat;
> >   }
> > 
> > Would this work with Swig?
> 
> This is the same situation as before, i.e. SWIG needs to know about
> Mat to be able to instantiate uBlasMatrix.
> 
> > If we make this change, we should consider to what extent the
> > limitations of Swig should affect the future development of DOLFIN. 
> > 
> > Another possibility is to consider Boost.python. This came up on the
> > DOLFIN mailing list last year when PyDOLFIN started. It seems to offer
> > better compatibility with C++. After a quick look on the web, I saw that
> > the guys at Simula have experience with both Swig and Boost.python, so
> > they could be a very useful resource. There is a oldish presentation
> > comparing different tools at
> > http://people.web.psi.ch/geus/talks/europython2004_geus.pdf .
> > 
> 
> It's not that this is impossible to solve with SWIG, it's that it
> requires extra code to solve (i.e. it's not fully automatic). And the
> more code we have, the harder it is to maintain DOLFIN, so we should
> keep the code as small as possible.
> 
> But the example you posted with a manual wrapping of uBlas gives me an idea:
> 
> http://www2.laas.fr/~tlemaire/viewsvn_jafar/?do=view&project=jafarModules&path=/trunk/jmath/include/jmath/ublasMatrix.i
> 
> Perhaps we can redefine the uBlas classes for SWIG in a minimal way,
> since we're not interested in exporting the entire uBlas interface at
> this point. I'll try that. If it's just a matter of essentially just
> defining class names, then that's an ok solution.
> 

I had the impression that they wrap just the uBlas data types that they
use. Here is a simple example,

http://www2.laas.fr/~tlemaire/viewsvn_jafar/?do=view&project=jafarModules&path=/trunk/jmath/include/jmath/jblas.i


At this stage, we just need to take care of ublas::numermatrix<double>
and ublas::compressed_matrix<double>.


> I should also take a look at Boost.Python and Pyste (automated
> interface generator), I haven't spent any time experimenting with that
> yet. It does have advantages.
> 
> I don't think the limitations of SWIG (or other automatic interface
> generators) should affect the design of the DOLFIN interface. But I
> think it's also true that if we design the DOLFIN interface well, then
> it won't be hard to wrap it (and the interface should then also be
> small).
> 
> But I'm not saying the templated uBlasMatrix is a bad design, it uses
> templates to minimize code size, which is what we want. Let's try to
> make it work.

OK. In the previous implementation of uBlaseSparseMatrix and
uBlasDenseMatrix, some inconsistencies in the implementation had already
crept in, so as long as dense and sparse uBlas matrices share the same
code, I'm happy.

Garth
> 
> 
> 
> 
> 
>   Johan