dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Apr 28, 2009 at 03:25:18PM -0500, Matthew Knepley wrote:
> On Tue, Apr 28, 2009 at 3:05 PM, Robert Kirby <robert.c.kirby@xxxxxxxxx> wrote:
> 
>     Hi all,
>     it's my understanding that the way ufc ordering works is for adjacent cells
>     to
>     alternate orientation so that they traverse edges (and faces in 3d) the
>     same global
>     way.  It seems that in 2d this is equivalent to two-coloring a graph (each
>     cell is either
>     clockwise or counterclockwise)
> 
>     Has there been any thought to issues at imposing ufc ordering in parallel,
>     where each
>     process has to assign an orientation to the first local cell, and different
>     processors
>     might disagree?
> 
> 
> How would this disagreement come about? Maybe I do not understand what UFC is
> doing
> here is how I do it:
> 
>   1) Values are associated with Sieve points. If there are multiple values on
> an edge, these
>        values are ordered here.
> 
>   2) Every Sieve arrow has an orientation. This orientation produced by a
> traversal concatenates
>       these orientations, and is relative to orientation to the initial
> orientation in the Sieve.
> 
>   3) I do not see the parallel problem because all data is just traded between
> shared sieve
>       points, and thus has identical orientations. However, I use the
> traversals to construct
>       ordered arrays of data. Maybe UFC does something else.
> 
>   Matt

With UFC, the orientation is never stored but implied by the vertices
of the entity, going from lower index to higher index. So an edge from
vertex 15 to 25 will be directed 15 --> 25 which means two cells
sharing a common edge from 15 to 25 will both assign the same
direction (since they have a common numbering for the vertices).

-- 
Anders

Attachment: signature.asc
Description: Digital signature