dolfin team mailing list archive

[Ola Skavhaug <skavhaug@xxxxxxxxx>]

Garth N. Wells skrev den 25/07-2007 følgende:
> 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?

Well, one problem is that PyCC uses its own linear algebra system (or
collection of linear algebra systems). It would me much simpler if we can just
inherit a set of base classes, and then use our code transparently with
DOLFIN. The alternative would be to compile DOLFIN with the specific linear
algebra systems of PyCC. I fear that this would require much work.

I suggest that we invest some time to resolve how this should be done in a
general and flexible manner. It might require some work, but we are ready to
do this. The benefits of the merge will for sure pay this effort off.

Ola


> 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
> > 
> 
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev