← Back to team overview

dolfin team mailing list archive

Re: ufc ordering in parallel

 

On Tue, Apr 28, 2009 at 03:36:48PM -0500, Matthew Knepley wrote:
> On Tue, Apr 28, 2009 at 3:32 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> 
>     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).
> 
> 
> How does this work for higher dimensions?
> 
>    Matt

You mean faces on tets? Same thing there, we assign a unique orientation
based on the vertices of the faces.

Or do you mean higher dimension as in higher than R^3? Kent and I did
this for arbitrary subsimplices in R^n in the Exterior Calculus
package and it works there as well. In particular numbering entities
based on a lexicographical ordering of their non-incident vertices.

-- 
Anders

Attachment: signature.asc
Description: Digital signature


Follow ups

References