dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Feb 05, 2007 at 10:28:07AM +0100, Johan Hoffman wrote:
> > 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!
> 
> That sounds good; so we all agree for future design that it should be
> clear to the user how the dofs are ordered, and the user should have full
> access to manipulate the ordering through an interface such as
> dolfin::DofMap.

I'm not sure we agree completely yet. I was thinking the DofMap class
should take whatever dof ordering comes out of FFC and then apply
different reordering algorithms on this dof ordering (if necessary).

A user of DofMap can say: reorder the dofs by this algorithm or by
this algorithm. For example: reorder the dofs by Cuthill-McKee. It's
not clear to me a user can say: order the dofs in this very particular
way:

    first vertex degrees of freedom for the first component
    then edge degrees of freedom for the first component
    first vertex degrees of freedom for the second component
    then edge degrees of freedom for the second component

> We have to allow for also this low level manipulation of the functions
> since we will not be able to cover all possible functionality with high
> level interfaces at this point.

What is it you need to do?

The UFC specification is still up for review. If it looks like we have
missed something important, we need to know so we can decide if it is
covered by the current specification or if we need to add something to
the interface.

Also, take a look at the current thread

    "create_sub_element (mixed functions)"

on ufc-dev which I think is very much related to this issue.

/Anders