dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Feb 05, 2007 at 01:12:31PM +0100, Johan Hoffman wrote:
> > 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?

The ordering is only communicated through the function tabulate_dofs().
Other than that, it will only be documented in the manuals.

Is there some specific use case you can think of where you need to
know how the dofs are ordered?

/Anders