dolfin team mailing list archive

["Dag Lindbo" <dag@xxxxxxxxxx>]

>
>
> 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.

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?

/Dag

>
>> The thing that's changed is that a Function saves its data in a
>> GenericVector which can be anything, a PETScVector, a uBlasVector,
>> an EpetraVector, or even your own implementation of a vector class.
>>
>> The class Vector is a particular implementation of a Vector, decided
>> at compile-time depending on how you have configured DOLFIN. If you
>> compile with PETSc, then it's a wrapper for a PETScVector, otherwise
>> it's a wrapper for a uBlasVector.
>>
>> Some work needs to be done to get all the linear algebra behave well
>> in both Python and C++. This will likely take some weeks so we might
>> not be able to fix everything before the release.
>>
>> (I will add the solve() problem above to the TODO list.)
>>
>
>
>