On Tue, Sep 24, 2013 at 10:28 AM, Garth N. Wells <[email protected]> wrote:
> On 24 September 2013 09:18, Johan Hake <[email protected]> wrote: > > On Tue, Sep 24, 2013 at 10:04 AM, Garth N. Wells <[email protected]> > wrote: > >> > >> On 24 September 2013 08:56, Johan Hake <[email protected]> wrote: > >> > On Mon, Sep 23, 2013 at 9:29 PM, Garth N. Wells <[email protected]> > wrote: > >> >> > >> >> 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? > >> > > >> > > >> > 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. > > > > > It's probably all ok. My concern is if anyone relies on > DofMap::ownership_range in a way that will lead to problems. > If we provide an other way to figure out if it is a sub dofmap the user can adapt his code ;) >> > >> >> > 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... > > > > I'm not so keen on holding a reference/pointer to the 'root' it it's > not essential because the of circular dependency. Maybe just allowing > const access to the vector is enough? > We could use weak_ptr to the parent to avoid memory leakage. const access wont prevent a user trying to plot a sub function, which could cause some havoc. Johan > > Garth > > > Johan > > > > > >> > >> Garth > >> > >> > Johan > >> > > >> >> > >> >> > >> >> Garth > >> >> > >> >> > Johan > >> >> > > >> >> > _______________________________________________ > >> >> > fenics mailing list > >> >> > [email protected] > >> >> > http://fenicsproject.org/mailman/listinfo/fenics > >> >> > > >> > > >> > > > > > >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
