December 2012 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] MPI_Initialized, MPI_Query_thread, MPI_Is_thread_main
by Jeff Hammond 27 Dec '12

27 Dec '12

See https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/357. It's not a proposal in the sense that I do not have a PDF demonstrating a LaTeX implementation of the suggested text changes, but I did provide in my ticket the text changes I think address this issue. Jeff On Fri, Dec 16, 2011 at 10:38 AM, Jeff Squyres <jsquyres(a)cisco.com> wrote: > +1 / good points. > > Will you make a proposal about this? > > > On Dec 16, 2011, at 10:44 AM, Jeff Hammond wrote: > >> Are MPI_Initialized and MPI_Query_thread guaranteed to be thread-safe >> by all implementations? If these MPI calls cannot be made in a fully >> multithreaded context, how can a multithreaded library determine that >> it can make MPI calls in an unrestricted fashion, i.e. determine if >> MPI was initialized with MPI_THREAD_MULTIPLE? Must the multithreaded >> library mutex around these two MPI calls and assume that >> MPI_THREAD_SERIALIZED is always available? >> >> Can MPI_Is_thread_main be called from a thread that is not main when >> only MPI_THREAD_FUNNELED is supported? I recall that the funneled >> mode stipulates that only the main thread can make MPI calls and there >> is no text excepting this routine from that constraint. >> >> Thanks, >> >> Jeff >> >> -- >> Jeff Hammond >> Argonne Leadership Computing Facility >> University of Chicago Computation Institute >> jhammond(a)alcf.anl.gov / (630) 252-5381 >> http://www.linkedin.com/in/jeffhammond >> https://wiki-old.alcf.anl.gov/index.php/User:Jhammond >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

EuroMPI 2013: Call for Papers
by Rolf Rabenseifner 20 Dec '12

20 Dec '12

Dear all, the new MPI-3.0 standard and first implementations are available. This opens the door for a lot of new and interesting research in providing and using parallel programming models. The EuroMPI 2013 may be an ideal conference for publishing your new results. Find below the early call for papers. My apologies for double postings. Merry Christmas and a Happy New Year / Season's greetings Rolf Rabenseifner ________________________________ Recent Advances in Message Passing Interface. 20th European MPI Users' Group Meeting (EuroMPI 2013) EuroMPI 2013 is being held in cooperation with SIGHPC Madrid, Spain, September 15-18, 2013 BACKGROUND AND TOPICS ----------------------- EuroMPI is the preeminent meeting for users, developers and researchers to interact and discuss new developments and applications of message-passing parallel computing, in particular in and related to the Message Passing Interface (MPI). The annual meeting has a long, rich tradition, and the 20th European MPI Users' Group Meeting will again be a lively forum for discussion of everything related to usage and implementation of MPI and other parallel programming interfaces. Traditionally, the meeting has focused on the efficient implementation of aspects of MPI, typically on high-performance computing platforms, benchmarking and tools for MPI, short-comings and extensions of MPI, parallel I/O and fault tolerance, as well as parallel applications using MPI. The meeting is open towards other topics, in particular application experience and alternative interfaces for high-performance heterogeneous, hybrid, distributed memory systems. Topics of interest include, but are not limited to: - MPI implementation issues and improvements - Extensions to and shortcomings of MPI - Tools and environments for MPI - Hybrid and heterogeneous programming with MPI and other interfaces - Relation of MPI to alternative interfaces for hybrid/heterogeneous distributed memory systems - Interaction between message-passing software and hardware, in particular new high performance architectures - Fault tolerance in message-passing implementations and systems - Performance evaluation for MPI and MPI based applications- - Automatic performance tuning of MPI applications and implementations - Verification of message passing applications and protocols - Applications using message-passing, in particular in Computational Science and Scientific Computing - Non-standard message-passing applications - Parallel algorithms in the message-passing paradigm - Algorithms using the message-passing paradigm The meeting will feature contributed talks on the selected, peer-reviewed papers, invited expert talks covering upcoming and future issues, a vendor session where selected vendors will present their new developments in hybrid and heterogeneous cluster and high-performance architectures, a poster session, and a tutorial day. The scientific part of the conference is organized in cooperation with ACM SIGHPC. Conference proceedings will be published in the ACM Digital Library, which includes short and long papers, workshop papers, and posters. Selected high quality papers will be published in an international journals. There will also be a reward for the overall best paper from the academic conference. SUBMISSION INFORMATION ----------------------- Contributors are invited to submit a full paper as a PDF document not exceeding 6 pages in English. The title page should contain an abstract of at most 100 words and five specific, topical keywords. The paper must be formatted according to double-column ACM ICPS proceedings style. The usage of LaTeX for preparation of the contribution as well as the submission in camera ready format is strongly recommended. Style files can be found at http://www.acm.org/publications/icps-instructions/. New work that is not yet mature for a full paper, short observations, and similar brief announcements are invited for the poster session. Contributions to the poster session should be submitted in the form of a two page abstract. All contributions will be fully peer reviewed by the program committee. Papers shall be submitted electronically via Easychair, see http://www.easychair.org/conferences/?conf=eurompi2013. AWARDS ------- There will be awards for the best paper and best student paper. These awards will be chosen by the program committee. The best paper award will be given to the paper judged to have the highest overall quality. SCHEDULE, IMPORTANT DATES -------------------------- - Submission of full papers and poster: March 29th, 2013 - Author notification: May 11th, 2013 - Camera Ready papers due: June 15th, 2013 - Tutorial(s): September 15th, 2012 - Conference: September 16th-18th, 2013 COMMITTEE ---------- GENERAL CHAIR Jack Dongarra, University of Tennessee, Knoxville, USA ORGANIZERS, PC CHAIRS Javier Garcia Blas, Carlos III University (fjblas(a)inf.uc3m.es) Jesus Carretero, Carlos III University (jesus.carretero(a)uc3m.es) PROGRAM COMMITTEE Pavan Balaji, Argonne National Laboratory Siegfried Benkner, University of Vienna George Bosilca, Innovative Computing Laboratory - University of Tennessee Gil Bloch, Mellanox Technologies Ron Brightwell, Sandia National Laboratories Darius Buntinas, Argonne National Laboratory Franck Cappello, INRIA and University of Illinois at Urbana-Champaign Yiannis Cotronis, National and Kapodistrian University of Athens Chi-Yin Chow, Department of Computer Science, City University of Hong Kong Anthony Danalis, University of Tennessee Luiz Derose, Cray Christian Engelmann, Oak Ridge National Laboratory Edgar Gabriel, University of Houston Brice Goglin, INRIA Ganesh Gopalakrishnan, University of Utah David Goodell, Argonne National Laboratory Richard Graham, Oak Ridge National Laboratory William Gropp, University of Illinois at Urbana-Champaign Rainer Keller, HFT Stuttgart, University of Applied Science Julian Kunkel, University of Hamburg Thomas Herault, University of Tennessee Bronis De Supinski, Lawrence Livermore National Laboratory Thomas Ludwig, German Climate Computing Center and University of Hamburg David E. Singh, University Carlos III of Madrid Torsten Hoefler, ETH Zurich Atsushi Hori, RIKEN AICS Florin Isaila, University Carlos III of Madrid Akihiro Inokuchi, Osaka University Yutaka Ishikawa, Graduate School of Information Science and Technology / Information Technology Center, The University of Tokyo Emmanuel Jeannot, INRIA Dries Kimpe, Argonne National Laboratory Jesper Larsson Traeff, Vienna University of Technolog Alexey Lastovetsky, UCD School of Computer Science & Informatics Laurent Lefevre, INRIA Dong Li, Oak Rdige National Lab Ewing Lusk, Argonne National Laboratory Guillaume Mercier, ENSEIRB/INRIA Bernd Mohr, Juelich Supercomputing Center Raffaele Montella, Department of Applied Science - University of Naples Parthenope Matthias Mueller, ZIH, TU Dresden Jose Nelson Amaral, University of Alberta Jaechun No, Sejong University Maria S. Perez, Technical University of Madrid Rolf Rabenseifner, HLRS, University of Stuttgart Rolf Riesen, IBM Gudula Ruenge Chemnitz University of Technology Mitsuhisa Sato, University of Tsukuba Christian Siebert, RWTH Aachen University Anna Sikora, DACSO - UAB Shinji Sumimoto, Fujitsu Laboratories FrC)dC)ric Suter, IN2P3 Computing Center Jeff Squyres, Cisco Alexander Supalov, Intel GmbH Domenico Talia, Universita della Calabria Vinod Tipparaju, AMD Rajeev Thakur, Argonne National Laboratory Carsten Trinitis, University of Bedfordshire Yuichi Tsujita, Kinki University Denis Trystram, Grenoble university Keith Underwood, Intel Alan Wagner, University of British Columbia Roland Wismueller, University of Siegen Roman Wyrzykowski, Czestochowa University of Technology Xin Yuan, Flroida State University CONFERENCE FEES ---------------- The conference will hopefully be well supported by sponsors, which will help directly towards keeping the fees low. As far as possible, special student fees will be offered.

1 0

Re: [Mpi-forum] Communicator info arguments
by Pavan Balaji 07 Dec '12

07 Dec '12

Aha, yes. Sorry, I missed that earlier. -- Pavan On 12/07/2012 04:33 PM US Central Time, Jeff Hammond wrote: > In 6.4.4, I find this: > > "Info hints are not propagated by MPI from one communicator to another > except when the communicator is duplicated using MPI_COMM_DUP or > MPI_COMM_IDUP. In this case, all hints associated with the original > communicator are also applied to the duplicated communicator." > > I think this resolves any ambiguity. > > Jeff > > On Fri, Dec 7, 2012 at 4:13 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: >> >> Right. I'm trying to understand what the intention was. >> >> The intention stated at the Forum might not be accurate. >> >> Either way, it needs to be stated in the standard, what the application >> should expect. >> >> -- Pavan >> >> On 12/07/2012 04:11 PM US Central Time, Jeff Hammond wrote: >>> Okay, sorry, I didn't understand your question properly. >>> >>> I think your example of intercomm_merge indicates that propagating >>> info with functions other than dup is problematic and probably not >>> easily specified. The safest thing to do is to say that they do not >>> propagate. >>> >>> Jeff >>> >>> On Fri, Dec 7, 2012 at 4:04 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: >>>> >>>> My question was for the other communicator creation functions. >>>> Specifically, Comm_split in my query below. >>>> >>>> -- Pavan >>>> >>>> On 12/07/2012 04:01 PM US Central Time, Jeff Hammond wrote: >>>>> >From MPI-3 6.4.2 (MPI_COMM_DUP): >>>>> >>>>> "MPI_COMM_DUP duplicates the existing communicator comm with the >>>>> associated key values, topology information and info hints." >>>>> >>>>> "MPI_COMM_DUP_WITH_INFO behaves exactly as MPI_COMM_DUP except that >>>>> the info hints associated with the communicator comm are not >>>>> duplicated in newcomm. The hints provided by the arguments info are >>>>> associated with the output communicator newcomm instead." >>>>> >>>>> Jeff >>>>> >>>>> On Fri, Dec 7, 2012 at 3:56 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: >>>>>> >>>>>> Apologies if this query needs to go a specific working group. I wasn't >>>>>> sure which one, so I'm sending it to the overall mailing list. >>>>>> >>>>>> If a communicator is created using MPI_COMM_DUP_WITH_INFO, is the info >>>>>> argument "sticky" to all child communicators? That is, if I split the >>>>>> output communicator further, will the info argument propagate? >>>>>> >>>>>> Adam said that it would, at the Forum, but that doesn't seem accurate, >>>>>> since that'll get weird if I do an Intercomm_merge with two >>>>>> communicators, one of which has an info argument and the second does not. >>>>>> >>>>>> I couldn't find text saying one way or another in the document. >>>>>> >>>>>> -- Pavan >>>>>> >>>>>> -- >>>>>> Pavan Balaji >>>>>> http://www.mcs.anl.gov/~balaji >>>>>> _______________________________________________ >>>>>> mpi-forum mailing list >>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Pavan Balaji >>>> http://www.mcs.anl.gov/~balaji >>> >>> >>> >> >> -- >> Pavan Balaji >> http://www.mcs.anl.gov/~balaji > > > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi-forum] Communicator info arguments
by Jeff Hammond 07 Dec '12

07 Dec '12

In 6.4.4, I find this: "Info hints are not propagated by MPI from one communicator to another except when the communicator is duplicated using MPI_COMM_DUP or MPI_COMM_IDUP. In this case, all hints associated with the original communicator are also applied to the duplicated communicator." I think this resolves any ambiguity. Jeff On Fri, Dec 7, 2012 at 4:13 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > Right. I'm trying to understand what the intention was. > > The intention stated at the Forum might not be accurate. > > Either way, it needs to be stated in the standard, what the application > should expect. > > -- Pavan > > On 12/07/2012 04:11 PM US Central Time, Jeff Hammond wrote: >> Okay, sorry, I didn't understand your question properly. >> >> I think your example of intercomm_merge indicates that propagating >> info with functions other than dup is problematic and probably not >> easily specified. The safest thing to do is to say that they do not >> propagate. >> >> Jeff >> >> On Fri, Dec 7, 2012 at 4:04 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: >>> >>> My question was for the other communicator creation functions. >>> Specifically, Comm_split in my query below. >>> >>> -- Pavan >>> >>> On 12/07/2012 04:01 PM US Central Time, Jeff Hammond wrote: >>>> >From MPI-3 6.4.2 (MPI_COMM_DUP): >>>> >>>> "MPI_COMM_DUP duplicates the existing communicator comm with the >>>> associated key values, topology information and info hints." >>>> >>>> "MPI_COMM_DUP_WITH_INFO behaves exactly as MPI_COMM_DUP except that >>>> the info hints associated with the communicator comm are not >>>> duplicated in newcomm. The hints provided by the arguments info are >>>> associated with the output communicator newcomm instead." >>>> >>>> Jeff >>>> >>>> On Fri, Dec 7, 2012 at 3:56 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: >>>>> >>>>> Apologies if this query needs to go a specific working group. I wasn't >>>>> sure which one, so I'm sending it to the overall mailing list. >>>>> >>>>> If a communicator is created using MPI_COMM_DUP_WITH_INFO, is the info >>>>> argument "sticky" to all child communicators? That is, if I split the >>>>> output communicator further, will the info argument propagate? >>>>> >>>>> Adam said that it would, at the Forum, but that doesn't seem accurate, >>>>> since that'll get weird if I do an Intercomm_merge with two >>>>> communicators, one of which has an info argument and the second does not. >>>>> >>>>> I couldn't find text saying one way or another in the document. >>>>> >>>>> -- Pavan >>>>> >>>>> -- >>>>> Pavan Balaji >>>>> http://www.mcs.anl.gov/~balaji >>>>> _______________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> >>>> >>>> >>> >>> -- >>> Pavan Balaji >>> http://www.mcs.anl.gov/~balaji >> >> >> > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [Mpi-forum] Communicator info arguments
by Pavan Balaji 07 Dec '12

07 Dec '12

Right. I'm trying to understand what the intention was. The intention stated at the Forum might not be accurate. Either way, it needs to be stated in the standard, what the application should expect. -- Pavan On 12/07/2012 04:11 PM US Central Time, Jeff Hammond wrote: > Okay, sorry, I didn't understand your question properly. > > I think your example of intercomm_merge indicates that propagating > info with functions other than dup is problematic and probably not > easily specified. The safest thing to do is to say that they do not > propagate. > > Jeff > > On Fri, Dec 7, 2012 at 4:04 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: >> >> My question was for the other communicator creation functions. >> Specifically, Comm_split in my query below. >> >> -- Pavan >> >> On 12/07/2012 04:01 PM US Central Time, Jeff Hammond wrote: >>> >From MPI-3 6.4.2 (MPI_COMM_DUP): >>> >>> "MPI_COMM_DUP duplicates the existing communicator comm with the >>> associated key values, topology information and info hints." >>> >>> "MPI_COMM_DUP_WITH_INFO behaves exactly as MPI_COMM_DUP except that >>> the info hints associated with the communicator comm are not >>> duplicated in newcomm. The hints provided by the arguments info are >>> associated with the output communicator newcomm instead." >>> >>> Jeff >>> >>> On Fri, Dec 7, 2012 at 3:56 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: >>>> >>>> Apologies if this query needs to go a specific working group. I wasn't >>>> sure which one, so I'm sending it to the overall mailing list. >>>> >>>> If a communicator is created using MPI_COMM_DUP_WITH_INFO, is the info >>>> argument "sticky" to all child communicators? That is, if I split the >>>> output communicator further, will the info argument propagate? >>>> >>>> Adam said that it would, at the Forum, but that doesn't seem accurate, >>>> since that'll get weird if I do an Intercomm_merge with two >>>> communicators, one of which has an info argument and the second does not. >>>> >>>> I couldn't find text saying one way or another in the document. >>>> >>>> -- Pavan >>>> >>>> -- >>>> Pavan Balaji >>>> http://www.mcs.anl.gov/~balaji >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> >>> >>> >> >> -- >> Pavan Balaji >> http://www.mcs.anl.gov/~balaji > > > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi-forum] Communicator info arguments
by Jeff Hammond 07 Dec '12

07 Dec '12

Okay, sorry, I didn't understand your question properly. I think your example of intercomm_merge indicates that propagating info with functions other than dup is problematic and probably not easily specified. The safest thing to do is to say that they do not propagate. Jeff On Fri, Dec 7, 2012 at 4:04 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > My question was for the other communicator creation functions. > Specifically, Comm_split in my query below. > > -- Pavan > > On 12/07/2012 04:01 PM US Central Time, Jeff Hammond wrote: >>>From MPI-3 6.4.2 (MPI_COMM_DUP): >> >> "MPI_COMM_DUP duplicates the existing communicator comm with the >> associated key values, topology information and info hints." >> >> "MPI_COMM_DUP_WITH_INFO behaves exactly as MPI_COMM_DUP except that >> the info hints associated with the communicator comm are not >> duplicated in newcomm. The hints provided by the arguments info are >> associated with the output communicator newcomm instead." >> >> Jeff >> >> On Fri, Dec 7, 2012 at 3:56 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: >>> >>> Apologies if this query needs to go a specific working group. I wasn't >>> sure which one, so I'm sending it to the overall mailing list. >>> >>> If a communicator is created using MPI_COMM_DUP_WITH_INFO, is the info >>> argument "sticky" to all child communicators? That is, if I split the >>> output communicator further, will the info argument propagate? >>> >>> Adam said that it would, at the Forum, but that doesn't seem accurate, >>> since that'll get weird if I do an Intercomm_merge with two >>> communicators, one of which has an info argument and the second does not. >>> >>> I couldn't find text saying one way or another in the document. >>> >>> -- Pavan >>> >>> -- >>> Pavan Balaji >>> http://www.mcs.anl.gov/~balaji >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> >> > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [Mpi-forum] Communicator info arguments
by Pavan Balaji 07 Dec '12

07 Dec '12

My question was for the other communicator creation functions. Specifically, Comm_split in my query below. -- Pavan On 12/07/2012 04:01 PM US Central Time, Jeff Hammond wrote: >>From MPI-3 6.4.2 (MPI_COMM_DUP): > > "MPI_COMM_DUP duplicates the existing communicator comm with the > associated key values, topology information and info hints." > > "MPI_COMM_DUP_WITH_INFO behaves exactly as MPI_COMM_DUP except that > the info hints associated with the communicator comm are not > duplicated in newcomm. The hints provided by the arguments info are > associated with the output communicator newcomm instead." > > Jeff > > On Fri, Dec 7, 2012 at 3:56 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: >> >> Apologies if this query needs to go a specific working group. I wasn't >> sure which one, so I'm sending it to the overall mailing list. >> >> If a communicator is created using MPI_COMM_DUP_WITH_INFO, is the info >> argument "sticky" to all child communicators? That is, if I split the >> output communicator further, will the info argument propagate? >> >> Adam said that it would, at the Forum, but that doesn't seem accurate, >> since that'll get weird if I do an Intercomm_merge with two >> communicators, one of which has an info argument and the second does not. >> >> I couldn't find text saying one way or another in the document. >> >> -- Pavan >> >> -- >> Pavan Balaji >> http://www.mcs.anl.gov/~balaji >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi-forum] Communicator info arguments
by Jeff Hammond 07 Dec '12

07 Dec '12

>From MPI-3 6.4.2 (MPI_COMM_DUP): "MPI_COMM_DUP duplicates the existing communicator comm with the associated key values, topology information and info hints." "MPI_COMM_DUP_WITH_INFO behaves exactly as MPI_COMM_DUP except that the info hints associated with the communicator comm are not duplicated in newcomm. The hints provided by the arguments info are associated with the output communicator newcomm instead." Jeff On Fri, Dec 7, 2012 at 3:56 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > Apologies if this query needs to go a specific working group. I wasn't > sure which one, so I'm sending it to the overall mailing list. > > If a communicator is created using MPI_COMM_DUP_WITH_INFO, is the info > argument "sticky" to all child communicators? That is, if I split the > output communicator further, will the info argument propagate? > > Adam said that it would, at the Forum, but that doesn't seem accurate, > since that'll get weird if I do an Intercomm_merge with two > communicators, one of which has an info argument and the second does not. > > I couldn't find text saying one way or another in the document. > > -- Pavan > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Communicator info arguments
by Pavan Balaji 07 Dec '12

07 Dec '12

Apologies if this query needs to go a specific working group. I wasn't sure which one, so I'm sending it to the overall mailing list. If a communicator is created using MPI_COMM_DUP_WITH_INFO, is the info argument "sticky" to all child communicators? That is, if I split the output communicator further, will the info argument propagate? Adam said that it would, at the Forum, but that doesn't seem accurate, since that'll get weird if I do an Intercomm_merge with two communicators, one of which has an info argument and the second does not. I couldn't find text saying one way or another in the document. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

MPI- Next
by Richard Graham 05 Dec '12

05 Dec '12

At this week's meeting we have started to get organized for MPI-Next (still need to decide on what it is called). The administrative roles are: Chair: Martin Schulz Secretary: Jeff Squyres Hosts: dependent on location Convener: Rich Graham We also put together a small group that will put a first cut at defining a steering committee: (not all are aware they are on this, so can decline) Rich Graham Bill Gropp Martin Schulz Brian Barrett Dave Goodell Tony Skjellum Rich

1 0