On May 23, 2013, at 9:50 AM, "Blosch, Edwin L" <edwin.l.blosch_at_[hidden]> 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
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.
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/