[MOAB-dev] Some MOAB capability questions

[Chris Eldred]

1) That makes sense and is easy to implement, thanks!

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)?

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?

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.

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?

Is the ordering convention for edges/vertices the one returned by
get_adjacencies?

-Chris

On Thu, Oct 17, 2013 at 5:41 PM, Iulian Grindeanu <iulian at mcs.anl.gov>wrote:

>
>
> ------------------------------
>
> Hey MOAB-dev,
>
> I have some quick questions about capabilities in MOAB:
>
> 1) For bridge_adjacencies, is it possible to have them return the original
> (calling) Entity as well? For example, if I call
>     result = MeshTopoUtil(iface).get_bridge_adjacencies(*start_elem, 1, 2,
> NC);
> 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?
>
> 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)
>
>
> 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.
>
>
> Are you asking about polyhedra or polygon?
> 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.
>
> 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).
>
> 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)
>
> 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.
>
>
> 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?
>
> for polyhedra and polygons, we do not have a CN representation.
> For polygons, we have a clear convention for numbering edges and vertices
> (it is also natural)
>  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.
>
> 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)
>
> 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.
>
> Your question refers to edges in polyhedra or to edges in polygons? Or to
> faces in polyhedra?
>
> Anyway, the sense in the face between polyhedra (or edge between polygons)
> is fixed, so maybe you can use that.
>
> Maybe I didn't understand your question.
>
> Thanks,
> Iulian
>
>
> Thanks,
> Chris Eldred
>
> --
> 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 / celdred at atmos.colostate.edu
>
>
>


-- 
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 / celdred at atmos.colostate.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20131018/229e7412/attachment.html>