Entity sets - containment and parent-child

[Tim Tautges]

Mark Beall wrote:
> 

> 
> The information we have for classification is, for every mesh entity, 
> what is the lowest dimension geometric model entity it is on (e.g. a 
> model face will have it's interior mesh vertices, interior mesh edges 
> and mesh faces classified on it - the mesh edges and vertices on the 
> edges and vertices bounding it will be classified on the boundary 
> entities). So for classification (mesh to model) we'd return the iGeom 
> handle to the model entity in the other half of the relation. For 
> inverse classification (model to mesh), we'll return a "entity set" 
> that's actually a wrapper to an iterator over the entities classified on 
> the model entity.
> 

Sounds reasonable.


>>
>> 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.
> 
> OK, I thought that createAssociation just created an empty relation. 

It depends on the underlying implementation.  I was thinking that way in your case, where there's no inference needed, 
since you always keep classification info around.  In my case, the association is empty, until the infer is requested.

A
> couple of questions:
> - createAssociation implies that there can only be a single relation 
> between two interfaces. Offhand I can't think of a example of where 
> there might be more than one, but it seems it might be possible.

I think so too.  This is one of the reasons I think it's useful to have distinct "relation" objects.  The fact that the 
interface doesn't seem to support a variety of uses is more a factor of nobody really using it besides me.

In the longer run, I see there being other pairwise relations too, e.g. a field with a tag.

> - why does createAssociation take in whether the relation is an entity 
> or a set rather than that being returned? It makes sense if the relation 
> is empty, doesn't really make sense if the relation is something like 
> our classification that already exists (or classification in general 
> since there really should only be one way to describe that).
> 

In most cases you can support either, and which one you want depends on the usage.  I think this would be far more 
useful though if there were a function to change the type of relation dynamically.  Requesting an entity-set type be 
changed to an entity-both type, and back again, for smoothing, is the easiest use case for this, but adaptive refinement 
is another good example.

- tim

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

-- 
================================================================
"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