For the extended operators, I was going to write: 1) DMComplexGetLabelClosure- returns the points from a transitive closure with a given value for a given label (this will implement both star(vertex) \ support(vertex) and closure(cell) \ cone(cell); along with many other operators) 2) DMComplexGetNeighbors- returns U cone(support()) OR U support(cone()) by setting a Boolean flag
These two operators should cover "nearest neighbors" of all types. On Thu, Aug 23, 2012 at 12:39 PM, Chris Eldred <chris.eldred at gmail.com> wrote: > Sounds good- I will write the extended topological operators ( > star(vertex) \ support(vertex) ; closure(cell) \ cone(cell) and U > cone(support(edge)) ) and let you know if I have questions/run into > issues! > > -Chris > > On Thu, Aug 23, 2012 at 12:22 PM, Matthew Knepley <knepley at gmail.com> > wrote: >> On Thu, Aug 23, 2012 at 12:19 PM, Chris Eldred <chris.eldred at gmail.com> >> wrote: >>> >>> I am working with a 2D unstructured mesh using sieve and I wanted to >>> get some advice on how to determine adjacency relations using the >>> topological operators provided by Sieve (cone, support, closure, >>> star). I have figured out the following: >>> >>> Vertices for a given edge: cone(edge) >>> Cells for a given edge: support(edge) >>> >>> Cells for a given vertex: star(vertex) \ support(vertex) >>> Edges for a given vertex: support(vertex) >>> >>> Edges for a given cell: cone(cell) >>> Vertices for a given cell: closure(cell) \ cone(cell) >>> >>> The set of edges associated with the cells for a given edge: U >>> cone(support(edge)) - ie the union of the cones of the support of the >>> edge >>> >>> Are there other topological operators that more naturally express >>> these relations (especially the ones involving unions or complements)? >> >> >> The only other builtin operations are meet and join. You are correct that >> you >> want to use union there. We could add routines like >> >> DMComplexGetConeUnion(dm, [p], &unionSize, &unionArray); >> >> but it was not clear that would do anything other than bloat the interface. >> I >> think the best way to procede is to write these convenience routines using >> the lower level primitives, and move them into PETSc if they turn out to be >> useful. I can help you write them. >> >> Matt >> >>> >>> >>> -- >>> Chris Eldred >>> DOE Computational Science Graduate Fellow >>> Graduate Student, Atmospheric Science, Colorado State University >>> B.S. Applied Computational Physics, Carnegie Mellon University, 2009 >>> chris.eldred at gmail.com >> >> >> >> >> -- >> 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 > > > > -- > Chris Eldred > DOE Computational Science Graduate Fellow > Graduate Student, Atmospheric Science, Colorado State University > B.S. Applied Computational Physics, Carnegie Mellon University, 2009 > chris.eldred at gmail.com -- Chris Eldred DOE Computational Science Graduate Fellow Graduate Student, Atmospheric Science, Colorado State University B.S. Applied Computational Physics, Carnegie Mellon University, 2009 chris.eldred at gmail.com
