<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: times new roman,new york,times,serif; font-size: 12pt; color: #000000'>Hello,<br>Please see below<br><br><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div id="DWT2881"><div>1) That makes sense and is easy to implement, thanks!<br><br></div>2) Sorry for the confusion, I am working with 2D meshes so it would be polygons. So get_adjacencies returns a fixed order; but bridge_adjacencies does not (since it returns a Range)? <br>
<br>Mostly what I need are Tags that are associated with the connections between entities (for example, all of the edges for a given face, or all of the bridge adjacent edges for a given edge). These would be used for storing weights associated with a finite difference stencil (where the stencil is defined in terms of adjacencies or bridge adjacencies). It sounds like side number would work for non-bridge adjacencies, do you have a suggestion for bridge adjacencies?<br></div></div></blockquote>my suggestion would be to not use "MeshTopoUtil"; use Interface::get_adjacency() version that returns std::vector<EntityHandle> ;<br>first get a list of edges (ordered in canonical order, guaranteed, with create_if_missing = true), then get adjacencies again for each edge (if you need a list of cells in the right order)<br><br>Each edge will be oriented in some way, you have to use "side_number" to make sure.<br><br><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div>
<br></div><div id="DWT2882">My meshes will be either all one type of polygonal cell (quads or hexagons) or very minimally degenerate (example an icosahedral grid on the sphere, where everything is a hexagon except for 12 pentagonal cells); so I can accept the MPAS solution of having every polygon with the same number of vertices (and thus all Tags can be fixed-length) and just dealing with the pentagonal degeneracy in some way.<br></div></div></blockquote>yes, you will have to check, to be sure about the actual number of vertices, something like this<br><font face="courier new,courier,monaco,monospace,sans-serif">...<br> result = thisMB->get_connectivity(*iter, conn, num_nodes);<br> ...<br> // treat padded polygons, if existing; count backwards, see how many of the last nodes are repeated<br> // assume connectivity is fine, otherwise we could be in trouble<br> actual_num_nodes_polygon = num_nodes;<br> while (actual_num_nodes_polygon >= 3 &&<br> conn[actual_num_nodes_polygon-1]==conn[actual_num_nodes_polygon-2])<br> actual_num_nodes_polygon--;<br> num_sides = actual_num_nodes_polygon;</font><br>...<br><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div>
<br></div><div id="DWT2883">3) I am referring to edges between polygons. It sounds like the orientation (sense?) of the edge wrt a polygon is what I need. How is that accessed?<br><br></div></div></blockquote>using side_number() method on Interface, it returns the sense also.<br>For padded polygons this is not working yet, but it is an easy fix.<br><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div></div><div id="DWT2884">Is the ordering convention for edges/vertices the one returned by get_adjacencies?<br></div></div></blockquote>for vertices use get_connectivity; for edges , yes, use std::vector<> variant<br><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div>
<br></div>-Chris<br><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 17, 2013 at 5:41 PM, Iulian Grindeanu <span dir="ltr"><<a href="mailto:iulian@mcs.anl.gov" target="_blank">iulian@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:times new roman,new york,times,serif"><br><br><hr><div class="im"><blockquote style="padding-left:5px;font-size:12pt;font-style:normal;margin-left:5px;font-family:Helvetica,Arial,sans-serif;text-decoration:none;font-weight:normal;border-left:2px solid #1010ff">
<div dir="ltr"><div>Hey MOAB-dev,<br><br></div><div>I have some quick questions about capabilities in MOAB:<br><br></div><div>1) For bridge_adjacencies, is it possible to have them return the original (calling) Entity as well? For example, if I call<br>
result = MeshTopoUtil(iface).get_bridge_adjacencies(*start_elem, 1, 2, NC);<br></div><div>on a 2D quadrilateral mesh where start_elem is a face, it will return the 4 adjacent cells (as intended). Is there an option to have it return start_elem AND the 4 adjacent cells?<br>
</div><div><br></div></div></blockquote></div>no, I don't think so; but you just need then NC.insert(*start_elem), and you are done, aren't you? (NC is the output range with the 4 adjacent cells)<div class="im"><br>
<br><blockquote style="padding-left:5px;font-size:12pt;font-style:normal;margin-left:5px;font-family:Helvetica,Arial,sans-serif;text-decoration:none;font-weight:normal;border-left:2px solid #1010ff"><div dir="ltr"><div></div>
<div>2) Consider a variable length tag for a cell in a polyhedral mesh, with a tag length equal to the number of neighbouring cells. The neighbouring cells can be obtained with a bridge_adjacency. Is there a way to associate each entry of the tag with a specific cell from the bridge_adjacency in a consistent manner? This would be useful, for example, in generating/storing weights that are associated with a stencil.<br>
</div><div><br></div></div></blockquote><br></div>Are you asking about polyhedra or polygon?<br>Polyhedra is defined in moab by a list of faces, and each face is a polygon (or 2d cell). I think that you would have to go to each face in order, and get the other cell (using get_adjacencies to the face); the order of faces in polyhedra is fixed, and guaranteed.<br>
<blockquote style="padding-left:5px;font-size:12pt;font-style:normal;margin-left:5px;font-family:Helvetica,Arial,sans-serif;text-decoration:none;font-weight:normal;border-left:2px solid #1010ff"><div dir="ltr"><div></div>
</div></blockquote>Using bridge_adjacency will return a Range, so you lose the order of sides. (because a Range is a container that orders the entity handles you add to it). If the order is important, you have to use std::vector<EntityHandle> containers to store your faces/ (or edges for polygons). <br>
<br>for polygons, you may need to use side_number to get the order. (but then you have to go through edges, anyway, Core::side_number works between 2d cells and edges, for example)<br><br>As a side note, Danqing added an option (for MPAS reader), where all polygons have the same number of vertices; the last vertices might be repeated. It is not default yet, but there are many advantages. One would be for you, for example, that you need a fixed size tag, not a variable one (would save memory there too). Of course, to get the actual number of vertices, you may need to do some comparisons between last vertices.<div class="im">
<br><br><blockquote style="padding-left:5px;font-size:12pt;font-style:normal;margin-left:5px;font-family:Helvetica,Arial,sans-serif;text-decoration:none;font-weight:normal;border-left:2px solid #1010ff"><div dir="ltr"><div>
</div><div>3) For edges in a polyhedral mesh, my application requires the selection of a preferred direction (orientation) for flow across that edge. This is conventionally denoted n_{e,i}, where e is an edge and i is a cell; it is +1 for flow into the cell i and -1 for flow out of the cell i. What is the best way to represent this in MOAB? Is this connected to the side_number/canonical numbering?<br>
</div></div></blockquote></div>for polyhedra and polygons, we do not have a CN representation.<br>For polygons, we have a clear convention for numbering edges and vertices (it is also natural)<br> for polygons, the edges are numbered from the first vertex (so edge 0 is between vertex 0 and vertex 1, ..., last edge is between last vertex and vertex 0). This is also the positive orientation for the edge, with respect to the polygon. <br>
<br>So an edge between 2 polygons will most likely be positive oriented on one polygon, and negative oriented on the other. (assuming that the polygons are oriented similarly)<br><br>For a polygon in a polyhedra, our convention is that it is positive oriented if the normal is out of the polyhedra. Between 2 polyhedra, the polygon will be positive oriented for one and negative for the other.<br>
<br>Your question refers to edges in polyhedra or to edges in polygons? Or to faces in polyhedra?<br><br>Anyway, the sense in the face between polyhedra (or edge between polygons) is fixed, so maybe you can use that.<br><br>
Maybe I didn't understand your question.<br><br>Thanks,<br>Iulian<div class="im"><br><blockquote style="padding-left:5px;font-size:12pt;font-style:normal;margin-left:5px;font-family:Helvetica,Arial,sans-serif;text-decoration:none;font-weight:normal;border-left:2px solid #1010ff">
<div dir="ltr"><div>
</div><div><br></div>Thanks,<br>Chris Eldred<br clear="all"><div><div><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> / <a href="mailto:celdred@atmos.colostate.edu" target="_blank">celdred@atmos.colostate.edu</a>
</div></div></div>
</blockquote><br></div></div></div></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> / <a href="mailto:celdred@atmos.colostate.edu" target="_blank">celdred@atmos.colostate.edu</a>
</div></div></div></div></div></div>
</blockquote><br></div></body></html>