[petsc-dev] Adjacency relations in Sieve and stencils

Jed Brown jedbrown at mcs.anl.gov
Thu Aug 23 18:18:53 CDT 2012

On Thu, Aug 23, 2012 at 6:16 PM, Matthew Knepley <knepley at gmail.com> wrote:

> On Thu, Aug 23, 2012 at 5:59 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>> On Thu, Aug 23, 2012 at 5:50 PM, Chris Eldred <chris.eldred at gmail.com>wrote:
>>> 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.
>> What about having
>> = 0x4,DMCOMPLEX_CELL = 0x8} DMComplexPointType;
>> DMComplexGetClosure(dm,point_type,label,array,basepoint,&npoints,&values)
>> You can always use point_type = my_type-1 to get values from all points
>> in the closure, but this allows you to jump directly to particular levels.
>> Similar for Support. Then you could get rid of cone and star because nobody
>> can remember those anyway. You just have Closure and Support with results
>> restricted to points of a given type (topological dimension).
> Never.

Note that you can do bitwise or and that mytype-1 gives the current Closure
behavior while mytype>>1 gives Cone. (Wrap the shifts in convenience
functions if you like.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120823/f6f1977a/attachment.html>

More information about the petsc-dev mailing list