dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Feb 02, 2007 at 10:15:09PM +0100, Garth N. Wells wrote:
> 
> 
> Anders Logg wrote:
> > On Fri, Feb 02, 2007 at 09:32:13PM +0100, Garth N. Wells wrote:
> >> Anders Logg wrote:
> >>> On Fri, Feb 02, 2007 at 02:46:35PM +0100, Johan Hoffman wrote:
> >>>>> Johan Hoffman wrote:
> >>>>>> About the global dof numbering for the different components in a
> >>>>>> function
> >>>>>> defined by a mixed element: I get the impression that we use a different
> >>>>>> ordering for the mixed dofs than for the dofs of a regular vector valued
> >>>>>> function?
> >>>>>>
> >>>>> I don't think so. For both mixed and vector elements, dofs at the same
> >>>>> node do not lie next to each other in the dof mapping.
> >>>>>
> >>>>> It will be possible to choose the dof ordering soon when the new
> >>>>> assembly is  up and running. There is already a new class DofMap which
> >>>>> will handle this.
> >>>>>
> >>>>> Garth
> >>> Generally, you can never be sure how the dofs are ordered. This could
> >>> potentially change between different versions of FFC or between
> >>> different form compilers. As long as the generated code follows the
> >>> UFC specification, the dof maps may be different.
> >>>
> >> This sounds strange. DofMap will provide the functionality to influence 
> >> the dof mapping. UFC should provide the input to DofMap, but the user 
> >> should then be able to manipulate it if they wish.
> > 
> > I don't mind documenting how FFC actually orders the dofs, but the
> > idea of the UFC interface is that one should not need to know intimate
> > details of FFC to work with the generated code.
> >
> 
> What I'm trying to say is that a user should be able to influence the 
> dof mapping through the public member functions of dolfin::DofMap. They 
> don't need to know the details of FFC, or even UFC.

Then I understand and I agree!

/Anders