Entity sets - containment and parent-child

[Mark Beall]

On Nov 16, 2009, at 1:40 PM, Tim Tautges wrote:

>
>
> Mark Beall wrote:
>> OK, so given an iRel_RelationHandle that represents classification  
>> information, one would call iRel_getEntEntAssociation to get the  
>> relation from a mesh entity to a model entity or the opposite.  
>> That's fine, we can create a special kind of relation that would  
>> act the right way for that kind of query. I'd have to think a bit  
>> whether the functions to modify that relation could be made to work  
>> correctly.
>
> Note, the initialization of the relation is something I've always  
> considered very database-specific, and I've also wondered whether  
> something like that could be expressed abstractly in the language of  
> the existing data model.  As it is right now, Lasso (my  
> implementation of iRel) is written to match geometric entities by id  
> and dimension to corresponding sets in the mesh.  I could specify  
> those rules abstractly right now, but it would help to have other  
> examples of classification to know whether that could be generic.   
> Though, maybe it isn't useful to think about generic implementations  
> of iRel.

The information we have for classification is, for every mesh entity,  
what is the lowest dimension geometric model entity it is on (e.g. a  
model face will have it's interior mesh vertices, interior mesh edges  
and mesh faces classified on it - the mesh edges and vertices on the  
edges and vertices bounding it will be classified on the boundary  
entities). So for classification (mesh to model) we'd return the iGeom  
handle to the model entity in the other half of the relation. For  
inverse classification (model to mesh), we'll return a "entity set"  
that's actually a wrapper to an iterator over the entities classified  
on the model entity.

>> For that to work, we'd have to provide a way for a user to get the  
>> relation that represents classification (since, for us, it will  
>> always already exist). I don't see a way to do that, although I  
>> guess that's pretty specific to our implementation.
>
> That's what createAssociation/inferAllAssociations are supposed to  
> do.  In the case of databases with existing relations/ 
> classifications like yours, I'd expect the create to return a  
> relation object that could just query those classifications (maybe  
> the infer would be a noop in that case).  You'd probably need to  
> return error if the application specified a relation type you  
> couldn't support.

OK, I thought that createAssociation just created an empty relation. A  
couple of questions:
- createAssociation implies that there can only be a single relation  
between two interfaces. Offhand I can't think of a example of where  
there might be more than one, but it seems it might be possible.
- why does createAssociation take in whether the relation is an entity  
or a set rather than that being returned? It makes sense if the  
relation is empty, doesn't really make sense if the relation is  
something like our classification that already exists (or  
classification in general since there really should only be one way to  
describe that).

mark


> Carl's all over the iterator questions I suspect...
>
> - tim
>
>> I did read the emails between you and Carl. I take it that issues  
>> related to entity sets when the mesh is modified are still undefined.
>> To start with a really simple question related to that, what is the  
>> behavior for an iterator created by iMesh_initEntIter if the mesh  
>> is modified while iterating over it? If, for example, I'm writing a  
>> routine that will, say, iterate over all the regions in a mesh and  
>> do some modification to some of them. That modification may delete  
>> and create other regions in the mesh. What is the defined behavior  
>> of the iterator with respect to the deleted and newly created  
>> regions?
>> mark
>> On Nov 16, 2009, at 11:47 AM, Tim Tautges wrote:
>>> [On a separate note, I've got a request in to restore tstt- 
>>> interface email archives from before Oct or so; if you know of a  
>>> working link to those, please forward, as I've lost mine]
>>>
>>> These things have all been discussed and thought about, but  
>>> they're buried in the list archives.  However, a careful read of  
>>> the iRel header (http://www.itaps.org/software/iRel_html/ 
>>> index.html) would be beneficial.  Looking back at that, maybe some  
>>> examples there would help.
>>>
>>> In particular, what you're requesting (the ability to get a mesh  
>>> entity's corresponding model entity) is what's referred to as an  
>>> "entity-entity" relation.  The ability to represent both set-based  
>>> and entity-based relations is a "both"-type relation.  What is  
>>> missing from iRel, but asked about by me some time ago, is a  
>>> function to change relation types dynamically.  Without going into  
>>> a lot of detail, going from an entity-set to an entity-entity  
>>> relation can have dramatic memory costs; going from an entity- 
>>> entity to an entity-set type can have dramatic execution time  
>>> costs.  We need to enable both, because both types are important  
>>> to various types of use cases.
>>>
>>> Please read through the email exchange over the last several weeks  
>>> between Carl and me, discussing maintenance of sets under mesh  
>>> modification.
>>>
>>> - tim
>>>
>>> Mark Beall wrote:
>>>> I think the concept of an entity set is useful for some things.  
>>>> We have something similar that we use internally in our code when  
>>>> we need to do operations on a portion of a mesh. The are somewhat  
>>>> different than what I see here as an entity set since what we're  
>>>> really relying on is their behavior when the mesh is modified -  
>>>> removing entities that are deleted and adding new ones that are  
>>>> created, but then, the only purpose we have them for is to keep  
>>>> track of things when we are modifying a mesh.
>>>> We're struggling a bit to figure out how to effectively interface  
>>>> some of the concepts in ITAPS to how we deal with things.  I'm  
>>>> not trying to judge things, but, at times it seems to be that  
>>>> ITAPS is a bit closer to being a specification of an  
>>>> implementation for some things than specifying an interface.
>>>> For some of the things you list that you use entity sets for  
>>>> (geometric topology, parallel partitions) we have very concrete  
>>>> expressions of those concepts within our implementation. They  
>>>> don't build on a common foundation since the ways they are used  
>>>> and the rules on how they must be used are quite different.
>>>> In our world, a mesh is always classified on a model. The model  
>>>> may be a proper geometric model or could just be topology.  
>>>> Various attributes (boundary conditions, material properties,  
>>>> etc.) are always specified on the model rather than the mesh. The  
>>>> relation between the mesh and model is stored bidirectionally and  
>>>> is always consistent (except in the middle of very low level  
>>>> operations on the mesh which are atomic operations anyhow).
>>>> For us, access to data such as entities in a mesh, entities  
>>>> classified on a model entity, partition boundaries, etc. are all  
>>>> done through iterators. You never explicitly deal with the "list  
>>>> of entities", only iterators that are created that can return the  
>>>> entities of interest. To me, this is a nice way to hide the  
>>>> implementation - the iterators could be iterating over a single  
>>>> list, a set of lists, or calculating the data on the fly - the  
>>>> interface is still the same.
>>>> I've been looking at iRel to understand how classification works  
>>>> here (actually reverse classification - the set of mesh entities  
>>>> on a model entity - I don't see a concept anywhere that would  
>>>> give you what model entity a mesh entity is classified on). It  
>>>> seems that we can emulate the entity sets that need to be  
>>>> returned by having a type of entity set that is implemented by  
>>>> one of our iterators. However that entity set certainly won't be  
>>>> modifiable since you can't arbitrarily modify that relationship  
>>>> (and since it's bidirectional, it has to be done correctly -   
>>>> which for us is to set the classification of the mesh entity  
>>>> which then updates the reverse classification information).
>>>> There are some similar issues in iMeshP since, again, the way we  
>>>> represent partitions (what iMeshP calls Parts) is very explicit  
>>>> in our code (they are actually the same data structure as a  
>>>> serial mesh, but with some extra iterators that allow access to  
>>>> entities on the partition boundaries). I'm going to wait to go  
>>>> into these questions until Saurabh gets back from his vacation  
>>>> since he's just started looking into this.
>>>> The reason I asked the question on how entity sets would be used  
>>>> to represent the relation between the mesh and the model is that,  
>>>> in the way we approach things, that's a fundamental property  
>>>> which affects just about any code that modifies the mesh (e.g.  
>>>> you can't do a swap of a mesh edge classified on a model edge  
>>>> since the result would break our rules for a valid mesh). I  
>>>> haven't seen anything in the documentation that describes what,  
>>>> if any, rules there are like that in the ITAPS world. Your rules  
>>>> might be quite different than ours, but I think there have to be  
>>>> some, somewhere...
>>>> mark
>>>> On Nov 13, 2009, at 2:13 PM, Tim Tautges wrote:
>>>>>> 2) Has anyone defined how entity sets would be used to describe  
>>>>>> the relation between a mesh and a model? Since there is more  
>>>>>> than one possible way to do that (you add the mesh of the edge  
>>>>>> around a face as children of the entity set for the mesh face  
>>>>>> and I add them as entity sets in the entity set for the mesh  
>>>>>> face), it would seem that it needs to be defined otherwise no  
>>>>>> one will be able to write code that uses that information.
>>>>>
>>>>> TTYTT, I've had trouble enough just convincing the group that  
>>>>> sets themselves were useful.  In my thinking, what you describe  
>>>>> above is a convention for how data gets embedded in the data  
>>>>> model.  I follow various types of conventions for e.g. geometric  
>>>>> topology, boundary conditions and materials, parallel  
>>>>> partitions, and various other things.  I've not been able to  
>>>>> convince others about the utility of conventions for options to  
>>>>> use for loading mesh in parallel.  And finally, there are many  
>>>>> cases where there's not a single "right" convention.  For  
>>>>> example, storing model-mesh relationships in sets is very memory  
>>>>> efficient, but time-inefficient if you're querying individual  
>>>>> entities for their model equivalents.  One specific thing I've  
>>>>> mulled over proposing is some common functionality for  
>>>>> converting, or copying, set membership to tags, and vice versa.   
>>>>> You'd do the set-to-tag conversion e.g. in preparation for  
>>>>> smoothing or adapting, then the reverse after that was done and  
>>>>> you wanted to recover memory.
>>>
>>> -- 
>>> ================================================================
>>> "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
>>>
>
> -- 
> ================================================================
> "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
>