- devel - mailman3.cels.anl.gov

Re: [mpich-devel] find out what processes are on the same node
by Jeff Hammond 03 Jul '13

03 Jul '13

https://wiki.alcf.anl.gov/parts/index.php/Implementing_a_Symmetric_Heap has an implementation of MPE_Comm_split_node that does a very simple O(Nproc) implementation of MPI_Comm_split_type(type=SHARED) using MPI_Get_processor_name. It also shows the non-portable implementation for Cray and Blue Gene that one can use until MPI-3 is deployed on those systems. Jim Dinan wrote an O(log Nproc) implementation of MPI_Comm_split_type(type=SHARED) that I have somewhere but I don't like it because it's confusing to my small brain. Jeff ----- Original Message ----- From: "Rob Latham" <robl(a)mcs.anl.gov> To: devel(a)mpich.org Sent: Wednesday, July 3, 2013 10:53:15 AM Subject: Re: [mpich-devel] find out what processes are on the same node On Wed, Jul 03, 2013 at 10:39:55AM -0500, Tatiana V. Martsinkevich wrote: > Hello, > > I have a couple of questions: > > 1) is there a way to find out what other processes reside in the same > node as my_rank from within MPICH? MPI_GET_PROCESSOR_NAME might be what you are looking for. ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA -- 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 ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

Re: [mpich-devel] find out what processes are on the same node
by Rob Latham 03 Jul '13

03 Jul '13

On Wed, Jul 03, 2013 at 10:39:55AM -0500, Tatiana V. Martsinkevich wrote: > Hello, > > I have a couple of questions: > > 1) is there a way to find out what other processes reside in the same > node as my_rank from within MPICH? MPI_GET_PROCESSOR_NAME might be what you are looking for. ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] find out what processes are on the same node
by Jeff Hammond 03 Jul '13

03 Jul '13

Check out the new MPI-3 function MPI_Comm_split_type that is supported by MPICH-3. Best, Jeff ----- Original Message ----- From: "Tatiana V. Martsinkevich" <tanya.manekineko(a)gmail.com> To: devel(a)mpich.org Sent: Wednesday, July 3, 2013 10:39:55 AM Subject: [mpich-devel] find out what processes are on the same node Hello, I have a couple of questions: 1) is there a way to find out what other processes reside in the same node as my_rank from within MPICH? I found this function: MPIR_Comm_is_node_aware(comm_ptr) and if it's true I can get access (although not always?) to comm_ptr->node_comm. I wonder what are the situations when I won't be able to know what processes are on the same node ( i.e. comm_ptr->node_comm is null) and is there any other way to get the info then? 2) MPIR_Comm_is_node_aware() returns true if comm->hierarchy_kind == MPID_HIERARCHY_PARENT and apparently there are the following hierarchies: /* flat, parent, node, or node_roots */ Could someone please explain what are each of the hierarchy? regards, -- Tatiana V. Martsinkevich PhD student INRIA Saclay, University of Paris Sud XI -- 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 ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

find out what processes are on the same node
by Tatiana V. Martsinkevich 03 Jul '13

03 Jul '13

Hello, I have a couple of questions: 1) is there a way to find out what other processes reside in the same node as my_rank from within MPICH? I found this function: MPIR_Comm_is_node_aware(comm_ptr) and if it's true I can get access (although not always?) to comm_ptr->node_comm. I wonder what are the situations when I won't be able to know what processes are on the same node ( i.e. comm_ptr->node_comm is null) and is there any other way to get the info then? 2) MPIR_Comm_is_node_aware() returns true if comm->hierarchy_kind == MPID_HIERARCHY_PARENT and apparently there are the following hierarchies: /* flat, parent, node, or node_roots */ Could someone please explain what are each of the hierarchy? regards, -- Tatiana V. Martsinkevich PhD student INRIA Saclay, University of Paris Sud XI

1 0

Re: [mpich-devel] ./autogen.sh refuses to believe 2.69>2.67
by Jeff Hammond 12 Jun '13

12 Jun '13

Indeed, it is indicative of an installation on a cross-mounted filesystem where the user is foolishly trying to use autotools built in a PPC64 environment within an x86_64 one. Sorry for being stupid. Jeff On Wed, Jun 12, 2013 at 12:42 PM, David Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: > This situation is usually a symptom of some underlying autoconf/autotools configuration problem (like a busted m4 install or 32-/64-bit compat issue). For some reason the sanity check before looking for a specific version is either very weak or missing (I can't remember off the top of my head). > > Also, make sure that 2.69 is a known version to the script (though I think it is). > > -Dave > > On Jun 12, 2013, at 12:24 PM, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > >> Any suggestions? >> >> Jeff >> >> [jhammond@login1 git]$ ./autogen.sh >> >> #################################### >> ## Replicating confdb (and similar) >> #################################### >> >> syncing 'src/mpl' --> 'src/pm/hydra/mpl' >> syncing 'confdb' --> 'src/mpi/romio/confdb' >> syncing 'confdb' --> 'src/mpl/confdb' >> syncing 'confdb' --> 'src/pm/hydra/confdb' >> syncing 'confdb' --> 'src/pm/hydra/mpl/confdb' >> syncing 'confdb' --> 'test/mpi/confdb' >> syncing 'confdb' --> 'src/armci/m4' >> >> #################################### >> ## Checking user environment >> #################################### >> >> Verifying the location of autogen.sh... done >> Checking if autotools are in the same location... yes, all in >> /home/jhammond/TOOLS >> Checking for autoconf version... bad autoconf installation >> You either do not have autoconf in your path or it is too old (version >> 2.67 or higher required). You may be able to use >> >> autoconf --version >> >> Unfortunately, there is no standard format for the version output and >> it changes between autotools versions. In addition, some versions of >> autoconf choose among many versions and provide incorrect output). >> >> [jhammond@login1 git]$ autoconf --version >> autoconf (GNU Autoconf) 2.69 >> Copyright (C) 2012 Free Software Foundation, Inc. >> License GPLv3+/Autoconf: GNU GPL version 3 or later >> <http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. >> >> Written by David J. MacKenzie and Akim Demaille. >> >> -- >> 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 >> ALCF docs: http://www.alcf.anl.gov/user-guides > -- 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 ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

Re: [mpich-devel] ./autogen.sh refuses to believe 2.69>2.67
by Antonio J. Peña 12 Jun '13

12 Jun '13

I'm using 2.69 as well without problems. On Wednesday, June 12, 2013 12:32:00 PM Wesley Bland wrote: > I'm running 2.69 on my machine as well and am not having any problems. Does > autogen have some log that I'm unaware of? You could always tell it to > leave you alone with -atvercheck=no, but that's probably not the right > answer. > > Wesley > > On Jun 12, 2013, at 12:24 PM, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > > Any suggestions? > > > > Jeff > > > > [jhammond@login1 git]$ ./autogen.sh > > > > #################################### > > ## Replicating confdb (and similar) > > #################################### > > > > syncing 'src/mpl' --> 'src/pm/hydra/mpl' > > syncing 'confdb' --> 'src/mpi/romio/confdb' > > syncing 'confdb' --> 'src/mpl/confdb' > > syncing 'confdb' --> 'src/pm/hydra/confdb' > > syncing 'confdb' --> 'src/pm/hydra/mpl/confdb' > > syncing 'confdb' --> 'test/mpi/confdb' > > syncing 'confdb' --> 'src/armci/m4' > > > > #################################### > > ## Checking user environment > > #################################### > > > > Verifying the location of autogen.sh... done > > Checking if autotools are in the same location... yes, all in > > /home/jhammond/TOOLS > > Checking for autoconf version... bad autoconf installation > > You either do not have autoconf in your path or it is too old (version > > 2.67 or higher required). You may be able to use > > > > autoconf --version > > > > Unfortunately, there is no standard format for the version output and > > it changes between autotools versions. In addition, some versions of > > autoconf choose among many versions and provide incorrect output). > > > > [jhammond@login1 git]$ autoconf --version > > autoconf (GNU Autoconf) 2.69 > > Copyright (C) 2012 Free Software Foundation, Inc. > > License GPLv3+/Autoconf: GNU GPL version 3 or later > > <http://gnu.org/licenses/gpl.html>, > > <http://gnu.org/licenses/exceptions.html> This is free software: you are > > free to change and redistribute it. There is NO WARRANTY, to the extent > > permitted by law. > > > > Written by David J. MacKenzie and Akim Demaille. -- Antonio J. Peña Postdoctoral Appointee Mathematics and Computer Science Division Argonne National Laboratory 9700 South Cass Avenue, Bldg. 240, Of. 3148 Argonne, IL 60439-4847 (+1) 630-252-7928 apenya(a)mcs.anl.gov

1 0

Re: [mpich-devel] ./autogen.sh refuses to believe 2.69>2.67
by David Goodell (dgoodell) 12 Jun '13

12 Jun '13

This situation is usually a symptom of some underlying autoconf/autotools configuration problem (like a busted m4 install or 32-/64-bit compat issue). For some reason the sanity check before looking for a specific version is either very weak or missing (I can't remember off the top of my head). Also, make sure that 2.69 is a known version to the script (though I think it is). -Dave On Jun 12, 2013, at 12:24 PM, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > Any suggestions? > > Jeff > > [jhammond@login1 git]$ ./autogen.sh > > #################################### > ## Replicating confdb (and similar) > #################################### > > syncing 'src/mpl' --> 'src/pm/hydra/mpl' > syncing 'confdb' --> 'src/mpi/romio/confdb' > syncing 'confdb' --> 'src/mpl/confdb' > syncing 'confdb' --> 'src/pm/hydra/confdb' > syncing 'confdb' --> 'src/pm/hydra/mpl/confdb' > syncing 'confdb' --> 'test/mpi/confdb' > syncing 'confdb' --> 'src/armci/m4' > > #################################### > ## Checking user environment > #################################### > > Verifying the location of autogen.sh... done > Checking if autotools are in the same location... yes, all in > /home/jhammond/TOOLS > Checking for autoconf version... bad autoconf installation > You either do not have autoconf in your path or it is too old (version > 2.67 or higher required). You may be able to use > > autoconf --version > > Unfortunately, there is no standard format for the version output and > it changes between autotools versions. In addition, some versions of > autoconf choose among many versions and provide incorrect output). > > [jhammond@login1 git]$ autoconf --version > autoconf (GNU Autoconf) 2.69 > Copyright (C) 2012 Free Software Foundation, Inc. > License GPLv3+/Autoconf: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Written by David J. MacKenzie and Akim Demaille. > > -- > 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 > ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

Re: [mpich-devel] ./autogen.sh refuses to believe 2.69>2.67
by Wesley Bland 12 Jun '13

12 Jun '13

I'm running 2.69 on my machine as well and am not having any problems. Does autogen have some log that I'm unaware of? You could always tell it to leave you alone with -atvercheck=no, but that's probably not the right answer. Wesley On Jun 12, 2013, at 12:24 PM, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > Any suggestions? > > Jeff > > [jhammond@login1 git]$ ./autogen.sh > > #################################### > ## Replicating confdb (and similar) > #################################### > > syncing 'src/mpl' --> 'src/pm/hydra/mpl' > syncing 'confdb' --> 'src/mpi/romio/confdb' > syncing 'confdb' --> 'src/mpl/confdb' > syncing 'confdb' --> 'src/pm/hydra/confdb' > syncing 'confdb' --> 'src/pm/hydra/mpl/confdb' > syncing 'confdb' --> 'test/mpi/confdb' > syncing 'confdb' --> 'src/armci/m4' > > #################################### > ## Checking user environment > #################################### > > Verifying the location of autogen.sh... done > Checking if autotools are in the same location... yes, all in > /home/jhammond/TOOLS > Checking for autoconf version... bad autoconf installation > You either do not have autoconf in your path or it is too old (version > 2.67 or higher required). You may be able to use > > autoconf --version > > Unfortunately, there is no standard format for the version output and > it changes between autotools versions. In addition, some versions of > autoconf choose among many versions and provide incorrect output). > > [jhammond@login1 git]$ autoconf --version > autoconf (GNU Autoconf) 2.69 > Copyright (C) 2012 Free Software Foundation, Inc. > License GPLv3+/Autoconf: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Written by David J. MacKenzie and Akim Demaille. > > -- > 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 > ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

./autogen.sh refuses to believe 2.69>2.67
by Jeff Hammond 12 Jun '13

12 Jun '13

Any suggestions? Jeff [jhammond@login1 git]$ ./autogen.sh #################################### ## Replicating confdb (and similar) #################################### syncing 'src/mpl' --> 'src/pm/hydra/mpl' syncing 'confdb' --> 'src/mpi/romio/confdb' syncing 'confdb' --> 'src/mpl/confdb' syncing 'confdb' --> 'src/pm/hydra/confdb' syncing 'confdb' --> 'src/pm/hydra/mpl/confdb' syncing 'confdb' --> 'test/mpi/confdb' syncing 'confdb' --> 'src/armci/m4' #################################### ## Checking user environment #################################### Verifying the location of autogen.sh... done Checking if autotools are in the same location... yes, all in /home/jhammond/TOOLS Checking for autoconf version... bad autoconf installation You either do not have autoconf in your path or it is too old (version 2.67 or higher required). You may be able to use autoconf --version Unfortunately, there is no standard format for the version output and it changes between autotools versions. In addition, some versions of autoconf choose among many versions and provide incorrect output). [jhammond@login1 git]$ autoconf --version autoconf (GNU Autoconf) 2.69 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+/Autoconf: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David J. MacKenzie and Akim Demaille. -- 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 ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

Re: [mpich-devel] Win questions
by Bob Cernohous 10 Jun '13

10 Jun '13

> Active target separates exposure and access epochs. It is erroneous > for a process to engage in more than one exposure epoch or more than > one access epoch per window. So it's ok for many processes to > expose (post/wait) to me concurrently, but for a given window I can > access only one (start/complete) at a time. > Your example code looks ok to me. Are you getting an error message? Yeah, it's definitely a PAMID problem. As I said, Rank 0 confuses Rank 4 when it's working on LR group 5/7. I just wanted to verify the example was ok and that I wasn't trying to fix something too odd. > ~Jim. > On Jun 7, 2013 9:11 AM, "Bob Cernohous" <bobc(a)us.ibm.com> wrote: > I haven't worked on rma before but was working on a problem and ran > into this **comment in MPI_Win_post: > > "Starts an RMA exposure epoch for the local window associated with > win. **Only the processes belonging to group should access the > window with RMA calls on win during this epoch. Each process in > group must issue a matching call to MPI_Win_start. MPI_Win_post does > not block." > > Would overlapping epochs be violating the ** line? I decided I > probably need to support this but I wondered if it's bending or > breaking the 'rules'? > > The problem (code at the bottom of this email) is using a cartesian > communicator and alternating "left/right' accumulates with 'up/down' > accumulates on a single win. So: > > - Ranks 0,1,2,3 are doing a left/right accumulate. > - Ranks 4,5,6,7 are doing a left/right accumulate. > - ... > > and then sometimes... > > - Ranks 0,1,2,3 complete and enter the 'up/down' accumulate epoch > -- Rank 0 does MPI_Win_post to ranks 4,12 > -- Rank 1 doesn MPI_Win_post to ranks 5,13 > ... > > So is Rank 0 posting to Rank 4 while 4 is still in the epoch with 5/ > 6/7 a violation of "Only the processes belonging to group should > access the window with RMA calls on win during this epoch"? From > Rank 4's point of view, rank 0 isn't in the group for the current win/epoch. > > Putting a barrier (or something) in between or using two different > win's fixes it. I like using two win's since it separates the > epochs and clearly doesn't use the wrong group/rank on the win. > > /* RMA transfers in left-right direction */ > MPI_Win_post(grp_lr, 0, win); > MPI_Win_start(grp_lr, 0, win); > MPI_Accumulate(&i, 1, MPI_INT, ranks_lr[LEFT] , 0, 1, MPI_INT, > MPI_SUM, win); > MPI_Accumulate(&i, 1, MPI_INT, ranks_lr[RIGHT], 0, 1, MPI_INT, > MPI_SUM, win); > MPI_Win_complete(win); > MPI_Win_wait(win); > > /* RMA transfers in up-down direction */ > MPI_Win_post(grp_ud, 0, win); > MPI_Win_start(grp_ud, 0, win); > MPI_Accumulate(&i, 1, MPI_INT, ranks_ud[UP] , 0, 1, MPI_INT, > MPI_SUM, win); > MPI_Accumulate(&i, 1, MPI_INT, ranks_ud[DOWN], 0, 1, MPI_INT, > MPI_SUM, win); > MPI_Win_complete(win); > MPI_Win_wait(win);

1 0