Entity sets - containment and parent-child

[Carl Ollivier-Gooch]

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

Actually, the docs for iRel say:

     /**\brief  Set a relation between an entity and several entities
      *
      * Set a relation between an entity and several entities.  If either
         is a set and that side of the relation is 'both'-type, set 
relations
         for individual entities in that set too.
         \param instance Interface instance
         \param rel Relation handle being queried
         \param ent1 1st entity of relation being set
         \param switch_order If non-zero, ent1 is associated with iface2 and
                  ent_array_2 with iface1 of
                  specified relation, otherwise vica versa
         \param ent_array_2 Entity(ies) to be related to ent1
         \param num_entities Number of entities in ent_array_2
         \param *ierr Pointer to error value, returned from function
     */

While weak on syntax (this block describes Ent-EntArr, Set-EntArr, 
Ent-SetArr, and Set-SetArr functions), the doc string implies that 
one-to-many entity-to-entity relationships are allowed, in either 
direction.  So yes, we can, with the current interface, classify 
multiple mesh entities onto a single geometric entity -and- expect that 
the reverse classification data will exist.

 From the point of view of mesh topology modification, being able to 
efficiently find the geometric entity a mesh entity is classified on is 
essential.  Having many-to-one entity-entity relations provides this, 
but mesh set to geom entity doesn't, because there's no efficient way to 
find which sets an entity belongs to.

For solvers and design (and probably other things as well), being able 
to efficiently find the mesh entities classified on a geometric entity 
is equally important.  Having one-to-many entity-entity relations 
provides this, as does geom entity to mesh set relations.

Bottom line:  what we currently have in the interface is sufficient to 
handle all this efficiently in terms of CPU time, at the expense of 
explicitly carrying the two-way relationships between one geometric 
entity and many mesh entities.

Now, carrying the two-way multimap (or whatever implementation you 
choose) for one-to-many and many-to-one relations isn't particularly 
cheap from a memory point of view, I grant you, and so presumably the 
ability to explicitly switch from many mesh entities -> one geom entity 
to one mesh set -> one geom entity would be a useful thing.

 From the client point of view, I can see explicitly requesting the 
switch from sets to entities, deleting the sets (since they'll go 
obsolete anyway), and creating new sets after modification (each 
containing all mesh entities classified on a single geometric entity).

I can also see cases where a client would prefer to keep the same set 
handles, but still require the explicit translation before and after 
(since the set contents aren't likely to be trustworthy, unless iRel 
explicitly removes the entity from the set when its relation is broken 
with the geom entity that is related to the set).

Finally, if the relationship is flagged as both ent-ent and set-ent, 
then it's possible for iRel to correctly update the contents of sets 
that store classification as it updates relations with creation/deletion 
of entities.

Sets with other semantics are still not reliable after mesh 
modification, though.

And now that I'm sure I've got everyone confused, it's time to sign off. :-)

Carl

-- 
------------------------------------------------------------------------
Dr. Carl Ollivier-Gooch, P.Eng.                   Voice: +1-604-822-1854
Associate Professor                                 Fax: +1-604-822-2403
Department of Mechanical Engineering             email: cfog at mech.ubc.ca
University of British Columbia              http://www.mech.ubc.ca/~cfog
Vancouver, BC  V6T 1Z4                  http://tetra.mech.ubc.ca/ANSLab/
------------------------------------------------------------------------