dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Jul 13, 2006 at 04:54:43PM +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.

Which part of the uBlas interface for a uBlasSparseMatrix will we
export? If we are not exporting anything more than what is in the
interface of uBlasSparseMatrix (including GenericMatrix), then we
don't need to make uBlasSparseMatrix a subclass of the uBlasMatrix
template anyway and could have a uBlasMatrix as a private member as in
the PETSc wrappers.

> 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.
> 
>   Johan

As far as I can tell, the advantage of the templating to reduce code
size would still remain even if we make uBlasMatrix<...> a private
member. Would then the only argument to have the uBlas wrappers as
subclasses of a template the convenience when working directly through
the original uBlas interface in C++?

/Anders