iMesh telecon: closure and adjacency

[Tim Tautges]

I was under the impression that asking for self-adjacencies was supposed to return an error.  I agree with Jim that 
silently returning nothing makes things less bad, though not ideal.  If it returns an error, then there are clear 
efficiency problems, due to the required filtering that you'd have to do on lists of entities passed to the adjacency 
call.  Are we sure that a silent return-nothing is what we specified?  I thought for sure it was supposed to return error...

- tim


On 09/08/2010 11:29 AM, Carl Ollivier-Gooch wrote:
> 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
>

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706