On 23 September 2013 18:20, Johan Hake <[email protected]> wrote:
> I am working on sub-function assignment. To facilitate caching of dof
> indices for a particular assignment combination I suggest introducing a
> FunctionAssigner class which caches the necessary indices (dofs) for the
> whole domain.
>
> Something like:
>
>   mesh = UnitSquareMesh(10,10)
>   V = FunctionSpace(mesh, "CG", 1)
>   VV = V*V
>
>   # Assign two scalar functions to the components of a mixed function
>   assigner0 = FunctionAssigner([V, V], VV)
>
>   # Assign components of a mixed function to scalar Functions
>   assigner1 = FunctionAssigner(VV, [V, V])
>
>   # Assign a scalar function to a component of a mixed function
>   assigner2 = FunctionAssigner(V, VV.sub(1))
>
>   u0, u1 = Function(V), Function(V)
>   U = Function(VV)
>
> Then in some time loop:
>
>   while t < tstop:
>       ...
>       assigner0.assign([u0, u1], U)
>       ...
>       assigner1.assign(U, [u0, u1])
>       ...
>       assigner2.assign(u0, U.sub(1))
>
> In C++ the equivalent to a list of Foo will be a std::vector of shared Foos.
>
> Comments?
>
> By using sub spaces and sub functions we avoid using indices in the
> interface, which I think is neat. However, there are some limitations with
> the present interface:
>
> 1) The FunctionAssigner needs to have access to the local ownership range of
> a sub dofmap, but that is not possible as it is set to 0,0 during
> construction. Could we add a proper local ownership range to a sub dofmap?

I need this too in another context (related to field split). I don't
have a resolution, but did think that perhaps a sub-dofmap should hold
pointer to the 'root' dofmap?

> 2) The FunctionAssigner need to be able to access the private _vector of a
> parent Function during the assignment, as calling subfunc.vector() raises an
> error. This can be fixed by a friend statement. Is that acceptable?
>

Could be ok. Maybe we can come up with a safe way to allow the vector
to be accessed?

Garth

> Johan
>
> _______________________________________________
> fenics mailing list
> [email protected]
> http://fenicsproject.org/mailman/listinfo/fenics
>
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics

Reply via email to