dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Apr 09, 2008 at 08:23:41PM +0200, Dag Lindbo wrote:
> >
> >
> > Anders Logg wrote:
> >> On Wed, Apr 09, 2008 at 06:14:35PM +0200, Ola Skavhaug wrote:
> >>> Dag Lindbo skrev den 09/04-2008 følgende:
> >>>> Hello again!
> >>>>
> >>>> Why is it not possible any longer to get the Vector associated with a
> >>>> Function? E.g:
> >>>>
> >>>> #include <dolfin.h>
> >>>> using namespace dolfin;
> >>>>
> >>>> int main()
> >>>> {
> >>>>    Function u;
> >>>>    Vector& v = u.vector();
> >>>> }
> >>> int main()
> >>> {
> >>>      Function u;
> >>>      Vector v;
> >>>      v = u.vector();
> >>>      return 0;
> >>> }
> >>>
> >>> Should work. A Function returns a GenericVector reference, and the
> >>> Vector
> >>> reference needs to be a Vector. Then the operator= in Vector is applied
> >>> in the
> >>> assignment.
> >>>
> >>> Ola
> >>
> >> I don't think one should need to make a copy of the vector. It should
> >> work to either use the vector you get by calling vector() directly,
> >> for example
> >>
> >>   solve(A, u.vector(), b); // Doesn't work currently but it should!
> >>
> >> You may also do
> >>
> >>   GenericVector& x = u.vector();
> >>
> >
> > This works. Can someone remind me how to convert a GenericVector into
> > the underlying vector type( e.g. a uBlasVector or a PETScVector)?
> >
> > Garth
> 
> From the point of view of the significant, and growing, number of us who
> write solvers using dolfin for non-fem-research applications: Using a
> GenericVector (which, I suppose, was not intended for the public
> interface) plus a dynamic cast is not up to par with the otherwise
> wonderfully sleek public interfaces in dolfin.

Do you really need the dynamic cast? It should be enough to do

  GenericVector& x = u.vector();

When it comes to the use of Vector, GenericVector, PETScVector, etc,
the principles are the following:

  1. If you want a specific backend like PETSc, then use PETScVector.

  2. If you don't care about the backend, then use Vector.

  3. If you write a *function* that should be able to accept vectors
     from any backend as input, then use GenericVector.

> Won't a change like not being able to do Vector& v = u.vector() force a
> _lot_ of breakage and consternation among "users" if it went into a
> release?

Yes, probably. But the interfaces are not finished, hence

  0.7.x << 1.0.

:-)

We're much more stable in terms of interfaces than we used to be
and we're slowly converging towards 1.0.

We will do some more "improvements" to the linear algebra interface in
the coming days. Please shout if we break anything and post a list of
issues you want fixed before the release.

-- 
Anders