← Back to team overview

dolfin team mailing list archive

Re: Initialization of discrete functions (related to bug 24)

 

>> Why do I care? I'm looking at the current state of the LinearPDE class.
>> Here, the solution vector is a member function, and the solution
>> Function is initialized with a reference to this vector. I.e. the
>> LinearPDE (not the DiscreteFunction) owns the solution vector. This is
>> of course a problem if the LinearPDE goes out of scope before the
>> solution function (bug 24). It is also a bit counter-intuitive.
>>
>> If it was possible to do an initialization like above, then the solve()
>> method would simply do
>> u.init(mesh, form, 1);
>> GenericVector& x = u.vector();
>> <solve>
>
> There is a member local_vector in DiscreteFunction that could be used
> for this. If this is nonzero, then the DiscreteFunction owns its data.
>
> See if you can figure out a good way for the DiscreteFunction to know
> that it should take responsibility for the vector here.
>

Right... I don't see how to do this without breaking the encapsulation of
both Function and DiscreteFunction (making LinearPDE friend in both).
Bundle attached.

Garth, does this look OK?

In essence, the member x is removed from the LinearPDE class. in
LinearPDE::solve I do

  (...)
  Vector b;
  Vector* x = new Vector();
  (... call solver etc)

  u.init(mesh, *x, a, 1);
  DiscreteFunction& uu = dynamic_cast<DiscreteFunction&>(*u.f);
  uu.local_vector = x;

/Dag

Attachment: dolfin-dag-080421.hg
Description: Binary data


Follow ups

References