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
