dolfin team mailing list archive

[Matthew Knepley <knepley@xxxxxxxxx>]

On Tue, Apr 28, 2009 at 3:40 PM, Anders Logg <logg@xxxxxxxxx> wrote:

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


Yes, this is what I meant. It seems like this will only work for simplices?

  Matt


>
> --
> Anders
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkn3adUACgkQTuwUCDsYZdEzeQCcD0imcewh0IhvLY2oE/h9EoKY
> 45wAn3i9pdGq7fvT0pr8OfXNgIG5XSEn
> =CTvc
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>
>


-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener