[mpiwg-sessions] Can I query a set even if I'm not in it?

[Jeff Squyres (jsquyres)]

On Apr 28, 2016, at 1:40 PM, Dan Holmes <dholmes at epcc.ed.ac.uk> wrote:
> 
> What about supplying ocean_set and atoms_set on the command-line - should ocean processes only see ocean_set and not atoms_set?

That is what I had been thinking, yes.

> Can I do multi-physics couple simulations where  communication happens occasionally between the groups but very often within the groups? I’d need ocean_set -> comm_ocean and mpi://WORLD -> filtered to include some ocean and some not ocean -> comm_exchange. With a 2-way partition then WORLD disjoint ocean gives atoms.

I'm not quite sure what you're asking here.

Yes, in my mental model -- which I'm not saying we have to stick to; it's just the one I had been assuming -- MPI_SESSION_GET_NAMES returns the set names to which you belong.

In your example, I agree: MPI_GROUP_DIFFERENCE of a group from mpi://WORLD and a group from user://ocean will give you the group representing the atmosphere processes.

Are you looking for something different?

> Isn't mph://SELF just not a special case like HEAD in git? mph://WORLD is sort of like master in git (pretty much always defined but not always where the main action is). I think there’s some mileage in exploring the {set names, set members} -> {git branches, git commits} analogy.

I don't completely follow your analogy...

My point was that currently, there is only a uniqueness argument for set names in a single process.  Hence, multiple processes could know of a set named "foo", but they may be the same set, or they will be a different set.  mpi://SELF is one such example.

Meaning: if a process asks for set "foo", which "foo" is it referring to -- the one to which it belongs, or some other "foo"?  And if there are multiple other "foo" sets, which one should be returned?

>> Point #2 alone may dictate that set names are only meaningful in the process in which they were queried / returned by the runtime.
> 
> Set names don’t necessarily mean the same thing in all processes but that doesn’t stop them being meaningful.

Unique identification of a set to which you do not belong -- and the scalability baggage that carries -- may make this idea challenging.

-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/