← Back to team overview

dolfin team mailing list archive

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

 

On Mon, Apr 21, 2008 at 02:31:15PM +0200, Dag Lindbo wrote:
> Hello Dolfin!
> 
> Currently, one may not initialize a DiscreteFunction with something like 
> init(Mesh&, Form&, uint). All init-methods involve also a 
> GenericVector&. I think it would be useful to have a init-method that 
> uses only the form and mesh, which then allocates a vector for itself 
> (so that the DiscreteFunction actually "owns" its own dofs). Or is there 
> a particular reason not to allow this?

Yes, since users should not use DiscreteFunction but instead work
through the common Function interface. Then the vector argument is
needed to so that Function knows that it should intitialize a
DiscreteFunction and not some other kind of function, like
ConstantFunction or UserFunction.

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

-- 
Anders


Follow ups

References