itaps-parallel removal of

[Carl Ollivier-Gooch]

Mark Miller wrote:
> I didn't read this fully before I responded.
> 
>> In this context, I could argue that the parallel read will have to do 
>> some outside-iMeshP communication so that the reading proc can have all 
>> the part handles.
> 
> Yes, I think this would address my concern. But, this ability
> to message pass part handles around implies things about them,
> such as they can't be pointers, that, are important to call out.
> 
> Also, perhaps something more fundamental is at work in my thinking
> that I just can't put a fingure on. But, I think it has to do
> with dancing around the issue of the mapping of part handles to
> processors (and perhaps even to specific parts on those processors).
> 
> Mark S. argued that we can't be 'scalable' and have a requirement
> that we maintain a list of all part handles (as well as their
> mpi ranks) on any one processor. I am pretty sure I agree with
> this. At the same time, doesn't it mean that no processor really
> has the 'complete' picture of the mapping from processors to parts?
> And, aren't there a great many situations in which this mapping
> DOES NOT require O(num_parts) storage and we we could, in fact,
> get away with storing it on eachh processor? And, isn't Carl's
> attempt to use 30-m bits to represent a part handle just another
> way of making this mapping computable? So, aren't we really
> dancing around the issue of how best to maintain this mapping?

Mark,

I think you're right about this.  Certainly you're right that I've 
basically come up with a scheme that does this mapping.  Onkar sketched 
a different (and likely more workable) scheme in an earlier email.  So I 
guess the questions before us reduce to:

1.  Is there a use case in which an application or service that wouldn't 
otherwise have in hand the ID's of all parts (this latter clause covers 
partitioners but not necessarily load balancers, for instance) is going 
to need to be able to identify and communicate with parts other than its 
neighbors?

2.  If the answer to 1 is yes, what capabilities do we need to add to 
the interface to support the sort of mapping Mark describes?  Or is this 
a situation in which we should have an all-to-all communication so that 
each process will know about every part (including the current 
part-to-part communication graph?)?

Carl

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/
------------------------------------------------------------------------