Entity sets - containment and parent-child

[Mark Shephard]

Mark Beall brings-up the issues that we have discussed many times in 
terms of needing to be able to have tools an methods that support mesh 
modification operations when using iMesh and iMeshP. We have clearly 
discussed this need and recently Carl also pointed out that he can not 
see how to support mesh modification operations based on the basics of 
sets with their implementation as defined by iMesh.

In our discussions we have tended to use the terms of classification 
(mesh-to-geometric model(Gmodel) and reverse classification 
(Gmodel-to-mesh). As discussed extensively at one of our boot camps the 
mesh sets can do Gmodel-to-mesh and Tim indicated he does do such things 
in MOAB at the MOAB level (as near as I know not directly exposed at the 
iRel interface level). At the boot camp we agreed that iRel needed to 
also support mesh-to-Gmodel. We further discussed that maybe some 
implementations would support mesh-to-model only and others may do the 
equivalent of model-to-mesh through mesh sets. We were also hoping to 
figure out implementations that may effectively do both.

I do not remember the details, but was reminded by Luo that there were 
requests to add the ability to support classification (the relationship 
of a mesh entity to a geometric model entity) and interface functions 
proposed, but never included. Note that the iMesh/iMeshP demonstration 
we did last year for SC08 stuff we were not able to adapt to curved 
geometry of do any of the proper updates of other mesh relationships 
because there was no support for classification. This is the key reason 
we have been forced to only be able to do FMDB implementations of mesh 
adapt for SLAC and PPPL since they need mesh-to-model relations.

In terms of moving forward I think there are two overall steps that can 
be followed.

The first step that will at least get us off the dime so the mesh 
adaptation service can properly work with iMesh/iMeshP (as well as other 
tools) is to get the mesh-to-Gamodel functions into iRel.

The second step is to discuss if the mesh sets interface should be 
extended or modified in any way to deal with the Gmodel-to-mesh 
relations in a more formal functional way at the interface level. There 
was a series of email between Carl and Tim on this that I must admit I 
was not able to follow very well. I also expect that the Simmetrix guys 
can also provide very useful input to this in terms of options and some 
of the issues.

Although I think the first step will do a lot and at least let mesh 
modification tools be supported properly through iMesh, if that is all 
we do its my guess that the implementations that support effective mesh 
modifications will not be using mesh sets. (Carl clearly pointed this 
out one of his emails.)

However, if we can also do the second step and find a solution that 
works for all, then I would expect we can have implementations that can 
effectively support the full range of things effectively. This would be 
great since, as also discussed in the bootcamp at RPI, when we go to the 
analysis step having an effective means to have the Gmodel-to-mesh 
relationship is more efficient than the mesh-to-Gmodel relationship.

I think an effective implementation that supports mesh modification and 
the analysis steps would maintain a "complete" understanding of both 
relations while not having the "full" set of data in terms of the 
relationships for all entities in both directions. The terms "complete" 
and "full" here are being used on the context that in a "full" 
representation all the data relationships are being explicitly stored 
while "complete" means that there is sufficient information stored that 
the all the relations can be constructed on the fly in the number of 
operations that is independent of the number of entities in the mesh. 
(We have been looking at aspects of supporting this.) If the interface 
specification is defined in a manner that is independent of what is 
stored then this could be workable. However, I expect that requires the 
interface has some degree of understanding that of Gmodel-to-mesh and 
mesh-to-Gmodel relationship types. It seams that since iRel is the 
relations functions and ITAPS clearly has the three things of geometric 
models, meshes and fields that having iRel have some knowledge of the 
fact it is operating on those various relations makes sense. Although we 
are not ready to discuss the fields relations until Mark Miller and Carl 
get to do their document, I think the geometric model and mesh is a easy 
lift to do if we want to.

Mark


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