Subject: [UFC-dev] Interpretation of tabulate_facet_dofs and tabulate_entity_dofs

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 2 Jan 2008 14:44:30 +0100

I have implemented the new functions in my local ufc repository, both
to ufc.h and the python utilities, and the manual. I have some
problems with compiling the manual though (seems to be the eps files
and the algorithm environment), so I won't check in before that is
resolved.

There's also an issue I'm not sure we all have the same interpretation
of. I propose the following interpretation of the ufc::dof_map
functions tabulate_facet_dofs and tabulate_entity_dofs:

tabulate_entity_dofs:
 Pure connectivity information, i.e. returns 0 dofs for DG elements
(all dofs are associated with the cell), and 0 dofs for facets of
linear Lagrange elements (all dofs are associated with vertices, none
with facets).

tabulate_facet_dofs:
 Not to be used to get connectivity information, includes dofs at
vertices and edges of the facet, and includes discontinuous dofs. Can
this be used to apply Dirichlet conditions for all elements then?

This may be different from the current implementation of
tabulate_facet_dofs in FFC (at least for DG elements, am I right?),
but it is consistent with how I've implemented tabulate_facet_dofs in
SyFi, and it is consistent with the manual for UFC v1.0:

3.7.8    The function num facet dofs
 virtual unsigned int num_facet_dofs() const = 0;
This function returns the number of dofs tied to a single facet of a cell. This
is the number of dofs that should be set if a Dirichlet boundary condition is
applied to a single facet.

-- 
Martin

---

From: Anders Logg <[email-masked]>
Date: Wed, 2 Jan 2008 15:37:26 +0100

> and the algorithm environment), so I won't check in before that is

I think algorithm.sty has been removed from Ubuntu (it disappeared for
me in an upgrade) so we just need to add it to the repository.
 
> linear Lagrange elements (all dofs are associated with vertices, none

I'm a little confused. Shouldn't tabulate_entity_dofs give the dofs
associated with any given entity, so for DG elements they should
return the dofs associated with the cell if one asks for the cell,
otherwise 0 for vertices, edges etc.

> this be used to apply Dirichlet conditions for all elements then?

I think we decided (in FFC) to not include the dofs on the facets for
DG. I think this should only return the dofs associated with the facet
*and all entities of lower dimension incident with the facet*.

For DG, we set strong BCs by using tabulate_coordinates. There are
three ways to locate the dofs for BCs in DOLFIN:

  enum BCMethod {topological, geometrical, pointwise};

The topological method sets the values for dofs returned by
tabulate_facet_dofs, geometrical looks at the coordinates (which is
slower but will also catch the dofs for DG elements), and pointwise is
used to set a BC at a single point.

> SyFi, and it is consistent with the manual for UFC v1.0:

Can we change so that we don't include the cell dofs (for DG) in
tabulate_facet_dofs? Including the interior dofs leads to problems
when setting BCs. Consider the following mesh of the unit square:

  _______
 |  /|  /|
 | / | / |
 |/__|/__|
 |  /|* /|
 | / | / |
 |/__|/__|

The triangle marked with a * has two vertex dofs at the boundary, but
since it does not have an edge on the boundary, the two vertex dofs
will never be tabulated (by tabulate_facet_dofs).

To catch those two dofs, one must look at the coordinates (which is
what the geometrical search in DOLFIN does).

> applied to a single facet.

This looks correct and it does not seem be inconsistent with *not*
including the interior dofs for a DG element.

-- 
Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 2 Jan 2008 17:12:06 +0100

> me in an upgrade) so we just need to add it to the repository.

Ok. Can you add it if you have it?

> otherwise 0 for vertices, edges etc.

Yes, that's what I intended to write.

> *and all entities of lower dimension incident with the facet*.

Agreed. I'll update the manual with that sentence.

> what the geometrical search in DOLFIN does).

Ok.

> including the interior dofs for a DG element.

Ok. I'll make this clearer in the manual as well.

-- 
Martin

---

From: Anders Logg <[email-masked]>
Date: Wed, 2 Jan 2008 22:57:03 +0100

> Ok. Can you add it if you have it?

ok, done.

-- 
Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Thu, 3 Jan 2008 14:33:44 +0100

> > Ok. Can you add it if you have it?

This didn't help. My computer still uses 100% cpu for a very long time
(I don't know if it's infinite) when seeing the \begin{algorithm}, or
when including the eps files. Evince make my laptop with 2Gb memory
swap when opening f.ex. hexahedron.eps, so something is strange there.
But it didn't help to use ps2ps on the eps files, although that makes
evince read them quickly. I also get some strange errors on the tables
in reference_cell_common and numbering_common.

But the files I've changed compiles fine, so the manual changes are
ready for revision. See appendix E for which new functions are added.

--
Martin

---

From: Anders Logg <[email-masked]>
Date: Fri, 4 Jan 2008 00:50:15 +0100

> in reference_cell_common and numbering_common.

You must have a broken system. hexahedron.eps looks like a perfectly
fine eps to me (evince version 2.20.1-0ubuntu). Compiling the manual
works fine.

> ready for revision. See appendix E for which new functions are added.

ok, looks good. But I would like to take a closer look before we
release 1.1. Maybe we can set a deadline for everyone interested to
comment and then we make the release?

-- 
Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Fri, 4 Jan 2008 08:51:20 +0100

> comment and then we make the release?

Sounds good. There's no rush, so what about before the end of January?

-- 
Martin

---

From: Anders Logg <[email-masked]>
Date: Sun, 6 Jan 2008 21:22:40 +0100

> Sounds good. There's no rush, so what about before the end of January?

How about a week later? There's quite a few deadlines already at Jan
31.

-- 
Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Sun, 6 Jan 2008 21:37:56 +0100

Ok.

-- 
Martin