itaps-parallel removal of

[Mark Miller]

Carl Ollivier-Gooch wrote:
> 
> 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

So, I am curious here. Assuming the PartHandle datatype is totally implementation
defined and assuming it is totally opaque to the client -- as I think it should
be, how is it that an application is able to get into the state of
having in hand the ID's of all the parts without a iMeshP_getPartsOnRank()
or some such function in the interface? Are we assuming that PartHandles
have been message passed around by the client itself? If so, how does
that happen? I may be missing something but I don't see how it is possible
for an application to get into this state to begin with -- at least not
without making some assumptions about how PartHandle is implemented.

On the other hand -- now I am contradicting myself -- what good is a part
handle if I don't also have some need to manipulate entities in the part?

(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?)?

-- 
Mark C. Miller, Lawrence Livermore National Laboratory
email: mailto:miller86 at llnl.gov
(M/T/W) (925)-423-5901 (!!LLNL BUSINESS ONLY!!)
(Th/F)  (530)-753-8511 (!!LLNL BUSINESS ONLY!!)