iMesh telecon: closure and adjacency

[Carl Ollivier-Gooch]

On 09/08/2010 12:53 AM, James Porter wrote:
> On Tue, 2010-09-07 at 12:18 -0700, Carl Ollivier-Gooch wrote:
>> One issue that was raised (more or less as an aside while talking about
>> iMesh compliance) is whether an entity should be considered adjacent to
>> itself.  The spec currently says that it is not, for first adjacencies.
>>    Also, the spec says that a second adjacency call should not return the
>> originating entity, even if it otherwise would.
>
> In my experience, I've never found it useful to exclude an entity from
> its adjacency list. While I understand the reasoning that "adjacent"
> implies "not myself", it always just makes things harder for me. For
> example, if I wanted to get all the information necessary to (re)create
> a set of entities, I could use iMesh_getAdjEntIndices to get all the
> entities plus the vertices that comprise them. However, this fails if
> the set contains vertices too. I'm not sure if it's MOAB-specific or
> not, but (as I recall) trying this even returns an error, so I don't get
> *any* useful data.

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

* The requested type and topology are required to be consistent; if they 
aren't, the implementation is expected to return an error code of 
BAD_TYPE_AND_TOPOLOGY.  (Ditto for inconsistent requests to create an 
iterator.)   We discussed last week whether this consistency requirement 
is a good thing.  Jason argued that if an app asks for a particular 
topology (i.e., not iMesh_ALL_TOPOLOGIES) then the type should be 
ignored.  The spec currently says that the type and topology must be 
consistent (or one of them must be a wildcard).  Personally, I don't see 
any reason to change this behavior: even if the caller is being passed a 
topology and isn't sure what it might be, using iBase_ALL_TYPES for the 
type makes the call consistent.  Are there possible scenarios in which 
this might require different coding in a service/app?  Yes, but that's 
true for every decision in the API.

> At the very least, I think getting the adjacent vertices to a vertex
> should just return an empty list instead of returning an error. There's
> nothing so fundamentally "wrong" about returning same-dimension
> adjacencies that it should return an error, in my opinion.

Not returning an error is the behavior that's currently expected: asking 
a face for adjacent faces (for instance) is supposed to silently return 
an empty list.  For array calls, that entity will return an empty 
sublist, even though others will produce non-empty sublists.

Overall, I guess I'm not seeing a real problem that needs solving here. 
  (And if there isn't, then we should take advantage of an opportunity 
to leave the syntax and semantics of the API alone.)  Am I overlooking 
something in the above?

Carl

-- 
------------------------------------------------------------------------
Dr. Carl Ollivier-Gooch, P.Eng.                   Voice: +1-604-822-1854
Professor                                           Fax: +1-604-822-2403
Department of Mechanical Engineering             email: cfog at mech.ubc.ca
University of British Columbia              http://www.mech.ubc.ca/~cfog
Vancouver, BC  V6T 1Z4                  http://tetra.mech.ubc.ca/ANSLab/
------------------------------------------------------------------------