iMesh telecon: closure and adjacency

Mark Miller miller86 at llnl.gov
Wed Sep 8 10:36:28 CDT 2010


Hi all,

So, I don't have anywhere near as much experience with this in practice
as others do. But, I'm inclined to believe there are good arguments
(from performance perspective, software engineering perspective as well
as data model perspective) either way. In cases like this, I wonder if
it wouldn't be better to make the behavior optionally controlled at the
discretion of the caller. The default could be to NOT include self. But
either have an alternative call or extra arg to tell implementation that
it MUST include self. Yeah, it means another API change. But, I think
that its likely that it will be better in the long run anyways.

Mark

On Wed, 2010-09-08 at 00:53, 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.
> 
> 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.
> 
> - Jim
-- 
Mark C. Miller, Lawrence Livermore National Laboratory
================!!LLNL BUSINESS ONLY!!================
miller86 at llnl.gov      urgent: miller86 at pager.llnl.gov
T:8-6 (925)-423-5901    M/W/Th:7-12,2-7 (530)-753-8511



More information about the tstt-interface mailing list