Entity sets - containment and parent-child

[Mark Beall]

On Nov 17, 2009, at 5:01 PM, Tim Tautges wrote:

> Mark Beall wrote:
>>>
>>> Here's an example:  Suppose you're doing swapping, or any other  
>>> topological modification to a mesh.  Chances are excellent that  
>>> you only want to do the 2-2 swap on the surface if both surface  
>>> faces classify on the same model face.  Now, if you've got an  
>>> entity-entity relation giving you classification, that's an easy  
>>> test.  On the other hand, if you've got a geometric entity-mesh  
>>> set relation, you have to find out which set a mesh face is in,  
>>> which can only be done through an exhaustive search of faces.  So  
>>> the higher memory (e-e) relation is much lower CPU.
>> Right, sorry, I was thinking about the entity sets in the wrong way  
>> (somehow my brain was thinking that the switch_order argument would  
>> magically do this, but that's not what it does).
>> So then createAssociation(model,mesh) should create a entity-set  
>> relation and createAssociation(mesh,model) should create a  
>> different entity-entity relation. Of course, in our implementation,  
>> these are really just things that are pretending to be relations  
>> and entity sets, but that doesn't really matter.
>
> Note that as currently spec'd, relations are two-way, so I suspect  
> having a mesh/geometry entity/entity-type relation wouldn't be much  
> good, since each geometry entity would only be related to one mesh  
> entity (which couldn't be an entity set, since those are different  
> things in the iMesh interface).
>

Well, the entity set - model entity direction of the other relation  
wouldn't be very useful either. Perhaps it could be of some use if the  
actual implementation of classification is done using entity sets, but  
if an application relies on that it's probably not going to work if  
the implementation is different (for us, the "entity set" in this case  
will actually be a pointer to an iterator, it won't be the same  
iterator each time, so that relation wouldn't be useful for much).

It would seem to be nicest if classification was represented by a  
single relation, but the useful information here (what mesh entities  
are classified on a model entity and what model entity is a mesh  
entity classified on) are each one direction of two different relations.

mark