On Wed, Jul 25, 2012 at 1:07 PM, Chris Eldred <span dir="ltr"><<a href="mailto:chris.eldred@gmail.com" target="_blank">chris.eldred@gmail.com</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">
Lets consider the mesh from "Flexible Representation of Computational Meshes" on the LHS of figure 2. (0,1) (0,2) (0,3) and (0,4) are vertices; (0,5), (0,6), (0,7), (0,8) and (0,9) are edges; (0,10) and (0,11) are cells. My field would be defined as (for example):<br>
<br>field ( (0,5) ; (0,10) ) = 1.0<br>field ( (0,6) ; (0,10) ) = 2.0<br>field ( (0,7) ; (0,11) ) = 1.3<br><div class="gmail_quote">etc.<br><br>Does that make sense?<br></div></blockquote><div><br></div><div>Oh, are you wanting something like DG? The tying of data values to mesh points is primarily to indicate</div>
<div>sharing of values. If you have something like DG, I would initially do something like you did, which is</div><div>assign all the variables to the cell since they are not shared. Since the cone is always oriented, the</div>
<div>association between edges and values would be guaranteed.</div><div><br></div><div>I have thought about another way to do this, but I don't think its any easier. You could instead associate</div><div>2 values with an edge, one for one side and the other for another. You can then look at the coneOrientation</div>
<div>for that edge in the cell to know which value to choose for the cell. I am not sure this is easier, but it does</div><div>facilitate communication of the "other" value for cells with neighbors on other processes.</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">On Wed, Jul 25, 2012 at 11:57 AM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Wed, Jul 25, 2012 at 12:52 PM, Chris Eldred <span dir="ltr"><<a href="mailto:chris.eldred@gmail.com" target="_blank">chris.eldred@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The closure operation makes sense, but what I want is something a little different.<br><br>I have a field that is defined as follows:<br>field(edge,cell) = blah<br>ie it really lives on the union of cells and edges (or vertex/edges, cells/vertexs, etc.)<br>
</blockquote><div><br></div></div><div>We need to make the language more precise. The union of the cell and edge is what</div><div>closure would give you.</div><div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Is this something that can be defined using DMComplex and Sections?</blockquote><div><br></div></div><div>I cannot understand from this explanation. Can you give a small example?</div><div><br></div><div> Thanks,</div><div>
<br>
</div><div> Matt</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div class="gmail_quote">On Wed, Jul 25, 2012 at 11:39 AM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Wed, Jul 25, 2012 at 11:23 AM, Chris Eldred <span dir="ltr"><<a href="mailto:chris.eldred@gmail.com" target="_blank">chris.eldred@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I was wondering if it was possible to have fields that are shared between points in a sieve DAG: <br><br>For example, I would like to have data that is connected to both an edge and a cell (instead of just tied to a Section). Consider a cell with three edges (ie a triangular cell).<br>
<br>Before I was just using a length 3 array attached to the cell with the convention that the ordering of the array matched the ordering of the edge list associated with the cell. Now, I would like an implementation that does not assume anything about the ordering of the edge list (since I am getting that from cones/supports).<br>
</blockquote><div><br></div></div><div>I think what you want is the Closure operation. The closure of a cell will give you all the unknowns on its edges and vertices.</div><div>Does that make sense?</div><div><br></div><div>
Thanks,</div>
<div><br></div><div> Matt</div><div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks,<br>-Chris Eldred<span><font color="#888888"><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>
</font></span></blockquote></div></div><span><font color="#888888"><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>
</font></span></blockquote></div><br><br clear="all"><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><div><div><br><br clear="all"><span class="HOEnZb"><font color="#888888"><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>
</font></span></div></div></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><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>
</font></span></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>