dolfin team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxx>]

> On Mon, Feb 05, 2007 at 11:44:50AM +0100, Johan Hoffman wrote:
>> > 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.)?
>
> The idea of the UFC specification is to describe an interface between
> form compilers (like FFC or SyFi) and form assemblers (like DOLFIN or
> PyCC). You should be able to take a form compiled with any form
> compiler that supports UFC and stick it into any form assembler that
> supports UFC.
>
> One important part of the interface is the function
>
>     tabulate_dofs()
>
> which tabulates the global dof numbers for the dofs on an element.
>
> The arguments of the function tabulate_dofs() are covered by the UFC
> specification, but how the dofs are ordered is not covered. The dofs
> are ordered differently by FFC and by SyFi.
>
> How the dofs are actually ordered by FFC is no secret and it will be
> documented completely in the FFC manual, but you should not need to
> care about how the dofs are ordered, other than for debugging. If you
> need to know the ordering for debugging, just look it up in the manual
> or look at the generated code, which could say something like
>
>     dofs[0] = c.entity_indices[0][0];
>     dofs[1] = c.entity_indices[0][1];
>     dofs[2] = c.entity_indices[0][2];
>     unsigned int offset = m.num_entities[0];
>     dofs[3] = offset + c.entity_indices[1][0];
>     dofs[4] = offset + c.entity_indices[1][0] + 1;
>     dofs[5] = offset + c.entity_indices[1][1];
>     dofs[6] = offset + c.entity_indices[1][1] + 1;
>     dofs[7] = offset + c.entity_indices[1][2];
>     dofs[8] = offset + c.entity_indices[1][2] + 1;
>     offset = offset + 2*m.num_entities[1];
>     dofs[9] = offset + c.entity_indices[2][0];
>
> (This example is UFC code generated for scalar degree 3 Lagrange
> elements with the current development version of FFC.)
>
>> >> 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,...
>
> For debugging I understand you may need to know the particular
> ordering, but do you really need it otherwise? Is there some specific
> example you could give? If we have missed something in the UFC
> specification, it is important that we know so we can correct it.
>
>> > 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.
>
> Yes, this has been fixed.
>
>> 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.
>
> This is not covered by the UFC. Instead, you need to define Functions
> for these objects. DOLFIN then provides default implementations of
> these functions. Currently the following functions are supported:
>
>     MeshSize
>     InvMeshSize
>     FacetNormal
>

Yes this is probably better.

>> 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.
>
> The idea is rather to define an interface that can remain constant for
> a long time, among other things to avoid incompatibilities between
> different versions of FFC and DOLFIN.

Ok. With this motivation things makes sense, and I guess UFC should be
kept to a minimum only dealing with essential information. But then
FFC-Dolfin is coupled e.g. by a common ordering (contrary to maybe
FFC-PyCC for example). Maybe you'll get by often without knowing this, but
I think you may need it sometimes, even though you should get by most of
the time with MeshFunction and interpolation using FFC.

/Johan


> /Anders
>
>> > 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
>> >
>>
>>
>> _______________________________________________
>> FFC-dev mailing list
>> FFC-dev@xxxxxxxxxx
>> http://www.fenics.org/mailman/listinfo/ffc-dev
> _______________________________________________
> UFC-dev mailing list
> UFC-dev@xxxxxxxxxx
> http://fenics.org/mailman/listinfo/ufc-dev
>