Entity sets - containment and parent-child

[Mark Beall]

On Nov 18, 2009, at 9:37 AM, Jason Kraftcheck wrote:

> Mark Beall wrote:
>> As the, fairly obvious, followup to my last email, since iRel already
>> admits to the fact that there is a special relation between the  
>> mesh and
>> the model (cf. iRel_createVtxAndAssociate, etc.) and has stated
>> requirements on that relation (it must be between the geometry and  
>> mesh
>> instance in that order), why not just create a special type of  
>> relation
>> in iRel that represents that. For example:
>>
>> void iRel_createGeomMeshAssociation(...,iBase_instance geom,
>> iBase_instance mesh, ... options ..., iRel_GeomMeshHandle *rel);
>>
>
> Tim and I have discussed having special creation functions before.   
> I think
> it is a good idea for two reasons:  1) For some implementations,  
> some types
> of relations are handled in a special way and 2) The i*_instance  
> handles are
> unique types that do not implicitly cast to iBase_instance.   
> However, I do
> not see why one would need a special type of relation handle.  That  
> would
> necessitate a lot of extra functions just to avoid abstracting  
> things a bit
> in the implementation.  I'd rather see the above function look like:
>
>
> void iRel_createGeomMeshAssociation(...,iGeom_instance geom,
> iMesh_instance mesh, ... options ..., iRel_RelationHandle *rel);

That's better, I wasn't sure if you could mention iMesh_instance in  
the iRel header.

>> options here would say what directions you want the relation to  
>> support
>>
>
> I don't strongly object to having such an option, but is it  
> necessary?  Why
> not just generate the relation links in the backwards (or forwards)
> direction when they are first requested?

Probably not necessary. You would need the function I mention below to  
say that you no longer need the relation in a certain direction.

More useful here (or somewhere) would be to be able to specify what  
types of entities you need classification information for. As I  
mentioned before one could reasonably store classification only  
between mesh and model entities of the same dimension, however code  
using the relation might need lower dimension entities too.

>> void iRel_getGeomMeshAssociation(...,iRel_GeomMeshHandle rel,
>> iBase_EntityHandle modelEnt, iBase_EntitySetHandle *meshEnts);
>>
>> void iRel_getMeshGeomAssociation(..., iRel_GeomMeshHandle rel,
>> iBase_EntityHandle meshEnt, iBase_EntityHandle *geomEnt);
>>
>> maybe some other functions to create or release the relation in one
>> direction or the other (possibly instead of the options on creation)
>>
>> and the iRel_createVtxAndAssociate etc. functions take in a
>> iRel_GeomMeshHandle
>>
>> Discussion points:
>>
>> - Yes, it's less generic, however it's already not generic in the
>> interface, for iRel_createVtxAndAssociate to work, the relation has  
>> to
>> be created in a certain way. This way it's enforced (rather than just
>> documented).
>>
>
> So we should duplicate every function in the interface for every  
> possible
> combination of interface types just to avoid one or two functions  
> that could
> potentially fail because they were passed the wrong type of  
> relation?   This
> would make the interface more type-safe but not, IMO, better  
> considering the
> added complexity.

It's really more a matter of making things clear and having the  
relations represent the correct information.

Relations as they exist in iRel seem to me to require two separate  
relations to express the relation between a mesh and a model since in  
one direction that relation is a entity to an entity-set and in the  
other direction it's an entity to an entity (Carl's response yesterday  
might mean this isn't true, but I'm not sure I completely understood  
what he meant). What I've suggested as an interface for this allows  
these two relations to be expressed as a single relation that has the  
needed information. IMO this is clearer and actually less complex for  
people to understand.

>> - If some application wants this relation, they want this relation,  
>> not
>> something else.
>>
>
> I don't get this.  If the application only wants one relation, why  
> would it
> have a handle to any other relation?

User error. There isn't any way that I see to specify what kind of  
relation an application (really more likely a library or something  
that builds on this) needs other than through documentation. Even if  
it gets a relation between a model and a mesh, how would it be able to  
ensure that the right information is in there (e.g. It needs not just  
the mesh faces classified on a model face, but also the mesh vertices)

>> - It avoids the discussion about whether or not it's necessary to be
>> able to change a generic entity-set relation to an entity-both  
>> relation
>> (or whatever) and gives the functionality for the case it's obviously
>> needed.
>>
>
> I haven't been following that discussion, so I'm probably missing  
> something.
> I don't see how having a special type of relation for iMesh/iGeom  
> provides
> this any more seamlessly than providing it for any relation type.   
> It just
> limits the functionality to one relation type.
>
>> - Rather than figuring out how classification should be implemented
>> (tags, entity-both relations) it's a generic expression of that  
>> relation
>> that can be implemented in different ways.
>>
>
> So is the current interface.  The use of tags is an implementation  
> detail.
> The use of entity->set relations is a data model question.  We could  
> mandate
> that all iGeom->iMesh relations are entity->entity with the current
> interface as well.  We do not do so because one might have an  
> implementation
> that stores an entity->set relation to conserve space (does not  
> explicitly
> store classification for every entity.)  You solution of just  
> removing that
> implementation option a) may not be acceptable to all and b) doesn't  
> require
> any change to the interface.

This is kind of my point. The relation you want in the direction from  
model to mesh is really entity to entity-set (e.g for a model face  
what are all the mesh faces classified on it). If it's permitted to  
express the relation, in that direction, as entity to entity then  
other codes that use that relation will have to know that they have to  
deal with both cases. People won't do that, things won't work  
together. If it's clearly specified what information is in this  
relation, then various functionality will be able to work together.

mark