On Tue, Apr 28, 2009 at 3:40 PM, Anders Logg <[email protected]> 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 <[email protected]> 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 < > [email protected]> > > 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 > [email protected] > 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
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
