Subject: [UFC-dev] mixed dof numbering

From: "Johan Hoffman" <[email-masked]>
Date: Fri, 2 Feb 2007 14:24:04 +0100 (MET)

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 guess the natural way is to order the global dofs such that all
components for a given node (e.g. a vertex for Lagrange elements) lies
together, which I think gives the better block structure? It appears that
the mixed dofs are ordered differently?

Maybe I'm wrong? But if not, we should take care of this as soon as
possible, since it is very confusing.

/Johan

---

From: "Garth N. Wells" <[email-masked]>
Date: Fri, 02 Feb 2007 14:35:11 +0100

> ordering for the mixed dofs than for the dofs of a regular vector valued

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

> _______________________________________________
> DOLFIN-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>

---

From: "Johan Hoffman" <[email-masked]>
Date: Fri, 2 Feb 2007 14:46:35 +0100 (MET)

> assembly is  up and running. There is already a new class DofMap which

Ok, thanks, so it would be "block-ordering" in both. Then our problem is
probably related to something else...

/Johan

> FFC-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/ffc-dev
>

---

From: Anders Logg <[email-masked]>
Date: Fri, 2 Feb 2007 21:18:00 +0100

> > assembly is  up and running. There is already a new class DofMap which

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 means that it is very important that everything you need to know
about the generated code is covered by the UFC specification.

I will post on a related subject (ufc::finite_element::sub_element)
in a while to ufc-dev.

/Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Fri, 02 Feb 2007 21:32:13 +0100

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

Garth

---

From: Anders Logg <[email-masked]>
Date: Fri, 2 Feb 2007 21:49:02 +0100

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

/Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Fri, 02 Feb 2007 22:15:09 +0100

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

Garth

---

From: Anders Logg <[email-masked]>
Date: Fri, 2 Feb 2007 22:16:55 +0100

> don't need to know the details of FFC, or even UFC.

Then I understand and I agree!

/Anders

---

From: "Johan Hoffman" <[email-masked]>
Date: Mon, 5 Feb 2007 10:28:07 +0100 (MET)

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

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.

/Johan

---

From: Anders Logg <[email-masked]>
Date: Mon, 5 Feb 2007 11:08:38 +0100

> access to manipulate the ordering through an interface such as

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

> level interfaces at this point.

What is it you need to do?

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.

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.

/Anders

---

From: "Johan Hoffman" <[email-masked]>
Date: Mon, 5 Feb 2007 11:44:50 +0100 (MET)

>> >> >>>>>> About the global dof numbering for the different components in
>> a
>> >> >>>>>> function
>> >> >>>>>> 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
>> >> >>>>> assembly is  up and running. There is already a new class
>> DofMap
>> >> which
>> >> >>>>> will handle this.
>> >> >>>>>
>> >> >>>>> Garth

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

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

> covered by the current specification or if we need to add something to

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.

> on ufc-dev which I think is very much related to this issue.

Ok.

/Johan

> UFC-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/ufc-dev
>

---

From: "Garth N. Wells" <[email-masked]>
Date: Mon, 05 Feb 2007 12:03:21 +0100

> stand-alone packages with a UFC in between (and similar for PyCC etc.)?

dolfin::DofMap should/can be constructed to return whatever is needed, 
in addition to renumbering, etc.

> sizes etc. in the form. I am not updated on UFC of today, so maybe it is

I would like to see the functionality to define functions on entities 
with topological dimension different from the geometric dimension (like 
on triangles in 3D). Then things like normals and tangents can be 
treated as functions.  I think that it's better to keep mesh geometry 
out of the form compiler.

> continuous improvements. But I assume that this is what you do.

I agree about UFC. I think that we'll see what we really need when
we start using it. Don't get too attached to the new UFC standard :).

Garth

---

From: Anders Logg <[email-masked]>
Date: Mon, 5 Feb 2007 12:07:35 +0100

> 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 

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

> 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

> 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

---

From: "Johan Hoffman" <[email-masked]>
Date: Mon, 5 Feb 2007 12:13:38 +0100 (MET)

> in addition to renumbering, etc.

Sounds good!

> out of the form compiler.

Yes, this may be the best way to go. Such an extension should not be to
hard, as far as I can see.

/Johan

---

From: "Johan Hoffman" <[email-masked]>
Date: Mon, 5 Feb 2007 12:26:10 +0100 (MET)

>> >> >> >>>>>> defined by a mixed element: I get the impression that we
>> use a
>> >> >> different
>> >> >> >>> Generally, you can never be sure how the dofs are ordered.
>> This
>> >> >> could
>> >> >> >>> different form compilers. As long as the generated code
>> follows
>> >> the
>> >> >> >> the dof mapping. UFC should provide the input to DofMap, but
>> the
>> >> user

Yes this is probably better.

> 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

---

From: Anders Logg <[email-masked]>
Date: Mon, 5 Feb 2007 13:02:24 +0100

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

/Anders

---

From: "Johan Hoffman" <[email-masked]>
Date: Mon, 5 Feb 2007 13:12:31 +0100 (MET)

>> >> >> >> >>>>>> About the global dof numbering for the different
>> components
>> >> in
>> >> >> a
>> >> >> >> >>>>>> function
>> >> >> >> >>>>> I don't think so. For both mixed and vector elements,
>> dofs
>> >> at
>> >> >> the
>> >> >> >> same
>> >> >> >> >>>>> It will be possible to choose the dof ordering soon when
>> the
>> >> >> new
>> >> >> >> >> This sounds strange. DofMap will provide the functionality
>> to
>> >> >> >> influence
>> >> >> >> > I don't mind documenting how FFC actually orders the dofs,
>> but
>> >> the
>> >> >> >> 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
>> >> >> clear to the user how the dofs are ordered, and the user should
>> have
>> >> >> full
>> >> I think it is good that you are including (I assume it was decided
>> so)
>> >> the

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

---

From: Anders Logg <[email-masked]>
Date: Mon, 5 Feb 2007 13:18:58 +0100

> 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