← Back to team overview

dolfin team mailing list archive

Re: (no subject)

 

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


Follow ups

References