itaps-parallel copy information stored in iMesh

[Carl Ollivier-Gooch]

Mark Miller wrote:
> Hi All,
> 
>  
> 
> On page 16 of Karen's talk made at the ITAPS bootcamp on monday,
> 
> we all agreed on the 'Duplicated information for copies' which was
> 
> - owner of an entity knows part-/entity-handles of all its copies
> 
> - all copies know remote part-/entity-handle of the owned entity
> 
> - all boundary entities know part-/entity-handles of all its copies
> 
>  
> 
> While I can understand that portions of this information are useful
> 
> for various applications that may need to modify the mesh, none
> 
> of it is useful for read-only applications, like a viz. tool. So,
> 
> I'd like to make a pitch to allow applications to indicate to iMesh
> 
> if some or all of this information is needed. In other words, will
> 
> the application even engage in the operations for which we determined
> 
> this information is essential? If not, then why are we going to the
> 
> trouble of storing it? Yes, viz-tools need ghost entities. And, viz-tools
> 
> need the ability to create ghost entities (as well as tag or field
> 
> data defined on those entities). But, viz-tools don't need a concept
> 
> of 'owner' for an entity nor do they need to know where all
> 
> the copies of entities are. Its extra information they don't need.
> 
> Even though its only going to happen on the 'boundaries', its still
> 
> worth NOT storing it if we don't need it.

One point of order here:  Mark, isn't a viz tool going to need to know 
where the copies of bdry entities are so that (for instance) a 
streamline can be continuous across parts?

Even in that case, I agree that -ownership- is a concept that a viz tool 
won't care about (nor will anything else that doesn't modify the mesh). 
  Perhaps this is a situation where implementation could choose to 
accept a load-time argument that identifies the mesh database as 
read-only, and then optimize internally?  Not all implementations will 
take advantage of this savings, probably, but at least then they have 
the option to.

There may be any easy way to go beyond that without causing headaches 
for implementations, but I haven't thought about it long enough to come 
up with a 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/
------------------------------------------------------------------------