dolfin team mailing list archive

[Johan Jansson <jjan@xxxxxxxxxxx>]

On Thu, Mar 01, 2007 at 10:42:21AM +0100, Anders Logg wrote:
> On Thu, Mar 01, 2007 at 10:13:00AM +0100, Johan Jansson wrote:
> > Hi!
> > 
> > I've made the assumption that the ordering of the vertices in a
> > physical triangle are counter-clockwise. Can I make this assumption?
> 
> No, unfortunately not. The new ordering means that the vertices are
> always ordered by ascending global index:
> 
>        15 19 25
>        15 17 25
>        etc
> 
> The orientation depends on how the vertices happen to be numbered.
> 
> This makes life much easier when dealing with degrees of freedom on
> edges and facets. For example, two adjacent triangles will always
> agree on the direction of a common edge:
> 
>              25______17
>              /\      /
>             /  \    /
>            /    \  /
>           /______\/
>          19      15
> 
> Here, the common edge is from 15 --> 25. The left triangle is
> clockwise and the right one is counter-clockwise in the plane.
> 
> Note that no special ordering can be assumed if the mesh has not been
> ordered. If you just read a mesh from file, then the ordering depends
> on how the vertices happen to be numbered in that file. To order a
> mesh, just do
> 
>     mesh.order();
> 
> Every ordered mesh follows the convention in the UFC, FFC and DOLFIN
> manuals (unless there is a bug in the implementation).

Ok. This is not a big issue, as long as it's well-defined.

> 
> > (I have a mesh now where this is not true) If not, then we need
> > functions for computing the orientation (and the corresponding in
> > 3D). Alternatively we need to enforce the ordering.
> > 
> > Or have I missed something?
> 
> I think we had a function orientation() a while back that computed the
> orientation of a cell (it has not been ported to the new
> mesh). Perhaps this can be readded?
> 

Sure, I'll try to figure it out.

  Johan