dolfin team mailing list archive

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

Anders Logg wrote:
> 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).

I thought that this would be a simple solution, but there a "new Vector" 
in DiscreteFunction which requires that the vector type be known. If 
this is somehow re-written, the above approach could be used.

Garth



> /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