Entity sets - containment and parent-child

[Tim Tautges]

Mark Beall wrote:
> OK. However, I could do the same thing with two entity sets. In your 
> first example, I could use one to describe the mesh classified on the 
> model face and another to describe the mesh on the boundary of the model 
> face. If I modify your example a bit to include another division of the 
> mesh on the model face, say, a partitioning of it, then I need another 
> entity set anyhow. Essentially having the parent-child relationship 
> gives you some, but not all, of the functionality of another entity set 
> in that one set.
> 

It's not that parent/child relations between sets are the only way one could do something, it's rather that they are an 
abstraction that makes convenient many relationships that occur in metadata that comes with meshes.  You could eliminate 
sets entirely, representing them with tags instead.  But, that wouldn't be easy to traverse, and would probably be 
inefficient too.  And, in your example above, if I understand it correctly, you'd need to embed some sort of 
relationship between the model face owned mesh set and the model face bounding mesh set.  Parent/child relations allow 
you to represent that graph explicitly.

> Two other questions that your answer brings up:
> 
> 1) If you want to decompose your "model face" set into multiple subsets, 
> wouldn't it be best to have the iterators on entity sets be capable of 
> doing a "deep" traversal of the entity set (returning all of entities in 
> the entity set, even if they are contained in a entity set contained in 
> the entity set). It would seem that if entity sets are going to be used 
> in the way you describe, everyone would have to write that code anyhow 
> since they don't know what they will be given.
> 

Yeah, that's quite common.  In fact, I use various iMesh extension functions, and that's one of them.  See 
http://trac.mcs.anl.gov/projects/ITAPS/browser/MOAB/trunk/tools/iMesh/iMesh_extensions.h for the complete list.

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

- tim

> 
> 
> On Nov 12, 2009, at 12:36 PM, Tim Tautges wrote:
> 
>> I figured you'd ask that next.  The two that come to mind most readily:
>>
>> a) I use entity sets to represent geometric topology groupings in the 
>> mesh, and parent/child relations between those to represent the 
>> topological relationships between the original geometric entities.  
>> So, I have "model face" sets, whose contents are the mesh owned by 
>> that model face, and children corresponding to the bounding model 
>> edges.  Instead of directly including the mesh faces in a model face 
>> set, say I want to preserve a grouping of those faces, e.g. the 
>> original rectangles of faces composing an "E" or "L" shaped structured 
>> mesh.  This would most naturally be stored as rectangle sets of faces 
>> contained in the model face set.  Similar examples can be made for 
>> swept meshes in 3d.
>>
>> b) Parts in a parallel mesh: parent-child relations can be used to 
>> represent the relationship between parts and their boundaries.  If you 
>> construct a partition using e.g. material sets or model volume sets, 
>> then a part set will have both child sets (the boundaries of the part) 
>> and contained sets (the model volumes composing the part).
>>
>> - tim
>>
>> Mark Beall wrote:
>>> I'd be interested in knowing the various use cases for using entity 
>>> set containment vs. a parent-child relationship. It seems to me that 
>>> they are just about identical, so I'm curious when one would use one 
>>> vs. the other.
>>> mark
>>
>> -- 
>> ================================================================
>> "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