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&))?
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
