itaps-parallel removal of

[Onkar Sahni]

> On Wed, 2008-03-19 at 10:24 -0600, Onkar Sahni wrote:
>> >
>> > In the specific case of repartitioning, it knows because every entity
>> > comes to it with a part handle attached.
>>
>>   every local entity comes with local part-handle(s) (may be neighbors
>> touching each other for graph-edges crossing inter-part/process bdry.)
>> and how can a partitioning service then get local part-handle(s)
>> transported to remote parts/processes. This is exactly the point I was
>> trying to make during boot-camp.
>
> I too have been concerned about this, but had reached a conclusion
> similar to Carl's that non-iMeshP communications would be necessary to
> obtain remote part handles.  An iMeshP solution that removes that would
> be fine with me.

  For non-iMeshP communications, service/user/application/client would
have to know how to send/recv. (pack/unpack) part-handles. If we use
integers (or pre-defined fixed number of bits) for remote part IDs it
would be fine in case of non-iMeshP communications otherwise we may want
to add some functionality (on this issue for part IDs) in interface.

- Onkar

>
> Vitus
>
>> During file I/O (parallel read) I think (as of now) we will have to talk
>> in terms of integers for part IDs (or may be pair of integers) and map
>> these to processes/ranks (this map could default to something but can be
>> provided by application).
>>
>> - Onkar
>>
>> >
>> > I'll admit I hadn't thought about (one of?) the bootstrap problem: how
>> > does a parallel read manage to work out which part handle for some
>> > remote part goes with however the part is identified in the file?  I
>> can
>> > imagine any number of really bad, expensive ways to do that, but
>> having
>> > a mapping from part number to part ID would be cleaner, more accurate,
>> > and faster.
>> >
>> > So in the end, I think Mark's got me convinced of the need for a
>> > function to do this mapping.  I think it's possible to implement this
>> in
>> > a way that requires no communication (and not too much storage, at
>> least
>> > in common cases), although obviously this mapping will have to be one
>> of
>> > the things that updatePartitionAll updates.
>>
>>   If we reserve bits (fixed m and n across processes), then I think
>> updatePartitionAll do not necessarily need to do anything extra for part
>> IDS (and their mapping).
>>
>> - Onkar
>>
>> >
>> > 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/
>> > ------------------------------------------------------------------------
>> >
>>
>>
>>
>
>
>