Entity sets - containment and parent-child

[Mark Beall]

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.