Linux Intel Fortran 2017 Update 1: problem with MPI mod files

Linux Intel Fortran 2017 Update 1: problem with MPI mod files

Prior to 2017 Update 1, all worked well.

After 2017 Update 1, when compiling I get the error:

     error #7013: This module file was not generated by any release of this compiler.   [MPI]

which is associated with the line

     use MPI

Do I now need to "build" these mod files (the same way that I have to build the interfaces to LAPACK95 and BLAS95)?

 

Thread Topic: 

Bug Report
18 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Whose MPI provided the module, since that's not a component of Intel Fortran. It could be Intel MPI if you have the Cluster Edition.

What is the include path for this compile? Please attach a .gzipped version of the mpi.mod you think it is referencing.

Retired 12/31/2016

It's Intel MPI; I installed the Cluster Edition.

Here are my environment variables that include the string INTEL:

INTEL_BASE_PATH=/opt/intel/compilers_and_libraries/linux
INTEL_LICENSE_FILE=/opt/intel/compilers_and_libraries_2017.1.132/linux/licenses:/opt/intel/licenses:/home/pgomme/intel/licenses
INTEL_MKL_PATH=/opt/intel/compilers_and_libraries/linux/mkl/lib/mic
INTEL_PYTHONHOME=/opt/intel/debugger_2017/python/intel64/
INTEL_TARGET_ARCH=intel64
INTEL_TARGET_PLATFORM=linux

(Is there an easier way to determine my include path?)

Here's something that works: I compiled with

-I/opt/intel/compilers_and_libraries_2017.1.132/linux/mpi/intel64/include/

Compiler success also using

-I/opt/intel/compilers_and_libraries_2017.1.132/linux/mpi/mic/include/

And, failure if I use

-I/opt/intel/compilers_and_libraries_2017.1.132/linux/mpi/mic/include/gfortran/4.7.0/

Not surprising since I'm not using the GNU Fortran compiler.

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.

Paul

 

How are you establishing the compiler environment? INCLUDE is the environment variable it looks for.

Retired 12/31/2016

echo $INCLUDE yields nothing (i.e., blank). I use my own environment variable (so that I don't tromp all over default environment variables), MY_INCLUDE; its value is

-I/opt/intel/compilers_and_libraries/linux/mkl/include/intel64/lp64 -I/home/pgomme/f90/Library -mkl=parallel

In case it helps, here's the command that's being run to compile my program:

mpif90 model4mpi.f90 ql.o nlpqly.o nlpqlp.o -I/opt/intel/compilers_and_libraries/linux/mkl/include/intel64/lp64 -I/home/pgomme/f90/Library -mkl=parallel -o model4mpi -O0  -L/home/pgomme/f90/Library -lgomme -lmkl_lapack95_lp64 -lmkl_blas95_lp64

And here are lines from my .bashrc file:

export I_MPI_F90=ifort
INTEL_BASE_PATH=/opt/intel/compilers_and_libraries/linux
INTEL_MKL_PATH=$INTEL_BASE_PATH/mkl/lib/intel64
# For MPI programming
source $INTEL_BASE_PATH/mpi/bin64/mpivars.sh
source $INTEL_BASE_PATH/bin/compilervars.sh intel64

export MY_LIBS="-L$HOME/f90/Library -lgomme -lmkl_lapack95_lp64 -lmkl_blas95_lp64"
export MY_INCLUDE="-I$INTEL_BASE_PATH/mkl/include/intel64/lp64 -I$HOME/f90/Library -mkl=parallel"

export PROFILE_INCPATHS=$MY_INCLUDE
export PROFILE_PRELIB=$MY_LIBS

Paul

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.

Retired 12/31/2016

ifortvars.sh is symlinked to compilervars.sh which I'm already sourcing.

I know that the compiler doesn't know about MY_INCLUDE; I use it in my Makefile.

Here's the thing: The original release of Intel Fortran 2017 works just fine. The update evidently "breaks" something. 

You'll need to identify which .mod it's complaining about. Adding -list and examining the .lst file for the list of options might provide a clue.

Retired 12/31/2016

I hate to disagree with Steve, but the compiler does not use an INCLUDE environment variable on Linux.  

Add "-dryrun" (without the quotes) to your command, and post the output please.   You can obfuscate your directory names if you want, but  keep ours of course.

What is happening is that one of those 20 mpi.mod files is being found in one of the directories added by -I<dir> and that incorrectly-found mod file was not compiled for Intel64.

           We just need to figure out why.

                       thanks --

                                            --Lorri

 

I was misled by the documentation - sorry about that. Lorri is, of course, correct.

Retired 12/31/2016

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

-I/opt/intel/compilers_and_libraries_2017.0.098/linux/mpi/intel64/include/gfortran

(which as 8 subdirectories and nothing else) while the one that doesn't work (the update 1) reads

-I/opt/intel/compilers_and_libraries_2017.1.132/linux/mpi/intel64/include/gfortran/5.1.0

which points to a directory with 4 mod files (mpi.mod, mpi_base.mod, mpi_constants.mod, mpi_sizeofs.mod).

One work around I found was to copy the relevant mod files into /usr/local/include.

Paul

 

 

Attachments: 

AttachmentSize
Downloadtext/plain make_2017.txt15.95 KB
Downloadtext/plain make_2017_update1.txt15.93 KB

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.

Retired 12/31/2016

Steve,

Several things.

(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.

(2) My desktop machine (make_2017.txt) compiles just fine. So, it seems that there's some change in update1.

(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. 

Paul

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.

Retired 12/31/2016

In Intel MPI, mpif90 without the -fc=ifort option invokes gfortran.  This won't play with ifort (not only because of the incompatible .mod files).  Use the fc option or the mpiifort spelling.

mpiifort works. Thanks. Feel free to close this topic (I don't see that I can do so).

Paul

Hi all,

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.

To reproduce:

bash:~$ source /path/to/psxevars.sh # located in <install-dir>/parallel_studio_xe_<version>.x.xxx/bin
bash:~$ export I_MPI_F90=ifort # should cause mpif90 to use ifort instead of gfortran
bash:~$ mpif90 -show
bash:~$ mpiifort -show

The last two commands should return identical build commands. They don't.

An extra "/gfortran" is incorrectly attached to the end of the include string.

 

One workaround is to modify your build script to use mpiifort instead of mpif90.

 

I believe this issue can be fixed by editing the mpif90 script (vim `which mpif90`), and replacing the line:

modincdir="${modincdir}/gfortran${gver}"

with this slight modification

if [ "$FC" = gfortran ]; then
    modincdir="${modincdir}/gfortran${gver}"
fi

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.

Quote:

Sean D. wrote:

Hi all,

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.

To reproduce:

bash:~$ source /path/to/psxevars.sh # located in <install-dir>/parallel_studio_xe_<version>.x.xxx/bin
bash:~$ export I_MPI_F90=ifort # should cause mpif90 to use ifort instead of gfortran
bash:~$ mpif90 -show
bash:~$ mpiifort -show

The last two commands should return identical build commands. They don't.

An extra "/gfortran" is incorrectly attached to the end of the include string.

 

One workaround is to modify your build script to use mpiifort instead of mpif90.

 

I believe this issue can be fixed by editing the mpif90 script (vim `which mpif90`), and replacing the line:

modincdir="${modincdir}/gfortran${gver}"

with this slight modification

if [ "$FC" = gfortran ]; then
    modincdir="${modincdir}/gfortran${gver}"
fi

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.

-Nick

Leave a Comment

Please sign in to add a comment. Not a member? Join today