I agree. Incidentally, this is what I'm experimenting with for function spaces defined on multiple meshes. The extra complexity is then handled by a special function space class.
-- Anders On Sun, Sep 15, 2013 at 10:37:15AM +0200, Martin Sandve Alnæs wrote: > Sounds reasonable. In the future we want a function space to possibly have > parts living on different submeshes. Then I guess that functionality will be > handled by FunctionSpace. > > Martin > > Den 14. sep. 2013 12:36 skrev "Garth N. Wells" <[email protected]> følgende: > > DofMap is necessarily rather complex to handle re-ordering, > distributed problems, constrained spaces (e.g. periodic bcs), and made > more complicated by 'Restrictions'. Having 'Restriction' functions in > DofMap is the wrong abstraction. A DofMap is constructed from a UFC > dofmap by feeding it the right input (i.e., the (sub)Mesh on which the > DofMap is defined). The DofMap shouldn't be aware of any restriction > to a sub-domain. This should be handled at the FunctionSpace level of > abstraction. > > I therefore propose that Restriction-related functions be removed from > GenericDofMap. Restricted spaces can still be supported but a DofMap > does not need to know about this post-construction. > > Garth > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics > > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
