dolfin team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxx>]

> On Mon, Feb 05, 2007 at 12:26:10PM +0100, Johan Hoffman wrote:
>> > 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.
>
> FFC-DOLFIN should not be coupled, or more precisely they should only
> be coupled through UFC interface. (The purpose of the UFC is to
> specify exactly what the coupling is.)

Ok. But then the numbering needs to be communicated through UFC in some
way as far as I can see. Because I think it is needed in Dolfin for
debugging and other things that may/will surface later on. Even if the
ordering does not have to be standardized in UFC, doesn't it make sense
that the ordering at least is communicated as a documentation?

/Johan

> /Anders
>
>> /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
>> >
>>
>>
>> _______________________________________________
>> 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
>