iRel proposal: removing non-one-to-one relation functions

[fabien delalondre]

Tim,

Can you please upload your latest version on svn (not sure redmine is yet
fully functional though) and I ll try to provide a use case to see if the
current interface meets my needs.

Thank you.

Fabien

> As was stated previously, we are still waiting for Tim to provide the
> up-dated iRel.h documentation to reflect the things discussed at the
> bootcamp that are needed by implementations other than MOAB. These items
> have been agreed to (twice now) but still not included in iRel.h. Until
> those items are settled it does not make sense to consider other changes
> that may influence the things we are waiting for.
>
> Tim - When with the updated iRel.h file be provided? If you can not get
> to it, there are others that could likely edit the iRel.h to reflect the
> things that were agreed to at the boot camp.
>
> Mark
>
>
> On 10/26/10 1:39 PM, James Porter wrote:
>> I haven't seen any responses to this. I'm hoping this is because no one
>> has a problem with it. I'll give it a few more days for comments, but if
>> no one pipes up, I'll make the proposed changes.
>>
>> - Jim
>>
>> On Mon, 2010-10-04 at 14:55 -0500, James Porter wrote:
>>> Currently in iRel, there are a handful of functions to get/set
>>> relations
>>> that aren't one-to-one (e.g. iRel_getEntEntArrRelation). It's my
>>> understanding that these are only meant to work in, say, Entity<->Set
>>> relations, and that the entity array returned is the contents of the
>>> set
>>> related to the entity on the left side. That is, it's equivalent to
>>> calling iRel_getEntSetRelation and then i(Mesh|Geom)_getEntities on the
>>> set you get back.
>>>
>>> I propose that these functions be removed. Here's why:
>>>
>>> Note 1: most of this is based on my discussion with Tim Tautges and our
>>> implementation, Lasso, so hopefully I'm not just misinterpreting the
>>> spec.
>>>
>>> Note 2: I use "left-" and "right-" prefixes to denote which side of the
>>> relation an entity or set is on.
>>>
>>> 1) Problems with setting relations
>>>
>>> The biggest problem with these functions is in setting relations. What
>>> you're actually doing is updating the contents of the related set to
>>> contain those new elements. That is, if left-ent A is related to
>>> right-set B, setting a relation between A and [C,D,...,Z] (where C-Z
>>> are
>>> right-ents) actually inserts C-Z into B. That's certainly not what I'd
>>> expect initially; I would expect iRel to only affect stuff in its own
>>> area (e.g. relation tags set on each interface). It gets worse because
>>> it's not clear what you should do when the set B doesn't exist (throw
>>> an
>>> error? create a new set? Lasso does the former, currently).
>>>
>>> This also presents further problems because there's no corresponding
>>> iRel_setEntSetArrRelation function, even though a set could be
>>> contained
>>> in a set just as easily as an entity.
>>>
>>> 2) Confusion about iRel's capabilities
>>>
>>> iRel really creates one-to-one (possibly asymmetric) relations, but
>>> these functions seem to imply that one-to-many or even many-to-many
>>> relationships are possible. This is not, as far as I can tell, the
>>> intention.
>>>
>>> 3) Not that useful
>>>
>>> In most cases, these functions only save a single line of code. If
>>> you're trying to be truly generic (i.e. you don't know what the
>>> set-side
>>> interface is), it's a little more complicated, but not much.
>>>
>>> 4) Hurts clarity of Python interfaces
>>>
>>> This is a mostly selfish reason, since I'm the developers of the ITAPS
>>> Python interfaces, but if all relation functions are one-to-one, I'm
>>> able to simplify the Python iRel interface's functions to "getRelation"
>>> and "setRelation", since I know a priori the type of element that
>>> should
>>> be returned when you call getRelation.
>>>
>>> - Jim
>>>
>>
>>
>
>