December 2014 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] missing Fortran bindings in MPICH
by Michael.Rachner＠dlr.de 15 Dec '14

15 Dec '14

Dear Junchao, In another email of today to discuss(a)mpich.org<mailto:[email protected]> I attached my sharedmemtest.f90 test program. At the end of that file I added a small sbr check_ftn_bindings . It is for checking for missing explicit Ftn-interfaces in the mpi-module. If you activate the USE-stmts in that sbr, you will get this output at compile time (with MPICH-3.0.4 and INTEL-14.0.1 on a Linux-cluster): rachner@master:~/dat> mpif90 sharedmemtest.f90 sharedmemtest.f90(246): error #6580: Name in only-list does not exist. [MPI_FINALIZE] use MYMPI, only: MPI_INIT, MPI_BARRIER, MPI_FINALIZE & ! <-- MPI-2 routines -----------------------------------------------^ sharedmemtest.f90(249): error #6580: Name in only-list does not exist. [MPI_WIN_ALLOCATE_SHARED] use MYMPI, only: MPI_WIN_ALLOCATE_SHARED, MPI_WIN_SHARED_QUERY, MPI_GET_LIBRARY_VERSION ! <-- MPI-3 routines ------------------------^ sharedmemtest.f90(249): error #6580: Name in only-list does not exist. [MPI_WIN_SHARED_QUERY] use MYMPI, only: MPI_WIN_ALLOCATE_SHARED, MPI_WIN_SHARED_QUERY, MPI_GET_LIBRARY_VERSION ! <-- MPI-3 routines -------------------------------------------------^ compilation aborted for sharedmemtest.f90 (code 1) rachner@master:~/dat> You can see, that also for sbr MPI_FINALIZE there is no explicit Ftn-interface in the mpi-module (“use mpi”). (By the way: In our MPICH-3.0.4 implementation there exist no mpi_base.f90, only a mpi_base.mod file.) It is a good investment in the future, that MPICH has provided explicit interfaces now for the mpi-f08 module. But: Do normal Ftn-compilers already support Ftn2008 features already sufficiently, so that we can actually use that mpi_f08 module? There is the problem, I think. Have you tried, whether it works for the INTEL-Ftn-compiler? If it does not work, I suggest, you may contact INTEL, telling them, which Ftn08-feature are desirable but still missing in their Ftn95 compiler. Greetings Michael Rachner Von: Junchao Zhang [mailto:[email protected]] Gesendet: Freitag, 12. Dezember 2014 18:05 An: <discuss(a)mpich.org> Betreff: Re: [mpich-discuss] missing Fortran bindings in MPICH Hi, Michael, I checked and found MPI_FINALIZE did have an explicit interface, at least in MPICH-3.1.3. You can search the file mpi_base.f90 in your MPICH build. We recently fixed the explicit interface problem in MPI Fortran 2008 bindings. You need to "use mpi_f08" in your code. A paper on that is at http://dl.acm.org/citation.cfm?id=2642777 The new bindings are already included in MPICH-3.2a1. It requires Fortran2008 + TS29113 capable compilers, such as Cray ftn 8.3.3+ or gfortran-dev. If you'd like to have a try, I can instruct you how to do that. Thanks. --Junchao Zhang On Fri, Dec 12, 2014 at 5:55 AM, <Michael.Rachner(a)dlr.de<mailto:[email protected]>> wrote: Dear developers of MPICH, For your convenience, I forward the emails in mvapich-discuss concerning the missing Fortran bindings. Possibly this I can encourage you a bit, adding (as OPENMPI did it successfully) the missing explicit Ftn-interfaces in the mpi-module for those MPI-routines with parameters of "Choice"-type? At least: You may add the explicit Ftn-interface for the sbr MPI_FINALIZE . It is missing in MPICH-3.0.4 too. Greetings Michael Rachner -----Ursprüngliche Nachricht----- Von: mvapich-discuss [mailto:[email protected]<mailto:[email protected]>] Im Auftrag von Michael.Rachner(a)dlr.de<mailto:[email protected]> Gesendet: Freitag, 12. Dezember 2014 12:38 An: mvapich-discuss(a)cse.ohio-state.edu<mailto:[email protected]> Betreff: [mvapich-discuss] WG: WG: missing Fortran bindings in MVAPICH2-2.1a Sorry, I wanted to send my email not to Jonathan alone, but to the mvapich-discuss. Michael -----Ursprüngliche Nachricht----- Von: Rachner, Michael Gesendet: Freitag, 12. Dezember 2014 10:03 An: 'Jonathan Perkins' Betreff: AW: [mvapich-discuss] WG: missing Fortran bindings in MVAPICH2-2.1a Thank You, Jonathan, for this hint. Indeed, the problem with the missing explicit Ftn-interfaces in the mpi-module are the arguments of "choice"-type. Fortran 95 don't like them. So the MPI-3.0 Standard document contains a complicated chapter 17.1 with these things. As a consequence, MPICH seems to have chosen the slim way omitting in the mpi-module ("use mpi") the explicit Ftn-interfaces for MPI-routines with choice-type arguments, whereas OPENMPI has chosen the cumbercome way providing the explicit Ftn-interfaces even for these MPI-routines. They succeeded. For details: In November there were some emails discussing this issue in the OPENMPI-forum. Greetings Michael Rachner -----Ursprüngliche Nachricht----- Von: Jonathan Perkins [mailto:[email protected]<mailto:[email protected]>] Gesendet: Donnerstag, 11. Dezember 2014 16:17 An: Rachner, Michael Cc: mvapich-discuss(a)cse.ohio-state.edu<mailto:[email protected]> Betreff: Re: [mvapich-discuss] WG: missing Fortran bindings in MVAPICH2-2.1a Hello Michael. My investigation turned up the same issue in MPICH-3.1.3. MVAPICH2-2.1a is based on MPICH-3.1.2 so it inherits the same behavior. Here is a snippet from MPICH's user guide: 4.2 Special Issues for Fortran MPICH provides two kinds of support for Fortran programs. For Fortran 77 programmers, the file mpif.h provides the definitions of the MPI constants such as MPI COMM WORLD. Fortran 90 programmers should use the MPI module instead; this provides all of the definitions as well as interface definitions for many of the MPI functions. However, this MPI module does not provide full Fortran 90 support; in particular, interfaces for the routines, such as MPI Send, that take “choice” arguments are not provided. It sounds like these are routines with ``choice'' arguments. On Thu, Dec 11, 2014 at 01:29:03PM +0000, Michael.Rachner(a)dlr.de<mailto:[email protected]> wrote: > Dear developers, > > I have just found, that exactly the same 11 missing Ftn-interfaces are also missing in MPICH-3.0.4, MSMPI-5.0, IMPI-5.0.0 . > So that looks, as if you all have inherited these missing interfaces from MPICH. > > In contrast, with OPENMPI-1.8.2 all explicit Ftn-interfaces for MPI-routines needed by our CFD-code are present. Compliment! > > Greetings > Michael Rachner > > > Von: mvapich-discuss > [mailto:[email protected]<mailto:[email protected]>] Im Auftrag von > Michael.Rachner(a)dlr.de<mailto:[email protected]> > Gesendet: Donnerstag, 11. Dezember 2014 13:12 > An: mvapich-discuss(a)cse.ohio-state.edu<mailto:[email protected]> > Betreff: [mvapich-discuss] missing Fortran bindings in MVAPICH2-2.1a > > Dear developers of MVAPICH2, > > I found, that the explicit interfaces in the mpi-module are still missing in MVAPICH2-2.1a (with INTEL-14.0.4) for these 11 MPI-routines: > MPI_BCAST > MPI_GATHER , MPI_GATHERV > MPI_REDUCE , MPI_ALLREDUCE > MPI_SCATTER, MPI_SCATTERV > MPI_SSEND , MPI_RECV > MPI_WIN_ALLOCATE_SHARED, MPI_WIN_SHARED_QUERY > > Greetings > Michael Rachner > > _______________________________________________ > mvapich-discuss mailing list > mvapich-discuss(a)cse.ohio-state.edu<mailto:[email protected]> > http://mailman.cse.ohio-state.edu/mailman/listinfo/mvapich-discuss _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Bug in MPI_WIN_SHARED_QUERY using MPICH-3.0.4 from Fortran95-code
by Michael.Rachner＠dlr.de 15 Dec '14

15 Dec '14

Dear Junchao, I attached a downsized Fortran95 program for testing the MPI-3 shared memory feature (MPI_WIN_ALLOCATE_SHARED, MPI_WIN_SHARED_QUERY). You may add it to your MPICH test suite. (The program is not secret, so I place it here for everybody, because it may serve also as an example, how to do the shared memory coding in a Ftn-code.) In that program I have inserted 2 ad-hoc prints, just before and just after the call of sbr MPI_WIN_SHARED_QUERY, which print the value of the 4th-parameter DISP_UNIT (named idisplace_unit in the code) of that sbr . You can run the program by: mpif90 sharedmemtest.f90 mpiexec -np 2 -bind-to core -prepend-rank ./a.out On our LINUX cluster with MPICH-3.0.4 and Intel-14.0.1 the 2 print-stmts write this: [0] ---Info-print just BEFORE calling MPI_WIN_QUERY: idisplace_unit= -6666 <-- -6666 is my arbitrary initialization value [0] ===Info-print just AFTER calling MPI_WIN_QUERY: idisplace_unit= -6666 [1] ---Info-print just BEFORE calling MPI_WIN_QUERY: idisplace_unit= -6666 [1] ===Info-print just AFTER calling MPI_WIN_QUERY: idisplace_unit= -6666 You see, that sbr MPI_WIN_SHARED_QUERY does not overwrite the initialized value, but should do it. I observed the same wrong behavior also in our Fortran95-CFD-code. I cannot easily install another MPICH-version. We have only MPICH-3.0.4 . So, do you find that behavior with that program also with the most recent MPICH-version? Greetings Michael Rachner Von: Junchao Zhang [mailto:[email protected]] Gesendet: Freitag, 12. Dezember 2014 20:50 An: <discuss(a)mpich.org> Betreff: Re: [mpich-discuss] Bug in MPI_WIN_SHARED_QUERY using MPICH-3.0.4 from Fortran95-code Michael, I could not reproduce the problem with MPICH master. I checked MPICH's F90 binding of this routine. It looks good. There are C tests for this routine in MPICH test suite. They also ran fine. Could you either upgrade your MPI to MPICH-3.1.3 or send me your test case? Thanks. --Junchao Zhang On Fri, Dec 12, 2014 at 4:53 AM, <Michael.Rachner(a)dlr.de<mailto:[email protected]>> wrote: Dear developers of MPICH, I am running MPICH-3.0.4 with a Fortran95-code on a LINUX-cluster using the INTEL-14.0.1 Ftn-compiler. In that code I employ the shared memory feature (using MPI_WIN_ALLOCATE_SHARED and MPI_WIN_SHARED_QUERY). It works fine, but nevertheless I detected a little bug in MPI_WIN_SHARED_QUERY: MPI_WIN_SHARED_QUERY(WIN, RANK, SIZE, DISP_UNIT, BASEPTR, IERROR) The MPI-3.0 Standard document (chapter 11.2, on p. 410) prescribes that the 4th parameter DISP_UNIT is a result from the call of this sbr. However, with MPICH no value is returned for DISP_UNIT. You can easily test that, by setting DISP_UNIT to a control number ( e.g. DISP_UNIT = -7777 ) just before the call of sbr MPI_WIN_SHARED_QUERY. Just after that sbr-call the variable DISP_UNIT still contains that control number, but should not. Greetings Michael Rachner _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Bug in MPI_WIN_SHARED_QUERY using MPICH-3.0.4 from Fortran95-code
by Junchao Zhang 12 Dec '14

12 Dec '14

Michael, I could not reproduce the problem with MPICH master. I checked MPICH's F90 binding of this routine. It looks good. There are C tests for this routine in MPICH test suite. They also ran fine. Could you either upgrade your MPI to MPICH-3.1.3 or send me your test case? Thanks. --Junchao Zhang On Fri, Dec 12, 2014 at 4:53 AM, <Michael.Rachner(a)dlr.de> wrote: > > Dear developers of MPICH, > > > > I am running MPICH-3.0.4 with a Fortran95-code on a LINUX-cluster using > the INTEL-14.0.1 Ftn-compiler. > > In that code I employ the shared memory feature (using > MPI_WIN_ALLOCATE_SHARED and MPI_WIN_SHARED_QUERY). > > It works fine, but nevertheless I detected a little bug in > MPI_WIN_SHARED_QUERY: > > > > MPI_WIN_SHARED_QUERY(WIN, RANK, SIZE, DISP_UNIT, BASEPTR, IERROR) > > > > The MPI-3.0 Standard document (chapter 11.2, on p. 410) prescribes that > the 4th parameter DISP_UNIT is a result from the call of this sbr. > > However, with MPICH no value is returned for DISP_UNIT. > > > > You can easily test that, by setting DISP_UNIT to a control number ( > e.g. DISP_UNIT = -7777 ) just before the call of sbr > MPI_WIN_SHARED_QUERY. > > Just after that sbr-call the variable DISP_UNIT still contains that > control number, but should not. > > > > Greetings > > Michael Rachner > > > > > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] missing Fortran bindings in MPICH
by Junchao Zhang 12 Dec '14

12 Dec '14

Hi, Michael, I checked and found MPI_FINALIZE did have an explicit interface, at least in MPICH-3.1.3. You can search the file mpi_base.f90 in your MPICH build. We recently fixed the explicit interface problem in MPI Fortran 2008 bindings. You need to "use mpi_f08" in your code. A paper on that is at http://dl.acm.org/citation.cfm?id=2642777 The new bindings are already included in MPICH-3.2a1. It requires Fortran2008 + TS29113 capable compilers, such as Cray ftn 8.3.3+ or gfortran-dev. If you'd like to have a try, I can instruct you how to do that. Thanks. --Junchao Zhang On Fri, Dec 12, 2014 at 5:55 AM, <Michael.Rachner(a)dlr.de> wrote: > > Dear developers of MPICH, > > For your convenience, I forward the emails in mvapich-discuss concerning > the missing Fortran bindings. > Possibly this I can encourage you a bit, adding (as OPENMPI did it > successfully) the missing explicit Ftn-interfaces in the mpi-module > for those MPI-routines with parameters of "Choice"-type? > > At least: You may add the explicit Ftn-interface for the sbr > MPI_FINALIZE . It is missing in MPICH-3.0.4 too. > > Greetings > Michael Rachner > > > > > > > -----Ursprüngliche Nachricht----- > Von: mvapich-discuss [mailto:[email protected]] > Im Auftrag von Michael.Rachner(a)dlr.de > Gesendet: Freitag, 12. Dezember 2014 12:38 > An: mvapich-discuss(a)cse.ohio-state.edu > Betreff: [mvapich-discuss] WG: WG: missing Fortran bindings in > MVAPICH2-2.1a > > Sorry, I wanted to send my email not to Jonathan alone, but to the > mvapich-discuss. > Michael > > > > -----Ursprüngliche Nachricht----- > Von: Rachner, Michael > Gesendet: Freitag, 12. Dezember 2014 10:03 > An: 'Jonathan Perkins' > Betreff: AW: [mvapich-discuss] WG: missing Fortran bindings in > MVAPICH2-2.1a > > Thank You, Jonathan, for this hint. > Indeed, the problem with the missing explicit Ftn-interfaces in the > mpi-module are the arguments of "choice"-type. Fortran 95 don't like them. > So the MPI-3.0 Standard document contains a complicated chapter 17.1 > with these things. > As a consequence, MPICH seems to have chosen the slim way omitting in the > mpi-module ("use mpi") the explicit Ftn-interfaces for MPI-routines with > choice-type arguments, whereas OPENMPI has chosen the cumbercome way > providing the explicit Ftn-interfaces even for these MPI-routines. They > succeeded. > For details: In November there were some emails discussing this issue in > the OPENMPI-forum. > > Greetings > Michael Rachner > > > -----Ursprüngliche Nachricht----- > Von: Jonathan Perkins [mailto:[email protected]] > Gesendet: Donnerstag, 11. Dezember 2014 16:17 > An: Rachner, Michael > Cc: mvapich-discuss(a)cse.ohio-state.edu > Betreff: Re: [mvapich-discuss] WG: missing Fortran bindings in > MVAPICH2-2.1a > > Hello Michael. My investigation turned up the same issue in MPICH-3.1.3. > MVAPICH2-2.1a is based on MPICH-3.1.2 so it inherits the same behavior. > > Here is a snippet from MPICH's user guide: > > 4.2 Special Issues for Fortran > > MPICH provides two kinds of support for Fortran programs. For > Fortran 77 programmers, the file mpif.h provides the definitions of > the MPI constants such as MPI COMM WORLD. Fortran 90 programmers > should use the MPI module instead; this provides all of the > definitions as well as interface definitions for many of the MPI > functions. However, this MPI module does not provide full Fortran 90 > support; in particular, interfaces for the routines, such as MPI > Send, that take “choice” arguments are not provided. > > It sounds like these are routines with ``choice'' arguments. > > On Thu, Dec 11, 2014 at 01:29:03PM +0000, Michael.Rachner(a)dlr.de wrote: > > Dear developers, > > > > I have just found, that exactly the same 11 missing Ftn-interfaces are > also missing in MPICH-3.0.4, MSMPI-5.0, IMPI-5.0.0 . > > So that looks, as if you all have inherited these missing interfaces > from MPICH. > > > > In contrast, with OPENMPI-1.8.2 all explicit Ftn-interfaces for > MPI-routines needed by our CFD-code are present. Compliment! > > > > Greetings > > Michael Rachner > > > > > > Von: mvapich-discuss > > [mailto:[email protected]] Im Auftrag von > > Michael.Rachner(a)dlr.de > > Gesendet: Donnerstag, 11. Dezember 2014 13:12 > > An: mvapich-discuss(a)cse.ohio-state.edu > > Betreff: [mvapich-discuss] missing Fortran bindings in MVAPICH2-2.1a > > > > Dear developers of MVAPICH2, > > > > I found, that the explicit interfaces in the mpi-module are still > missing in MVAPICH2-2.1a (with INTEL-14.0.4) for these 11 MPI-routines: > > MPI_BCAST > > MPI_GATHER , MPI_GATHERV > > MPI_REDUCE , MPI_ALLREDUCE > > MPI_SCATTER, MPI_SCATTERV > > MPI_SSEND , MPI_RECV > > MPI_WIN_ALLOCATE_SHARED, MPI_WIN_SHARED_QUERY > > > > Greetings > > Michael Rachner > > > > > _______________________________________________ > > mvapich-discuss mailing list > > mvapich-discuss(a)cse.ohio-state.edu > > http://mailman.cse.ohio-state.edu/mailman/listinfo/mvapich-discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

missing Fortran bindings in MPICH
by Michael.Rachner＠dlr.de 12 Dec '14

12 Dec '14

Dear developers of MPICH, For your convenience, I forward the emails in mvapich-discuss concerning the missing Fortran bindings. Possibly this I can encourage you a bit, adding (as OPENMPI did it successfully) the missing explicit Ftn-interfaces in the mpi-module for those MPI-routines with parameters of "Choice"-type? At least: You may add the explicit Ftn-interface for the sbr MPI_FINALIZE . It is missing in MPICH-3.0.4 too. Greetings Michael Rachner -----Ursprüngliche Nachricht----- Von: mvapich-discuss [mailto:[email protected]] Im Auftrag von Michael.Rachner(a)dlr.de Gesendet: Freitag, 12. Dezember 2014 12:38 An: mvapich-discuss(a)cse.ohio-state.edu Betreff: [mvapich-discuss] WG: WG: missing Fortran bindings in MVAPICH2-2.1a Sorry, I wanted to send my email not to Jonathan alone, but to the mvapich-discuss. Michael -----Ursprüngliche Nachricht----- Von: Rachner, Michael Gesendet: Freitag, 12. Dezember 2014 10:03 An: 'Jonathan Perkins' Betreff: AW: [mvapich-discuss] WG: missing Fortran bindings in MVAPICH2-2.1a Thank You, Jonathan, for this hint. Indeed, the problem with the missing explicit Ftn-interfaces in the mpi-module are the arguments of "choice"-type. Fortran 95 don't like them. So the MPI-3.0 Standard document contains a complicated chapter 17.1 with these things. As a consequence, MPICH seems to have chosen the slim way omitting in the mpi-module ("use mpi") the explicit Ftn-interfaces for MPI-routines with choice-type arguments, whereas OPENMPI has chosen the cumbercome way providing the explicit Ftn-interfaces even for these MPI-routines. They succeeded. For details: In November there were some emails discussing this issue in the OPENMPI-forum. Greetings Michael Rachner -----Ursprüngliche Nachricht----- Von: Jonathan Perkins [mailto:[email protected]] Gesendet: Donnerstag, 11. Dezember 2014 16:17 An: Rachner, Michael Cc: mvapich-discuss(a)cse.ohio-state.edu Betreff: Re: [mvapich-discuss] WG: missing Fortran bindings in MVAPICH2-2.1a Hello Michael. My investigation turned up the same issue in MPICH-3.1.3. MVAPICH2-2.1a is based on MPICH-3.1.2 so it inherits the same behavior. Here is a snippet from MPICH's user guide: 4.2 Special Issues for Fortran MPICH provides two kinds of support for Fortran programs. For Fortran 77 programmers, the file mpif.h provides the definitions of the MPI constants such as MPI COMM WORLD. Fortran 90 programmers should use the MPI module instead; this provides all of the definitions as well as interface definitions for many of the MPI functions. However, this MPI module does not provide full Fortran 90 support; in particular, interfaces for the routines, such as MPI Send, that take “choice” arguments are not provided. It sounds like these are routines with ``choice'' arguments. On Thu, Dec 11, 2014 at 01:29:03PM +0000, Michael.Rachner(a)dlr.de wrote: > Dear developers, > > I have just found, that exactly the same 11 missing Ftn-interfaces are also missing in MPICH-3.0.4, MSMPI-5.0, IMPI-5.0.0 . > So that looks, as if you all have inherited these missing interfaces from MPICH. > > In contrast, with OPENMPI-1.8.2 all explicit Ftn-interfaces for MPI-routines needed by our CFD-code are present. Compliment! > > Greetings > Michael Rachner > > > Von: mvapich-discuss > [mailto:[email protected]] Im Auftrag von > Michael.Rachner(a)dlr.de > Gesendet: Donnerstag, 11. Dezember 2014 13:12 > An: mvapich-discuss(a)cse.ohio-state.edu > Betreff: [mvapich-discuss] missing Fortran bindings in MVAPICH2-2.1a > > Dear developers of MVAPICH2, > > I found, that the explicit interfaces in the mpi-module are still missing in MVAPICH2-2.1a (with INTEL-14.0.4) for these 11 MPI-routines: > MPI_BCAST > MPI_GATHER , MPI_GATHERV > MPI_REDUCE , MPI_ALLREDUCE > MPI_SCATTER, MPI_SCATTERV > MPI_SSEND , MPI_RECV > MPI_WIN_ALLOCATE_SHARED, MPI_WIN_SHARED_QUERY > > Greetings > Michael Rachner > > _______________________________________________ > mvapich-discuss mailing list > mvapich-discuss(a)cse.ohio-state.edu > http://mailman.cse.ohio-state.edu/mailman/listinfo/mvapich-discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Bug in MPI_WIN_SHARED_QUERY using MPICH-3.0.4 from Fortran95-code
by Michael.Rachner＠dlr.de 12 Dec '14

12 Dec '14

Dear developers of MPICH, I am running MPICH-3.0.4 with a Fortran95-code on a LINUX-cluster using the INTEL-14.0.1 Ftn-compiler. In that code I employ the shared memory feature (using MPI_WIN_ALLOCATE_SHARED and MPI_WIN_SHARED_QUERY). It works fine, but nevertheless I detected a little bug in MPI_WIN_SHARED_QUERY: MPI_WIN_SHARED_QUERY(WIN, RANK, SIZE, DISP_UNIT, BASEPTR, IERROR) The MPI-3.0 Standard document (chapter 11.2, on p. 410) prescribes that the 4th parameter DISP_UNIT is a result from the call of this sbr. However, with MPICH no value is returned for DISP_UNIT. You can easily test that, by setting DISP_UNIT to a control number ( e.g. DISP_UNIT = -7777 ) just before the call of sbr MPI_WIN_SHARED_QUERY. Just after that sbr-call the variable DISP_UNIT still contains that control number, but should not. Greetings Michael Rachner _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Fault tolerance of an MPI cluster after one node dies
by Bland, Wesley B. 10 Dec '14

10 Dec '14

We’ve been doing work specifically on this. In the latest alpha, an experimental version of the ULFM specification was added. You’re welcome to try it out. If you’re not familiar, I’d recommend reading through some of the documentation on www.fault-tolerance.org <http://www.fault-tolerance.org/>. You can find some tutorials along with the specification. Thanks, Wesley > On Dec 10, 2014, at 6:31 AM, YANG Fan <iddmbr(a)gmail.com <mailto:[email protected]>> wrote: > > Hi, > > Is it possible for an MPI distributed cluster to continue working if one node dies? I'm not sure if MPICH provides such functionality. > > It seems that MPI_Comm_create requires that all processes in the superset communicators to be alive; while the errhandler with --disable-auto-cleanup also does not avoid such issue, as one process cannot call MPI_Finalize(). > > Thanks in advance! > > Best Regards, > Fan > _______________________________________________ > discuss mailing list discuss(a)mpich.org <mailto:[email protected]> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss <https://lists.mpich.org/mailman/listinfo/discuss> _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Fault tolerance of an MPI cluster after one node dies
by YANG Fan 10 Dec '14

10 Dec '14

Hi, Is it possible for an MPI distributed cluster to continue working if one node dies? I'm not sure if MPICH provides such functionality. It seems that MPI_Comm_create requires that all processes in the superset communicators to be alive; while the errhandler with --disable-auto-cleanup also does not avoid such issue, as one process cannot call MPI_Finalize(). Thanks in advance! Best Regards, Fan _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

(no subject)
by Chafik sanaa 09 Dec '14

09 Dec '14

Hi I try to use both Scatterv and GAtterv function in my algorithm but when I stock the same value "CFC [NIV [nv] .tab_cls [rang_proc]]. taille_ptt_trame_cls" in the two variables "sendcounts" and "recvcount" of Scatterv does not give me the value "CFC [NIV [nv] .tab_cls [rang_proc]]. taille_ptt_trame_cls" for the variable recvcount (i use 2 process for running this program): #include <stdio.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <math.h> #include "mpi.h" struct Etat_str { int nbr_action; int indice_cls; int indice_Niv; int R[4]; int P[4][20]; int PI[4][20]; int taille_ptt_trame; int ptt_trame[100]; }; struct FU_par_Niv_str { int indice_cls; double tab_etat_FU_t[2][20]; double tab_etat_FU_t_plus_1[2][20]; }; struct NIV_str { int long_trame; int nbr_cls; int tab_cls[30]; int tab_etat_restr[30]; int nbr_etat_restr; int tab_dplc[20]; int tab_nomb_elm[20]; int tab_donné_total[200]; int deplacement[30]; int count[30]; }; struct CFC_str { int nb_etat_CFC; int nbr_etat_restrient_CFC; int nbr_etat_appartient_pas_CFC; int nbr_etat_successeur_CFC = 0; double tab_Vt_instantane[30]; int tab_etat_CFC[20]; int tab_etat_appartient_pas_CFC[30]; int tab_etat_successeur_CFC[30 * 30]; int tab_etat_restrient_CFC[30]; int taille_ptt_trame_cls; int ptt_trame_cls[100]; //int tab_emplacement[20]; }; int main(int argc, char** argv) { int nbr_proc, rang_proc; int recvcount; int ierr, i, itask, entet; int buffsize, sendcounts[2048], displs[2048], *receive_counts, *receive_displacements; double **sendbuff, *recvbuff, *buffer1, buffsum, buffsums[2048], buffer[3]; double inittime, totaltime; int espace_memoir_trame = 150; double gama = 0.5; double sigma = 0.2; int teste; int m1 = 10, n1 = 16; const int nbr_etat = 8; int buffsize1[nbr_etat]; struct Etat_str Etat[nbr_etat]; struct FU_par_Niv_str FU_par_Niv[nbr_etat]; int E[16][10] = { { 2, 2, 0, 1, 0, 0, 0, 0, 0, 0 }, { 2, 4, 1, 0, 0, 0, 0, 0, 0, 0 }, { 2, 1, 1, 0, 0, 0, 0, 0, 0, 0 }, { 2, 3, 0, 1, 0, 0, 0, 0, 0, 0 }, { 1, 2, 0, 0, 0, 1, 0, 0, 0, 0 }, { 2, 4, 0, 0, 1, 0, 0, 0, 0, 0 }, { 2, 1, 0, 0, 0, 1, 0, 0, 0, 0 }, { 2, 2, 0, 0, 0, 0, 1, 0, 0, 0 }, { 2, 1, 0, 0, 0, 0, 0, 1, 0, 0 }, { 2, 6, 0, 0, 0, 0, 1, 0, 0, 0 }, { 2, 2, 0, 0, 1, 0, 0, 0, 0, 0 }, { 3, 2, 0, 0, 1, 0, 0, 0, 0, 0 }, { 3, 5, 0, 0, 0, 0, 0, 0, 1, 0 }, { 3, 1, 0, 0, 0, 0, 0, 0, 0, 1 }, { 2, 5, 0, 0, 0, 0, 0, 0, 0, 1 }, { 2, 4, 0, 0, 0, 0, 0, 0, 1, 0 } }; int pas = 0; for (int i = 0; i < nbr_etat; i++) { Etat[i].nbr_action = E[pas][0]; int s1 = 0; for (int j = pas; j < (pas + Etat[i].nbr_action); j++) { Etat[i].R[s1] = E[j][1]; int s2 = 0; for (int k = 2; k < m1; k++) { Etat[i].P[s1][s2] = E[j][k]; s2++; } s1++; } pas += E[pas][0]; } struct CFC_str CFC[20]; struct NIV_str NIV[20]; int m = 8, n = 8; int A[8][8] = { { 1, 1, 0, 0, 0, 0, 0, 0 }, { 1, 1, 0, 0, 0, 0, 0, 0 }, { 0, 0, 0, 1, 0, 0, 0, 0 }, { 0, 0, 1, 1, 0, 0, 0, 0 }, { 0, 0, 0, 0, 1, 1, 0, 0 }, { 0, 0, 1, 0, 1, 0, 0, 0 }, { 0, 0, 1, 0, 0, 0, 1, 1 }, { 0, 0, 0, 0, 0, 0, 1, 1 } }; int A1[8][8]; for (int i = 0; i < m; i++) { for (int j = 0; j < n; j++) { A1[i][j] = A[i][j]; } } for (int i = 0; i < m; i++) { for (int j = 0; j < n; j++) if (i == j) { A[i][j] = 1; } else { A[i][j] = A[i][j]; } } for (int k = 0; k < n; k++) { for (int j = 0; j < n; j++) { for (int i = 0; i < n; i++) { if ((A[i][j] + (A[i][k] * A[k][j])) >= 1) A[i][j] = 1;//>=1 } } } int tab_etat[nbr_etat]; int tab_etat_echange[nbr_etat]; for (int i = 0; i < n; i++) { tab_etat[i] = i; tab_etat_echange[i] = i; } i = 0; int nbr_cfc = 0; while (i < n) { if ((tab_etat[i] != n) && (i != n - 1)) { int p = 0; nbr_cfc++; tab_etat[i] = n; CFC[nbr_cfc - 1].tab_etat_CFC[p] = i; Etat[i].indice_cls = nbr_cfc - 1; int j = 0; while (j < n) { if ((tab_etat[j] != n) && (j != i)) { for (int k = 0; k < n; k++) { if (A[i][k] != A[j][k]) { j = j + 1; break; } else if ((A[i][k] == A[j][k]) && (k == n - 1)) { tab_etat[j] = n; p++; CFC[nbr_cfc - 1].tab_etat_CFC[p] = j; Etat[j].indice_cls = nbr_cfc - 1; j = j + 1; } } } else { j = j + 1; } } CFC[nbr_cfc - 1].nb_etat_CFC = p + 1; i = i + 1; } else if ((tab_etat[i] != n) && (i == n - 1)) { int p = 0; nbr_cfc++; CFC[nbr_cfc - 1].tab_etat_CFC[p] = i; CFC[nbr_cfc - 1].nb_etat_CFC = 1; break; } else { i = i + 1; } } for (int i = 0; i < nbr_cfc; i++) { int l = 0; for (int k = 0; k < nbr_etat; k++) { int j = 0; while (j < CFC[i].nb_etat_CFC) { if (tab_etat_echange[k] != CFC[i].tab_etat_CFC[j]) { j = j + 1; if (j == CFC[i].nb_etat_CFC){ CFC[i].tab_etat_appartient_pas_CFC[l] = tab_etat_echange[k]; l++; } } else if (tab_etat_echange[k] == CFC[i].tab_etat_CFC[j]) { break; } } } CFC[i].nbr_etat_appartient_pas_CFC = l; } int B[nbr_etat][nbr_etat]; for (int i = 0; i < nbr_cfc; i++) { for (int j = 0; j < nbr_etat; j++) { B[i][j] = 0; for (int k = 0; k < CFC[i].nb_etat_CFC; k++) { if (A1[CFC[i].tab_etat_CFC[k]][j]>0) { B[i][j] = 1; break; } } } } for (int i = 0; i < nbr_cfc; i++) { int i2 = 0; int i1 = 0; for (int k = 0; k<CFC[i].nbr_etat_appartient_pas_CFC; k++) { if ((B[i][CFC[i].tab_etat_appartient_pas_CFC[k]])>0) { i2++; CFC[i].tab_etat_successeur_CFC[i1] = CFC[i].tab_etat_appartient_pas_CFC[k]; i1++; } } CFC[i].nbr_etat_successeur_CFC = i2; } for (int i = 0; i < nbr_cfc; i++) { int i3 = 0; for (int j = 0; j < CFC[i].nb_etat_CFC; j++) { CFC[i].tab_etat_restrient_CFC[i3] = CFC[i].tab_etat_CFC[j]; i3++; } for (int k = 0; k < CFC[i].nbr_etat_successeur_CFC; k++) { CFC[i].tab_etat_restrient_CFC[i3] = CFC[i].tab_etat_successeur_CFC[k]; i3++; } CFC[i].nbr_etat_restrient_CFC = CFC[i].nbr_etat_successeur_CFC + CFC[i].nb_etat_CFC; } int C[nbr_etat][nbr_etat]; int D[nbr_etat][nbr_etat]; for (int i = 0; i < nbr_cfc; i++) { for (int j = 0; j < nbr_cfc; j++) { C[i][j] = 0; D[i][j] = 0; if (i == j) { C[i][j] = 1; D[i][j] = 1; } else if (i != j) { for (int k = 0; k < CFC[j].nb_etat_CFC; k++) { if (B[i][CFC[j].tab_etat_CFC[k]] == 1) { C[i][j] = 1; D[i][j] = 1; break; } } } } } int D1[nbr_etat]; int ni = 0; bool test = true; do { for (int i = 0; i < nbr_cfc; i++) { int sum = 0; for (int j = 0; j < nbr_cfc; j++) { if (D[i][j]>0) { sum++; } D1[i] = sum; } } int nbr_test = 0; for (int i = 0; i < nbr_cfc; i++) { nbr_test += D1[i]; } if (nbr_test>0) { int k = 0; for (int j = 0; j < nbr_cfc; j++) { if (D1[j] == 1) { NIV[ni].tab_cls[k] = j; for (int s = 0; s < nbr_cfc; s++) { D[s][j] = 0; } k++; NIV[ni].nbr_cls = k;/**/ } NIV[ni].nbr_cls = k; } ni++; test = 1; } else if (nbr_test == 0) { test = false; } } while (test); int nbr_niv = ni; for (int i = 0; i < nbr_niv; i++) { NIV[i].deplacement[0] = 0; for (int j = 0; j < NIV[i].nbr_cls; j++) { NIV[i].count[j] = CFC[NIV[i].tab_cls[j]].nbr_etat_restrient_CFC; NIV[i].deplacement[j + 1] = NIV[i].count[j]; } } for (int i = 0; i < nbr_niv; i++) { int l = 0; for (int j = 0; j < NIV[i].nbr_cls; j++) { for (int k = 0; k < CFC[NIV[i].tab_cls[j]].nbr_etat_restrient_CFC; k++) { NIV[i].tab_etat_restr[l] = CFC[NIV[i].tab_cls[j]].tab_etat_restrient_CFC[k]; l++; } } NIV[i].nbr_etat_restr = l; } for (int i = 0; i < nbr_etat; i++) { for (int j = 0; j < Etat[i].nbr_action; j++) { for (int k = 0; k < CFC[Etat[i].indice_cls].nbr_etat_restrient_CFC; k++) { Etat[i].PI[j][k] = Etat[i].P[j][CFC[Etat[i].indice_cls].tab_etat_restrient_CFC[k]]; } } } for (int i = 0; i < nbr_niv; i++) { for (int j = 0; j < NIV[i].nbr_cls; j++) { FU_par_Niv[j].indice_cls = NIV[i].tab_cls[j]; for (int k = 0; k < CFC[NIV[i].tab_cls[j]].nbr_etat_restrient_CFC; k++) { FU_par_Niv[j].tab_etat_FU_t[0][k] = CFC[NIV[i].tab_cls[j]].tab_etat_restrient_CFC[k]; FU_par_Niv[j].tab_etat_FU_t_plus_1[0][k] = CFC[NIV[i].tab_cls[j]].tab_etat_restrient_CFC[k]; FU_par_Niv[j].tab_etat_FU_t[1][k] = 0; FU_par_Niv[j].tab_etat_FU_t_plus_1[1][k] = 0; } } } int a1, a2, a3; for (int nv = 0; nv < nbr_niv; nv++) { for (int j = 0; j < NIV[nv].nbr_cls; j++) { a1 = CFC[NIV[nv].tab_cls[j]].nb_etat_CFC; a2 = CFC[NIV[nv].tab_cls[j]].nbr_etat_restrient_CFC; for (int k = 0; k < CFC[NIV[nv].tab_cls[j]].nb_etat_CFC; k++) { int a4 = 0; a3 = Etat[CFC[NIV[nv].tab_cls[j]].tab_etat_CFC[k]].nbr_action; Etat[CFC[NIV[nv].tab_cls[j]].tab_etat_CFC[k]].taille_ptt_trame = 1 + a2*a3 + a3; printf("%d la taille = %d \n", NIV[nv].tab_cls[j], Etat[CFC[NIV[nv].tab_cls[j]].tab_etat_CFC[k]].taille_ptt_trame); Etat[CFC[NIV[nv].tab_cls[j]].tab_etat_CFC[k]].ptt_trame[a4] = a3; for (int s = 0; s < a3; s++) { a4++; Etat[CFC[NIV[nv].tab_cls[j]].tab_etat_CFC[k]].ptt_trame[a4] = Etat[CFC[NIV[nv].tab_cls[j]].tab_etat_CFC[k]].R[s]; } for (int s1 = 0; s1 < a3; s1++) { for (int s2 = 0; s2 < a2; s2++) { a4++; Etat[CFC[NIV[nv].tab_cls[j]].tab_etat_CFC[k]].ptt_trame[a4] = Etat[CFC[NIV[nv].tab_cls[j]].tab_etat_CFC[k]].PI[s1][s2]; } } } } } int a4, a5; MPI_Init(&argc, &argv); MPI_Comm_rank(MPI_COMM_WORLD, &rang_proc); MPI_Comm_size(MPI_COMM_WORLD, &nbr_proc); for (int nv = 0; nv < nbr_niv; nv++) { if (rang_proc == 0){ printf("rang_proc=%d \n", rang_proc); for (int j = 0; j < NIV[nv].nbr_cls; j++) { int jj = 0; int a6 = 0; a4 = 2; int z1 = a6; CFC[NIV[nv].tab_cls[j]].ptt_trame_cls[a6] = CFC[NIV[nv].tab_cls[j]].nb_etat_CFC; a6 += 1; CFC[NIV[nv].tab_cls[j]].ptt_trame_cls[a6] = CFC[NIV[nv].tab_cls[j]].nbr_etat_restrient_CFC; a4 += CFC[NIV[nv].tab_cls[j]].nbr_etat_restrient_CFC; int z2 = a6; a6 += 1; int a7; for (int i = 0; i < CFC[NIV[nv].tab_cls[j]].ptt_trame_cls[z2]; i++) { if (i >= CFC[NIV[nv].tab_cls[j]].ptt_trame_cls[z1]) { a7 = a6 + i; CFC[NIV[nv].tab_cls[j]].ptt_trame_cls[a7] = CFC[NIV[nv].tab_cls[j]].tab_Vt_instantane[i]; } else { a7 = a6 + i; CFC[NIV[nv].tab_cls[j]].ptt_trame_cls[a7] = 0; } } a6 = a7 + 1; for (int k = 0; k < CFC[NIV[nv].tab_cls[j]].nb_etat_CFC; k++) { a5 = Etat[CFC[NIV[nv].tab_cls[j]].tab_etat_CFC[k]].taille_ptt_trame; a4 += a5; for (int s2 = 0; s2 < a5; s2++) { CFC[NIV[nv].tab_cls[j]].ptt_trame_cls[a6] = Etat[CFC[NIV[nv].tab_cls[j]].tab_etat_CFC[k]].ptt_trame[s2]; a6++; } } CFC[NIV[nv].tab_cls[j]].taille_ptt_trame_cls = a4; } } recvbuff = (double *)malloc(sizeof(double)*espace_memoir_trame); if (rang_proc == 0) { sendbuff = (double **)malloc(sizeof(double *)* nbr_proc);// on execute pour deux proc sendbuff[0] = (double *)malloc(sizeof(double)*nbr_proc*espace_memoir_trame); for (i = 1; i < nbr_proc; i++) { sendbuff[i] = sendbuff[i - 1] + espace_memoir_trame; } } else { sendbuff = (double **)malloc(sizeof(double *)* 1); sendbuff[0] = (double *)malloc(sizeof(double)* 1); } if (rang_proc == 0){ for (itask = 0; itask< nbr_proc; itask++) { int k; displs[itask] = itask*espace_memoir_trame; sendcounts[itask] = CFC[NIV[nv].tab_cls[itask]].taille_ptt_trame_cls; printf("sendcounts[%d]=%d \n", itask, sendcounts[itask]); printf("-----------------------------\n"); k = 0; for (i = 0; i<sendcounts[itask]; i++) { sendbuff[itask][i] = CFC[NIV[nv].tab_cls[itask]].ptt_trame_cls[i]; } printf("\n"); } } recvcount = CFC[NIV[nv].tab_cls[rang_proc]].taille_ptt_trame_cls; printf("rank = % drecvcount= %d \n",rang_proc, recvcount); printf("-----------------------------\n"); ierr = MPI_Scatterv(sendbuff[0], sendcounts, displs, MPI_DOUBLE, recvbuff, recvcount, MPI_DOUBLE, 0, MPI_COMM_WORLD); int f = 0; double *V_t = NULL; double *V_t_1 = NULL; double *V_choi_max = NULL; int *pi = NULL; V_t_1 = (double *)malloc(sizeof(double)*recvbuff[1]); V_t = (double *)malloc(sizeof(double)*recvbuff[1]); pi = (int *)malloc(sizeof(int)*recvbuff[0]); double ech = 0; for (int i = 0; i < recvbuff[1]; i++) { int y = 2 + i; V_t[i] = recvbuff[y]; ech = recvbuff[y]; V_t_1[i] = ech; } bool fini = true; int M = 0; while (fini) { for (int i = 0; i < recvbuff[1]; i++) { V_t_1[i] = V_t[i]; } M++; for (int i = 0; i < recvbuff[0]; i++) { int y = 2 + recvbuff[1], o; double *R = NULL; double **P = NULL; double gama = 0.5; int r = 2 + recvbuff[1]; if (i == 0) { V_choi_max = (double *)malloc(sizeof(double)*recvbuff[r]); R = (double *)malloc(sizeof(double)*recvbuff[r]); for (int j = 0; j < recvbuff[r]; j++) { R[j] = recvbuff[r + j + 1]; } o = r + 1 + recvbuff[r]; P = (double **)malloc(sizeof(double *)* recvbuff[r]); for (int i = 0; i < recvbuff[r]; i++) { P[i] = (double *)malloc(sizeof(double)*recvbuff[1]); } for (int i1 = 0; i1 < recvbuff[r]; i1++) { for (int j1 = 0; j1 < recvbuff[1]; j1++) { P[i1][j1] = recvbuff[o]; o++; } } for (int i1 = 0; i1 < recvbuff[r]; i1++) { double sum = 0; for (int j1 = 0; j1 < recvbuff[1]; j1++) { sum += P[i1][j1] * V_t_1[j1]; } V_choi_max[i1] = R[i1] + (gama*sum); } double max = V_choi_max[0]; pi[i] = 0; for (int i1 = 0; i1 < recvbuff[r]; i1++)// vers le nbr d action { if (max <= V_choi_max[i1]) { max = V_choi_max[i1]; pi[i] = i1; } } V_t[i] = max; free(R); for (int i = 0; i < recvbuff[r]; i++) free(P[i]); free(P); } else { y += 1 + recvbuff[y] + recvbuff[y] * recvbuff[1]; int yy = y + 1 + recvbuff[y] + recvbuff[y] * recvbuff[1]; R = (double *)malloc(sizeof(double)*recvbuff[y]); for (int j = 0; j < recvbuff[y]; j++) { R[j] = recvbuff[y + j + 1]; } int oo = y + recvbuff[y]; P = (double **)malloc(sizeof(double *)* recvbuff[y]);// on execute pour deux proc for (int i = 0; i < recvbuff[y]; i++) { P[i] = (double *)malloc(sizeof(double)*recvbuff[1]); } for (int i1 = 0; i1 < recvbuff[y]; i1++) { for (int j1 = 0; j1 < recvbuff[1]; j1++) { oo += 1; P[i1][j1] = recvbuff[oo]; } } for (int i1 = 0; i1 < recvbuff[y]; i1++) { double sum = 0; for (int j1 = 0; j1 < recvbuff[1]; j1++) { sum += P[i1][j1] * V_t_1[j1]; } V_choi_max[i1] = R[i1] + (gama*sum); } double max = V_choi_max[0]; pi[i] = 0; for (int i1 = 0; i1 < recvbuff[y]; i1++) { if (max <= V_choi_max[i1]) { max = V_choi_max[i1]; pi[i] = i1; } } V_t[i] = max; free(R); for (int i = 0; i < recvbuff[y]; i++) free(P[i]); free(P); } } int psi = 1; fini = false; for (int i = 0; i < recvbuff[1]; i++) { if (fabs(V_t[i] - V_t_1[i]) >= psi) { fini = true; break; } } } for (int i = 0; i < recvbuff[1]; i++) printf("V_tF[%d]=%0.2f \n",i, V_t[i]); printf("\n"); int p = 0; buffer1 = (double *)malloc(sizeof(double)*recvbuff[1]); for (i = 0; i<recvbuff[1]; i++) { p++; buffer1[i] = V_t[i]; } receive_counts = (int *)malloc(sizeof(int)*NIV[nv].nbr_cls); receive_displacements = (int *)malloc(sizeof(int)*NIV[nv].nbr_cls); for (int d = 0; d < NIV[nv].nbr_cls; d++) { receive_counts[d] = NIV[nv].count[d]; receive_displacements[d] = NIV[nv].deplacement[d]; } MPI_Gatherv(buffer1, p, MPI_DOUBLE, buffer, receive_counts, receive_displacements, MPI_DOUBLE, 0, MPI_COMM_WORLD); if (rang_proc == 0){ for (int s1 = 0; s1<NIV[nv].nbr_etat_restr; s1++) { for (int s2 = nv + 1; s2 < nbr_niv; s2++) { for (int s3 = 0; s3 < NIV[s2].nbr_cls; s3++) { for (int s4 = 0; s4 < CFC[NIV[s2].tab_cls[s3]].nbr_etat_restrient_CFC; s4++) { if (NIV[nv].tab_etat_restr[s1] == CFC[NIV[s2].tab_cls[s3]].tab_etat_restrient_CFC[s4]) { CFC[NIV[s2].tab_cls[s3]].tab_Vt_instantane[s4] = buffer[s1]; } } } } } fflush(stdout); } MPI_Barrier(MPI_COMM_WORLD); if (rang_proc == 0) { free(sendbuff[0]); free(sendbuff); free(receive_counts); free(receive_displacements); } else { free(sendbuff[0]); free(sendbuff); free(recvbuff); } } MPI_Finalize(); } _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] less busy polling with Nemesis
by Bland, Wesley B. 09 Dec '14

09 Dec '14

Hi Daniel, We are actually working on this at the moment. There is a ticket to describe the status of the work: https://trac.mpich.org/projects/mpich/ticket/79. Despite the appearance, there is work planned here. Currently, this is slated for MPICH 3.3 in 2016. It’s possible that it could show up earlier in the nightlies, but there’s no guarantees. Thanks, Wesley On Dec 9, 2014, at 1:17 PM, Daniel Ibanez <dan.a.ibanez(a)gmail.com<mailto:[email protected]>> wrote: Hello, I have noticed that simple things like MPI_Barrier will raise my CPU usage to near 100% while waiting, and read in past emails and the FAQ that this is due to busy polling in Nemesis. As far as I can tell, the one solution usually offered to reduce this CPU usage is reconfiguring with sockets instead of Nemesis. I would also like to use the MPI_THREAD_MULTIPLE feature, but I read that the socket channels don't support it, and it would be annoying to have to recompile MPICH to get one benefit or the other. I was just wondering if recent advancements invalidated some of the above and officially ask what the options are for reducing the CPU usage of MPICH during barriers. Thank you, _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0