VS 2015 and MKL for Intel Fortran 2019-045-053

[Groundsel]

I am presently trying to migrate a Fortran based solution using Intel 2019-045-053 in Visual Studio 2015.  One of my programs requires the GESV routine in the Math Kernel Library.  How do I set up a suitable MKL for this application?  (The old configuration used VS 2010 with Intel 2013-1-119..)  I have tried to find another such query - but have not found anything I can comprehend.

Cheers!
Tom Stevens

[mecej4]

The generic name GESV gets resolved to specific Fortran 95 wrapper routine names. To use such generic names, your code must contain a USE LAPACK95 statement, and you should specify that the Lapack95, BLAS95 and MKL libraries be used at link time.

If building from Visual Studio, in the project properties you need to check (and, if not set, set) the MKL include directory, and select the MKL libraries. In addition, specify mkl_lapack95.lib and mkl_blas95.lib as additional inputs to the linker.

See https://software.intel.com/en-us/mkl-windows-developer-guide-configuring-intel-visual-fortran-to-link-with-intel-mkl and other related pages for details.

[Groundsel]

That is a pretty good description of what I was doing on the old configuration:  VS 2010 on Windows 7 and Intel Fortran 2013_sp1.3.202.  My trouble was not in how to use the MKL - but to "activate it" (or should I be saying "get it").  From what you are saying above, can I infer that the Fortran being used with VS 2015 will have its MKL directories installed with it?  If so, where should I look.  (I am looking to do X64 builds.)

[mecej4]

There is nothing to "activate". If you chose to have MKL installed as part of Parallel Studio (or Fortran Composer), MKL will have been installed.

If you open an Intel Fortran x64 command window and enter the command set MKL , you should see the environment variable MKLROOT expanded to the directory path where MKL was installed. If, instead, the response is Environment variable MKL not defined, the installation is not complete, perhaps, and you need to search for the MKL files. Usually, the MKL directory is at <Parallel_Studio_root_directory>\windows\mkl .

There is also a batch file called mklvars.bat that can be used to set up the MKL environment for use with a C compiler, but that batch file is automatically run from the ifortvars.bat or compilervars.bat file that is run when you open an Ifort command window from the Start menu.

[JohnNichols]

One suggestion is to download the VS2017 or 2019 community editions and then reinstall Intel Fortran.  It tells you all the batch files to run, you now need to download the MKL samples separately - no idea why - I then find the sample for the routine you want to use and copy the bits you need. Very easy as long as you turn on the switch to use the MKL in the project properties. I just did that for a Monte Carlo Simulation and it worked a treat with MKL routines. 

Of course if you have a work computer that you are not allowed to touch -- then you have other problems -- my suggestion is to try it all on a home computer - unless you are in a secure environment, DOD etc.., and then I would ask GOD for help, although I have found that Steve as the left hand of god can solve just about anything and mecej4 as the right hand can solve anything.  Of course this is the correct place to ask these questions. 

[Groundsel]

Thanks John,

That makes a good Plan B.  Before I "tear up" what I have managed with VS 2015, however, can anyone tell me which property among a project's settings should contain the MKL include directory.   I believe I have found it for Intel Fortran 2019-045-053 to be:

C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2019.1.144\windows\mkl\include

Fortunately, I do have admin privilege on my technical PC; so I can discover that.  It appears to me that the right stuff appears in this Include directories subdirectories: intel64\ilp64 and intel64\ip64.  I am hoping that VS 2015 will know what to do when I get down to the include.  I need, however, to know what property to try this on.

Cheers!

Tom Stevens

[JohnNichols]

it is in the properties page -- see picture 

C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\mkl\bin

This is the location to start rummaging in - mklvars bat is here.  

Try one of the sample MKL programs in a new solution and get it working that usually shows you the errors quickly.  

I suggest the move to vs 2017, they dual load and it is a much better interface 

[Groundsel]

I have noted the property caught in your picture and set that property to Sequential/Qmksequential.  I am still getting not found messages for lapack95 or mkl_lapack95 whichever I use.  I think it is time I took up your VS 2017 suggestion.  My reason for switching from VS 2010 is that the local folk-lore has Microsoft stopping support after 10 years meaning that VS 2010 has limited life expectancy.  Presumably, the time horizon for VS 2017 will be further into the future than for VS 2015.  So, if it is easier to apply than is VS 2015, it becomes a no brainer to use it in preference.

Thank-you all for your suggestions.

Cheers!
Tom Stevens

[JohnNichols]

Here is a fairly simple and standard MKL program that I developed over the last week. It includes everything set up as a 2017 sln file,  you can see if it runs, but do download vs 2017 community and reinstall Intel Fortran 

[mecej4]

Older versions of MKL (such as 2013_sp1.3.202), in contrast to current versions of MKL, did not come with prebuilt Lapack95 and BLAS95 libraries. The source files and makefiles to build those libraries and their associated module files were provided with the package, along with a batch file that you executed once for each architecture of interest (selected from IA32, LP64, ILP64). 

[gib]

I wouldn't be too concerned about support for VS 2010 if I were you.  I am still using both VS 2005 and VS2010.  I have never needed any support from Microsoft.  There could be other good reasons for switching to a more recent VS, of course.

[Groundsel]

I have VS 2015 working for us, sort of.   It is nothing like as convenient as was VS 2010 with earlier Fortran releases.

1. Our principal use is on a solution with 93 projects.  Some of them are dll's and some exe's which need the dll's.
2. These are executed in a single application directory containing the entire suite of assemblies along with scripts (vbs and bat's) managed by a graphic user interface (GUI).  Not all the executable or library names are of the default form projectname.exe or prolectname.dll. 
3. Under VS 2010, I used to be able to make the output target directory the single execution directory.  They would be mapped there at the time of creation along with their manifest files which would be automatically embedded.
4. I have not yet found a way to make VS 2015 do step 3.  It leaves the manifest file behind and then can't embed it.  I have tried various combinations of linker and manifest tools properties but none seem to work.  I keep getting messages that something or other (manifest or executable) can't be found.
5. Only by letting everything default so that the assembly has the name project.exe or project.dll. as befits the case, and letting all the target and intermediate directories be assigned by default could I get clean builds.
6. I had to write assemblies.vbs to copy all the assemblies created in their respective default target folders into the executable folders with their proper names expected there.
7. I find myself having to do a rebuild (project only) when a simple build used to be sufficient.  So I have made a change to one routine within a project and I have to rebuild the project; not just a simple build command for the project which compiles the changed routines only and then builds the assembly.

I shall keep playing around with it but may revert to VS 2010.. It is not obvious to me why the ground rules (perhaps defaults) have been changed.  To be sure, I did have to clean manifest files from the execution directory every once in a while.  But that was a simple delete with wild cards from a command prompt window.  That looks pretty good in place of the rigmarole induced by these changes in Visual Studio.

Cheers!
Tom Stevens