[MOAB-dev] Some MOAB capability questions

Fri Oct 18 16:09:11 CDT 2013

Hello, 
Please see below 

----- Original Message -----

| 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 suggestion would be to not use "MeshTopoUtil"; use Interface::get_adjacency() version that returns std::vector<EntityHandle> ; 
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) 

Each edge will be oriented in some way, you have to use "side_number" to make sure. 

| 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.

yes, you will have to check, to be sure about the actual number of vertices, something like this 
... 
result = thisMB->get_connectivity(*iter, conn, num_nodes); 
... 
// treat padded polygons, if existing; count backwards, see how many of the last nodes are repeated 
// assume connectivity is fine, otherwise we could be in trouble 
actual_num_nodes_polygon = num_nodes; 
while (actual_num_nodes_polygon >= 3 && 
conn[actual_num_nodes_polygon-1]==conn[actual_num_nodes_polygon-2]) 
actual_num_nodes_polygon--; 
num_sides = actual_num_nodes_polygon; 
... 

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

using side_number() method on Interface, it returns the sense also. 
For padded polygons this is not working yet, but it is an easy fix. 

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

for vertices use get_connectivity; for edges , yes, use std::vector<> variant 

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

| | | 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/dc585a8f/attachment-0001.html>