Much appreciated, guys. I am a middle man in a discussion over whether MPI should be handled by apps people or system people and there was some confusion when we saw RHEL6 had an RPM for OpenMpi. Your comments make it clear that there is a pretty strong preference to build OpenMpi on the system to be used, with the compilers that match your apps compiler. Just a prereq for supporting a development environment
-------- Original message -------- From: Tim Prince <n...@aol.com> Date: To: us...@open-mpi.org Subject: Re: [OMPI users] EXTERNAL: Re: basic questions about compiling OpenMPI On 5/25/2013 8:26 AM, Jeff Squyres (jsquyres) wrote: > On May 23, 2013, at 9:50 AM, "Blosch, Edwin L" <edwin.l.blo...@lmco.com> > wrote: > >> Excellent. Now I've read the FAQ and noticed that it doesn't mention the >> issue with the Fortran 90 .mod signatures. Our applications are Fortran. >> So your replies are very helpful -- now I know it really isn't practical for >> us to use the default OpenMPI shipped with RHEL6 since we use both Intel and >> PGI compilers and have several applications to accommodate. Presumably if >> all the applications did INCLUDE 'mpif.h' instead of 'USE MPI' then we >> could get things working, but it's not a great workaround. > No, not even if they use mpif.h. Here's a chunk of text from the v1.6 README: > > - While it is possible -- on some platforms -- to configure and build > Open MPI with one Fortran compiler and then build MPI applications > with a different Fortran compiler, this is not recommended. Subtle > problems can arise at run time, even if the MPI application > compiled and linked successfully. > > Specifically, the following two cases may not be portable between > different Fortran compilers: > > 1. The C constants MPI_F_STATUS_IGNORE and MPI_F_STATUSES_IGNORE > will only compare properly to Fortran applications that were > created with Fortran compilers that that use the same > name-mangling scheme as the Fortran compiler with which Open MPI > was configured. > > 2. Fortran compilers may have different values for the logical > .TRUE. constant. As such, any MPI function that uses the Fortran > LOGICAL type may only get .TRUE. values back that correspond to > the the .TRUE. value of the Fortran compiler with which Open MPI > was configured. Note that some Fortran compilers allow forcing > .TRUE. to be 1 and .FALSE. to be 0. For example, the Portland > Group compilers provide the "-Munixlogical" option, and Intel > compilers (version >= 8.) provide the "-fpscomp logicals" option. > > You can use the ompi_info command to see the Fortran compiler with > which Open MPI was configured. > > Even when the name mangling obstacle doesn't arise (it shouldn't for the cited case of gfortran vs. ifort), run-time library function usage is likely to conflict between the compiler used to build the MPI Fortran library and the compiler used to build the application. So there really isn't a good incentive to retrogress away from the USE files simply to avoid one aspect of mixing incompatible compilers. -- Tim Prince _______________________________________________ users mailing list us...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/users
