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

[Mark Beall]

I should probably stay out of this discussion since all of this is  
completely paged out of my brain....

What Jason is describing is pretty much how we did (or plan to, not  
sure) implement "sets" for classification.

There are some minor issues with this, some of them similar to the  
issue about implementations that don't implement iMeshP Parts using  
entity sets (see my posting to the itaps-parallel list on December 21,  
2009 8:25:58 PM EST) in that some of the operations defined for entity  
sets don't make sense in this case.

mark


On Oct 28, 2010, at 6:02 PM, Jason Kraftcheck wrote:

> On 10/28/2010 04:19 PM, James Porter wrote:
>
>>
>> That is what happens now, and it's part of why the behavior for
>> setEntEntArrRelation is bizarre. For instance, what happens when  
>> there's
>> no related set on the "Set" side? I think Tim and I agreed that it
>> should currently return an error, but this would be problematic for
>> people who don't want to work with sets.
>>
>> Again, this argument is basically why I'm not endorsing my suggestion
>> (I'm ok with the status quo), but the main difference is that "Set"
>> provides an *indirect* one-to-many relationship, and "EntArr"  
>> provides a
>> *direct* one-to-many relationship. That is, in the "Set" case, you  
>> have
>> to go through getEntities to get to the "many". Currently, I think  
>> the
>> iRel spec is strongly oriented towards using one-to-one relations
>> interally (that's certainly how Lasso does it), with the one-to-many
>> relations being "emulated" by way of already-existing functionality
>> (sets) in iMesh/iGeom. Whether this is a good thing or not depends on
>> what you think of sets.
>>
>> As I mentioned with setEntEntArrRelation, this does potentially  
>> change
>> some of the semantics of other functions. The main reason I wanted to
>> get rid of the non-one-to-one functions in iRel is because of this
>> behavior.
>
> RPI doesn't want to do the indirect solution (anything with entity  
> sets) so
> we need some kind of compromise that doesn't require them.  I  
> thought that
> the current setEntEntArrRelation (and related functions) would do that
> without preventing us from implementing this indirectly with sets.
>
>
> I do think that doing things with set handles would be a cleaner  
> interface.
> So I'm going to try to describe a possible way that RPI could  
> implement
> such a solution without (hopefully) loss of performance.  Of course  
> I have
> no idea about the internal details of FMDB, so this could be  
> completely
> unworkable.  And what you choose to implement and how is obviously  
> none of
> my business.  I'm just sharing an idea that I had.
>
> What if, in FMDB, when asked for the "entity set" in the iMesh API  
> related
> to some entity in the iGeom API, a /special/ entity set handle was  
> passed
> back that didn't correspond to a real, user-defined entity set but  
> rather
> the more abstract idea of "all the mesh entities classified to some
> geometric entity".  Basically, to specify the classification for some
> entity, rather than doing the following:
>  iRel_setEntEntArrRelation( ..., geom_entity, 0, mesh_ent_array,  
> len, ... )
> you instead did:
>  iBase_EntitySetHandle faux_set;
>  iRel_getEntEntRelation( ..., geom_entity, ..., &faux_set, ... );
>  iMesh_addEntArrToSet( ..., mesh_ent_array, len, faux_set, ... );
>
> If there was no "real" entity set (the iRel call returned some special
> handle that just meant mesh for the fifth geometric surface or  
> whatever),
> the cost of that call should be almost nothing.  And if the set  
> handle is
> "special", such that there are no "real" entity sets involved, then  
> the call
> to iMesh_addEntArrToSet shouldn't be any more expensive than the
> iRel_setEntEntArrRelation would have been.
>
> I know that seems a rather round-about and confusing way to do  
> things.  So
> I'll briefly try to explain the core idea at a little bit higher  
> level.  All
> of the functions in the iMesh and iGeom interfaces dealing with  
> entity set
> handles can be split into two groups:
>  1) those that create/destroy entity sets and modify parent/child  
> links
> and
>  2) the rest of the functions.
>
> If we ignore everything in 1) for a minute, then and just look at  
> 2), then
> 2) looks a lot like an API to work with any arbitrary grouping of  
> entities
> that an implementation might have.  Examples could include the group  
> of mesh
> entities classified to some geometric entity or the group of  
> entities in a
> parallel part.  We have a nice API for dealing with collections of  
> entities
> stored on the implementation side of the API*.  And that could still  
> be the
> case even with the functions in 1) if one considers user-defined  
> entity sets
> to be only one of many types of entity groupings stored on the
> implementation side of the interface.
>
> - jason
>
>
> * In fact, I've often wished that there were another type of
> implementation-side grouping that is a kind if transitory set.  If  
> more
> queries and modification routines worked with such 'temporary  
> groups' it
> would simplify a lot of API calls and make complex operations  
> composed of
> passing results of one API call to another much simpler and more  
> efficient.
>
>