On Tue, Sep 24, 2013 at 10:04 AM, Garth N. Wells <gn...@cam.ac.uk> wrote:
> On 24 September 2013 08:56, Johan Hake <hake....@gmail.com> wrote: > > On Mon, Sep 23, 2013 at 9:29 PM, Garth N. Wells <gn...@cam.ac.uk> wrote: > >> > >> On 23 September 2013 18:20, Johan Hake <hake....@gmail.com> 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? > > > > > > That would be nice. But we need to make sure circular references do not > > cause memory leakage. We might also have a name problem as the 'root', > > 'parent', aso, names are now used by the Hierarchical class. > > > > Also, why is it not possible to just copy the owner_ship range from the > > parent during construction? > > > > That's possible and is simpler, but maybe it should have a different > name for sub-dofmaps, otherwise it might appear that a sub-dofmap is > not a view when it really is. Could it lead to unpredictable behavior? The dofs accessed from the sub dofmap are all correctly interpreted to the subspace, compared to the _vector data contained in a sub Function. We could add a some member function which could be queried whenever one need to find out if the dofmap is a sub dofmap. For example we could store the component vector, like we do for FunctionSpace. If the component is not empty it is a sub 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? > > > > > > This could be fixed if the 'root' Function could be accessed from the sub > > function, similar to the sub dofmap. > > > > Yes. > > Any name suggestions, for such a method? parent and root are all taken... Johan > Garth > > > Johan > > > >> > >> > >> Garth > >> > >> > Johan > >> > > >> > _______________________________________________ > >> > fenics mailing list > >> > fenics@fenicsproject.org > >> > http://fenicsproject.org/mailman/listinfo/fenics > >> > > > > > >
_______________________________________________ fenics mailing list fenics@fenicsproject.org http://fenicsproject.org/mailman/listinfo/fenics
