[MOAB-dev] Some MOAB capability questions

[Iulian Grindeanu]

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

| 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20131017/dc4940e8/attachment.html>