dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Dec 17, 2008 at 12:15:38AM +0000, Garth N. Wells wrote:
> I'm running into some problems with the new Function design when trying 
> to update a solver. I'll try to sketch the issue as simply as possible.
> 
>      Function v;
>      Function u, p;
> 
>      // First form for U = (u, p)
>      FirstBilinearForm a_1(V1, V1);
>      FirstLinearForm   L_1(V1);
>      LinearPDE pde_first(a_1, L_1);
> 
>      // Second form which depends on u
>      SecondBilinearForm a_2(V2, V2);
>      SecondLinearForm   L_2(V2, u);
>      LinearPDE pde_second(a_2, L_2);
> 
>      Function U;
>      for(uint i = 0; i < 10; ++i)
>      {
>        pde_first.solve(U);
> 
>        // This step breaks down because FunctionSpaces don't match
>        u = U[0];
>        p = U[1];
> 
>        pde_second.solve(v);
>      }
> 
> The problem is in assigning Functions since we now check the FunctionSpace.

Which check is it that fails?

> To get around this, I tried
> 
>      FunctionSpace V(mesh);
>      Function U(V);
>      Function u = U[0];
>      Function p = U[1];
> 
> which throws an exception because U does not have a vector.

What if we remove the check in operator[] and then in the constructor
that gets a SubFunction we rely on v.v.vector() which (after Martin's
fix from yesterday) will always return a vector with the dofs
(possibly interpolated if there were no dofs before).

-- 
Anders


> Any suggestions on how to address this? Should we have a function that 
> allows assignment of a Function irrespective of the Function space 
> (Function::assign(const Function&))?

Attachment: signature.asc
Description: Digital signature