← Back to team overview

dolfin team mailing list archive

Re: (no subject)

 

Martin Sandve Alnæs wrote:
2007/7/25, Anders Logg <logg@xxxxxxxxx>:
Garth N. Wells wrote:
Anders Logg wrote:
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
This is used to create copies of the vector (when creating a sub
function or in the copy constructor). How about adding a factory
function to GenericVector? (And also to GenericFoo in general.)

     virtual GenericVector* create() = 0;

Then we can call this instead of new Vector() in DiscreteFunction.cpp.

/Anders

I already have this in pycc::GenericVector/Foo, but I call it "copy",
which I think is a better name.

I also thought of naming it copy(), but this is not alwats appropriate. In DiscreteFunction, one needs to create a new vector which is not a copy (but which is a copy of a slice of the vector). Having a copy() function might be useful, but one can create a new object and then copy the values by get/set.

For eventual other situations which require type-independent
construction of GenericFoo without an object to copy, we can have a
factory design:

class GenericFooFactory
{
public:
  GenericFoo * create_foo(...) const = 0;
  ...
};

This is implemented for each backend, and create_foo can be defined
with several different argument lists.

Martin

Why not place it as a member function in GenericFoo? Then we avoid having a number of additional classes (PETScVectorFactor, PETScMatrixFactory, uBlasVectorFactory, ...).

/Anders



Follow ups

References