I haven't attached any mpi.mod files since I'm not all sure which one I should attach (running find tells me there are 20 mpi.mod files installed under /opt/intel). Clearly, the ones associated with the intel64 and mic directories are OK. I guess the question is why the compiler isn't seeing these. I've run a diff on mpif90 between the original release of the product (2017.0.098) and update 1 (2017.1.132) and see nothing that seems wrong.

The compiler looks at INCLUDE. It knows nothing about MY_INCLUDE. You're including only MKL files, not Intel MPI or the compiler's own modules. I don't know what the mpif90 command adds.

I recommend using the provided ifortvars.sh (.csh) file, "source" it to get the appropriate things set up. You should also check the Intel MPI documentation to see what, if anything, you need for its environments.

I'm attaching 2 files. make-2017.txt is from my desktop (with the 2017 product installed, no update). make_2017_update1.txt is from another machine with the 2017 update 1 applied. I took a quick look and noticed that the one that works (2017 no update) has an include that has a line

Attachments:

It reads to me as if a gfortran install got put in on top of Intel Fortran. There should be NO gfortran folders or files inside an Intel compiler install. This is not normal. The compiler is seeing the gfortran version of mpi.mod and appropriately complaining.

(1) The machine that I used to give you the output from make_2017_update1.txt is a pretty clean install of Linux Mint 18. I can check (later) if Linux Mint installs gfortran by default. Certainly, I didn't install it on my own.

(3) Why should the Intel Fortran installer "care" that gfortran is installed on my machine. Maybe I need gfortran for instructional purposes. Maybe I want to compare the performance of gfortran relative to Intel Fortran.

Ok, I think I see now. It's Intel MPI that installed gfortran .mod files under its part of the tree, and it's Intel MPI that is "polluting" the ifort command with the gfortran-compatible .mod files. I'm not familiar with how Intel MPI does its install and configuration to know if that's a bug or something else. I'm going to move this to the Clustering Technology forum to get an Intel MPI expert to take a look.

Sorry this thread is a little old. I think this highlights a bug in the mpif90 script / wrapper.

When we set I_MPI_F90=ifort, we expect the underlying compiler for the mpif90 wrapper to switch to ifort, so that programmers don't need to change their build scripts when switching between intel and gnu compilers. This almost works, except for one small bug.

The gfortran include directory should only be included if gfortran is the underlying compiler. I'm not able to test this on my system, as I am not the administrator. Perhaps someone from Intel could comment on the validity.

Sorry this thread is a little old. I think this highlights a bug in the mpif90 script / wrapper.

When we set I_MPI_F90=ifort, we expect the underlying compiler for the mpif90 wrapper to switch to ifort, so that programmers don't need to change their build scripts when switching between intel and gnu compilers. This almost works, except for one small bug.

The gfortran include directory should only be included if gfortran is the underlying compiler. I'm not able to test this on my system, as I am not the administrator. Perhaps someone from Intel could comment on the validity.

Thanks for pointing out this issue and workaround. We were seeing the same issue (and opened a ticket

about it, still waiting on a response).

The really funny thing about this is that the mpif90 from 2017.0.098 only worked correctly because of

another bug that prevented the correct modincdir to be added for gfortran (otherwise this would

have been broken earlier). I get that Intel appears to want everyone to use mpiifort rather than

mpif90, but we have a lot of legacy software that would need a lot of changes just to use the

newer versions of Intel compilers and MPI. It seems to me that fixing mpif90 is the way to go.