Entity sets - containment and parent-child

[Tim Tautges]

Obviously, it's now time to document both iRel and the use of sets and tags.  However, to be fair, a) I know plenty of 
external people and groups who have understood sets and relations just fine, and b) it's only very recently that there 
seems to be more serious support, on an implementation and application level, for sets.

- tim

Mark Shephard wrote:
> Based on the recent exchanges more information is becoming available 
> indicating that there appears to be ways to the things we need to do. 
> That is obviously good news.
> 
> However, at a minimum I think the documentation needs to be clearer to 
> people. I would argue that the Simmetrix guys and the RPI guys have 
> pretty good understanding of what meshes, geometric models and the 
> relationships between them are. Yet, the RPI guys did not see a way with 
> acceptable performance to do the mesh-to-model relationship and it is 
> taking a lot of time and emails for the Simmetrix guys to see a solution 
> to this issue. If that is the case, how do we ever expect others to be 
> able to use the tools in a productive manner?
> 
> Do you have a working iRel implementation that used mesh-to-model 
> relationships? If yes, I sure people would fine it useful to see.
> 
> Thus at a minimum, it would seam to me that there is clear information 
> provided that makes it clear to people how to deal with mesh-to-model 
> and model-to-mesh relationships. The two options to do that are to have 
> clearly defined iRel functions specifically for those relations or there 
> is a clear explanation of how to do it with the current functions. I 
> would argue that mesh-to-model and model-to-mesh are such basic 
> relations that having obvious things for them is desirable. However, the 
> second approach of at least provided the information needed to do it can 
> work within the ITAPS group.
> 
> It is also pretty critical that it be possible to have efficient 
> implementations that can deal with applications focused on using 
> model-to-mesh relations or mesh-to-model relations. Ideally it would be 
> nice to be able to efficiently support both, but I expect the obvious 
> way of implement that would introduce an unacceptable memory increase.
> 
> It also appears that are unresolved issues and/or not very useful 
> behaviors of things in sets under mesh modification that still need to 
> be worked out (your other email this morning).
> 
> 
> 
> Carl Ollivier-Gooch wrote:
>> Mark Shephard wrote:
>>> 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.
>>
>> I'm not sure I quite understand the problem here.  As I read the iRel 
>> interface, it's possible to get associations both ways as things 
>> currently stand.  Also, there are in fact iRel functions that allow 
>> you to create with association (both vertices and other entities).
>>
>> As I see it, the biggest problem presently with classification-like 
>> things under mesh modification is that we need to be able to force 
>> entity-to-set associations to be entity-to-entity before modification 
>> and then switch back afterwards.  This surely isn't that hard, though 
>> perhaps costly in memory.
>>
>>> 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.)
>>
>> This may not be true for all types of mesh modification, but for 
>> insert / remove / swap kinds of things, yes I think it is.
>>
>>> 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.) 
>>
>> I don't think there's currently any guarantee that every entity will 
>> necessarily be related, but every entity that is will be related two-way.
>>
>> Carl
>>
> 
> 

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