dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Apr 09, 2008 at 11:34:48PM +0200, Dag Lindbo wrote:
> > 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.
> >
> 
> This makes perfect sense, which is why I'm concerned with this change. Two
> things that many users who go beyond solving Poisson on a square might do:
> 
> 1) Post-process some computational results before they are written to disk.
> 2) Manually compute some function, e.g. stabilization, before assembly.
> 
> In each of these cases the data both before and after the "manual"
> computation is associated with a particular Function. Isn't it natural
> here to want to work with references to the underlying Vector in the
> Function? But now this does not seem to be possible, which is my
> objection. Working with the GenericVector& violates your principles above
> (in the context of "user code").
> 
> At the same time, the functionality of Vector is expanding (which I very
> much welcome).

I don't think you should need to change anything in your code, as long
as you work through the interface defined by the GenericVector class,
in particular since the interfaces of Vector and GenericVector are (or
will be) identical.

So, anything you can do with a Vector, you can do (or will be able to
do) with a GenericVector.

I know it currently breaks for solve(), so you can't do

  solve(A, u.x(), b);

but you will be able to do so when this has been fixed.

> >> 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.
> >
> 
> Trust me, I will play my part :)

Excellent.

-- 
Anders