On Apr 28, 2016, at 2:00 PM, Bland, Wesley <[email protected]> wrote:
We could resolve it by treating set makeup like a caching problem. You take the most local version of the set that you know about. If you ask for set “foo” and you have a set “foo” of which you’re a member, you get that one. Otherwise, you go looking for one somewhere else. That could still result in collisions and in that case, you’d have to error our saying that you didn’t provide something well-enough specified.
I'm a bit wary of this. It's a little weird (to me) that in *some* cases, multiple "foo" sets are ok, but in *other* cases, multiple "foo" sets might not be ok.
I’m not sure that’s a great solution, but it at least gets us partway there.
We (the FTWG) probably have to think more about if/how doing in-place replacement would work if we could have this sort of global knowledge somewhere (even if it’s in a distributed runtime and is slow). It might not be worth pursuing, but it seemed like it might open the door to some nicer forms of FT that people have asked for.
Ok.
Thanks, Wesley
On Apr 28, 2016, at 12:53 PM, Jeff Squyres (jsquyres) <[email protected]> wrote:
On Apr 28, 2016, at 1:40 PM, Dan Holmes <[email protected]> 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 [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________ mpiwg-sessions mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-sessions
_______________________________________________ mpiwg-sessions mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-sessions
-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/