Entity sets - containment and parent-child

[Tim Tautges]

Mark Beall wrote:
> 
> OK, so given an iRel_RelationHandle that represents classification 
> information, one would call iRel_getEntEntAssociation to get the 
> relation from a mesh entity to a model entity or the opposite. That's 
> fine, we can create a special kind of relation that would act the right 
> way for that kind of query. I'd have to think a bit whether the 
> functions to modify that relation could be made to work correctly.
> 

Note, the initialization of the relation is something I've always considered very database-specific, and I've also 
wondered whether something like that could be expressed abstractly in the language of the existing data model.  As it is 
right now, Lasso (my implementation of iRel) is written to match geometric entities by id and dimension to corresponding 
sets in the mesh.  I could specify those rules abstractly right now, but it would help to have other examples of 
classification to know whether that could be generic.  Though, maybe it isn't useful to think about generic 
implementations of iRel.

> For that to work, we'd have to provide a way for a user to get the 
> relation that represents classification (since, for us, it will always 
> already exist). I don't see a way to do that, although I guess that's 
> pretty specific to our implementation.
> 

That's what createAssociation/inferAllAssociations are supposed to do.  In the case of databases with existing 
relations/classifications like yours, I'd expect the create to return a relation object that could just query those 
classifications (maybe the infer would be a noop in that case).  You'd probably need to return error if the application 
specified a relation type you couldn't support.

Carl's all over the iterator questions I suspect...

- tim

> I did read the emails between you and Carl. I take it that issues 
> related to entity sets when the mesh is modified are still undefined.
> 
> To start with a really simple question related to that, what is the 
> behavior for an iterator created by iMesh_initEntIter if the mesh is 
> modified while iterating over it? If, for example, I'm writing a routine 
> that will, say, iterate over all the regions in a mesh and do some 
> modification to some of them. That modification may delete and create 
> other regions in the mesh. What is the defined behavior of the iterator 
> with respect to the deleted and newly created regions?
> 
> mark
> 
> 
> On Nov 16, 2009, at 11:47 AM, 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.
>>
>> -- 
>> ================================================================
>> "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