iMesh telecon: closure and adjacency

[Tim Tautges]

The topic came up when it was pointed out that MOAB fails certain tests in the compliance test that test for this. 
Given the recent discussion on root set satisfying or not satisfying all the set-based functionality, I requested 
another discussion on this subject.

Note, if I'm the only one that thinks this is an issue, then by all means let's not waste another phone discussion 
finding that out.  My reasoning for thinking that it should be changed is:
1) people keep describing this as closure, when closure mathematically includes the entity as well as its boundary.
2) From the application code's perspective, and given the concept of abstraction embodied by using the same data type 
for entity handles of any dimension, I think it makes more sense for adjacencies to return the entity itself if it's the 
requested dimension.  There's also an efficiency issue here, since with the current spec, if we get all entities in a 
set, and request the adjacent vertices, we need to filter out the vertices already in that entity list, then add them 
back to the result.  This came up most recently when implementing mesh copy/move in MeshKit.

Maybe we should take a vote (3 allowed answers, yes/no/let's discuss ? )

- tim

On 09/07/2010 02:22 PM, Mark Shephard wrote:
> This has been discussed over and over again. It has been decided
> multiple times that by definition an entity is not adjacent to itself.
> Why are we going to discuss it yet again?
>
> On 9/7/10 3:18 PM, 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.
>>
>> Here's a link for a doodle poll on possible times for discussion of this
>> point.
>>
>> http://www.doodle.com/grz22wai95muq85d
>>
>> Given how short our time is before the IMR tutorial (and given that we
>> presumably would all like to have implementations be compliant at that
>> time), I personally think it's a good idea for us to converge on the
>> current spec pending a possible change. Others may disagree.
>>
>> 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