Entity sets - containment and parent-child

[Tim Tautges]

[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