itaps-parallel definition for 'neighbors of a part'

[Devine, Karen D]

On 2/13/08 12:31 PM, "Carl Ollivier-Gooch" <cfog at mech.ubc.ca> wrote:

> Tim Tautges wrote:
>> "Objects for which ownership is clearly defined" will definitely be
>> different than "objects in the partition", both in the case of
>> lower-dimensional entities (which aren't in the 2nd group) and multiple
>> partitions (where you have to qualify which partition you're talking
>> about).
>>
>> Also, now that we're discussing getNumOfTypePar, we should also allow in
>> this function for passing something equivalent to "no partition" and "no
>> set", so that an application can find information about the global mesh,
>> independent of partition.  This will be important for example when
>> multiple partitions exist with partitioned objects of different
>> dimension (think 3d region partition and surface face partition, where
>> objects in the face partition can bound objects in the region partition).
>
> This both addresses my concern about (what I think of) as the obvious
> global query and has a parallel (pun intended) to the root set formalism
> that we already use in serial.
>
> But will this integrate seamlessly with, for instance, iterators?
>
> Suppose I have partitioned my mesh on the basis of regions, but now I
> want to iterate over faces within each part (for swapping, or for a
> solver, or for some other reason).  If the part is a covering of the
> partition, and the partition contains only the regions, I've got nothing
> to iterate over (or query or count).  Either that, or the union of parts
> has different membership than the partition and the sum of getNumOfType
> by parts isn't getNumOfTypePar for the partition...

>From the application perspective, this type of query is a very natural one.
For example, a finite element mesh may be partitioned by vertices, but the
application loops over elements in each part (including shared elements) to
do the matrix fill.  I think our queries should not return information about
only those entities used to generate a partition.

>
> Fundamentally, it looks like we may need two families of functions, one
> that acts only on the entities that were used for division into parts,
> and one that acts on all the entities in the mesh.  I suspect that,
> except for partitioning, the latter is likely to be used/usable
> overwhelmingly more often.  So that's the one that I think we should
> mean when we count entities, do entity queries, and create iterators in
> the "natural" iMesh-like ways.  Queries related to what was used for
> division into parts have a place, too, and I'm certainly not saying we
> shouldn't preserve that information, but IMO that place is secondary.

If information about the "objects" used to generate a partition are needed
only by a partitioning algorithm, shouldn't they be managed there?  Are
there other cases where iMesh would care?


>
> Of course, I may be overlooking some large class of use cases where the
> notion of all entities of a particular dimension or topology with local
> right-to-modify just isn't adequate.  Obviously, I'm having trouble
> imagining what those would be. :-)
>
> 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/
> ------------------------------------------------------------------------
>
>
>