← Back to team overview

dolfin team mailing list archive

  1. dolfin team
  2. Mailing list archive
  3. Message #07309

Re: Invalid conversion from dolfin::GenericVector to dolfin::Vector

  Thread Previous • Date Previous • • Thread Next 


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").
We needed to move to GenericVector because there were problems with our old design. One problem was that we could get hold of 'DefaultVector' and perform operations specific to uBLAS or PETSc, depending on the compile options. One can still call PETSc or uBLAS specific functions, but now you have to explicitly specify the type of matrix/vector you want to work with. Another problem was that a number classes were unnecessarily tied to DefaultVector. There are more issues which others can elaborate upon. 



At the same time, the functionality of Vector is expanding (which I very
much welcome).


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
I don't think that the changes will be too big a deal for user code. None of my user code has broken, and I have quite a lot. You might need to change Matrix/Vector to GenericMatrix/GenericVector in some places. Requiring a dynamic cast is a good thing because you are consciously and explicitly requesting functionality which is specific to a particular underlying library. 

Garth


  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 :)

/Dag

_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev

References

  Thread Previous • Date Previous • • Thread Next