Entity sets - containment and parent-child

[Mark Beall]

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.

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.

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
>