Entity sets - containment and parent-child

[Mark Shephard]

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
>