August 2018 - mpiwg-sessions - mailman3.cels.anl.gov

Re: [mpiwg-sessions] PMIx Group status update
by Pritchard Jr., Howard 29 Aug '18

29 Aug '18

Thanks very much Ralph! -- Howard Pritchard B Schedule HPC-ENV Office 9, 2nd floor Research Park TA-03, Building 4200, Room 203 Los Alamos National Laboratory On 8/29/18, 12:29 PM, "mpiwg-sessions on behalf of Ralph H Castain via mpiwg-sessions" <mpiwg-sessions-bounces(a)lists.mpi-forum.org on behalf of mpiwg-sessions(a)lists.mpi-forum.org> wrote: >Hi folks > >I promised on the last call to keep people apprised of my progress. I >have implemented the collective versions of the new APIs >(PMIx_Group_construct/destruct) and have updated the PMIx_Fence operation >to look for group names, substituting the group members into the array of >participants. This all appears to be working correctly. > >The PR for it is here: https://github.com/pmix/pmix/pull/826 >or the branch itself: >https://github.com/rhc54/pmix-master/tree/topic/group > >You can see an example use of the code here: >https://github.com/rhc54/pmix-master/blob/topic/group/examples/group.c > >I’m now working on the async APIs (PMIx_Group_invite/join) - I have them >mostly implemented, but need to debug. >Ralph > >_______________________________________________ >mpiwg-sessions mailing list >mpiwg-sessions(a)lists.mpi-forum.org >https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions

1 0

Re: [mpiwg-sessions] PMIx Group status update
by Ralph H Castain 29 Aug '18

29 Aug '18

Should have also noted that I updated the web page describing these new functions: https://pmix.org/pmix-standard/pmix-groups/ I had to slightly modify the PMIx_Group_join[_nb] APIs, and there are a couple of “implementation notes” > On Aug 29, 2018, at 11:29 AM, Ralph H Castain via mpiwg-sessions <mpiwg-sessions(a)lists.mpi-forum.org> wrote: > > Hi folks > > I promised on the last call to keep people apprised of my progress. I have implemented the collective versions of the new APIs (PMIx_Group_construct/destruct) and have updated the PMIx_Fence operation to look for group names, substituting the group members into the array of participants. This all appears to be working correctly. > > The PR for it is here: https://github.com/pmix/pmix/pull/826 > or the branch itself: https://github.com/rhc54/pmix-master/tree/topic/group > > You can see an example use of the code here: https://github.com/rhc54/pmix-master/blob/topic/group/examples/group.c > > I’m now working on the async APIs (PMIx_Group_invite/join) - I have them mostly implemented, but need to debug. > Ralph > > _______________________________________________ > mpiwg-sessions mailing list > mpiwg-sessions(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions

1 0

PMIx Group status update
by Ralph H Castain 29 Aug '18

29 Aug '18

Hi folks I promised on the last call to keep people apprised of my progress. I have implemented the collective versions of the new APIs (PMIx_Group_construct/destruct) and have updated the PMIx_Fence operation to look for group names, substituting the group members into the array of participants. This all appears to be working correctly. The PR for it is here: https://github.com/pmix/pmix/pull/826 or the branch itself: https://github.com/rhc54/pmix-master/tree/topic/group You can see an example use of the code here: https://github.com/rhc54/pmix-master/blob/topic/group/examples/group.c I’m now working on the async APIs (PMIx_Group_invite/join) - I have them mostly implemented, but need to debug. Ralph

1 0

Re: [mpiwg-sessions] Next meeting - today - 1pm Eastern US time
by Pritchard Jr., Howard 27 Aug '18

27 Aug '18

Hi Folks, remember that Dan’s examples got moved to https://github.com/hpc/mpi_sessions_code_sandbox -- Howard Pritchard B Schedule HPC-ENV Office 9, 2nd floor Research Park TA-03, Building 4200, Room 203 Los Alamos National Laboratory From: mpiwg-sessions <mpiwg-sessions-bounces(a)lists.mpi-forum.org<mailto:[email protected]>> on behalf of MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> Reply-To: MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> Date: Monday, August 27, 2018 at 9:00 AM To: MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> Cc: HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]>> Subject: [mpiwg-sessions] Next meeting - today - 1pm Eastern US time Hi all, The next meeting for the Sessions WG is today at 1pm Eastern US time. The connection details for the call can be found here: http://mpi-forum.epcc.ed.ac.uk/mpiwg-sessions.php The wiki for the working group, including documentation about Sessions and minutes of previous meetings is here: https://github.com/mpiwg-sessions/sessions-issues/wiki We have two current topics. 1) Changes for the main part of the core sessions proposal https://github.com/mpiwg-sessions/mpi-standard/pull/8 2) Implementation of Sessions a) As a library on top of MPI-3.1 using connect/accept https://bitbucket.org/howard_pritchard/mpi_sessions_code_sandbox<https://bitbucket.org/howard_pritchard/mpi_sessions_code_sandbox/commits/all> b) Directly on top of PMIx, using PMIx groups https://github.com/pmix/RFCs/pull/33/files https://pmix.org/pmix-standard/pmix-groups/ Cheers, Dan. — Dr Daniel Holmes PhD Applications Consultant in HPC Research d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]> Phone: +44 (0) 131 651 3465 Mobile: +44 (0) 7940 524 088 Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. —

1 0

Next meeting - today - 1pm Eastern US time
by HOLMES Daniel 27 Aug '18

27 Aug '18

Hi all, The next meeting for the Sessions WG is today at 1pm Eastern US time. The connection details for the call can be found here: http://mpi-forum.epcc.ed.ac.uk/mpiwg-sessions.php The wiki for the working group, including documentation about Sessions and minutes of previous meetings is here: https://github.com/mpiwg-sessions/sessions-issues/wiki We have two current topics. 1) Changes for the main part of the core sessions proposal https://github.com/mpiwg-sessions/mpi-standard/pull/8 2) Implementation of Sessions a) As a library on top of MPI-3.1 using connect/accept https://bitbucket.org/howard_pritchard/mpi_sessions_code_sandbox<https://bitbucket.org/howard_pritchard/mpi_sessions_code_sandbox/commits/all> b) Directly on top of PMIx, using PMIx groups https://github.com/pmix/RFCs/pull/33/files https://pmix.org/pmix-standard/pmix-groups/ Cheers, Dan. — Dr Daniel Holmes PhD Applications Consultant in HPC Research d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]> Phone: +44 (0) 131 651 3465 Mobile: +44 (0) 7940 524 088 Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: [mpiwg-sessions] question about section 8.3 and MPI_COMM_SELF
by HOLMES Daniel 21 Aug '18

21 Aug '18

Hi Howard, As the session_init call takes an errorhandler, the problem is not “is there a good option to replace MPI_COMM_SELF?” but “which of the many errorhandlers supplied to the many session_init calls should be used this time?" If two libraries initialise two sessions (one each) and also both create and commit derived datatypes, which session’s errorhandler should be invoked when one of them runs out of resources? What if one specifies errors return and the other gives a errorhandler function pointer? If the error is really bad and must cause a scoped abort, which session is killed? There is a slide in the long slide deck that suggests solutions, none of which are particularly palatable. One such solution, for example, is that all operations must be scoped within a session - either directly taking a session handle as a function parameter for its “create” function or involving at least one MPI object that has been derived from a session. The default errorhandler is global state; so any sort of mutability is, in general, bad. Thus, another possibility is that all these non-scoped functions should be errors return all the time by definition, i.e. remove the possibility of having a custom errorhandler as the default errorhandler. Perhaps this could be “errors return (preferred) or are fatal (if necessary) depending on the quality of the MPI implementation” or some similar weasel words. Cheers, Dan. — Dr Daniel Holmes PhD Applications Consultant in HPC Research d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]> Phone: +44 (0) 131 651 3465 Mobile: +44 (0) 7940 524 088 Address: Room 3415, JCMB, The King’s Buildings, Edinburgh, EH9 3FD — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. — On 21 Aug 2018, at 14:59, Pritchard Jr., Howard <howardp(a)lanl.gov<mailto:[email protected]>> wrote: Hi Aurelien, responses interleaved below: -- Howard Pritchard B Schedule HPC-ENV Office 9, 2nd floor Research Park TA-03, Building 4200, Room 203 Los Alamos National Laboratory From: mpiwg-sessions <mpiwg-sessions-bounces(a)lists.mpi-forum.org<mailto:[email protected]>> on behalf of Aurelien Bouteiller <bouteill(a)icl.utk.edu<mailto:[email protected]>> Reply-To: MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> Date: Tuesday, August 21, 2018 at 7:41 AM To: MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> Subject: Re: [mpiwg-sessions] question about section 8.3 and MPI_COMM_SELF Howard, A similar issue has been discussed during the last virtual meeting about what happens to errors in MPI_INIT (in which it is not guaranteed that MPI_COMM_SELF) is completely initialized yet, and error handlers had no chance to be set by users yet). One of the feedback of the call is that in such cases, returning an error code is a desired outcome. That would particularly apply to session_init. I like this idea! I’ll put some text into 8.3 stating this behavior when using the Peer to Peer model for initialization. For the rest of the session operations, it could be beneficial to be able to set explicitly (i.e. with a session api call) what is the default/fallback error handler for when the MPI_COMM_SELF object has not been created, and the rules for precedence between these mechanisms when both are in play. I do not remember the group discussing these issues in much more details. Agreed. We need to come up with some way to deal with the way MPI_COMM_SELF is used currently as a grab bag of things. Best, Aurelien On Aug 20, 2018, at 14:20, Pritchard Jr., Howard <howardp(a)lanl.gov<mailto:[email protected]>> wrote: Hi Folks, Does anyone in the WG recall what our thoughts were concerning the case when MPI encounters an error in an MPI function not associated with a particular communicator, file, window, or (now) session? I’m concerned about this sentence in 8.3: When using the MPI calls that are not related to any objects are considered to be attached to the communicator MPI_COMM_SELF. Looking at the old power point slide deck, this problem is mentioned, but not addressed. Howard -- Howard Pritchard B Schedule HPC-ENV Office 9, 2nd floor Research Park TA-03, Building 4200, Room 203 Los Alamos National Laboratory _______________________________________________ mpiwg-sessions mailing list mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions _______________________________________________ mpiwg-sessions mailing list mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: [mpiwg-sessions] question about section 8.3 and MPI_COMM_SELF
by Pritchard Jr., Howard 21 Aug '18

21 Aug '18

Hi Aurelien, responses interleaved below: -- Howard Pritchard B Schedule HPC-ENV Office 9, 2nd floor Research Park TA-03, Building 4200, Room 203 Los Alamos National Laboratory From: mpiwg-sessions <mpiwg-sessions-bounces(a)lists.mpi-forum.org<mailto:[email protected]>> on behalf of Aurelien Bouteiller <bouteill(a)icl.utk.edu<mailto:[email protected]>> Reply-To: MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> Date: Tuesday, August 21, 2018 at 7:41 AM To: MPI Sessions working group <mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]>> Subject: Re: [mpiwg-sessions] question about section 8.3 and MPI_COMM_SELF Howard, A similar issue has been discussed during the last virtual meeting about what happens to errors in MPI_INIT (in which it is not guaranteed that MPI_COMM_SELF) is completely initialized yet, and error handlers had no chance to be set by users yet). One of the feedback of the call is that in such cases, returning an error code is a desired outcome. That would particularly apply to session_init. I like this idea! I’ll put some text into 8.3 stating this behavior when using the Peer to Peer model for initialization. For the rest of the session operations, it could be beneficial to be able to set explicitly (i.e. with a session api call) what is the default/fallback error handler for when the MPI_COMM_SELF object has not been created, and the rules for precedence between these mechanisms when both are in play. I do not remember the group discussing these issues in much more details. Agreed. We need to come up with some way to deal with the way MPI_COMM_SELF is used currently as a grab bag of things. Best, Aurelien On Aug 20, 2018, at 14:20, Pritchard Jr., Howard <howardp(a)lanl.gov<mailto:[email protected]>> wrote: Hi Folks, Does anyone in the WG recall what our thoughts were concerning the case when MPI encounters an error in an MPI function not associated with a particular communicator, file, window, or (now) session? I’m concerned about this sentence in 8.3: When using the MPI calls that are not related to any objects are considered to be attached to the communicator MPI_COMM_SELF. Looking at the old power point slide deck, this problem is mentioned, but not addressed. Howard -- Howard Pritchard B Schedule HPC-ENV Office 9, 2nd floor Research Park TA-03, Building 4200, Room 203 Los Alamos National Laboratory _______________________________________________ mpiwg-sessions mailing list mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions

1 0

Re: [mpiwg-sessions] question about section 8.3 and MPI_COMM_SELF
by Aurelien Bouteiller 21 Aug '18

21 Aug '18

Howard, A similar issue has been discussed during the last virtual meeting about what happens to errors in MPI_INIT (in which it is not guaranteed that MPI_COMM_SELF) is completely initialized yet, and error handlers had no chance to be set by users yet). One of the feedback of the call is that in such cases, returning an error code is a desired outcome. That would particularly apply to session_init. For the rest of the session operations, it could be beneficial to be able to set explicitly (i.e. with a session api call) what is the default/fallback error handler for when the MPI_COMM_SELF object has not been created, and the rules for precedence between these mechanisms when both are in play. I do not remember the group discussing these issues in much more details. Best, Aurelien > On Aug 20, 2018, at 14:20, Pritchard Jr., Howard <howardp(a)lanl.gov> wrote: > > Hi Folks, > > Does anyone in the WG recall what our thoughts were concerning > the case when MPI encounters an error in an MPI function > not associated with a particular communicator, file, window, or > (now) session? > > I’m concerned about this sentence in 8.3: > > When using the MPI calls that are not related to any objects are considered to be attached to the communicator > MPI_COMM_SELF. > > Looking at the old power point slide deck, this problem is mentioned, but not > addressed. > > Howard > > -- > Howard Pritchard > B Schedule > HPC-ENV > Office 9, 2nd floor Research Park > TA-03, Building 4200, Room 203 > Los Alamos National Laboratory > > _______________________________________________ > mpiwg-sessions mailing list > mpiwg-sessions(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions

1 0

Re: [mpiwg-sessions] will be on a plane today - and some observations
by Ralph H Castain 20 Aug '18

20 Aug '18

IIRC, there may be a default range setting that blocks the lookup - I’ll try to take a look later. Please understand that this isn’t an operation we spend a lot of effort supporting as virtually nobody has used it. > On Aug 20, 2018, at 4:26 PM, HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk> wrote: > > Hi Ralph, > > Unfortunately, the fact that “test3” is passing the “portname" on the command-line is a red-herring - connect/accept also fails when the “portname” is advertised by the job that opens the port using MPI_Publish_name and discovered by the other job using MPI_Lookup_name. This is the test case that the sandbox code relies on. I also modified the “test3” example to use Publish/Lookup to figure out if there was any difference in the internal handling (inside Open MPI and/or inside PMIx) between these situations. There is no difference in the final outcome or in the code path from dpm_connect_accept to the deadlock. > > In all cases, both processes get as far as ompi/dpm/dpm.c:398 (using git commit 5768336) and calls into PMIx_Connect. They both then get as far as opal/mca/pmix/pmix3x/pmix/src/client/pmix_client_connect.c:102 (same git hash), i.e. PMIX_WAIT_THREAD(&cb->lock); > > What happens next is an infinite loop that (at least) includes a whole bunch of calls to "HASH:STORE rank -2 key pmix.<various>” output messages that burns a couple of CPUs at 100% and shifts data on the local network at max-bandwidth. > > The MacOS Activity Monitor shows two orterun processes at 50% CPU each and one orte-server process at 100%. Network usage statistics are roughly in the same proportion. > > It’s going to be hard to progress any further without knowing a starting point for the code doing the HASH:STORE operations. I guess it’s the PMIx progress threads trying to complete the PMIX_PTL_SEND_RECV operations pushed onto the event queues in PMIx_Connect_nb but that isn’t helping me all that much. > > Cheers, > Dan. > — > Dr Daniel Holmes PhD > Applications Consultant in HPC Research > d.holmes(a)epcc.ed.ac.uk <mailto:[email protected]> > Phone: +44 (0) 131 651 3465 > Mobile: +44 (0) 7940 524 088 > Address: Room 3415, JCMB, The King’s Buildings, Edinburgh, EH9 3FD > — > The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. > — > >> On 20 Aug 2018, at 16:24, Ralph H Castain <rhc(a)open-mpi.org <mailto:[email protected]>> wrote: >> >> Passing a port on the cmd line for accept/connect was never implemented as I don’t think anyone really cared. Given how OMPI uses PMIx for that operation, it shouldn’t be all that difficult to do. >> >> As noted in the referenced issue, there was a problem last year with cross-mpirun connections. Not sure when I’ll have time to look at it. >> >> Canceling the meeting today is fine with me - I got pulled away and didn’t get the PMIx Groups implementation done (sigh). >> >> >>> On Aug 20, 2018, at 8:10 AM, HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk <mailto:[email protected]>> wrote: >>> >>> Hi Howard, >>> >>> Thanks for the update. Sounds promising. >>> >>> I'm trying to fix the test3.zip example from: >>> https://github.com/open-mpi/ompi/issues/3458#issuecomment-322951227 <https://github.com/open-mpi/ompi/issues/3458#issuecomment-322951227> >>> >>> If successful, this would extend the testing opportunities for the sandbox code to situations that involve more than one mpirun. The issue is definitely some sort of deadlock in PMIx but I’ve not figured it out completely yet. >>> >>> I’m cancelling the meeting today, unless anyone objects in the next 50 minutes. >>> >>> Cheers, >>> Dan. >>> — >>> Dr Daniel Holmes PhD >>> Applications Consultant in HPC Research >>> d.holmes(a)epcc.ed.ac.uk <mailto:[email protected]> >>> Phone: +44 (0) 131 651 3465 >>> Mobile: +44 (0) 7940 524 088 >>> Address: Room 3415, JCMB, The King’s Buildings, Edinburgh, EH9 3FD >>> — >>> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. >>> — >>> >>>> On 20 Aug 2018, at 15:55, Pritchard Jr., Howard <howardp(a)lanl.gov <mailto:[email protected]>> wrote: >>>> >>>> HI Folks, >>>> >>>> I’ll be on a plane at 11 AM MDT today so will not be able to call in. >>>> >>>> I tried running the tests Dan had added/modified and observed >>>> what he did, that one can’t allow more than one outstanding >>>> accept/connect going on at a time or Open MPI’s ORTE gets confused. >>>> I reduced this down to a simpler test which hangs with only 3 ranks >>>> and am narrowing down what the issue is. >>>> >>>> I’ll be opening a PR with changes to chapter 8 of the standard and >>>> replacement for MPI_Get_Set_Names later this week. >>>> >>>> Howard >>>> >>>> -- >>>> Howard Pritchard >>>> B Schedule >>>> HPC-ENV >>>> Office 9, 2nd floor Research Park >>>> TA-03, Building 4200, Room 203 >>>> Los Alamos National Laboratory >>>> >>>> _______________________________________________ >>>> mpiwg-sessions mailing list >>>> mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]> >>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions> >>> >>> The University of Edinburgh is a charitable body, registered in >>> Scotland, with registration number SC005336. >>> _______________________________________________ >>> mpiwg-sessions mailing list >>> mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]> >>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions> >> >> _______________________________________________ >> mpiwg-sessions mailing list >> mpiwg-sessions(a)lists.mpi-forum.org <mailto:[email protected]> >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > _______________________________________________ > mpiwg-sessions mailing list > mpiwg-sessions(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions

1 0

Re: [mpiwg-sessions] will be on a plane today - and some observations
by HOLMES Daniel 20 Aug '18

20 Aug '18

Hi Ralph, Unfortunately, the fact that “test3” is passing the “portname" on the command-line is a red-herring - connect/accept also fails when the “portname” is advertised by the job that opens the port using MPI_Publish_name and discovered by the other job using MPI_Lookup_name. This is the test case that the sandbox code relies on. I also modified the “test3” example to use Publish/Lookup to figure out if there was any difference in the internal handling (inside Open MPI and/or inside PMIx) between these situations. There is no difference in the final outcome or in the code path from dpm_connect_accept to the deadlock. In all cases, both processes get as far as ompi/dpm/dpm.c:398 (using git commit 5768336) and calls into PMIx_Connect. They both then get as far as opal/mca/pmix/pmix3x/pmix/src/client/pmix_client_connect.c:102 (same git hash), i.e. PMIX_WAIT_THREAD(&cb->lock); What happens next is an infinite loop that (at least) includes a whole bunch of calls to "HASH:STORE rank -2 key pmix.<various>” output messages that burns a couple of CPUs at 100% and shifts data on the local network at max-bandwidth. The MacOS Activity Monitor shows two orterun processes at 50% CPU each and one orte-server process at 100%. Network usage statistics are roughly in the same proportion. It’s going to be hard to progress any further without knowing a starting point for the code doing the HASH:STORE operations. I guess it’s the PMIx progress threads trying to complete the PMIX_PTL_SEND_RECV operations pushed onto the event queues in PMIx_Connect_nb but that isn’t helping me all that much. Cheers, Dan. — Dr Daniel Holmes PhD Applications Consultant in HPC Research d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]> Phone: +44 (0) 131 651 3465 Mobile: +44 (0) 7940 524 088 Address: Room 3415, JCMB, The King’s Buildings, Edinburgh, EH9 3FD — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. — On 20 Aug 2018, at 16:24, Ralph H Castain <rhc(a)open-mpi.org<mailto:[email protected]>> wrote: Passing a port on the cmd line for accept/connect was never implemented as I don’t think anyone really cared. Given how OMPI uses PMIx for that operation, it shouldn’t be all that difficult to do. As noted in the referenced issue, there was a problem last year with cross-mpirun connections. Not sure when I’ll have time to look at it. Canceling the meeting today is fine with me - I got pulled away and didn’t get the PMIx Groups implementation done (sigh). On Aug 20, 2018, at 8:10 AM, HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]>> wrote: Hi Howard, Thanks for the update. Sounds promising. I'm trying to fix the test3.zip example from: https://github.com/open-mpi/ompi/issues/3458#issuecomment-322951227 If successful, this would extend the testing opportunities for the sandbox code to situations that involve more than one mpirun. The issue is definitely some sort of deadlock in PMIx but I’ve not figured it out completely yet. I’m cancelling the meeting today, unless anyone objects in the next 50 minutes. Cheers, Dan. — Dr Daniel Holmes PhD Applications Consultant in HPC Research d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]> Phone: +44 (0) 131 651 3465 Mobile: +44 (0) 7940 524 088 Address: Room 3415, JCMB, The King’s Buildings, Edinburgh, EH9 3FD — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. — On 20 Aug 2018, at 15:55, Pritchard Jr., Howard <howardp(a)lanl.gov<mailto:[email protected]>> wrote: HI Folks, I’ll be on a plane at 11 AM MDT today so will not be able to call in. I tried running the tests Dan had added/modified and observed what he did, that one can’t allow more than one outstanding accept/connect going on at a time or Open MPI’s ORTE gets confused. I reduced this down to a simpler test which hangs with only 3 ranks and am narrowing down what the issue is. I’ll be opening a PR with changes to chapter 8 of the standard and replacement for MPI_Get_Set_Names later this week. Howard -- Howard Pritchard B Schedule HPC-ENV Office 9, 2nd floor Research Park TA-03, Building 4200, Room 203 Los Alamos National Laboratory _______________________________________________ mpiwg-sessions mailing list mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. _______________________________________________ mpiwg-sessions mailing list mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions _______________________________________________ mpiwg-sessions mailing list mpiwg-sessions(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0