dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

Garth N. Wells wrote:
> Ola Skavhaug wrote:
> > 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.
>
> Yes, I agree and I'm looking forward to the merge. Would the below 
> template approach work for you? Function will require some changes for 
> parallel assembly and solve (which is being worked on), so now is a good 
> time to work out what we need to make the merge smooth.
>
> Garth

I think there is a very simple solution. We just change the constructor 
of Function to

    Function(Mesh& mesh, GenericVector& x, const Form& form, uint i = 1)

and the vector member of DiscreteFunction to

    GenericVector* x;

Then if one needs a Function that uses a particular linear algebra 
backend, then just create the Function from a PETScVector, uBlasVector 
or EpetraVector. Otherwise, create it from a Vector (tied to the default 
backend) or let the Function itself decide (in which case it will be a 
Vector).

/Anders



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