dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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

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

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

/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