iRel.h interface update [was iRel proposal: removing non-one-to-one relation functions]

[Tim Tautges]

On 11/01/2010 07:48 AM, Mark Shephard wrote:

>>
>> To be fair, input was solicited many times, starting about year 2.5, and
>> none showed up until about year 7.
>
> That is untrue. The importance of supporting classification and reverse
> classification was discussed at the opening meeting of this project in
> 2001. This well established requirement is used by many groups and has
> always been important. Until there is an effective method to support it
> we are still at the same point we have been at for a long time.
>

The point I was making was that there was no real attempt to implement the iRel interface as proposed in year 2.5 or so, 
that I recall, until about a year and a half ago.

> Your other email has lots of statements and assumptions that are not true.
>

Besides platitudes like this, can you point out specifics?  I'm making an honest attempt to raise real issues here, and 
this "yes it did" "no it didn't" doesn't move us forward.

> I do not understand why you will not allow the technical people to work
> together to define a solution all implementations would accept? To be
> more specific, at least twice there were solutions put on the table that
> appeared to meet the needs of both sides only to have them not followed
> through on in iRel.h. When iRel.h is such that you, Seegyoung and Mark
> Beall feel things will work, we are set. Until then, we are where we
> have always been.

That's what I thought we had in January.  So far, I haven't seen any information about somebody actually trying to 
implement it (besides Mark B's statement last week that that's what they were planning), nor a simple use case 
demonstrating where that solution falls short.  In cases like this, where there are conflicting statements about whether 
the current proposal works or not for the important use cases, I'd think real use cases would help resolve those.  I 
myself don't see much difficulty in coming up with use cases that reflect the various needs, but I think I shouldn't be 
the only one writing those.

- tim

>
>>
>> - tim
>>
>>>>
>>>> ** Between different implementations of ITAPS interfaces
>>>>
>>>>> This avails non set-dominant impementation to support "iRel"
>>>>> effectively without interfering set-dominant
>>>>> implementation and not against neither of "interchangeability" and
>>>>> "interoperability".
>>>>
>>>> I must confess that my knowledge of other ITAPS implementations is
>>>> limited, but are you suggesting that a) you wouldn't support the
>>>> set-based functions in iRel at all, or b) that you'd support them, but
>>>> they wouldn't be the optimal way of working with data in your
>>>> implementation?
>>>
>>> We support all the set functions. However, controlling everything by
>>> sets becomes quite computationally intensive when you are doing lots of
>>> local mesh modification, which is exactly what users of out
>>> implementations are doing. Thus although we support sets, the
>>> applications we support typically use sets in specific ways that cause
>>> no complexity with the sets that are in place.
>>>
>>>>
>>>> If we're talking about (a) here, this is a pretty optimistic view,
>>>> perhaps overly so. Clearly, if one implementation supports a given
>>>> function and the other does not (e.g. a "set-dominant" interface
>>>> doesn't
>>>> fully support arrays or an "array-dominant" interface doesn't support
>>>> sets), that function is by definition not interchangeable. For
>>>> MOAB/CGM/Lasso, this problem is academic, since MOAB and CGM support
>>>> both set- and array-based operation (and Lasso will too, however it
>>>> ends
>>>> up looking), but for other implementations, this could be more serious
>>>> issue. In practice, this would mean that you'd be unable to use many of
>>>> the tools we write that target ITAPS interfaces.
>>>>
>>>> If we're talking about (b), see my discussion above on relation
>>>> cardinality.
>>>>
>>>> - Jim
>>>>
>>>
>>>
>>
>
>

-- 
================================================================
"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