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

Re: [Mpi-forum] make check is busted!
by Fab Tillier 31 Jan '12

31 Jan '12

I think the errors in the profiling chapters are benign: >Checking examples in ./chap-prof >Opening file prof.tex >ex256.c: In function 'PMPI_Example': >ex256.c:11: warning: control reaches end of non-void function >Error or warning detected in example on line 296 (prof.tex): >ex296.c:7: error: 'FUNCTION' declared as function returning a function This has to do with the FUNCTION() macro used in the example, being treated as a function itself. I don't have the slightest clue how to 'fix' this. >Example contains ... at line 325 >Error or warning detected in example on line 321 (prof.tex): >ex321.c:6: error: expected identifier or '(' before '%' token This one is probably a parsing issue, as it is not really code, but an example command line... -Fab Bronis R. de Supinski wrote on Tue, 31 Jan 2012 at 11:51:03 > > Hmm. That could explain why Fab found issues with the > profiling chapter. I checked it in the past and I have > not modified the examples so they should still work... > > On Tue, 31 Jan 2012, Jeff Squyres wrote: > >> Ok. >> >> I should also note that some of the warnings that come up when you > "make check" are dependent on your MPI implementation. E.g., in the F90 > examples, if your "use mpi" module doesn't explicitly declare MPI functions, > you may get warnings that they aren't declared. But that's not a problem in > the example code; it's a limitation of your MPI implementation. >> >> >> >> On Jan 31, 2012, at 10:51 AM, William Gropp wrote: >> >>> These should be managed by the chapter committees, and voted on a > part of the chapter. It would be counterproductive to vote on these > individually. >>> >>> Operationally, it is very difficult to mark up the text within the >>> verbatim environment - frankly, the effort to do so is not worthwhile. >>> >>> My recommendation is to make the chapter committees responsible for > these. Note that in some cases, the "fixes" are to the annotations, and do > not change the text, and hence need no vote. >>> >>> Bill >>> >>> On Jan 31, 2012, at 9:28 AM, Jeff Squyres wrote: >>> >>>> Bill -- >>>> >>>> If we make minor changes in examples in the text, do we need to >>>> annotate them with "ticket 0" so that they can be ultimately voted on? >>>> >>>> On Jan 31, 2012, at 10:16 AM, William Gropp wrote: >>>> >>>>> Fab, >>>>> >>>>> Yes, make check should build cleanly. For example, the errors in > coll.tex are Fortran 90 subroutines, listed as complete routines, that are > missing the required "END" statement. There are also "naked" examples > that don't have the proper annotations; these should be added. >>>>> >>>>> For those that don't know about the "make check" option - this makes > sure that our examples don't have simple errors in them - it requires a small > amount of work to add the necessary annotations (documented and > examples exist throughout the source) and our experience has been that > this catches a lot of errors that would otherwise be missed. In looking over > the make check output, I see quite a few of those. Chapter authors should > check their chapters. >>>>> >>>>> Bill >>>>> >>>>> On Jan 30, 2012, at 4:07 PM, Fab Tillier wrote: >>>>> >>>>>> Hey Folks, >>>>>> >>>>>> Is it reasonable for me to expect that building the examples in the > standard wouldn't generate a bunch of errors? Do we build the examples > before publishing drafts, etc? >>>>>> >>>>>> Just running 'make check' on the approved/MPI-3.0 branch gives me a >>>>>> bunch of errors, in the following files: - >>>>>> chap-one-side/one-side-2.tex - chap-context/context.tex - >>>>>> chap-coll/coll.tex - chap-binding/binding-2.tex - >>>>>> chap-topol/topol.tex - chap-prof/prof.tex >>>>>> >>>>>> Can the chapter owners figure out how to either fix or suppress these > errors? It makes it really hard to find errors I may have introduced - the > signal to noise ratio is really lousy. Alternatively, is there a 'correct' way of > running 'make check' that won't generate these? I ran autoconf in > mpicompilechk, then configure. Should I be specifying extra parameters or > anything? >>>>>> >>>>>> Thanks, >>>>>> -Fab >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpi-forum mailing list >>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>> >>>>> William Gropp >>>>> Director, Parallel Computing Institute >>>>> Deputy Director for Research >>>>> Institute for Advanced Computing Applications and Technologies >>>>> Paul and Cynthia Saylor Professor of Computer Science >>>>> University of Illinois Urbana-Champaign >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> William Gropp >>> Director, Parallel Computing Institute >>> Deputy Director for Research >>> Institute for Advanced Computing Applications and Technologies >>> Paul and Cynthia Saylor Professor of Computer Science >>> University of Illinois Urbana-Champaign >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] make check is busted!
by William Gropp 31 Jan '12

31 Jan '12

Yes, this relies on at least a valid mpi.h header file - for the new features, I'll need to create one for all of the MPI 3 additions. Bill On Jan 31, 2012, at 1:51 PM, Bronis R. de Supinski wrote: > > Hmm. That could explain why Fab found issues with the > profiling chapter. I checked it in the past and I have > not modified the examples so they should still work... > > On Tue, 31 Jan 2012, Jeff Squyres wrote: > >> Ok. >> >> I should also note that some of the warnings that come up when you "make check" are dependent on your MPI implementation. E.g., in the F90 examples, if your "use mpi" module doesn't explicitly declare MPI functions, you may get warnings that they aren't declared. But that's not a problem in the example code; it's a limitation of your MPI implementation. >> >> >> >> On Jan 31, 2012, at 10:51 AM, William Gropp wrote: >> >>> These should be managed by the chapter committees, and voted on a part of the chapter. It would be counterproductive to vote on these individually. >>> >>> Operationally, it is very difficult to mark up the text within the verbatim environment - frankly, the effort to do so is not worthwhile. >>> >>> My recommendation is to make the chapter committees responsible for these. Note that in some cases, the "fixes" are to the annotations, and do not change the text, and hence need no vote. >>> >>> Bill >>> >>> On Jan 31, 2012, at 9:28 AM, Jeff Squyres wrote: >>> >>>> Bill -- >>>> >>>> If we make minor changes in examples in the text, do we need to annotate them with "ticket 0" so that they can be ultimately voted on? >>>> >>>> On Jan 31, 2012, at 10:16 AM, William Gropp wrote: >>>> >>>>> Fab, >>>>> >>>>> Yes, make check should build cleanly. For example, the errors in coll.tex are Fortran 90 subroutines, listed as complete routines, that are missing the required "END" statement. There are also "naked" examples that don't have the proper annotations; these should be added. >>>>> >>>>> For those that don't know about the "make check" option - this makes sure that our examples don't have simple errors in them - it requires a small amount of work to add the necessary annotations (documented and examples exist throughout the source) and our experience has been that this catches a lot of errors that would otherwise be missed. In looking over the make check output, I see quite a few of those. Chapter authors should check their chapters. >>>>> >>>>> Bill >>>>> >>>>> On Jan 30, 2012, at 4:07 PM, Fab Tillier wrote: >>>>> >>>>>> Hey Folks, >>>>>> >>>>>> Is it reasonable for me to expect that building the examples in the standard wouldn't generate a bunch of errors? Do we build the examples before publishing drafts, etc? >>>>>> >>>>>> Just running 'make check' on the approved/MPI-3.0 branch gives me a bunch of errors, in the following files: >>>>>> - chap-one-side/one-side-2.tex >>>>>> - chap-context/context.tex >>>>>> - chap-coll/coll.tex >>>>>> - chap-binding/binding-2.tex >>>>>> - chap-topol/topol.tex >>>>>> - chap-prof/prof.tex >>>>>> >>>>>> Can the chapter owners figure out how to either fix or suppress these errors? It makes it really hard to find errors I may have introduced - the signal to noise ratio is really lousy. Alternatively, is there a 'correct' way of running 'make check' that won't generate these? I ran autoconf in mpicompilechk, then configure. Should I be specifying extra parameters or anything? >>>>>> >>>>>> Thanks, >>>>>> -Fab >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpi-forum mailing list >>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>> >>>>> William Gropp >>>>> Director, Parallel Computing Institute >>>>> Deputy Director for Research >>>>> Institute for Advanced Computing Applications and Technologies >>>>> Paul and Cynthia Saylor Professor of Computer Science >>>>> University of Illinois Urbana-Champaign >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> William Gropp >>> Director, Parallel Computing Institute >>> Deputy Director for Research >>> Institute for Advanced Computing Applications and Technologies >>> Paul and Cynthia Saylor Professor of Computer Science >>> University of Illinois Urbana-Champaign >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi-forum] make check is busted!
by Bronis R. de Supinski 31 Jan '12

31 Jan '12

Hmm. That could explain why Fab found issues with the profiling chapter. I checked it in the past and I have not modified the examples so they should still work... On Tue, 31 Jan 2012, Jeff Squyres wrote: > Ok. > > I should also note that some of the warnings that come up when you "make check" are dependent on your MPI implementation. E.g., in the F90 examples, if your "use mpi" module doesn't explicitly declare MPI functions, you may get warnings that they aren't declared. But that's not a problem in the example code; it's a limitation of your MPI implementation. > > > > On Jan 31, 2012, at 10:51 AM, William Gropp wrote: > >> These should be managed by the chapter committees, and voted on a part of the chapter. It would be counterproductive to vote on these individually. >> >> Operationally, it is very difficult to mark up the text within the verbatim environment - frankly, the effort to do so is not worthwhile. >> >> My recommendation is to make the chapter committees responsible for these. Note that in some cases, the "fixes" are to the annotations, and do not change the text, and hence need no vote. >> >> Bill >> >> On Jan 31, 2012, at 9:28 AM, Jeff Squyres wrote: >> >>> Bill -- >>> >>> If we make minor changes in examples in the text, do we need to annotate them with "ticket 0" so that they can be ultimately voted on? >>> >>> On Jan 31, 2012, at 10:16 AM, William Gropp wrote: >>> >>>> Fab, >>>> >>>> Yes, make check should build cleanly. For example, the errors in coll.tex are Fortran 90 subroutines, listed as complete routines, that are missing the required "END" statement. There are also "naked" examples that don't have the proper annotations; these should be added. >>>> >>>> For those that don't know about the "make check" option - this makes sure that our examples don't have simple errors in them - it requires a small amount of work to add the necessary annotations (documented and examples exist throughout the source) and our experience has been that this catches a lot of errors that would otherwise be missed. In looking over the make check output, I see quite a few of those. Chapter authors should check their chapters. >>>> >>>> Bill >>>> >>>> On Jan 30, 2012, at 4:07 PM, Fab Tillier wrote: >>>> >>>>> Hey Folks, >>>>> >>>>> Is it reasonable for me to expect that building the examples in the standard wouldn't generate a bunch of errors? Do we build the examples before publishing drafts, etc? >>>>> >>>>> Just running 'make check' on the approved/MPI-3.0 branch gives me a bunch of errors, in the following files: >>>>> - chap-one-side/one-side-2.tex >>>>> - chap-context/context.tex >>>>> - chap-coll/coll.tex >>>>> - chap-binding/binding-2.tex >>>>> - chap-topol/topol.tex >>>>> - chap-prof/prof.tex >>>>> >>>>> Can the chapter owners figure out how to either fix or suppress these errors? It makes it really hard to find errors I may have introduced - the signal to noise ratio is really lousy. Alternatively, is there a 'correct' way of running 'make check' that won't generate these? I ran autoconf in mpicompilechk, then configure. Should I be specifying extra parameters or anything? >>>>> >>>>> Thanks, >>>>> -Fab >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> >>>> William Gropp >>>> Director, Parallel Computing Institute >>>> Deputy Director for Research >>>> Institute for Advanced Computing Applications and Technologies >>>> Paul and Cynthia Saylor Professor of Computer Science >>>> University of Illinois Urbana-Champaign >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> William Gropp >> Director, Parallel Computing Institute >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> >> _______________________________________________ >> 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 >

1 0

Re: [Mpi-forum] make check is busted!
by Jeff Squyres 31 Jan '12

31 Jan '12

Ok. I should also note that some of the warnings that come up when you "make check" are dependent on your MPI implementation. E.g., in the F90 examples, if your "use mpi" module doesn't explicitly declare MPI functions, you may get warnings that they aren't declared. But that's not a problem in the example code; it's a limitation of your MPI implementation. On Jan 31, 2012, at 10:51 AM, William Gropp wrote: > These should be managed by the chapter committees, and voted on a part of the chapter. It would be counterproductive to vote on these individually. > > Operationally, it is very difficult to mark up the text within the verbatim environment - frankly, the effort to do so is not worthwhile. > > My recommendation is to make the chapter committees responsible for these. Note that in some cases, the "fixes" are to the annotations, and do not change the text, and hence need no vote. > > Bill > > On Jan 31, 2012, at 9:28 AM, Jeff Squyres wrote: > >> Bill -- >> >> If we make minor changes in examples in the text, do we need to annotate them with "ticket 0" so that they can be ultimately voted on? >> >> On Jan 31, 2012, at 10:16 AM, William Gropp wrote: >> >>> Fab, >>> >>> Yes, make check should build cleanly. For example, the errors in coll.tex are Fortran 90 subroutines, listed as complete routines, that are missing the required "END" statement. There are also "naked" examples that don't have the proper annotations; these should be added. >>> >>> For those that don't know about the "make check" option - this makes sure that our examples don't have simple errors in them - it requires a small amount of work to add the necessary annotations (documented and examples exist throughout the source) and our experience has been that this catches a lot of errors that would otherwise be missed. In looking over the make check output, I see quite a few of those. Chapter authors should check their chapters. >>> >>> Bill >>> >>> On Jan 30, 2012, at 4:07 PM, Fab Tillier wrote: >>> >>>> Hey Folks, >>>> >>>> Is it reasonable for me to expect that building the examples in the standard wouldn't generate a bunch of errors? Do we build the examples before publishing drafts, etc? >>>> >>>> Just running 'make check' on the approved/MPI-3.0 branch gives me a bunch of errors, in the following files: >>>> - chap-one-side/one-side-2.tex >>>> - chap-context/context.tex >>>> - chap-coll/coll.tex >>>> - chap-binding/binding-2.tex >>>> - chap-topol/topol.tex >>>> - chap-prof/prof.tex >>>> >>>> Can the chapter owners figure out how to either fix or suppress these errors? It makes it really hard to find errors I may have introduced - the signal to noise ratio is really lousy. Alternatively, is there a 'correct' way of running 'make check' that won't generate these? I ran autoconf in mpicompilechk, then configure. Should I be specifying extra parameters or anything? >>>> >>>> Thanks, >>>> -Fab >>>> >>>> >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> >>> William Gropp >>> Director, Parallel Computing Institute >>> Deputy Director for Research >>> Institute for Advanced Computing Applications and Technologies >>> Paul and Cynthia Saylor Professor of Computer Science >>> University of Illinois Urbana-Champaign >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > _______________________________________________ > 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/

1 0

Re: [Mpi-forum] March MPI Forum meeting
by Josh Hursey 31 Jan '12

31 Jan '12

Rolf, Thank you for reminding me about ticket #291. If we could add it to the beginning/end of the FT session on Monday that would be great - unless there is a better place for it, but I think this would be fine. I will be updating the ticket, hopefully, this week to get it ready for the March meeting. Thanks, Josh On Tue, Jan 31, 2012 at 11:08 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de>wrote: > Hi Rich, > > please can you do a few changes/corrections... to the agenda: > (Nothing spectacular - only small but needed things) > > - Monday 1:00pm - 6:00pm Plenary Session: Fault Tolerance working group - > Formal reading - Ticket #276 > > you should add #291 (it is related to FT an otherwise it will > have no chance because it is not announced for formal reading) > > - At the end of Monday, please add > > At any free time Plenary Session: Formal reading > Use of [] in output arrays ticket #125 > Consistent use of [] for input arrays ticket #126 > "same arguments" to MPI_Reduce ticket #218 > > - Tuesday 9:00-9:30am: please extend to 45 minutes (I add 3 further > tickets) > and add the following ticket numbers: > #185 #207 #215 #254 #255 #262 #263 #267 #268 #312 (from Rolf's slide 9) > #162 #182 #219 (from Rolf's slide 11) > > - Tuesday 9:30-10:00am moves to 9:45-10:15 > - Tuesday 10-10:15 is a 1st (!) vote and should go to the votes session > after the break. It is a trivial correction to NBC and will not have > any discussion. > > - Tuesday 10:20-11:30am Votes session > 2nd (!! not 1st) votes are #299 and #229 > In continues with 1st votes: > - starting with #272 (moved from 10:00 slot) > - and adding at the end: > MPI_Icomm_dup ticket #168 > Please move #294 (Goodell/Rabenseifner) at the end of 12:30-4:30pm slot. > Please add the following additional vote: > "One Single vote together *) for tickets > #185 #207 #215 #254 #255 #262 #263 #267 #268 #312 #162 #182 #219 > *) If somebody complains now or in the meeting, then single voting > can be done for specific tickets or voting can be done on the next day." > > - Tuesday 12:30-4:30pm: > - Please add after #305 a new ticket-line > Scalable irregular collectives (Hoefler) ticket #264 > - and at the end #294 from above: > MPI_UNWEIGHTED should not be NULL (Goodell/Rabenseifner) ticket #294 > > - Tuesday 4:45-6:30pm: > - 158: (Traeff/Rabenseifner) > - 187: (Ritzdorf/Rabenseifner) > > - Tuesday 7-9pm: > - MPI_IN_PLACE in Gather (Hoefler) ticket #159 > has wrong ticket number: it is #163 > > I also updated my slides based on your agenda (together with these > changes). > It is attached. > > Best regards > Rolf > > > ----- Original Message ----- > > From: "Richard L. Graham" <rlgraham(a)ornl.gov> > > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > > Sent: Monday, January 30, 2012 2:35:57 AM > > Subject: [Mpi-forum] March MPI Forum meeting > > Registration is up for the meeting, as is the agenda. Please check out > > the agenda - Rolf has done a lot of work to figure out the open 3.0 > > tickets. For those that have already passe a reading, there is no > > issue - voting will progress. On the other ones, I listed the ticket > > owner for all of these, to make sure that folks are aware that their > > tickets are up for discussion. If folks do not want to proceed with > > these, please let me know. Those that are on the hook are Koziel, > > Gropp, Hoefler, Dinan, Tillier, Snir, Squyres, and Moody - please > > confirm that you are OK with these tickets. Also, Traff and Ritzdorf > > are owners of two tickets, so someone else will need to move these > > along. > > > > Rich > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [Mpi-forum] March MPI Forum meeting
by Rolf Rabenseifner 31 Jan '12

31 Jan '12

Hi Rich, please can you do a few changes/corrections... to the agenda: (Nothing spectacular - only small but needed things) - Monday 1:00pm - 6:00pm Plenary Session: Fault Tolerance working group - Formal reading - Ticket #276 you should add #291 (it is related to FT an otherwise it will have no chance because it is not announced for formal reading) - At the end of Monday, please add At any free time Plenary Session: Formal reading Use of [] in output arrays ticket #125 Consistent use of [] for input arrays ticket #126 "same arguments" to MPI_Reduce ticket #218 - Tuesday 9:00-9:30am: please extend to 45 minutes (I add 3 further tickets) and add the following ticket numbers: #185 #207 #215 #254 #255 #262 #263 #267 #268 #312 (from Rolf's slide 9) #162 #182 #219 (from Rolf's slide 11) - Tuesday 9:30-10:00am moves to 9:45-10:15 - Tuesday 10-10:15 is a 1st (!) vote and should go to the votes session after the break. It is a trivial correction to NBC and will not have any discussion. - Tuesday 10:20-11:30am Votes session 2nd (!! not 1st) votes are #299 and #229 In continues with 1st votes: - starting with #272 (moved from 10:00 slot) - and adding at the end: MPI_Icomm_dup ticket #168 Please move #294 (Goodell/Rabenseifner) at the end of 12:30-4:30pm slot. Please add the following additional vote: "One Single vote together *) for tickets #185 #207 #215 #254 #255 #262 #263 #267 #268 #312 #162 #182 #219 *) If somebody complains now or in the meeting, then single voting can be done for specific tickets or voting can be done on the next day." - Tuesday 12:30-4:30pm: - Please add after #305 a new ticket-line Scalable irregular collectives (Hoefler) ticket #264 - and at the end #294 from above: MPI_UNWEIGHTED should not be NULL (Goodell/Rabenseifner) ticket #294 - Tuesday 4:45-6:30pm: - 158: (Traeff/Rabenseifner) - 187: (Ritzdorf/Rabenseifner) - Tuesday 7-9pm: - MPI_IN_PLACE in Gather (Hoefler) ticket #159 has wrong ticket number: it is #163 I also updated my slides based on your agenda (together with these changes). It is attached. Best regards Rolf ----- Original Message ----- > From: "Richard L. Graham" <rlgraham(a)ornl.gov> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Monday, January 30, 2012 2:35:57 AM > Subject: [Mpi-forum] March MPI Forum meeting > Registration is up for the meeting, as is the agenda. Please check out > the agenda - Rolf has done a lot of work to figure out the open 3.0 > tickets. For those that have already passe a reading, there is no > issue - voting will progress. On the other ones, I listed the ticket > owner for all of these, to make sure that folks are aware that their > tickets are up for discussion. If folks do not want to proceed with > these, please let me know. Those that are on the hook are Koziel, > Gropp, Hoefler, Dinan, Tillier, Snir, Squyres, and Moody - please > confirm that you are OK with these tickets. Also, Traff and Ritzdorf > are owners of two tickets, so someone else will need to move these > along. > > Rich > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [Mpi-forum] make check is busted!
by William Gropp 31 Jan '12

31 Jan '12

These should be managed by the chapter committees, and voted on a part of the chapter. It would be counterproductive to vote on these individually. Operationally, it is very difficult to mark up the text within the verbatim environment - frankly, the effort to do so is not worthwhile. My recommendation is to make the chapter committees responsible for these. Note that in some cases, the "fixes" are to the annotations, and do not change the text, and hence need no vote. Bill On Jan 31, 2012, at 9:28 AM, Jeff Squyres wrote: > Bill -- > > If we make minor changes in examples in the text, do we need to annotate them with "ticket 0" so that they can be ultimately voted on? > > On Jan 31, 2012, at 10:16 AM, William Gropp wrote: > >> Fab, >> >> Yes, make check should build cleanly. For example, the errors in coll.tex are Fortran 90 subroutines, listed as complete routines, that are missing the required "END" statement. There are also "naked" examples that don't have the proper annotations; these should be added. >> >> For those that don't know about the "make check" option - this makes sure that our examples don't have simple errors in them - it requires a small amount of work to add the necessary annotations (documented and examples exist throughout the source) and our experience has been that this catches a lot of errors that would otherwise be missed. In looking over the make check output, I see quite a few of those. Chapter authors should check their chapters. >> >> Bill >> >> On Jan 30, 2012, at 4:07 PM, Fab Tillier wrote: >> >>> Hey Folks, >>> >>> Is it reasonable for me to expect that building the examples in the standard wouldn't generate a bunch of errors? Do we build the examples before publishing drafts, etc? >>> >>> Just running 'make check' on the approved/MPI-3.0 branch gives me a bunch of errors, in the following files: >>> - chap-one-side/one-side-2.tex >>> - chap-context/context.tex >>> - chap-coll/coll.tex >>> - chap-binding/binding-2.tex >>> - chap-topol/topol.tex >>> - chap-prof/prof.tex >>> >>> Can the chapter owners figure out how to either fix or suppress these errors? It makes it really hard to find errors I may have introduced - the signal to noise ratio is really lousy. Alternatively, is there a 'correct' way of running 'make check' that won't generate these? I ran autoconf in mpicompilechk, then configure. Should I be specifying extra parameters or anything? >>> >>> Thanks, >>> -Fab >>> >>> >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> William Gropp >> Director, Parallel Computing Institute >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> >> _______________________________________________ >> 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 William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi-forum] make check is busted!
by Jeff Squyres 31 Jan '12

31 Jan '12

Bill -- If we make minor changes in examples in the text, do we need to annotate them with "ticket 0" so that they can be ultimately voted on? On Jan 31, 2012, at 10:16 AM, William Gropp wrote: > Fab, > > Yes, make check should build cleanly. For example, the errors in coll.tex are Fortran 90 subroutines, listed as complete routines, that are missing the required "END" statement. There are also "naked" examples that don't have the proper annotations; these should be added. > > For those that don't know about the "make check" option - this makes sure that our examples don't have simple errors in them - it requires a small amount of work to add the necessary annotations (documented and examples exist throughout the source) and our experience has been that this catches a lot of errors that would otherwise be missed. In looking over the make check output, I see quite a few of those. Chapter authors should check their chapters. > > Bill > > On Jan 30, 2012, at 4:07 PM, Fab Tillier wrote: > >> Hey Folks, >> >> Is it reasonable for me to expect that building the examples in the standard wouldn't generate a bunch of errors? Do we build the examples before publishing drafts, etc? >> >> Just running 'make check' on the approved/MPI-3.0 branch gives me a bunch of errors, in the following files: >> - chap-one-side/one-side-2.tex >> - chap-context/context.tex >> - chap-coll/coll.tex >> - chap-binding/binding-2.tex >> - chap-topol/topol.tex >> - chap-prof/prof.tex >> >> Can the chapter owners figure out how to either fix or suppress these errors? It makes it really hard to find errors I may have introduced - the signal to noise ratio is really lousy. Alternatively, is there a 'correct' way of running 'make check' that won't generate these? I ran autoconf in mpicompilechk, then configure. Should I be specifying extra parameters or anything? >> >> Thanks, >> -Fab >> >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > _______________________________________________ > 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/

1 0

Re: [Mpi-forum] make check is busted!
by William Gropp 31 Jan '12

31 Jan '12

Fab, Yes, make check should build cleanly. For example, the errors in coll.tex are Fortran 90 subroutines, listed as complete routines, that are missing the required "END" statement. There are also "naked" examples that don't have the proper annotations; these should be added. For those that don't know about the "make check" option - this makes sure that our examples don't have simple errors in them - it requires a small amount of work to add the necessary annotations (documented and examples exist throughout the source) and our experience has been that this catches a lot of errors that would otherwise be missed. In looking over the make check output, I see quite a few of those. Chapter authors should check their chapters. Bill On Jan 30, 2012, at 4:07 PM, Fab Tillier wrote: > Hey Folks, > > Is it reasonable for me to expect that building the examples in the standard wouldn't generate a bunch of errors? Do we build the examples before publishing drafts, etc? > > Just running 'make check' on the approved/MPI-3.0 branch gives me a bunch of errors, in the following files: > - chap-one-side/one-side-2.tex > - chap-context/context.tex > - chap-coll/coll.tex > - chap-binding/binding-2.tex > - chap-topol/topol.tex > - chap-prof/prof.tex > > Can the chapter owners figure out how to either fix or suppress these errors? It makes it really hard to find errors I may have introduced - the signal to noise ratio is really lousy. Alternatively, is there a 'correct' way of running 'make check' that won't generate these? I ran autoconf in mpicompilechk, then configure. Should I be specifying extra parameters or anything? > > Thanks, > -Fab > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

make check is busted!
by Fab Tillier 30 Jan '12

30 Jan '12

Hey Folks, Is it reasonable for me to expect that building the examples in the standard wouldn't generate a bunch of errors? Do we build the examples before publishing drafts, etc? Just running 'make check' on the approved/MPI-3.0 branch gives me a bunch of errors, in the following files: - chap-one-side/one-side-2.tex - chap-context/context.tex - chap-coll/coll.tex - chap-binding/binding-2.tex - chap-topol/topol.tex - chap-prof/prof.tex Can the chapter owners figure out how to either fix or suppress these errors? It makes it really hard to find errors I may have introduced - the signal to noise ratio is really lousy. Alternatively, is there a 'correct' way of running 'make check' that won't generate these? I ran autoconf in mpicompilechk, then configure. Should I be specifying extra parameters or anything? Thanks, -Fab

1 0