iRel interface updates

[Tim Tautges]

On 07/21/2010 05:31 PM, James Porter wrote:
> On Wed, 2010-07-21 at 18:08 -0400, seol at scorec.rpi.edu wrote:
>> - I think iBase_EntityIterator should be defined in iBase.
>
> That's reasonable. I think it should be defined in the same way as
> iBase_Instance (that is, as a void*) to minimize the amount of changes
> required for code that uses iMesh/iGeom. The other option would be to
> replace iMesh_EntityIterator with iBase_EntityIterator everywhere
> (likewise for iGeom).
>

I think the latter would be most appropriate, since the entity handle types are all in iBase.

>> - it's not clear what iRel_getEntArrSetIterArrRelation is for, and how
>> much it is useful
>
> I'm not sure either. Tim might know, since I think he added that to the
> interface.

This is to complement getEntArrSetArr, for those who don't want to interface in terms of entity sets.

>
>> - Any specific reasons for not having iRel_getEntSetArrRelation and
>> iRel_getSetSetArrRelation?
>
> I'm not sure if these make sense, but I haven't done much looking at the
> get/set relation code.
>

You can't currently relate a single entity/set to multiple sets, whereas you can relate a single set to multiple 
entities (indirectly, through a set-set relation).

>> - parameter type (in/out/inout) missed in iRel.h
>
> Good call, I'll add these.
>
>> - For consistant naming, how about iRel_create and iRel_destroy?
>> (respecting the discussion of create/destroy name change proposal in
>> http://lists.mcs.anl.gov/pipermail/tstt-interface/2010-May/000166.html)
>
> If iMesh and iGeom switch to this, I think iRel should follow suit.
>
>> - Do we have a mechanism to set the classification (relation between mesh
>> entity and geometric entity) at time of the mesh entity creation either in
>> iRel or iMesh?
>
> I don't think so. Tim might correct me on this, however.
>

A continuation of the long-standing argument about RISC versus CISC style of calling into these interfaces.

>>> Another change I'll suggest but have no strong attachment to is that we
>>> change iRel_RelationHandle to iRel_PairHandle to make a distinction
>>> between the relation of two interfaces (a "pair") and the relation of
>>> entities/sets (a "relation"). The changes would be as follows:
>>>
>>> * iRel_RelationHandle  ->  iRel_PairHandle
>>> * iRel_createRelation  ->  iRel_createPair
>>> * iRel_destroyRelation ->  iRel_destroyPair
>>> * iRel_getRelationInfo ->  iRel_getPairInfo
>>> * iRel_findRelations   ->  iRel_findPairs
>>
>> Multiple relations under pair umbrella is suggested. Not so sure if "pair"
>> is the most appropriate term, iow, multiple pairs under relation umbrella
>> makes more sense to me.
>
> Right now, a "RelationHandle" is strictly a connection between two
> interfaces. Most of the get/set Relation functions assume that there
> will only ever be two interfaces for a given RelationHandle. The
> "multiple pairs" case should be handled by the iRel instance itself, as
> opposed to the RelationHandle.
>
> My concern is that there are multiple things called "Relations" in iRel
> (namely an association between two interfaces and an association between
> two entities), and this can cause confusion when people just use the
> word "Relation".

This is analogous to a tag, where the term tag refers to the variable, and the tag value the variable value for a given 
entity/set.

- tim

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