Entity sets - containment and parent-child

[Mark Shephard]

I am not convinced that having lots of people reading lots of old emails 
is useful.

Please, what is needed is defining the solutions and/or clear 
documentation that supports doing what proiple need to do and tells them 
clearly how they can go about doing it.

Mark

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