On Thu, Aug 23, 2012 at 5:59 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im">On Thu, Aug 23, 2012 at 5:50 PM, Chris Eldred <span dir="ltr"><<a href="mailto:chris.eldred@gmail.com" target="_blank">chris.eldred@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For the extended operators, I was going to write:<br>
<br>
1) DMComplexGetLabelClosure- returns the points from a transitive<br>
closure with a given value for a given label (this will implement both<br>
star(vertex) \ support(vertex) and closure(cell) \ cone(cell); along<br>
with many other operators)<br>
2) DMComplexGetNeighbors- returns U cone(support()) OR U<br>
support(cone()) by setting a Boolean flag<br>
<br>
These two operators should cover "nearest neighbors" of all types.<br></blockquote><div><br></div></div><div>What about having<br><br>typedef enum {DMCOMPLEX_VERTEX = 0x1,DMCOMPLEX_EDGE = 0x2,DMCOMPLEX_FACE = 0x4,DMCOMPLEX_CELL = 0x8} DMComplexPointType;<br>
<br>DMComplexGetClosure(dm,point_type,label,array,basepoint,&npoints,&values)<br><br>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).</div>
</div></blockquote><div><br></div><div>Never.</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">
<div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br>
On Thu, Aug 23, 2012 at 12:39 PM, Chris Eldred <<a href="mailto:chris.eldred@gmail.com" target="_blank">chris.eldred@gmail.com</a>> wrote:<br>
> Sounds good- I will write the extended topological operators (<br>
> star(vertex) \ support(vertex) ; closure(cell) \ cone(cell) and U<br>
> cone(support(edge)) ) and let you know if I have questions/run into<br>
> issues!<br>
><br>
> -Chris<br>
><br>
> On Thu, Aug 23, 2012 at 12:22 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br>
>> On Thu, Aug 23, 2012 at 12:19 PM, Chris Eldred <<a href="mailto:chris.eldred@gmail.com" target="_blank">chris.eldred@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> I am working with a 2D unstructured mesh using sieve and I wanted to<br>
>>> get some advice on how to determine adjacency relations using the<br>
>>> topological operators provided by Sieve (cone, support, closure,<br>
>>> star). I have figured out the following:<br>
>>><br>
>>> Vertices for a given edge: cone(edge)<br>
>>> Cells for a given edge: support(edge)<br>
>>><br>
>>> Cells for a given vertex: star(vertex) \ support(vertex)<br>
>>> Edges for a given vertex: support(vertex)<br>
>>><br>
>>> Edges for a given cell: cone(cell)<br>
>>> Vertices for a given cell: closure(cell) \ cone(cell)<br>
>>><br>
>>> The set of edges associated with the cells for a given edge: U<br>
>>> cone(support(edge)) - ie the union of the cones of the support of the<br>
>>> edge<br>
>>><br>
>>> Are there other topological operators that more naturally express<br>
>>> these relations (especially the ones involving unions or complements)?<br>
>><br>
>><br>
>> The only other builtin operations are meet and join. You are correct that<br>
>> you<br>
>> want to use union there. We could add routines like<br>
>><br>
>> DMComplexGetConeUnion(dm, [p], &unionSize, &unionArray);<br>
>><br>
>> but it was not clear that would do anything other than bloat the interface.<br>
>> I<br>
>> think the best way to procede is to write these convenience routines using<br>
>> the lower level primitives, and move them into PETSc if they turn out to be<br>
>> useful. I can help you write them.<br>
>><br>
>> Matt<br>
>><br>
>>><br>
>>><br>
>>> --<br>
>>> Chris Eldred<br>
>>> DOE Computational Science Graduate Fellow<br>
>>> Graduate Student, Atmospheric Science, Colorado State University<br>
>>> B.S. Applied Computational Physics, Carnegie Mellon University, 2009<br>
>>> <a href="mailto:chris.eldred@gmail.com" target="_blank">chris.eldred@gmail.com</a><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> What most experimenters take for granted before they begin their experiments<br>
>> is infinitely more interesting than any results to which their experiments<br>
>> lead.<br>
>> -- Norbert Wiener<br>
><br>
><br>
><br>
> --<br>
> Chris Eldred<br>
> DOE Computational Science Graduate Fellow<br>
> Graduate Student, Atmospheric Science, Colorado State University<br>
> B.S. Applied Computational Physics, Carnegie Mellon University, 2009<br>
> <a href="mailto:chris.eldred@gmail.com" target="_blank">chris.eldred@gmail.com</a><br>
<br>
<br>
<br>
--<br>
Chris Eldred<br>
DOE Computational Science Graduate Fellow<br>
Graduate Student, Atmospheric Science, Colorado State University<br>
B.S. Applied Computational Physics, Carnegie Mellon University, 2009<br>
<a href="mailto:chris.eldred@gmail.com" target="_blank">chris.eldred@gmail.com</a><br>
</div></div></blockquote></div></div></div><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>