dolfin team mailing list archive

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

Martin Sandve Alnæs wrote:
> 2007/7/24, Garth N. Wells <g.n.wells@xxxxxxxxxx>:
> > Martin Sandve Alnæs wrote:
> > > 2007/7/24, Garth N. Wells <g.n.wells@xxxxxxxxxx>:
> > > > Martin Sandve Alnæs wrote:
> > > > > As I understand it, "Matrix" is just a convenience class for users who
> > > > > don't care about the underlying format. It should never be used at the
> > > > > library level (because it ties the library to one format for each
> > > > > compilation of the library), and can be ignored by anybody who
> > > > > actually cares about which library they'll use.
> > > > I would say that it is more than just a convenience class - it's more
> > > > like the default linear algebra backend. Part of the idea is to tie the
> > > > library to one format in order to guarantee that various objects are
> > > > compatible with each other.
> > > This doesn't sound like what Anders told me. Its the very idea of
> > > "tying" the library compile-time to a single backend that I don't
> > > like. As long as the rest of the library depends on GenericMatrix and
> > > not Matrix, I'm happy. In that case, Matrix is a nice user-side
> > > feature to keep user code portable.
> > >
> > >
> > > > A possibility would be to make objects like
> > > > Function templated, at the cost of increased complexity.
> > > I don't see where Function enters this?
> > A Function requires a vector to store the dofs. This is currently a
> > Vector, so it would have to be possible to specify the type of vector.
> > With the current design, it's not enough to just make the underlying
> > pointer a GenericVector.
> >
> > Garth
>
> Using more than one linear algebra backend with this design must
> require separately compiled libraries for each backend then? This is
> not ok for Python apps at all, and will make the PyCC merge impossible
> in my opinion.

What's the problem that makes things impossible?

I agree that it would be more elegant to allow the use of different 
back-ends, and it should require only a minor redesign. The least 
intrusive solution would be to make Function a templated class,

template< class T > Function
{
  public:

    . . .
    T& vec();

  private:

    T* vector;
}

Garth

> I guess this requirement stems from that Function needs to construct
> objects of GenericVector subclasses? We could use a factory design
> then. The factory pattern is usually a good solution when "virtual
> constructors" are needed, like here. But this probably leads to
> changes many places, so I'm not trying to come up with a solution
> right now.
>
> Martin
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev