dolfin team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxx>]

> 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
>

Ok. As a Dolfin developer/user I find this a bit unsettling; to not be
able to access the underlying ordering. It goes into the core idea of
Dolfin to be able to access the FEM structures on different levels,
including the lowest possible one. Without this possibility it appears
that you will have to dig into FFC or even UFC to access this information,
which would appear to go against the idea of Dolfin and FFC to be
stand-alone packages with a UFC in between (and similar for PyCC etc.)?

>> 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?

In developing Dolfin I would like to access this information in the
process of debugging, add functionality relating to particular dofs (it
can be useful to know what are nodal/edge dofs for example), i/o when
dealing with external formats, adding preliminary functionality which is
not yet implemented in FFC,...

> 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.

I think it is good that you are including (I assume it was decided so) the
option of integration over subdomains/-surfaces in one form. You would
also like to access mesh geometry such as normals and tangents, cell/face
sizes etc. in the form. I am not updated on UFC of today, so maybe it is
already covered.

Unfortunately, I think it is hard to once for all define a UFC
specification that will cover what you will need as a PDE-modeller. I
think it is very wise to build a structure for UFC which allow for
continuous improvements. But I assume that this is what you do.

> 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.

Ok.

/Johan


> /Anders
> _______________________________________________
> UFC-dev mailing list
> UFC-dev@xxxxxxxxxx
> http://fenics.org/mailman/listinfo/ufc-dev
>