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

Re: [mpich-discuss] mpifort wrapper compiler?
by Jeff Hammond 12 Dec '13

12 Dec '13

>> Is there any point to having --with-fortran take optional args {header,module,f08mod} to down-select from the default of 'all'? Can one skip the goofy Fortran ABI configure tests if only F08 is requested? > > The value/developer-overhead ratio for this seems to be too low. I read this as "we look forward to your patch" and will enqueue it in my low-priority TODO list :-) Jeff -- Jeff Hammond jeff.science(a)gmail.com

1 0

Re: [mpich-discuss] mpifort wrapper compiler?
by Jeff Squyres (jsquyres) 12 Dec '13

12 Dec '13

On Dec 12, 2013, at 8:02 AM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > Will the following tradeoff be acceptable to everyone? > > * We allow users to specify a Fortran compiler using “FC” and “FCFLAGS”. This will result in a wrapper called “mpifort”. > > * We’ll maintain mpif90 as a symbolic link to mpifort for backward compatibility. > > * If no separate F77 compiler is specified, we’ll use FC as the F77 compiler as well. In this case, mpif77 will be a symbolic link to mpifort. > > * But users have the ability to provide a separate F77 compiler, in which case a new mpif77 is created. > > This way, we can still support compilers that have a different F77 compiler. But for most compilers there’ll be a single mpifort (with mpif90 and mpif77 symbolic links for backward compatibility for some time). That sounds perfect. -- 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: [mpich-discuss] mpifort wrapper compiler?
by Pavan Balaji 12 Dec '13

12 Dec '13

On Dec 12, 2013, at 8:28 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > Is there any point to having --with-fortran take optional args {header,module,f08mod} to down-select from the default of 'all'? Can one skip the goofy Fortran ABI configure tests if only F08 is requested? The value/developer-overhead ratio for this seems to be too low. -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] mpifort wrapper compiler?
by Jeff Hammond 12 Dec '13

12 Dec '13

> > > Will the following tradeoff be acceptable to everyone? > > * We allow users to specify a Fortran compiler using “FC” and “FCFLAGS”. This will result in a wrapper called “mpifort”. > > * We’ll maintain mpif90 as a symbolic link to mpifort for backward compatibility. > > * If no separate F77 compiler is specified, we’ll use FC as the F77 compiler as well. In this case, mpif77 will be a symbolic link to mpifort. > > * But users have the ability to provide a separate F77 compiler, in which case a new mpif77 is created. > > This way, we can still support compilers that have a different F77 compiler. But for most compilers there’ll be a single mpifort (with mpif90 and mpif77 symbolic links for backward compatibility for some time). > Yes. This sounds great. Is there any point to having --with-fortran take optional args {header,module,f08mod} to down-select from the default of 'all'? Can one skip the goofy Fortran ABI configure tests if only F08 is requested? In theory, users could provide all diff Fortran lang compilers or diff flags to indicate language and get wrappers for them but I suppose it is equally valid to say that users/packagers are responsible for doing this by hand. Jeff > >> On Dec 12, 2013, at 7:48 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >> >> On Dec 11, 2013, at 10:29 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: >> >>>> I agree that this is right for most cases, eg ifort, ftn and gfortran. I recall PGI has language-named variants. >> >> They also have pgifortran (my PGI license has expired, so I can't say what they do today). >> >>>> Not sure what you think should be done there. That is a case that actually matters to MPICH and OpenMPI builds from source by users (as opposed to IBM on BG). >>> >>> The Absoft compiler also has different names af77 and af90. >> >> >> Correct; it does not look like Absoft has consolidated down to a single Absoft executable. FWIW: I just asked an Absoft employee -- he said: >> >> ----- >> We have af77, af90, and af95. The af77 driver enables some legacy FORTRAN 77 >> extensions but there is no difference between af90 and af95. >> >> Also, all three drivers define the following symbols if the C pre-processor >> is invoked by convention ( all cap file extensions .F .F90 .F95 .FOR) or >> by option ( -cpp ), -D__ABSOFT__ and -D__ABSVER__=140 >> ----- >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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] mpifort wrapper compiler?
by Pavan Balaji 12 Dec '13

12 Dec '13

Will the following tradeoff be acceptable to everyone? * We allow users to specify a Fortran compiler using “FC” and “FCFLAGS”. This will result in a wrapper called “mpifort”. * We’ll maintain mpif90 as a symbolic link to mpifort for backward compatibility. * If no separate F77 compiler is specified, we’ll use FC as the F77 compiler as well. In this case, mpif77 will be a symbolic link to mpifort. * But users have the ability to provide a separate F77 compiler, in which case a new mpif77 is created. This way, we can still support compilers that have a different F77 compiler. But for most compilers there’ll be a single mpifort (with mpif90 and mpif77 symbolic links for backward compatibility for some time). — Pavan On Dec 12, 2013, at 7:48 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On Dec 11, 2013, at 10:29 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > >>> I agree that this is right for most cases, eg ifort, ftn and gfortran. I recall PGI has language-named variants. > > They also have pgifortran (my PGI license has expired, so I can't say what they do today). > >>> Not sure what you think should be done there. That is a case that actually matters to MPICH and OpenMPI builds from source by users (as opposed to IBM on BG). >> >> The Absoft compiler also has different names af77 and af90. > > > Correct; it does not look like Absoft has consolidated down to a single Absoft executable. FWIW: I just asked an Absoft employee -- he said: > > ----- > We have af77, af90, and af95. The af77 driver enables some legacy FORTRAN 77 > extensions but there is no difference between af90 and af95. > > Also, all three drivers define the following symbols if the C pre-processor > is invoked by convention ( all cap file extensions .F .F90 .F95 .FOR) or > by option ( -cpp ), -D__ABSOFT__ and -D__ABSVER__=140 > ----- > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > 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] mpifort wrapper compiler?
by Jeff Squyres (jsquyres) 12 Dec '13

12 Dec '13

On Dec 11, 2013, at 10:29 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: >> I agree that this is right for most cases, eg ifort, ftn and gfortran. I recall PGI has language-named variants. They also have pgifortran (my PGI license has expired, so I can't say what they do today). >> Not sure what you think should be done there. That is a case that actually matters to MPICH and OpenMPI builds from source by users (as opposed to IBM on BG). > > The Absoft compiler also has different names af77 and af90. Correct; it does not look like Absoft has consolidated down to a single Absoft executable. FWIW: I just asked an Absoft employee -- he said: ----- We have af77, af90, and af95. The af77 driver enables some legacy FORTRAN 77 extensions but there is no difference between af90 and af95. Also, all three drivers define the following symbols if the C pre-processor is invoked by convention ( all cap file extensions .F .F90 .F95 .FOR) or by option ( -cpp ), -D__ABSOFT__ and -D__ABSVER__=140 ----- -- 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: [mpich-discuss] mpifort wrapper compiler?
by Rajeev Thakur 11 Dec '13

11 Dec '13

>> The point is that MPI shouldn't try to subvert what the underlying Fortran compilers are doing. If they're consolidating down to a single name, so should we. And if you have platforms where they're not, great -- don't consolidate to a single name (e.g., mpifort) on those platforms, and/or rely on downstream vendors (e.g., IBM) to do the right things for their platforms/compiler suites (e.g., the mpif* scripts that IBM is apparently generating). >> > > I agree that this is right for most cases, eg ifort, ftn and gfortran. I recall PGI has language-named variants. Not sure what you think should be done there. That is a case that actually matters to MPICH and OpenMPI builds from source by users (as opposed to IBM on BG). The Absoft compiler also has different names af77 and af90. Rajeev

1 0

Re: [mpich-discuss] mpifort wrapper compiler?
by Jeff Hammond 11 Dec '13

11 Dec '13

> On Dec 11, 2013, at 6:39 PM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: > > I deleted all the stuff that JeffH and I argued about in person. It wasn't useful to keep arguing about those things here on the list. :-) > > > On Dec 7, 2013, at 3:50 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > >>> So other than the backwards compatibility issue, a single "mpifort" wrapper that makes all 3 interfaces available makes perfect sense. >>> >>> I don't think there can be any expectation that "mpif77" provides a true, honest, and only Fortran 77 compiler (because MPI never worked with Fortran 77). >> >> How about we have mpifisffc (MPI FIxed Source Form Fortran Compiler) >> and mpifrsffc (MPI FRee Source Form Fortran Compiler) then? > > When I asked earlier, everyone wanted "mpifort", and it's very much in conjunction with what several Fortran vendors are doing (i.e., a single executable name, and optional CLI options and/or .suffix examination if you want specific version syntax enforcement). > > Open MPI has already released mpifort into the wild, and I hope MPICH does the same, because it will really make users' lives easier if they can assume that "mpifort" exists everywhere. > > The point is that MPI shouldn't try to subvert what the underlying Fortran compilers are doing. If they're consolidating down to a single name, so should we. And if you have platforms where they're not, great -- don't consolidate to a single name (e.g., mpifort) on those platforms, and/or rely on downstream vendors (e.g., IBM) to do the right things for their platforms/compiler suites (e.g., the mpif* scripts that IBM is apparently generating). > I agree that this is right for most cases, eg ifort, ftn and gfortran. I recall PGI has language-named variants. Not sure what you think should be done there. That is a case that actually matters to MPICH and OpenMPI builds from source by users (as opposed to IBM on BG). >> The only natural conclusion at this point is that it is critical to >> deprecate both mpif.h and the 'mpi' module, since the 'mpi_f08' module >> is clearly the only sane way to use MPI from Fortran. > > Yes, this was the long-term plan. The Fortran WG should probably meet again to take steps towards deprecating mpif.h... and possibly the mpi module. :-) > +1 Jeff > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > 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] mpifort wrapper compiler?
by Jeff Squyres (jsquyres) 11 Dec '13

11 Dec '13

I deleted all the stuff that JeffH and I argued about in person. It wasn't useful to keep arguing about those things here on the list. :-) On Dec 7, 2013, at 3:50 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> So other than the backwards compatibility issue, a single "mpifort" wrapper that makes all 3 interfaces available makes perfect sense. >> >> I don't think there can be any expectation that "mpif77" provides a true, honest, and only Fortran 77 compiler (because MPI never worked with Fortran 77). > > How about we have mpifisffc (MPI FIxed Source Form Fortran Compiler) > and mpifrsffc (MPI FRee Source Form Fortran Compiler) then? When I asked earlier, everyone wanted "mpifort", and it's very much in conjunction with what several Fortran vendors are doing (i.e., a single executable name, and optional CLI options and/or .suffix examination if you want specific version syntax enforcement). Open MPI has already released mpifort into the wild, and I hope MPICH does the same, because it will really make users' lives easier if they can assume that "mpifort" exists everywhere. The point is that MPI shouldn't try to subvert what the underlying Fortran compilers are doing. If they're consolidating down to a single name, so should we. And if you have platforms where they're not, great -- don't consolidate to a single name (e.g., mpifort) on those platforms, and/or rely on downstream vendors (e.g., IBM) to do the right things for their platforms/compiler suites (e.g., the mpif* scripts that IBM is apparently generating). > The only natural conclusion at this point is that it is critical to > deprecate both mpif.h and the 'mpi' module, since the 'mpi_f08' module > is clearly the only sane way to use MPI from Fortran. Yes, this was the long-term plan. The Fortran WG should probably meet again to take steps towards deprecating mpif.h... and possibly the mpi module. :-) -- 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: [mpich-discuss] A good starting point for programming and understanding MPI, and parallel programming in general.
by Brock Palen 11 Dec '13

11 Dec '13

You should have no problem moving between them. Both follow the MPI API, you will have to recompile your code, but I every day take code developed on MPICH or MPICH Clones (Intel MPI) and compile with OpenMPI on my local cluster with no issues. Brock Palen www.umich.edu/~brockp CAEN Advanced Computing XSEDE Campus Champion brockp(a)umich.edu (734)936-1985 On Dec 11, 2013, at 11:27 AM, mark <dimitsas.markos(a)gmail.com> wrote: > Thanks for the pointers, they are always welcomed. Speaking about MPI and MPICH, if i try openmpi, will it be difficult to transcribe my projects and learning to mpich? Are they different or completely the same? In my opinion is like using a different IDE for the same language, so the same, but i am asked to follow the mpich as for my mpi and parallel programming studies. > > Στις 11/12/2013 05:52 μμ, ο/η Brock Palen έγραψε: >> I'm a big fan of CI tutor for getting started: >> >> >> http://www.citutor.org/ >> >> >> Brock Palen >> >> www.umich.edu/~brockp >> sing Your Own Computer to Run CI-Tutor MPI Exercises >> >> In order to use CI-Tutor courses and exercises involving MPI, you don't have to have access to XSEDE resources: you can run MPI on your own machine. Simply install your favorite implementation of MPI, if one is not already pre-installed. >> >> To find out whether MPI is already installed, run a query. For instance, on distributions that support rpm packaging: >> >> [arnoldg@lgheron ~]$ rpm -q openmpi >> openmpi-1.3.1-1.fc11.x86_64 >> OpenMPI (http:\\www.open-mpi.org) is a popular MPI implementation easily available for most Linux distributions. You must have root privileges in order to install OpenMPI on your system. The website includes tarballs and source code that you can download and use to build OpenMPI manually, or (if you are a relatively new Linux user) you can use the software management package that is included with your distribution. Below, we include example instructions for downloading and installing OpenMPI using the software management packages for two commonly-used Linux distributions, Fedora and Ubuntu. >> >> For example, to download and install OpenMPI on a machine running Fedora (or another RedHat-based distribution), you should be able simply to run the yum package manager: >> >> # yum install openmpi openmpi-devel openmpi-libs >> On an Ubuntu or other Debian-based distribution, you use the Synaptic or Aptitude package manager, either with the graphical user interface provided, or with the command line, e.g.: >> >> # apt-get install openmpi openmpi-dev openmpi-devel >> CAEN Advanced Computing >> XSEDE Campus Champion >> >> brockp(a)umich.edu >> >> (734)936-1985 >> >> >> >> On Dec 11, 2013, at 10:50 AM, Junchao Zhang >> <jczhang(a)mcs.anl.gov> >> wrote: >> >> >>> Hello, Mark, >>> Yes, you can install the latest mpich ( >>> http://www.mpich.org/downloads/ >>> ) and run it on your laptop. >>> Do a google search, there are many MPI tutorials. I used this one when I started to learn MPI, >>> https://computing.llnl.gov/tutorials/mpi/ >>> >>> >>> --Junchao Zhang >>> >>> >>> On Wed, Dec 11, 2013 at 8:54 AM, mark >>> <dimitsas.markos(a)gmail.com> >>> wrote: >>> Hello from Greece! >>> Being new in this field, what would be a good starting point to master MPI and parallel programming in general? First of i don't have a cluster, so all the computations are going to happen to a modern day linux laptop. >>> However if i get familiar with MPI, i will have the chance to work with a cluster remotely on some text retrieval algorithms (yea right :P) for my bachelor thesis. >>> So, looking for starting points and speed learning about MPI (and parallel programming) in general. >>> Any tips and advices are welcome.Thank you :) >>> >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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