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

[Tim Tautges]

Um, I wasn't the one that started this, it started with your open-ended indictment asserting that I don't listen to your 
needs (and the one in the 3rd sentence below continues this, but, to turn over a new leaf, I'll let that one stand on 
its merits).

- tim

On 11/01/2010 02:22 PM, Mark Shephard wrote:
> Tim,
>
> It appears that you want to just continue to drag this out and continue
> to point fingers.
>
> The use case of classification and reverse classification are obvious
> and have been stated over and over again. Mark Miller already responded
> to other aspects of your email from this morning.
>
> I still do not understand why it is not possible to let someone produce
> an iRel.h that works for all.
>
> Mark
>
>
> On 11/1/10 3:14 PM, Tim Tautges wrote:
>>
>>
>> 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