IMSL library call to Intel MKL

[Scott_Graham]

Hi,

I've recently re-compiled some code which uses the Intel MKL and the IMSL libraries.  The code  had compiled and run correctly under earlier releases of the compiler & MKL.  There is a call from c:\Program Files (x86)\VNI\imsl\fn701\Intel64\lib\imslmkl_dll.dll to a routine in the MKL which is not being found.  Has something changed in the new release of MKL which makes it no longer compatible with IMSL 7.01.  ?  Also when will there be a new release of the IMSL libs ?

Thanks!

[mecej4]

Please name the symbol that was not found by the linker.

The IMSL versions from Roguewave (and, similarly, the NAG FL) libraries, and quite a few packages such as Matlab, come with their own re-distribution of MKL DLLs. It is important that these copackaged MKL DLLs occur first in %PATH% before any other MKL version DLLs that also exist on your machine. Normally, this is taken care of by the start-up batch file for IMSL (fnlsetup.bat).

I recognize that you have the IMSL version that is distributed by Intel, and I expect it to be compatible with any recent version of MKL.Since the IMSL version from Intel is several years old (Roguewave is now at FNL 2018.), it is possible that some discrepancies may have crept in, and they can be looked at if you can describe how to reproduce the problem.

Note: you have posted this problem report in the IFort for Linux and Mac OSX forum, rather than in the IFort for Windows forum. Intel does not distribute IMSL with the Linux Fortran compiler, and DLLs pertain to Windows. 

[Scott_Graham]

Hi - Thanks for the prompt response.  My apologies for posting on  the incorrect forum.  I am happy to move this over into the Windows based forum if you prefer.

The Error is - "ENTRY POINT NOT FOUND.

The procedure entry point mkl_lapack_ao_zunmqr could not be located in the dynamic link library C:\Program Files (x86)\VNI\imsl\fn701\INtel64\imslmkl_dll.dll. " 

I don't believe I did any thing different this time when updating the FORTRAN compiler or MKL.  The compiler version is 18.0.3.210[Intel(R) 64]

 Thanks!

[mecej4]

The _ao_ prefix signifies that you wish to use the "auto_offload" feature of MKL and enable execution of Lapack zunmqr on the Xeon Phi coprocessor. This would require that you have the appropriate hardware and software for Xeon Phi.

If that is correct, you may have to re-post your question in the MKL forum or in the Xeon Phi forum. I do not have access to or experience with Xeon Phi.

I can see from https://software.intel.com/sites/default/files/11MIC42_How_to_Use_MKL_Automatic_Offload_0.pdf (refers to an older version of MKL) that only a subset of BLAS and Lapack functions are available with the AO feature.

[Scott_Graham]

Hi - I'm not intentionally calling anything associated with Xeon Phi.  However I have compiler options set for parallel execution, speed optimization etc. to take advantage of a multi-processor workstation.  If this is an internal call from the IMSL libraries to Intel MKL lapack routines I don't have any insight there...  The code used to compile and run fine under a the FORTRAN and MKL release 3-4 releases ago. So I suspect either pathing has changed in how the default install is done and I need to update path variables, or the new MKL is not 100% backward compatible to the older IMSL libs.  

[mecej4]

Do you have a reference to zunmqr in your sources? What are the commands/steps that you use to build? Which version of the compiler are you using?

If you do not have a Xeon Phi coprocessor (usually, a PCIEx card) on your PC, that call to mkl_lapack_ao_zunmqr should not have occurred. Does your environment contain any of the Phi-related variables set  (such as those mentioned in https://software.intel.com/en-us/articles/recommendations-to-choose-the-right-mkl-usage-model-for-xeon-phi) ?

Is it possible to share your source code (a cut-down version, just big enough to exhibit the problem, is preferred) ?

[Scott_Graham]

Hi - I'll try to chase down the exact calls via the debugger and see if I can find the re-create the problem in a sample code.  Thanks for the help!

[Scott_Graham]

Hi - I tried compiling for debug mode but the code doesn't launch.  So I searched the entire solution directory and there aren't any references to zunmqr.  I've attached a couple of JPGS which have the compiler options and linker options being used.   I'm currently using ver 18.0.3.210 of the compiler.   I've also attached some jpgs of the compiler and liker options from ver 16.0 of the compiler when all worked fine.   As best I can tell I was able to compile and run OK up through the version with MKL 18.0.124 (released approx 9/2017).  The only significant difference I see in the options is that with the newer version I am using /QaxSSE3.  The code is now being compiled for an Xeon 2687W based workstation instead of an older 1150 (?) processor. 

I haven't tried to re-compile the code since about 11/2017 and haven't altered it.  I just tried to keep up to date with the compiler releases and install those.  So nothing in the compiler/linker settings was changed since it was last successfully compiled and run in 11/2017.

Thanks again for the help.

[mecej4]

The Linker screenshots show a new twist: the specification of CUDAxxx libraries. Do you have one or more Nvidia graphics-coprocessor boards on your Xeon system? If not, why were the CUDA libraries specified to the linker?

[Scott_Graham]

Hi - I have a GE Force Graphics card that I use for large full matrix solutions using the CUDA libraries

[mecej4]

You seem to have a rather complex combination of software packages, and it is difficult to troubleshoot such a combination without having a similar setup locally. The version of IMSL 7 distributed by Intel contains only one CUDA library: imslblas_cuda.lib; no CUDA Lapack, no CUDA IMSL, and certainly no Xeon Phi /MIC libraries.

If I were in your position, the approach that I would take is to use the latest IFort and IMSL, leaving out MKL and CUDA libraries. Only if this configuration builds and runs does it make sense to cut in MKL and CUDA, improving performance without hurting functionality.

[Steve_Lionel]

If I recall correctly, the IMSL supplied by RogueWave to Intel omits all CUDA support. If you obtained IMSL separately, it does have CUDA support.

[Scott_Graham]

I have the Intel version of IMSL.  I put together my own Fortran routines (w/some CUDA guru help...)to call the CUDA library routines for large matrix solves.

Since I need the code to run, I did a "repair" install of ver 18.0.0.124, re-compiled and all worked fine.  I then noticed that the newer compiler releases were still available in VS 2015 so I re-compiled using 18.0.1.156,  then18.0.2.185, and then 18.0.3.210.  The code ran fine each time.  At this point I wasn't sure what got "fixed" but had the code gong again.  I then tried a "repair" installation of 18.0.3.210, re-compiled and got the same entry point error described above.  I then again did a "repair" install of 18.0.0.124, re-compiled and the code ran fine.  I tried 18.0.3.210 again and got the same error.  So I did another install of 18.0.0.124 to get things running again...  I did not try incremental "repair" installations of 18.0.1.156, or 18.0.2.185 but its possible that either of those may have also worked.

So it appears that the "repair" install process of 18.0.0.124 leaves the computer and/or VS 2015 in a state where it finds compatible versions of the compiler, MKL, and IMSL,  however the 18.0.3.210 "repair" install or install process does not.  VS 2015 allows you to select which compiler version is used, but I don't know which MKL version gets used... Is it possible VS 2015  is using the latest version of the compiler, but the 18.0.0.124 release of MKL ?  The IMSL ver 7.01 installation is the same.  

Hope that helps!
Scott

[Steve_Lionel]

Check your system PATH variable - the Intel Parallel Studio install doesn't add MKL DLLs to PATH and you may be pointing to something old.

[Scott_Graham]

 Hi Steve,
Thanks for your help!  I checked my path variables and the IFORT_COMPILER18 was set equal to"...18.0.124"  I tried changing it to "...18.3.210", restarted the computer, re-installed update 3 (18.3.210), re-compiled and got the same entry point error.  Interestingly also I tried running a version of the code (older *.exe file) that had previously run, and got the same entry point error as when the most recent install was set to 18.3.210.  I then re-installed 18.0.124, changed the path back to "..18.0.124 re-compiled and all was happy again...  I've attached a screen shot of the environment variables if that is of any help.  The common denominator is when 18.3.210 is the most recent install I get the entry point error, regardless of what the path variable was set to, and a version of the code that ran and was compiled when 18.0.124 was the most recent install, would not run after 18.3.210 was the most recent install.  Some dll/runtime in-compatibility somewhere ? 

Thanks Again,
Scott

[Steve_Lionel]

mecej4, in reply #2, has what I think is the right idea. IMSL links to MKL and assumes a particular set of MKL routines are available. Unfortunately, MKL has been willing to remove or incompatibly change APIs, which is horrifying to me.

I can think of a couple of options. One is to link to the IMSL variant that doesn't use MKL. I've been away from this for a while, but I think there is an include file with a name ending in _IMSL that lists the variant libraries. You could also link to the static IMSL libraries (and thus static MKL.)

I would also put in a complaint in the MKL forum about removal of a routine in a minor update (or at all.) For me, being a former run-time library developer (back in my DEC days), upward compatibility of libraries was an inviolable rule. Sadly, not all the Intel performance library teams subscribe to this notion.