April 2016 - mpiwg-sessions - mailman3.cels.anl.gov

Re: [mpiwg-sessions] Can I query a set even if I'm not in it?
by Jeff Squyres (jsquyres) 28 Apr '16

28 Apr '16

On Apr 28, 2016, at 2:00 PM, Bland, Wesley <wesley.bland(a)intel.com> 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) <jsquyres(a)cisco.com> wrote: >> >> On Apr 28, 2016, at 1:40 PM, Dan Holmes <dholmes(a)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(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-sessions mailing list >> mpiwg-sessions(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-sessions > > _______________________________________________ > mpiwg-sessions mailing list > mpiwg-sessions(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-sessions -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Sessions webex: Monday, 5/2
by Jeff Squyres (jsquyres) 28 Apr '16

28 Apr '16

Slides for this upcoming Monday's sessions WG meeting are posted: https://github.com/mpiwg-sessions/sessions-issues/wiki/2016-05-02-webex That page also includes a list of changes to the slides. Webex link is on the main page: https://github.com/mpiwg-sessions/sessions-issues/wiki -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpiwg-sessions] Can I query a set even if I'm not in it?
by Bland, Wesley 28 Apr '16

28 Apr '16

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 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. Thanks, Wesley > On Apr 28, 2016, at 12:53 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > > On Apr 28, 2016, at 1:40 PM, Dan Holmes <dholmes(a)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(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-sessions mailing list > mpiwg-sessions(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-sessions

1 0

Re: [mpiwg-sessions] Can I query a set even if I'm not in it?
by Jeff Squyres (jsquyres) 28 Apr '16

28 Apr '16

On Apr 28, 2016, at 1:40 PM, Dan Holmes <dholmes(a)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(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpiwg-sessions] Can I query a set even if I'm not in it?
by Dan Holmes 28 Apr '16

28 Apr '16

Hi Jeff, Inline comments. Cheers, Dan. > On 28 Apr 2016, at 18:17, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > > In principle, I don't think I have a problem with a process asking for a group for a set of which it is not a member. However: > > 1. You're correct about the scalability issues. > > --> This exposes an ambiguity in MPI_Session_get_names(): does that return *all* set names, or just sets to which the querying process belongs? I'm in favor of the latter. What about supplying ocean_set and atoms_set on the command-line - should ocean processes only see ocean_set and not atoms_set? 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 atmos. > > 2. There's also an issue about the uniqueness of set names. E.g., we defined that every process is part of mpi://SELF, but each of those sets are distinct from each other. E.g., when process X refers to mpi://SELF, is it referring to its *own* mpi://SELF, or the mpi://SELF relative to some other process? 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. > > 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. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-sessions mailing list > mpiwg-sessions(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-sessions -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: [mpiwg-sessions] Can I query a set even if I'm not in it?
by Jeff Squyres (jsquyres) 28 Apr '16

28 Apr '16

On Apr 26, 2016, at 4:11 PM, Bland, Wesley <wesley.bland(a)intel.com> wrote: > > Apologies if we’ve covered this and I’ve now forgotten, but it’s something that came up in the FTWG con call today. If I’m not in a set, am I still able to get the group it describes? > > An example is because the set names are easily serialized (because they’re strings), I could pass a set name around so that someone who wasn’t in the set could have access to it and therefore ask the runtime to create a group from it. In the group world, this is allowed: >> Section 6.4.2 (MPI 3.1 p. 230 line 4-5) - … a process may also define a group that does not include itself. FYI -- that's section 6.3.2, not 6.4.2. > This has advantages and disadvantages. The advantage is that we could do things like create inter-communicators without the bridge_comm as long as you have some other way of getting the set name. We decided on the last call that this was important. In the context of fault tolerance, it *might* be possible to do in-place replacement if we have the ability to touch all sets from anywhere (HUGE might there). > > The downside is that you have to be able to get the definition of any set from anywhere, which could have scalability issues (having to keep track of all the sets and how they overlap would be an O(p*s) problem, which we’re trying to avoid). In principle, I don't think I have a problem with a process asking for a group for a set of which it is not a member. However: 1. You're correct about the scalability issues. --> This exposes an ambiguity in MPI_Session_get_names(): does that return *all* set names, or just sets to which the querying process belongs? I'm in favor of the latter. 2. There's also an issue about the uniqueness of set names. E.g., we defined that every process is part of mpi://SELF, but each of those sets are distinct from each other. E.g., when process X refers to mpi://SELF, is it referring to its *own* mpi://SELF, or the mpi://SELF relative to some other process? Point #2 alone may dictate that set names are only meaningful in the process in which they were queried / returned by the runtime. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Can I query a set even if I'm not in it?
by Bland, Wesley 26 Apr '16

26 Apr '16

Apologies if we’ve covered this and I’ve now forgotten, but it’s something that came up in the FTWG con call today. If I’m not in a set, am I still able to get the group it describes? An example is because the set names are easily serialized (because they’re strings), I could pass a set name around so that someone who wasn’t in the set could have access to it and therefore ask the runtime to create a group from it. In the group world, this is allowed: > Section 6.4.2 (MPI 3.1 p. 230 line 4-5) - … a process may also define a group that does not include itself. > This has advantages and disadvantages. The advantage is that we could do things like create inter-communicators without the bridge_comm as long as you have some other way of getting the set name. We decided on the last call that this was important. In the context of fault tolerance, it *might* be possible to do in-place replacement if we have the ability to touch all sets from anywhere (HUGE might there). The downside is that you have to be able to get the definition of any set from anywhere, which could have scalability issues (having to keep track of all the sets and how they overlap would be an O(p*s) problem, which we’re trying to avoid). Thanks, Wesley

1 0

Notes from last week's meeting finally posted
by Bland, Wesley 25 Apr '16

25 Apr '16

Hi all, Sorry it took me so long to post the meeting notes from last week, but they’re finally on the wiki page: https://github.com/mpiwg-sessions/sessions-issues/wiki/2016-04-18-webex. I had a discussion with Jeff to convey the responses that we came up with during the call and he had some feedback that I’ve included. As always, feel free to make any corrections or complete any omissions. Thanks, Wesley

1 0

MPI_TAG_UB / MPI_WTIME_IS_GLOBAL
by Jeff Squyres (jsquyres) 11 Apr '16

11 Apr '16

I'm back from vacation (it was great, thanks for asking!); Wesley and I just reviewed the meeting you guys had last week. I've pushed new notes and slides based on the meeting last week: https://github.com/mpiwg-sessions/sessions-issues/wiki/2016-04-18-webex - (session,fn,context) must be unique in the finalize hook addition --> therefore there's never any confusion about which one to delete --> I don't like the stack push/pop model because then one entity can't easily remove its own hook (i.e., it has to go find who is holding its (fn,context) tuple and replace it -- ick! Deleting a hook is infrastructure functionality; we should have it in the core API) - It seems like a minimum distance change to leave MPI_TAG_UB and MPI_WTIME_IS_GLOBAL as communicator attributes -- but specifically state that they will be defined on *all* communicators. Comments? (FYI: I also made a few changes in the later slides that you did not get to talk about in the 2016-04-04 meeting; the 2016-04-18 slides are now the definitive version for *all* slides) -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpiwg-sessions] Slides posted to discuss next Monday
by Jim Dinan 08 Apr '16

08 Apr '16

Here's another presentation that's more recent: http://meetings.mpi-forum.org/secretary/2013/12/slides/jsquyres-init-finali… And one from way back: http://meetings.mpi-forum.org/secretary/2011/07/slides/ref-counted-init-fin… ~Jim. On Fri, Apr 8, 2016 at 10:41 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Hi All, > > I was looking through past meeting materials today and came across a past > init/finalize presentation that Jeff gave. I don't think there's a need to > revisit this discussion, since we ultimately reached the conclusion that > init/finalize are wedged at their current semantics, but it could be > interesting background for anyone who is interested: > > > http://meetings.mpi-forum.org/secretary/2013/09/slides/jsquyres-init-finali… > > ~Jim. > > On Mon, Apr 4, 2016 at 3:01 PM, Bland, Wesley <wesley.bland(a)intel.com> > wrote: > >> Hi all, >> >> I’ve updated the wiki with notes from today’s sessions call. Thanks to >> all who contributed. If I missed anything, feel free to correct it. >> >> The plan for next week will be to pick up where we left off which will be >> slide 69, MPI_GET_WTIME_IS_GLOBAL. >> >> Thanks, >> Wesley >> >> > On Mar 31, 2016, at 12:01 PM, Jeff Squyres (jsquyres) < >> jsquyres(a)cisco.com> wrote: >> > >> > Sessions WG -- >> > >> > I have posted notes and slides to discuss for this upcoming Monday: >> > >> > - edits to old slides to clarify old questions >> > - several new slides to propose/address answers to bigger questions >> (e.g., COMM_SPAWN/COMM_PARENT, etc.) >> > >> > See: >> https://github.com/mpiwg-sessions/sessions-issues/wiki/2016-04-04-webex >> > >> > Regrettably, I am unable to join the call on Monday. I'll go over the >> proposed updates with Wesley before Monday; hopefully he'll be able to help >> guide the conversation. >> > >> > Please take good notes / minutes. Wesley and I will sync up after the >> meeting. >> > >> > -- >> > Jeff Squyres >> > jsquyres(a)cisco.com >> > For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> > >> > _______________________________________________ >> > mpiwg-sessions mailing list >> > mpiwg-sessions(a)lists.mpi-forum.org >> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-sessions >> >> _______________________________________________ >> mpiwg-sessions mailing list >> mpiwg-sessions(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-sessions >> > >

1 0