Entity sets - containment and parent-child

[Carl Ollivier-Gooch]

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

-- 
------------------------------------------------------------------------
Dr. Carl Ollivier-Gooch, P.Eng.                   Voice: +1-604-822-1854
Associate Professor                                 Fax: +1-604-822-2403
Department of Mechanical Engineering             email: cfog at mech.ubc.ca
University of British Columbia              http://www.mech.ubc.ca/~cfog
Vancouver, BC  V6T 1Z4                  http://tetra.mech.ubc.ca/ANSLab/
------------------------------------------------------------------------