June 2013 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] mpich2 and windows server 2012
by Costas Yamin 27 Jun '13

27 Jun '13

1 0

Re: [mpich-discuss] mpich2 and windows server 2012
by Antonio J. Peña 27 Jun '13

27 Jun '13

Hi Lars, Unfortunately the MPICH team doesn't provide support for Windows anymore, as the development for Windows was discontinued some time ago, and we don't have any Windows experts anymore within our team. Maybe someone else in this mailing list can help you. Antonio On Thursday, June 27, 2013 09:59:37 AM Lars Lindbom wrote: Hi, I have a problem getting mpich2 to run on Windows Server 2012. We have a small set of servers successfully configured and running Windows Server 2008 R2 and MPICH2 without any problem. The error I get seems to indicate a problem in the authentication process. >"c:\Program Files (x86)\MPICH2\bin\mpiexec.exe" –validate SUCCESS >"c:\Program Files (x86)\MPICH2\bin\mpiexec.exe" -host localhost nonmem.exe Credentials for Lars rejected connecting to localhost Aborting: Unable to connect to localhost The credentials are correct and I have tried multiple user accounts with the same result. I don't think it's related but for what it's worth I have made sure that I have the same firewall settings for the mpich executables as on the 2008 R2 servers. I would appreciate any help in getting this solved. Thanks, Lars

1 0

mpich2 and windows server 2012
by Lars Lindbom 27 Jun '13

27 Jun '13

Hi, I have a problem getting mpich2 to run on Windows Server 2012. We have a small set of servers successfully configured and running Windows Server 2008 R2 and MPICH2 without any problem. The error I get seems to indicate a problem in the authentication process. >"c:\Program Files (x86)\MPICH2\bin\mpiexec.exe" –validate SUCCESS >"c:\Program Files (x86)\MPICH2\bin\mpiexec.exe" -host localhost nonmem.exe Credentials for Lars rejected connecting to localhost Aborting: Unable to connect to localhost The credentials are correct and I have tried multiple user accounts with the same result. I don't think it's related but for what it's worth I have made sure that I have the same firewall settings for the mpich executables as on the 2008 R2 servers. I would appreciate any help in getting this solved. Thanks, Lars

1 0

Re: [mpich-discuss] PMGR_COLLECTIVE ERROR
by Antonio J. Peña 26 Jun '13

26 Jun '13

Hi Andre, Could you check with our MVAPICH folks? There are a bunch of things that may cause issues not related to the MPICH code integrated into MVAPICH, so they may be able to provide you with a better support for your issue. In fact, the missing environment variable is likely to be related to the process manager, and you might be using mpirun_rsh, which is not developed by us. Antonio On Wednesday, June 26, 2013 10:29:37 AM Andre Pattantyus wrote: Hello, I am running a numerical dispersion model on a linux cluster with mvapich-1.2.0 and pgi/10.2 compiler. I am trying to submit a job on 8 processors with code written by the developer but I keep getting errors. Right now I am getting the following error when the executable hycm_std gets called: /share/huina/akp4221/hysplit/trunk/exec/hycm_stdPMGR_COLLECTIVE ERROR: unitialized MPI task: Missing required environment variable: MPIRUN_RANK I do not have root privileges but I would like to know what the potential issues I could be facing so I can let the administrator now. -- Andre PattantyusGraduate Student Research AssistantDepartment of MeteorologyUniversity of Hawaii at Manoa2525 Correa Rd, HIG 350Honolulu, HI 96822Phone: (845) 264-3582

1 0

Re: [mpich-discuss] Non-blocking Collectives
by Pavan Balaji 26 Jun '13

26 Jun '13

Hi Jiri, On 06/26/2013 03:08 PM, Jiri Simsa wrote: > Thank you for your quick answer. I am trying to understand the blocking > behavior of MPI_Wait in the case of non-blocking collectives. Is it safe > to assume that, for a non-blocking collective, MPI_Wait is guaranteed to > return once all other processes call the corresponding completion > operation (e.g. MPI_Wait or MPI_Test)? I'm not sure I understand your question. Are you asking if MPI_WAIT in a process is guaranteed to return after some finite amount of time after every other process has called MPI_WAIT? Then, yes. -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

PMGR_COLLECTIVE ERROR
by Andre Pattantyus 26 Jun '13

26 Jun '13

Hello, I am running a numerical dispersion model on a linux cluster with mvapich-1.2.0 and pgi/10.2 compiler. I am trying to submit a job on 8 processors with code written by the developer but I keep getting errors. Right now I am getting the following error when the executable hycm_std gets called: /share/huina/akp4221/hysplit/trunk/exec/hycm_std PMGR_COLLECTIVE ERROR: unitialized MPI task: Missing required environment variable: MPIRUN_RANK I do not have root privileges but I would like to know what the potential issues I could be facing so I can let the administrator now. -- Andre Pattantyus Graduate Student Research Assistant Department of Meteorology University of Hawaii at Manoa 2525 Correa Rd, HIG 350 Honolulu, HI 96822 Phone: (845) 264-3582

1 0

Re: [mpich-discuss] Non-blocking Collectives
by Jiri Simsa 26 Jun '13

26 Jun '13

Hi Pavan, Thank you for your quick answer. I am trying to understand the blocking behavior of MPI_Wait in the case of non-blocking collectives. Is it safe to assume that, for a non-blocking collective, MPI_Wait is guaranteed to return once all other processes call the corresponding completion operation (e.g. MPI_Wait or MPI_Test)? --Jiri On Wed, Jun 26, 2013 at 4:00 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > Hi Jiri, > > The completion of MPI_IBARRIER indicates that all processes have called > MPI_IBARRIER. This part is correct. > > However, the specification does not say that MPI_WAIT on one process has > to complete before others have called MPI_WAIT. That's related to > asynchronous progress and is a quality of implementation issue. > > -- Pavan > > > On 06/26/2013 02:54 PM, Jiri Simsa wrote: > >> Hi, >> >> I have a question about the semantics of non-blocking collective >> communication. For example, let's consider MPI_Ibarrier. The MPI 3.0 >> standard specifies that: >> >> "MPI_IBARRIER is a nonblocking version of MPI_BARRIER. By calling >> MPI_IBARRIER, a process notifies that it has reached the barrier. The >> call returns immediately, indepen- dent of whether other processes have >> called MPI_IBARRIER. The usual barrier semantics are enforced at the >> corresponding completion operation (test or wait), which in the intra- >> communicator case will complete only after all other processes in the >> communicator have called MPI_IBARRIER. In the intercommunicator case, it >> will complete when all processes in the remote group have called >> MPI_IBARRIER." >> >> My understanding of the standard is that that MPI_Wait(&request, >> &status), where request has been previously passed into MPI_Ibarrier, >> returns after all processes in the respective intra-communicator called >> MPI_Ibarrier. However, the mpich-3.0.4 library, seems to in some cases >> wait for all processes in the respective intra-communicator to call >> MPI_Wait. Here is an example that demonstrates this behavior: >> >> #include <mpi.h> >> #include <unistd.h> >> >> int main( int argc, char *argv[]) { >> MPI_Request request; >> MPI_Status status; >> MPI_Init(&argc, &argv ); >> int myrank; >> MPI_Comm_rank(MPI_COMM_WORLD, &myrank); >> if (myrank == 0) { >> MPI_Ibarrier(MPI_COMM_WORLD, &request); >> MPI_Wait(&request, &status); >> printf("%d, Completed barrier.\n", myrank); >> } else { >> MPI_Ibarrier(MPI_COMM_WORLD, &request); >> sleep(1); >> MPI_Wait(&request, &status); >> printf("%d, Completed barrier.\n", myrank); >> } >> MPI_Finalize(); >> return 0; >> } >> >> When executed with "mpiexec -n 2 ./example", I see the expected output >> and timing. However, when executed with "mpiexec -n 3 ./example", the >> call to MPI_Wait in process 0 returns only after the other processes >> wake up from sleep() and call MPI_Wait. >> >> Isn't this a violation of the standard? >> >> Best, >> >> --Jiri Simsa >> >> >> >> ______________________________**_________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/**mailman/listinfo/discuss<https://lists.mpich.org/mailman/listinfo/discuss> >> >> > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji >

1 0

Re: [mpich-discuss] Non-blocking Collectives
by Pavan Balaji 26 Jun '13

26 Jun '13

Hi Jiri, The completion of MPI_IBARRIER indicates that all processes have called MPI_IBARRIER. This part is correct. However, the specification does not say that MPI_WAIT on one process has to complete before others have called MPI_WAIT. That's related to asynchronous progress and is a quality of implementation issue. -- Pavan On 06/26/2013 02:54 PM, Jiri Simsa wrote: > Hi, > > I have a question about the semantics of non-blocking collective > communication. For example, let's consider MPI_Ibarrier. The MPI 3.0 > standard specifies that: > > "MPI_IBARRIER is a nonblocking version of MPI_BARRIER. By calling > MPI_IBARRIER, a process notifies that it has reached the barrier. The > call returns immediately, indepen- dent of whether other processes have > called MPI_IBARRIER. The usual barrier semantics are enforced at the > corresponding completion operation (test or wait), which in the intra- > communicator case will complete only after all other processes in the > communicator have called MPI_IBARRIER. In the intercommunicator case, it > will complete when all processes in the remote group have called > MPI_IBARRIER." > > My understanding of the standard is that that MPI_Wait(&request, > &status), where request has been previously passed into MPI_Ibarrier, > returns after all processes in the respective intra-communicator called > MPI_Ibarrier. However, the mpich-3.0.4 library, seems to in some cases > wait for all processes in the respective intra-communicator to call > MPI_Wait. Here is an example that demonstrates this behavior: > > #include <mpi.h> > #include <unistd.h> > > int main( int argc, char *argv[]) { > MPI_Request request; > MPI_Status status; > MPI_Init(&argc, &argv ); > int myrank; > MPI_Comm_rank(MPI_COMM_WORLD, &myrank); > if (myrank == 0) { > MPI_Ibarrier(MPI_COMM_WORLD, &request); > MPI_Wait(&request, &status); > printf("%d, Completed barrier.\n", myrank); > } else { > MPI_Ibarrier(MPI_COMM_WORLD, &request); > sleep(1); > MPI_Wait(&request, &status); > printf("%d, Completed barrier.\n", myrank); > } > MPI_Finalize(); > return 0; > } > > When executed with "mpiexec -n 2 ./example", I see the expected output > and timing. However, when executed with "mpiexec -n 3 ./example", the > call to MPI_Wait in process 0 returns only after the other processes > wake up from sleep() and call MPI_Wait. > > Isn't this a violation of the standard? > > Best, > > --Jiri Simsa > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] Non-blocking Collectives
by Jeff Hammond 26 Jun '13

26 Jun '13

How is what you see not consistent with "The usual barrier semantics are enforced at the corresponding completion operation (test or wait)..."? I don't know what you mean by "expected output and timing" since I don't share your interpretation of the MPI standard, but I believe that the n=3 case is absolutely consistent with the semantics of MPI_Ibarrier+MPI_Wait. Jeff On Wed, Jun 26, 2013 at 2:54 PM, Jiri Simsa <jsimsa(a)cs.cmu.edu> wrote: > Hi, > > I have a question about the semantics of non-blocking collective > communication. For example, let's consider MPI_Ibarrier. The MPI 3.0 > standard specifies that: > > "MPI_IBARRIER is a nonblocking version of MPI_BARRIER. By calling > MPI_IBARRIER, a process notifies that it has reached the barrier. The call > returns immediately, indepen- dent of whether other processes have called > MPI_IBARRIER. The usual barrier semantics are enforced at the corresponding > completion operation (test or wait), which in the intra- communicator case > will complete only after all other processes in the communicator have called > MPI_IBARRIER. In the intercommunicator case, it will complete when all > processes in the remote group have called MPI_IBARRIER." > > My understanding of the standard is that that MPI_Wait(&request, &status), > where request has been previously passed into MPI_Ibarrier, returns after > all processes in the respective intra-communicator called MPI_Ibarrier. > However, the mpich-3.0.4 library, seems to in some cases wait for all > processes in the respective intra-communicator to call MPI_Wait. Here is an > example that demonstrates this behavior: > > #include <mpi.h> > #include <unistd.h> > > int main( int argc, char *argv[]) { > MPI_Request request; > MPI_Status status; > MPI_Init(&argc, &argv ); > int myrank; > MPI_Comm_rank(MPI_COMM_WORLD, &myrank); > if (myrank == 0) { > MPI_Ibarrier(MPI_COMM_WORLD, &request); > MPI_Wait(&request, &status); > printf("%d, Completed barrier.\n", myrank); > } else { > MPI_Ibarrier(MPI_COMM_WORLD, &request); > sleep(1); > MPI_Wait(&request, &status); > printf("%d, Completed barrier.\n", myrank); > } > MPI_Finalize(); > return 0; > } > > When executed with "mpiexec -n 2 ./example", I see the expected output and > timing. However, when executed with "mpiexec -n 3 ./example", the call to > MPI_Wait in process 0 returns only after the other processes wake up from > sleep() and call MPI_Wait. > > Isn't this a violation of the standard? > > Best, > > --Jiri Simsa > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Jeff Hammond jeff.science(a)gmail.com

1 0

Non-blocking Collectives
by Jiri Simsa 26 Jun '13

26 Jun '13

Hi, I have a question about the semantics of non-blocking collective communication. For example, let's consider MPI_Ibarrier. The MPI 3.0 standard specifies that: "MPI_IBARRIER is a nonblocking version of MPI_BARRIER. By calling MPI_IBARRIER, a process notifies that it has reached the barrier. The call returns immediately, indepen- dent of whether other processes have called MPI_IBARRIER. The usual barrier semantics are enforced at the corresponding completion operation (test or wait), which in the intra- communicator case will complete only after all other processes in the communicator have called MPI_IBARRIER. In the intercommunicator case, it will complete when all processes in the remote group have called MPI_IBARRIER." My understanding of the standard is that that MPI_Wait(&request, &status), where request has been previously passed into MPI_Ibarrier, returns after all processes in the respective intra-communicator called MPI_Ibarrier. However, the mpich-3.0.4 library, seems to in some cases wait for all processes in the respective intra-communicator to call MPI_Wait. Here is an example that demonstrates this behavior: #include <mpi.h> #include <unistd.h> int main( int argc, char *argv[]) { MPI_Request request; MPI_Status status; MPI_Init(&argc, &argv ); int myrank; MPI_Comm_rank(MPI_COMM_WORLD, &myrank); if (myrank == 0) { MPI_Ibarrier(MPI_COMM_WORLD, &request); MPI_Wait(&request, &status); printf("%d, Completed barrier.\n", myrank); } else { MPI_Ibarrier(MPI_COMM_WORLD, &request); sleep(1); MPI_Wait(&request, &status); printf("%d, Completed barrier.\n", myrank); } MPI_Finalize(); return 0; } When executed with "mpiexec -n 2 ./example", I see the expected output and timing. However, when executed with "mpiexec -n 3 ./example", the call to MPI_Wait in process 0 returns only after the other processes wake up from sleep() and call MPI_Wait. Isn't this a violation of the standard? Best, --Jiri Simsa

1 0