Hi, Apologies for reviving an ancient thread but this seems like the best place to both obtain the information and also document it for the sake of future readers.
I wrote some code a while ago which relied on Restriction to extract parts of dolfin functions on submeshes (corresponding to different materials) for postprocessing and visualisation purposes. This worked fine until Restriction was removed in dolfin 1.5 (see [1]). I haven't needed it since, but now I fairly urgently need to revive this piece of code. So I would like to ask what the recommended way of doing this is in dolfin 1.6? None of the bits of information that I could find on Bitbucket [1] or on the Q&A forum (e.g. [2]) had any replies regarding whether an alternative for Restriction is available yet, but extracting parts of functions on submeshes seems like a fairly common thing to do so I'm hoping that there is an easy way. Apologies if I missed something obvious somewhere. Many thanks, Max [1] https://bitbucket.org/fenics-project/dolfin/issues/118/remove-restriction-from-generic-dofmap [2] http://fenicsproject.org/qa/6423/creating-restricted-function-restriction-attribute-mpi_comm 2013-09-15 22:49 GMT+01:00 Anders Logg <[email protected]>: > 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 >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
