iMesh telecon: closure and adjacency

[James Porter]

On Wed, 2010-09-08 at 09:29 -0700, Carl Ollivier-Gooch wrote:
> If MOAB is returning an error here, it shouldn't.  This is defined 
> implicitly by the behavior written into the unit tests, which expect (as 
> we decided a couple of years ago) consistent adjacency calls to do no 
> worse than silently return no data*; alas, we don't have definitive docs 
> on error returns.

This would be enough for me to be - if not actually happy - at least
more-or-less satisfied.

> If the set contains vertices and you ask every entity 
> for the indices of adjacent vertices, the non-vertices should return 
> what you expect, and the vertices should return empty sub-lists.  I 
> don't see how this makes it hard for you to replicate the contents of 
> the set.  What info are you going to be missing here?  If you're worried 
> about having an isolated vertex (one with no upward-adjacent entities in 
> the set), then you can iterate over vertices in the set to be sure you 
> get them all copied.

By defining entities to be adjacent to themselves, I can get all the
vertices "relevant" to a set (either verts themselves or adjacent verts
to other entities) as a single list. This makes things slightly easier
if I wanted to, say, copy the set because I can pass the adjacency list
directly to iMesh_getVtxCoords, and then pass that directly to
iMesh_createVtxArr. I had a similar issue when trying to extrude a
surface into a higher dimension, and in the end I wrote a version of
iMesh_getAdjEntIndices that worked how I wanted.

Again though, if the spec actually says that same-topology adjacency
calls return an empty list, I'm ok with that, even if it's not optimal
for my use.

If you'd like more details about why "entities are adjacent to
themselves" helps me, I can write up some stuff about how I extrude
surfaces, but be warned that I'm technically on vacation now, so I might
be slow to send stuff out.

- Jim