September 2019 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] Error/gap in MPI_NEIGHBOR_ALLTOALL/ALLGATHER
by Anthony Skjellum 29 Sep '19

29 Sep '19

All, please see: https://github.com/mpi-forum/mpi-issues/issues/153 Thanks, Tony On Fri, Sep 27, 2019 at 6:37 PM Anthony Skjellum via mpi-forum < mpi-forum(a)lists.mpi-forum.org> wrote: > Rolf let’s open a Ticket > > Anthony Skjellum, PhD > 205-807-4968 > > > > On Sep 27, 2019, at 6:09 PM, Rolf Rabenseifner via mpi-forum < > mpi-forum(a)lists.mpi-forum.org> wrote: > > > > Dear MPI collective WG, > > > > you may try to resolve the problem with a maybe wrong > > MPI specification for MPI_NEIGHBOR_ALLTOALL/ALLGATHER > > > > Dear MPI Forum member, > > > > you may own/use an MPI implementation that implements > > MPI_NEIGHBOR_ALLTOALL/ALLGATHER > > with race conditions if #nprocs in one dimension is > > only 1 or 2 and periodic==true > > > > The problem was reported as a bug of the OpenMPI library > > by Simone Chiochetti from DICAM at the University of Trento, > > but seems to be a bug in the MPI specification, > > or at least an advice to implementors is missing. > > > > I produced a set of animated slides. > > Please look at them in presentation mode with animation. > > > > Have fun with a problem that clearly prevents the use > > of MPI_NEIGHBOR_... routines with cyclic boundary condition > > if one wants to verify that mpirun -np 1 is doing > > the same as the sequential code. > > > > Best regards > > Rolf > > > > -- > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . > > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 . > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 . > > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner . > > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) . > > <neighbor_mpi-3_bug.pptx> > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > -- Anthony Skjellum, PhD skjellum(a)gmail.com Cell: +1-205-807-4968

1 0

Re: [Mpi-forum] Error/gap in MPI_NEIGHBOR_ALLTOALL/ALLGATHER
by Skjellum, Anthony 28 Sep '19

28 Sep '19

May iI open and assign to you preliminarily for at least the background and issue discussion (from emails) if not the solution? You are welcome to pose the solution too, but you know, that's not required to get us started 🙂 Anthony Skjellum, PhD Professor of Computer Science and Chair of Excellence Director, SimCenter University of Tennessee at Chattanooga (UTC) tony-skjellum(a)utc.edu [or skjellum(a)gmail.com] cell: 205-807-4968 ________________________________ From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org> on behalf of Rolf Rabenseifner via mpi-forum <mpi-forum(a)lists.mpi-forum.org> Sent: Saturday, September 28, 2019 3:53 AM To: Anthony Skjellum <skjellum(a)auburn.edu> Cc: Rolf Rabenseifner <rabenseifner(a)hlrs.de>; Main MPI Forum mailing list <mpi-forum(a)lists.mpi-forum.org>; Simone Chiocchetti <simone.chiocchetti(a)unitn.it>; MPI-3 Collective Subgroup Discussions <mpiwg-coll(a)lists.mpi-forum.org> Subject: Re: [Mpi-forum] Error/gap in MPI_NEIGHBOR_ALLTOALL/ALLGATHER Yes, if after seven years of MPI_NEIGHBOR_ALLTOALL, neither the user know whether their MPI library is wrong nor all implementors are sure how to implement this routine for 1 or 2 processes in cyclic Cartesian direction, then some wording is missing in the MPI standard. Best regards Rolf ----- Anthony Skjellum <skjellum(a)auburn.edu> wrote: > Rolf let’s open a Ticket > > Anthony Skjellum, PhD > 205-807-4968 > > > > On Sep 27, 2019, at 6:09 PM, Rolf Rabenseifner via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > > > Dear MPI collective WG, > > > > you may try to resolve the problem with a maybe wrong > > MPI specification for MPI_NEIGHBOR_ALLTOALL/ALLGATHER > > > > Dear MPI Forum member, > > > > you may own/use an MPI implementation that implements > > MPI_NEIGHBOR_ALLTOALL/ALLGATHER > > with race conditions if #nprocs in one dimension is > > only 1 or 2 and periodic==true > > > > The problem was reported as a bug of the OpenMPI library > > by Simone Chiochetti from DICAM at the University of Trento, > > but seems to be a bug in the MPI specification, > > or at least an advice to implementors is missing. > > > > I produced a set of animated slides. > > Please look at them in presentation mode with animation. > > > > Have fun with a problem that clearly prevents the use > > of MPI_NEIGHBOR_... routines with cyclic boundary condition > > if one wants to verify that mpirun -np 1 is doing > > the same as the sequential code. > > > > Best regards > > Rolf > > > > -- > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . > > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 . > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 . > > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner<http://www.hlrs.de/people/rabenseifner> . > > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) . > > <neighbor_mpi-3_bug.pptx> > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 . University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 . Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner<http://www.hlrs.de/people/rabenseifner> . Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) . _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0

Re: [Mpi-forum] Error/gap in MPI_NEIGHBOR_ALLTOALL/ALLGATHER
by Rolf Rabenseifner 28 Sep '19

28 Sep '19

Yes, if after seven years of MPI_NEIGHBOR_ALLTOALL, neither the user know whether their MPI library is wrong nor all implementors are sure how to implement this routine for 1 or 2 processes in cyclic Cartesian direction, then some wording is missing in the MPI standard. Best regards Rolf ----- Anthony Skjellum <skjellum(a)auburn.edu> wrote: > Rolf let’s open a Ticket > > Anthony Skjellum, PhD > 205-807-4968 > > > > On Sep 27, 2019, at 6:09 PM, Rolf Rabenseifner via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > > > Dear MPI collective WG, > > > > you may try to resolve the problem with a maybe wrong > > MPI specification for MPI_NEIGHBOR_ALLTOALL/ALLGATHER > > > > Dear MPI Forum member, > > > > you may own/use an MPI implementation that implements > > MPI_NEIGHBOR_ALLTOALL/ALLGATHER > > with race conditions if #nprocs in one dimension is > > only 1 or 2 and periodic==true > > > > The problem was reported as a bug of the OpenMPI library > > by Simone Chiochetti from DICAM at the University of Trento, > > but seems to be a bug in the MPI specification, > > or at least an advice to implementors is missing. > > > > I produced a set of animated slides. > > Please look at them in presentation mode with animation. > > > > Have fun with a problem that clearly prevents the use > > of MPI_NEIGHBOR_... routines with cyclic boundary condition > > if one wants to verify that mpirun -np 1 is doing > > the same as the sequential code. > > > > Best regards > > Rolf > > > > -- > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . > > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 . > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 . > > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner . > > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) . > > <neighbor_mpi-3_bug.pptx> > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 . University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 . Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner . Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) .

1 0

Re: [Mpi-forum] Error/gap in MPI_NEIGHBOR_ALLTOALL/ALLGATHER
by Anthony Skjellum 27 Sep '19

27 Sep '19

Rolf let’s open a Ticket Anthony Skjellum, PhD 205-807-4968 > On Sep 27, 2019, at 6:09 PM, Rolf Rabenseifner via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > Dear MPI collective WG, > > you may try to resolve the problem with a maybe wrong > MPI specification for MPI_NEIGHBOR_ALLTOALL/ALLGATHER > > Dear MPI Forum member, > > you may own/use an MPI implementation that implements > MPI_NEIGHBOR_ALLTOALL/ALLGATHER > with race conditions if #nprocs in one dimension is > only 1 or 2 and periodic==true > > The problem was reported as a bug of the OpenMPI library > by Simone Chiochetti from DICAM at the University of Trento, > but seems to be a bug in the MPI specification, > or at least an advice to implementors is missing. > > I produced a set of animated slides. > Please look at them in presentation mode with animation. > > Have fun with a problem that clearly prevents the use > of MPI_NEIGHBOR_... routines with cyclic boundary condition > if one wants to verify that mpirun -np 1 is doing > the same as the sequential code. > > Best regards > Rolf > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 . > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 . > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner . > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) . > <neighbor_mpi-3_bug.pptx> > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0

Error/gap in MPI_NEIGHBOR_ALLTOALL/ALLGATHER
by Rolf Rabenseifner 27 Sep '19

27 Sep '19

Dear MPI collective WG, you may try to resolve the problem with a maybe wrong MPI specification for MPI_NEIGHBOR_ALLTOALL/ALLGATHER Dear MPI Forum member, you may own/use an MPI implementation that implements MPI_NEIGHBOR_ALLTOALL/ALLGATHER with race conditions if #nprocs in one dimension is only 1 or 2 and periodic==true The problem was reported as a bug of the OpenMPI library by Simone Chiochetti from DICAM at the University of Trento, but seems to be a bug in the MPI specification, or at least an advice to implementors is missing. I produced a set of animated slides. Please look at them in presentation mode with animation. Have fun with a problem that clearly prevents the use of MPI_NEIGHBOR_... routines with cyclic boundary condition if one wants to verify that mpirun -np 1 is doing the same as the sequential code. Best regards Rolf -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 . University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 . Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner . Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) .

1 0

Re: [Mpi-forum] FYI 10am Eastern meeting today--Topic: Partitioned Comms---
by Skjellum, Anthony 25 Sep '19

25 Sep '19

The meeting of persistence WG on partitioned comms is confirmed for 10am Eastern today via zoom: https://tennessee.zoom.us/j/9916910516 Also sent Forum wide, as requested. Thanks, Tony [https://d24cgw3uvb9a9h.cloudfront.net/static/93679/image/thumb.png]<https://tennessee.zoom.us/j/9916910516> Join our Cloud HD Video Meeting now<https://tennessee.zoom.us/j/9916910516> Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference room solution used around the world in board, conference, huddle, and training rooms, as well as executive offices and classrooms. Founded in 2011, Zoom helps businesses and organizations bring their teams together in a frictionless environment to get more done. Zoom is a publicly traded company headquartered in San Jose, CA. tennessee.zoom.us Here is the full invite: Hi there, Anthony Skjellum is inviting you to a scheduled Zoom meeting. Topic: Anthony Skjellum's Personal Meeting Room Join from PC, Mac, Linux, iOS or Android: https://tennessee.zoom.us/j/9916910516 Or iPhone one-tap (US Toll): +16468769923,9916910516# or +16699006833,9916910516# Or Telephone: Dial: +1 646 876 9923 (US Toll) +1 669 900 6833 (US Toll) Meeting ID: 991 691 0516 International numbers available: https://zoom.us/u/acVk33oBeV Or an H.323/SIP room system: H.323: 162.255.37.11 (US West) or 162.255.36.11 (US East) Meeting ID: 991 691 0516 SIP: 9916910516(a)zoomcrc.com Thanks, Tony Anthony Skjellum, PhD Professor of Computer Science and Chair of Excellence Director, SimCenter University of Tennessee at Chattanooga (UTC) tony-skjellum(a)utc.edu [or skjellum(a)gmail.com] cell: 205-807-4968 ________________________________ From: Skjellum, Anthony Sent: Wednesday, September 25, 2019 8:08 AM To: mpiwg-persistence(a)lists.mpi-forum.org <mpiwg-persistence(a)lists.mpi-forum.org> Cc: Martin Schulz <schulzm(a)in.tum.de> Subject: FYI 10am Eastern meeting today--Topic: Partitioned Comms--- Hi, I am presently verifying that Ryan Grant is available to continue our efforts to finalize the Partitioned Comms. chapter and ticket for the December meeting. Once verified, I will also alert the entire forum, as requested by Martin Schulz. Thanks, Tony Anthony Skjellum, PhD Professor of Computer Science and Chair of Excellence Director, SimCenter University of Tennessee at Chattanooga (UTC) tony-skjellum(a)utc.edu [or skjellum(a)gmail.com] cell: 205-807-4968

1 0

No Virtual Meeting this week - please join the WG calls
by Martin Schulz 24 Sep '19

24 Sep '19

Hi all, We will have no virtual meeting call this week. However, some of the working groups responsible for the major tickets (HW topology, Semantics, BigCounts) are meeting this week, some close to the original time of the virtual meeting. If you have any comments on these tickets, please consider joining the respective WG call. I have asked the respective chairs to post the call announcements to the whole list. Thanks! Martin — Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ) Email: schulzm(a)in.tum.de

1 0

Hardware Topologies WG meeting tomorrow
by Guillaume Mercier 24 Sep '19

24 Sep '19

Hi all, A Telecon for the Hardware Topologies Working Group is scheduled tomorrow at 10am/GMT+2. Connection details are available on the WG's wiki: https://github.com/mpiwg-hw-topology/hw-topology-issues/wiki (see the link at the top of page). We'll mainly discuss the text for the guided mode of MPI_Comm_split_type with MPI_COMM_TYPE_HW_SUBDOMAIN and the query function for the implementation-defined names. Cheers, Guillaume

1 0

MPI Sessions - final (hopefully) changes (for MPI-4.0 anyway)
by HOLMES Daniel 19 Sep '19

19 Sep '19

Hi all, In the virtual meeting yesterday, I presented a first draft of new text to clarify the number of process sets in the Sessions proposal, in a manner following the precedent in the Tools chapter concerning the number of control/performance variables. However, there were very few attendees and I’d like a broader audience to see the proposed text to capture any objections or suggestions as soon as possible. I include the relevant Github diff below for your delectation. Note that we are deliberately punting on the whole idea of dynamic process sets (sets that change size or content at runtime) at this stage. Making process sets immutable leads to the creation of new process sets to reflect changes, which could lead to a long list of process sets, which could lead to resource exhaustion in the worst case. We discussed this in the virtual meeting; I outlined an idea to add a new function in a future proposal that would prune the list of process sets, e.g. MPI_Session_prune_psets. This avoids many of the race-conditions inherent in modifying a global iterator concurrently with usage of that iterator. That is, it delegates responsibility to the user to determine when it is safe to reduce the length of (and/or re-order the contents of) the list of process sets. We believe that the current proposed text is sufficient for Sessions 1.0, i.e. for MPI-4.0, and that we can add future extensions to achieve Sessions 2.0 without breaking the stuff in Sessions 1.0. Please scrutinise this part of the Sessions proposal one more time and let us (Howard and myself) know about any concerns/issues you have. Thanks! <https://github.com/mpiwg-sessions/mpi-standard/pull/37/files#diff-3f00f80f9…> @@ -956,7 +956,15 @@ \subsection{Runtime Query Functions} \mpifnewbind{MPI\_Session\_get\_num\_psets(session, npset\_names, ierror) \fargs TYPE(MPI\_Session), INTENT(IN) :: session \\ INTEGER, INTENT(OUT) :: npset\_names \\ INTEGER, OPTIONAL, INTENT(OUT) :: ierror} \mpifbind{MPI\_SESSION\_GET\_NUM\_PSETS(SESSION, NPSET\_NAMES, IERROR) \fargs INTEGER SESSION, NPSET\_NAMES, IERROR} This function is used to query the runtime for the number of available process sets in which the calling \MPI/ process is a member. The number of available process sets returned by this function may increase with subsequent calls to \mpifunc{MPI\_SESSION\_GET\_NUM\_PSETS}, but will not decrease. This function is used to query the runtime for the number of available process sets in which the calling \MPI/ process is a member. An \MPI/ implementation is allowed to increase the number of available process sets during the execution of an \MPI/ application when new process sets become available. However, \MPI/ implementations are not allowed to change the index of a particular process set name or to delete a process set name once it has been added. When a process set becomes invalid, for example, when some processes become unreachable due to failures in the communication system, subsequent usage of the process set name should return an appropriate error code. % [DAN] possibly advice to users for the next sentence? For example, creating an \const{MPI\_Group} from such a process set might succeed because it is a local operation, but creating an \const{MPI_Comm} from that group and attempting collective communication should return an appropriate error code. % Cheers, Dan. — Dr Daniel Holmes PhD Architect (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

Re: [Mpi-forum] Virtual Meetings for the MPI Forum
by schulzm＠in.tum.de 18 Sep '19

18 Sep '19

Hi Marc-Andre, Thanks for catching this - I indeed meant in “NO particular order”. I think this will depend on how much time we have left in the virtual meetings and where the working groups had been able to make independent progress. Thanks, Martin — Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ) Email: schulzm(a)in.tum.de > On 17. Sep 2019, at 10:20, Hermanns, Marc-André via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > Hi Martin, > > did you mean "in *no* particular order" or actually as you wrote "in particular order", which then would send HW Split Type below Partitioned Communication (which I think is not what we discussed, right?). > > Cheers, > Marc-Andre > > -- > Dr. rer. nat. Marc-André Hermanns > > IT Center > Group: High Performance Computing > Division: Computational Science and Engineering > RWTH Aachen University > Seffenter Weg 23 > 52074 Aachen > Phone: +49 241 80-24381 > hermanns(a)itc.rwth-aachen.de > www.itc.rwth-aachen.de > > > ________________________________________ > From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org> on behalf of Martin Schulz via mpi-forum <mpi-forum(a)lists.mpi-forum.org> > Sent: 17 September 2019 00:23:34 > To: Mohror, Kathryn via mpi-forum > Cc: Martin Schulz > Subject: [Mpi-forum] Virtual Meetings for the MPI Forum > > Hi all, > > As discussed at the forum meeting in Zurich, we will again have as series of virtual meetings (at the usual time, Wednesday 10am CT) to prepare for readings in September in Albuquerque. We will schedule the topics for these meetings a bit more dynamically as usual. It would be great if as many as possible could attend these meetings (or provide feedback based on the recordings, which we will post), to avoid surprises in December. > > For the meeting this week, we will focus on new text covering the remaining major points from Sessions, the ticket covering MPI_INFO_ENV before Init, and - if there is time left - tool UIDs. > > Looking at MPI 4.0, the most anticipated/requested features (and also the ones we advertised the most) are Sessions and BigCount. Hence, the ensure that those two are ready for the December meeting, these topic will get preference in the upcoming virtual meetings, other topics will be scheduled as needed and based on availability and readiness, but we will likely run out of meeting times (we have only until SC19 before the two week deadline). We will keep a list of possible topics on the website - currently this includes (in particular order): > > - Semantics and Terms > - Partitioned Communication > - Procedures document > - HW Split Type > - Cartesian/Halo Communicators > > (If I missed one, please let me know) > > Note, though, that this doesn’t mean other topics can’t and shouldn’t make progress or can’t be ready for the December meetings. The respective WGs should try to incorporate the forum feedback and update the respective tickets. Also, if forum feedback is needed, please free to use the email list or invite others to the WG meetings. > > I hope this all makes sense - if there are any concerns, please let me know. > > Thanks! > > Martin > > > > — > Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems > Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching > Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ) > Email: schulzm(a)in.tum.de<mailto:[email protected]> > > > > > > > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0