For version 11.1, please see Intel Fortran Compiler 11.1 Release Notes

To get product updates, log in to the Intel® Software Development Products Registration Center.

For questions or technical support, visit Intel® Software Developer Support

Update 8 - December 2011
Intel® Fortran Composer XE 2011 for Linux*

• English

Intel® Fortran Composer XE 2011 for Mac OS X*

• English

Intel® Visual Fortran Composer XE 2011 for Windows*

• English

Update 7 - October 2011
Intel® Fortran Composer XE 2011 for Linux*

• English
• Japanese

Intel® Fortran Composer XE 2011 for Mac OS X*

• English

Intel® Visual Fortran Composer XE 2011 for Windows*

• English
• Japanese

Update 6 - September 2011
Intel® Fortran Composer XE 2011 for Linux*

• English

Intel® Fortran Composer XE 2011 for Mac OS X*

• English

Intel® Visual Fortran Composer XE 2011 for Windows*

• English

Update 5 - July 2011
Intel® Fortran Composer XE 2011 for Linux*

• English

Intel® Fortran Composer XE 2011 for Mac OS X*

• English

Intel® Visual Fortran Composer XE 2011 for Windows*

• English

Update 4 - May 2011
Intel® Fortran Composer XE 2011 for Linux*

• English

Intel® Fortran Composer XE 2011 for Mac OS X*

• English

Intel® Visual Fortran Composer XE 2011 for Windows*

• English

Update 3 - March 2011
Intel® Fortran Composer XE 2011 for Linux*

• English
• Japanese

Intel® Fortran Composer XE 2011 for Mac OS X*

• English

Intel® Visual Fortran Composer XE 2011 for Windows*

• English
• Japanese

Update 2 - January 2011
Intel ® Fortran Composer XE 2011 for Linux*

• English

Intel® Fortran Composer XE 2011 for Mac OS X*

• English

Intel® Visual Fortran Composer XE 2011 for Windows*

• English

Update 1 - December 2010
Intel® Fortran Composer XE 2011 for Linux*

• English
• Japanese

Intel® Fortran Composer XE 2011 for Mac OS X*

• English

Intel® Visual Fortran Composer XE 2011 for Windows*

• English
• Japanese

Initial Product Release - November 2010
Intel® Fortran Composer XE 2011 for Linux*

• English

Intel® Fortran Composer XE 2011 for Mac OS X*

• English

Intel® Visual Fortran Composer XE 2011 for Windows*

• English

Intel® Visual Fortran Composer XE 2011 for Windows* (Intel® Visual Fortran) integrates with Microsoft developer tools with the goal of providing outstanding application performance on Intel processors as well as with compatible processors from other manufacturers. Intel Visual Fortran is a full-language Fortran 95 compiler with a majority of Fortran 2003 features plus a wide range of popular industry extensions.

Intel Visual Fortran is the successor to Compaq* Visual Fortran (CVF) and comes from the same development team. Intel Visual Fortran is highly compatible with CVF andm for most customers. migrating is easy.  This article will lead you through the process.

In most cases, you can rebuild existing CVF applications with the new compilers without source changes, but some applications may need minor coding changes, and build methods may need minor adjustments. This article describes the key differences you are likely to encounter. For additional details, refer to the appropriate compiler release notes and the compiler documentation.

If you already have installed Microsoft Visual Studio 2010*, Visual Studio 2008*, or Microsoft Visual Studio 2005*, Intel Visual Fortran will integrate into that Visual Studio development environment allowing you to create, build and debug Fortran and mixed-language applications. If you do not have a supported version of Microsoft Visual Studio installed, Intel Visual Fortran will install Microsoft Visual Studio 2010 Shell to provide a rich development environment for Fortran programming on IA-32 and Intel® 64 systems. (Note that some license types of Intel Visual Fortran do not provide Microsoft Visual Studio 2010 Shell. Please read the compiler's System Requirements for details.)

The Intel Visual Fortran product can coexist on a system with CVF, and you can continue using the older product if you wish. However, Intel Visual Fortran does not integrate with Microsoft Visual Studio 6 environment used by CVF, whereas CVF does not integrate with the newer versions of Microsoft Visual Studio. The Intel and Compaq products install into separate folder trees and use separate registry variables.

All Fortran sources must be recompiled with Intel Visual Fortran; you cannot use CVF-compiled objects, modules, or static libraries with Intel Visual Fortran. You can, however, use CVF-built dynamic link libraries (DLLs) with applications compiled with the Intel Visual Fortran Compiler, as long as you do not try to share input/ output units across the two environments. Note also that third-party libraries built for use with CVF may not work with Intel Visual Fortran . Contact the library supplier for more information.

Common Features

Intel Visual Fortran supports all of the CVF language syntax, including extensions from Digital Equipment Corporation (DEC) Fortran and Microsoft Fortran PowerStation* 4. All CVF library routines are supported, including those from the QuickWin and Portability libraries, as are all of the system-interface modules. In most cases, a simple rebuild of the application with the Intel compiler is all that is needed. Source changes that you may need to make are described below.

Features Not Supported

Intel Visual Fortran supports all of the language syntax supported by CVF. However, some of the CVF product features are not supported by Intel Visual Fortran. These include the following:

• Compaq Extended Math Library. The Intel® Math Kernel Library or third-party libraries such as IMSL* and NAG* may be suitable alternatives. (Intel Math Kernel Library is provided with Intel Visual Fortran Compiler Professional Edition and the IMSL library is provided with Intel Visual Fortran Compiler Professional Edition with IMSL. Other products must be obtained separately.)
• Format editor tool.
• Save Fortran Environment tool.

If you have existing applications that were created by the CVF COM Server Wizard, you may be able to rebuild them with Intel Visual Fortran. If you need to make changes to the interfaces, you can do so in CVF if you have left it installed. CVF COM Server Wizard projects cannot be converted to Intel® COM Server Wizard projects.

Although Intel Visual Fortran supports all CVF language syntax, incorrect programs which were compilable with CVF may result in error messages when compiled with Intel Visual Fortran. If you encounter unexpected error messages and need assistance resolving them, please see Getting Help

Behavior Differences

Some applications may be affected by changes in defaults:

• Unlike CVF, the Intel Fortran compiler can check for mismatches in argument lists across multiple source files, unlike CVF which did this only within a single source file.  You may see more error messages when the program is built with Intel Fortran due to this enhanced checking.  If you need help understanding a particular error message, search for it on the Intel Software Network web site or ask for help in the user forum. As a last resort, you can disable this enhanced checking by disabling the options /gen-interface (Fortran > Diagnostics > Generate Interface Blocks) and /warn:interface (Fortran > Diagnostics > Check Routine Interfaces).
• In CVF, the default for local variables in procedures was that SAVE semantics were assumed.  This caused the compiler to allocate local variables in static storage, which had the side-effect of these variables usually having an initial value of zero, though this was not guaranteed.  The Intel Fortran compiler defaults to /auto-scalar, which means that scalar variables are allocated on the stack by default, while arrays and derived types are still allocated statically.  If your program assumed that a local variable was preserved across calls or that it was initially zero, this can cause incorrect run-time behavior.  The solution is to add a SAVE declaration for variables that should be preserved, and/or to add initialization where required.  To revert to the CVF semantics, add the option /Qsave (in Visual Studio, this is property Fortran > Data > Local Variable Storage > All variables SAVE.  As of version 11, projects converted from CVF projects have /Qsave added by default.
• In CVF, floating point arithmetic was always done using the "X87" instructions, which could lead to inconsistent values of expressions depending on optimizer choices.  As of version 11, Intel Fortran uses the SSE2 instructions by default, which is faster and more consistent, but may give different results for some computations.  If you see this issue, try setting the option /fp:source (Fortran > Floating Point > Floating Point Moel > Source).  If that does not resolve the issue, specify that the X87 instructions are to be used by specifying /arch:ia32 (Fortran > Code Generation > Enable Enhanced Instruction Set > No enhanced instruction sets)

If you are using Microsoft Visual Studio 2010 Shell, the following limitations apply:

• No Microsoft language processors such as Visual C++* or Visual BASIC* are supplied.
• CVF projects cannot be converted to Intel Visual Fortran projects. Instead, create a new Intel Visual Fortran project and add your sources to it.
• The Microsoft Visual C++ Resource Editor, used to create and edit dialog boxes, icons and version resources, is not provided due to licensing restrictions. A freeware alternative is ResEdit from www.resedit.net. If you have existing resource files, they can be used
• The Intel® C++ Compiler cannot be used in this environment.

These limitations do not apply when using a retail edition of Microsoft Visual Studio.

Intel Visual Fortran includes project-conversion wizards to make it easy to migrate from CVF. Note that the project conversion wizards are not available if you are using Microsoft Visual Studio Premier Partner Edition. The steps and illustrations below assume use of Visual Studio 2008. The process using other versions of Visual Studio is similar.

Conversion is a two-step process:

1. Open the CVF workspace in Visual Studio by right-clicking on the workspace's .DSW file and selecting Open With... Microsoft Visual Studio 2008. You will see a message similar to the following:

Figure 1. Initial Project Conversion Dialog

Click Yes To All to convert each project to a Visual C++ project in a "solution" (similar to a workspace).

2. In the right or left pane, you will see the Solution Explorer with the project(s) present. If you do not see the Solution Explorer pane, select View>Solution Explorer. At this point, the conversion to Fortran project(s) is not yet complete. For each project, right-click the project name and select Extract Compaq Visual Fortran Project Items.

Figure 2. Extract Fortran Project Items Dialog

The project will now be converted.

Figure 3. Converted Project

If the CVF project contains both Fortran and C sources, it must be converted into two single-language projects under a solution - one builds a static library and the other links to that library - because Microsoft Visual Studio does not allow multiple languages in a single project. The project conversion wizard asks you which language has the main (linkable) project, Fortran or C, and makes the appropriate adjustments. Figure 4 is an example of converting a mixed-language project.

Figure 4. Mixed Language Project Dialog Box

In this example, the main (executable) program is in C, so we select "The Visual C++ Project".

After conversion, the mixed-language project looks like Figure 5.

Figure 5. Converted Mixed Language Project

In the prior example, the CVF NODLL project was split into a C++ executable project named NODLL and an Intel Fortran static library project NODLL_lib. The conversion wizard automatically makes NODLL_lib a dependent of NODLL, so that the library is built first and then is linked into the C code.

If you convert a CVF project, the conversion wizard will change project settings from the default to enhance compatibility with CVF. An important change is the default calling convention: if it was "Default" in CVF, the conversion wizard changes it to "CVF." (The following section provides more information on calling conventions.) Unless you had a mixed-language application that depended on CVF-specific calling conventions, you should set the default calling convention back to the default, in most cases.

If your mixed-language project was a static library project, two static library projects will be created, one a dependent of the other. Visual Studio will automatically combine the child library with the parent when the solution is built.

The Microsoft Visual Studio Integrated Development Environment (IDE) is somewhat different from the one shared by CVF and some users may at first find it difficult to perform common tasks. This paper covers some of the major changes, but it is not comprehensive. For more information on using the IDE, see the MSDN Library* documentation that accompanies Microsoft Visual Studio. (If you are using Microsoft Visual Studio 2010 Shell, you can access the MSDN Library at http://msdn2.microsoft.com/en-us/library)

Projects and Solutions

In CVF (and Visual C++ 6.0), "projects" were placed in "workspaces." A CVF workspace was little more than a container for one or more projects and was not involved in the build process. A project built something (an EXE, LIB or DLL file in most cases), and it could contain both Fortran and C code. One project was always designated as "active."

In Visual Studio, projects are substantially the same, but a project can be associated with only one language. For example, if you add C files to a Fortran project, the C files will be ignored. A solution holds multiple projects, but it is different from a workspace because you can build a solution, which builds all of the contained projects in a specified, user-configurable order.

When you have a mixed Fortran and C application, you must put the Fortran code into a Fortran project and the C code into a C (or C++) project. The projects get built separately and then, if appropriate, they are linked together. If the old project was a static library, two static library projects are created, with the objects going into a combined .LIB file. In this case, it does not matter which project you select as being the "main" project.

Changing Settings

Changing settings in the new Visual Studio environment is different as well. Instead of a tabbed dialog box for Settings, there is a tree-view set of "Property Pages." Figure 6 shows a set of property pages for an example project.

Figure 6. Property Pages

In this example, the Fortran General Property Page is displayed. Current property values that are the defaults are shown bolded, and a brief description of the highlighted property is displayed at the bottom of the pane.

1. To change a property value that has specific options, click on the value. An arrow icon displays to the right of the value.
   
   

   Figure 7. Changing a Property

2. Click on the arrow to display the options and select the desired option. Properties that offer a list of items, such as Additional Include Directories in the example above, display a list icon (three dots).

3. 3. Click the icon to open a separate dialog box, where you can enter the values. If you have only one value, type it directly on the Property page. You can directly type properties that are a single text string. In some cases, an arrow icon is available to allow you to select "Inherit from project defaults."

Debugging with Intel Visual Fortran is similar to using CVF, but some of the controls are in different places.

1. To set a breakpoint, click in the left margin next to a statement; the red Stop icon displays. As with CVF, you must set at least one breakpoint, otherwise the program will run to completion when debugging starts.
2. To execute under the debugger, click the green triangle "Play" icon next to the configuration name.

Unlike in CVF, there is not a default button on the toolbar for "Start Without Debugging". You can access this function by selecting it under the Debug menu or by pressing Ctrl+F5. If you want to add the button, select Tools>Customize. In the Commands tab, select Debug under Categories and drag the Start Without Debugging button to the toolbar.

Figure 8. Setting a Breakpoint

While Intel has taken great care to avoid the need for source changes to permit "rebuild and go," a number of implementation differences between the Intel and Compaq compilers necessitate making changes for selected applications. For the latest information on changes, please refer to the Intel Visual Fortran Compiler Release Notes.

While the part of the compiler that handles Fortran syntax and semantics, often referred to as the "front end," is derived from CVF, improvements have been made in detecting incorrect usage, and you may find that the new compiler issues diagnostic messages

for certain usages where the older compiler did not. For example, the compiler now gives an error for a source that makes a call to a non-pure intrinsic such as RANDOM_NUMBER from inside a pure procedure. In such cases, you will need to correct the coding errors. If you believe a diagnostic is inappropriate, please see Getting Help.

Default Calling Conventions Have Changed

In CVF, the default calling mechanism was STDCALL, and routine names were ‘decorated ' by adding @n to the end, where n was the number of bytes of argument list. Intel Visual Fortran Compiler adopts the more common C calling mechanism used by versions 7.1 and earlier of the Intel Fortran Compiler. Routine names are still converted to uppercase by default, and a leading underscore is added, but there is no @n suffix.

Another change is the manner in which CHARACTER argument lengths are passed. In CVF, these were passed immediately following the address of the CHARACTER item, but in Intel Visual Fortran, all the lengths are passed at the end of the argument list. In other words, the default has changed from /iface: mixed_str_len_arg to /iface:nomixed_str_len_arg.

If you have a Fortran-only application, this change may not be important to you. If, on the other hand, you have a mixed-language application, you need to be aware of the impact of the change in compiler default. You can tell the compiler to use the CVF default on the External Procedures property page, or with the /iface:cvf command-line switch.

A special case where the convention change matters is if your application uses "callback procedures". This is where you pass a routine name from your program as an argument to a library routine. Some kinds of library routines which use callbacks are Win_2 API and IMSL libraries, the QSORT routine from the Intel Fortran Portability Library, and also the USEROPEN keyword of the Fortran OPEN statement. Callback routines assume a specific calling convention and if there is a mismatch it can cause stack corruption and unpredictable results.

The Windows API always uses the STDCALL convention, so if you are passing Fortran routines to Windows API routines, be sure to add the directive

!DEC$ ATTRIBUTES STDCALL,REFERENCE :: routine-name

to the callback routine. Most other uses of callbacks, including the IMSL library, assume the compiler 's default conventions. If you encounter unexpected run-time errors, try setting the calling convention to "Default" to see if that resolves the issue.

GETARG, IARGC and NARGS Are Now Intrinsic

The command-line inquiry routines GETARG, IARGC and NARGS are now recognized as intrinsic procedures by the compiler. If your application source declares any of these names as EXTERNAL or provides an explicit procedure interface for them, you must remove those declarations to prevent link-time errors.

New Module Names for System and Library Declarations

Compaq Visual Fortran provided modules with definitions of Windows* API routines and symbols, as well as modules for Fortran library routines. These modules had names such as DFWIN, DFLIB, etc. Intel Visual Fortran provides compatible modules with the same names, but these are wrappers around modules with new names. You do not need to change your sources, but you should begin using the new names in new development. In DFLIB, symbols have been relocated into one of three new modules: IFCORE, IFPORT and IFQWIN.

You may find it useful to select the specific module containing the symbols you are interested in.

The individual Windows API modules such as KERNEL32 have the same names as in CVF. Note that new Win32 modules, such as PSAPI, have been added.

In most cases, you will not need to make changes in your build procedures. However, to provide for compatibility with future versions of Intel Fortran compilers, some changes are recommended. This section describes differences that affect building applications.

Compile Command is Now ifort

Under CVF, four command names were provided for invoking the compiler: df, f90, f77 and fl32. df and f90 were equivalent, f77 added options for compatibility with Compaq Fortran 77,and fl32 added options for compatibility with Microsoft Fortran PowerStation. In Intel Visual Fortran, ifort is the command name to invoke the compiler.

If you leave CVF installed on your system, it coexists with Intel Visual Fortran. When using the command line, be sure to use the appropriate shortcut in the Start menu to start your command session. For CVF, use "Fortran Command Prompt." For Intel Visual Fortran , use one of the selections under Intel Parallel Studio XE > Command Prompt. Each of these will establish the proper environment for the selected compiler. The IDEs are separate and do not interfere with each other.

Intel Visual Fortran Composer XE 2011 with IMSL 6.0*, includes the IMSL Fortran Numeric Library* 6.0 from Visual Numerics, Inc. In addition to many new and updated routines, the new version adds the following features not included in Compaq Visual Fortran Professional Edition:

1. Multithreaded libraries for improved performance on multi-core and multiprocessor systems..
2. DLL form of the libraries.
3. Support for the Intel® 64 architecture
4. New, unified interface modules making use of Fortran 95 generic interfaces and optional arguments.

The IMSL libraries are installed separarely from the compiler.  Please be sure to install the compiler first.

An existing application that uses the IMSL libraries will need few or no changes, unless you want to take advantage of the new features. You will need to make a change in how the application is built to reference the proper libraries. Below is an overview of this change. See the Intel Visual Fortran Compiler on-disk documentation under Building Applications, Using Libraries for additional details.

A change that may be needed is if your calls to the IMSL library pass callback routines. These are often used to evaluate user functions in "solver" routines. You must make sure that your callback routines use the default calling convention and not CVF 's STDCALL. See the above section on the change in calling conventions for more information.

Locating and Referencing the IMSL Libraries

In Compaq Visual Fortran, there was just one set of IMSL libraries: static and non-threaded. In Intel Visual Fortran Composer XE 2011 with IMSL, there are four sets of libraries with different names. Rather than explicitly list the libraries, as was commonly done with CVF, you should instead specify the path to the folder containing the libraries and use one of the supplied INCLUDE files to create a reference to the specific libraries required.

For additional options and details, please refer to the Building Applications manual on-disk documentation section on using the IMSL libraries (Building Applications > Using Libraries > Using the IMSL* Mathematical and Statistical Libraries).

Intel Visual Fortran Composer XE 2011 provides a rich feature set:

• Full support of Intel multi-core processors and 64-bit architectures
• Fortran 2003 and Fortran 2008 language features
• Quadruple-precision floating point REAL(16) and COMPLEX(32)
• Automatic parallelization
• OpenMP* support
• Advanced optimization for new Intel processors

For more information on these and other features, see the compiler Release Notes.

It is also the general rule that an executable or shared library built with one version of the Intel Fortran compiler can run on a system where shared libraries from a newer version have been installed.

While it is Intel's goal to maintain this "upwards compatibility", there are some cases where a recompile is required - usually due to an error in the earlier version.  This article lists and explains the known cross-version compatibility issues for the Intel Fortran compiler.

Note: Object code compiled with an Intel Fortran compiler version earlier than 8.0, or with any non-Intel Fortran compiler, cannot be mixed with code compiled with Intel Fortran 8.0 or later.

Version where behavior changed: 11.1
Operating System: Windows

In a mixed-version application, allocatable or pointer arrays that are allocated in code compiled by pre-11.1 compilers or by 11.1 and later compilers, must be deallocated in code compiled by the same version that allocated the array.  For example, consider the following main program:

program main
real(8), allocatable :: array(:)

interface
subroutine sub (a)
real(8), allocatable :: a(:)
end subroutine sub
end interface

allocate (array(100))

call sub(array)

print *, "Current size of array is ", SIZE(array)

deallocate (array)

end

and the following subroutine:

subroutine sub(a)
real(8), allocatable :: a(:)

if (allocated(a)) deallocate (a)

allocate (a(200))

a = 0

return

end subroutine sub

If the subroutine is compiled with version 11.0 and the main program is compiled with 11.1, when the program is run the result may be one of the following:

• An error message "Microsoft Visual C++ Debug Library - Debug Error! The block at [address] was allocated by aligned routines, use _aligned_free()"
  

• The application exits with no error message

• No error message is displayed, but the deallocate is ignored

The deallocate does not need to be explicit - it may be performed as part of an array assignment or an assignment of a derived type containing an allocatable array component.

The cause of the issue is a change in version 11.1 that causes all allocated memory to be aligned on 8-byte boundaries; this change is represented in the compiled object code and the alignment information is not attached to the allocated array. Different routines in the Microsoft C++ library are used to do aligned and unaligned allocates and frees and these cannot be mixed.  The explicit error message noted in the first bullet above is shown only when the application is linked with the "debug" libraries.

There is no known workaround for this issue other than recompiling the source so that the allocates and deallocates do not cross the 11.0-11.1 boundary.  This issue will be fixed in a future update to the Intel Fortran Compiler.

This page provides the current Installation Guide and Release Notes for the Intel® Fortran Compiler 11.1 products. All files are in PDF format - Adobe Reader* (or compatible) required.

To get product updates, log in to the Intel® Software Development Products Registration Center.

For questions or technical support, visit Intel® Software Developer Support

11.1 Update 9, July 2011 (IA-64 compiler update only)
Intel® Fortran Compiler Professional Edition for Linux*

• English

Intel® Fortran Compiler Professional Edition for Mac OS X*

• Not updated for Update 9

Intel® Visual Fortran Compiler Professional Edition for Windows*

• English

11.1 Update 8, December 2010
Intel® Fortran Compiler Professional Edition for Linux*

• English

Intel® Fortran Compiler Professional Edition for Mac OS X*

• English

Intel® Visual Fortran Compiler Professional Edition for Windows*

• English

11.1 Update 7, August 2010
Intel® Fortran Compiler Professional Edition for Linux*

• English

Intel® Fortran Compiler Professional Edition for Mac OS X*

• English

Intel® Visual Fortran Compiler Professional Edition for Windows*

• English

11.1 Update 6, April 2010

Intel® Fortran Compiler Professional Edition for Linux*

• English
• Japanese

• English

• English
• Japanese

• English

• English

• English

• English
• Japanese

• English

• English
• Japanese

• English

• English

• English

• English

• English
• Japanese

• English

• English
• Japanese

Software Requirement:
1. Intel® Visual FORTRAN Compiler Professional for Windows.  
The compiler was required to be installed and properly integrated to Microsoft VC 2005 or VC 2008.

2. Intel® MKL for windows
You can install the Stand alone MKL separately or the integrated MKL which comes along with Intel Fortran Compiler Professional version. 

3. Microsoft* Visual Studio 2005 or 2008. (MSVC*)
For who'd like to build x64 bit application, please install the MSVC* package which supports X64 development.

Step1 : Which kind of application: ia32, em64t or ia64 application you need to build?
Which target machine you need your application run on?
ia32: 32 bit application. 
EM64t: Intel® 64 bit application
IA64:  Intel® Itanium 64bit application.

Some more information what ia32 and intel64 Intel® architecture mean,  please see this article.

When build ia32 or em64t application on Intel®  XEON machine with windows*, in MSVC* environment, please check the project configuration manager=> active platform.  They should be  "ia32" or "X64" (which is corresponding to em64t).

Step 2 : Which MKL library you need link against?
2.1) please check the on-line KB article Intel® Math Kernel Library Link Line Advisor After choose it, you can get which libraries you need to list. 

For example,
"mkl_intel_c.lib mkl_intel_thread.lib mkl_core.lib libiomp5md.lib" is enough for a ia32 windows application generally.
"mkl_intel_lp64.lib mkl_intel_thread.lib mkl_core.lib libiomp5md.lib" is ok for a X64 windows application

Step 3: How to link MKL in your project manually?
3.1) Please follow the steps in how to use MKL in MSVC to add the include path, library path and mkl library as the article show. 

For example, add include path manually



please take care of about library path,  you need enter right directory:
<MKL install dir>\ia32,  for ia32 application
<MKL install dir>\em64t, for X64 application
<MKL install dir>\ia64, for IA64 application
they can't be mixed. 


Step 4: How to link MKL in your project automatically - One Button Support  (optional)
The recent MKL version have provided one "build" menu in MSVC environment. Click one button, all of environment setting and required libraries are ready in your project.
* This step can replace the step3 in most of cases.  
Or if the button is not show, please try step3, set the paths and library manually.

4.1) See below screenshot in MSVC 2005, click the version you need

Then the required library will be added in your project automatically.


4.2) In Visual Fortran compiler, it is a little different, to integrate MKL, please click the compiler option as below, change the "No" to value like /Qmkl:parallel or /Qmkl:sequential

Please note: some interface libraries (i.e. mkl_lapack95.lib mkl_blas95.lib fftw3xc_ms) are not MKL standard library, so the "one button" integration don't support it.  You may add them manually if you need to use them.

Step 5: About Compaq*Visual Fortran support and porting from 32bit to 64bit (Optional for who have used CVF)
CVF and Intel Fortran compiler use different call convention by default:
CVF: stdcall
Intel Fortran, C Compiler: cdecl (default interface of the Microsoft Visual C* application)

5.1) MKL support both of them on ia32 platform, but if you are porting from CVF to intel Fortran, you may take care of the required library: mkl_intel_s or mkl_intel_c.lib

• Using the CVF compiler
  The CVF compiler will link with mkl_intel_s[_dll].lib if routines are compiled with the default interface. However, if you compile with the option /iface=(cref,nomixed_str_len_arg), the compiler will link with mkl_intel_c[_dll].lib .
• Using the Intel® Fortran compiler
  The Intel Fortran compiler will link with mkl_intel_c[_dll].lib by default. But if the /Gm option is used, call mkl_intel_s  [_dll].lib (/Gm enables CVF and Powerstation calling convention compatibility, so does /iface:cvf).

5.2) MKL don't provide em64t and IA64 CVF interface support.  So if you are porting CVF 32bit application to X64 or IA64 platform with Intel Fortran compiler and MKL. Please note, you must to link "mkl_intel_lp64|ilp64, mkl_intel_thread, mkl_core.lib" and remove the compiler option /Gm or /iface:cvf.

Here is a MSVC 2005 project (Intel® Fortran 11.0.0.074 IA32 application) for your reference. DFT_VF_sample.zip

Troubleshooting
When build the project,
1. fatal error LNK1104: cannot open file 'mkl_xxx.lib'
please make sure the library is in the library path and the path you marked in step 3 or step 4 is right

2. "error #7002: Error opening the compiled module file.  Check INCLUDE paths. [MKL_DFTI]."
Please add the header file mkl_dfti.f90 in your code, for example,

! Include to build module MKL_DFTI
INCLUDE 'mkl_dfti.f90'
before  the code line
USE MKL_DFTI

Or copy the mkl_dfti.f90 file to the source directory of your project and include it in your Project.

1. Build a custom library (now unnecessary with Intel MKL 10.3): To interface with Intel MKL from Python we recommend you use the custom library builder in the tools/builder sub-directory of the Intel MKL package. The Intel® MKL User's Guide has documentation on this tool (docs online). Here briefly are the steps I took to do this:
   
   
   1. Set up your environment to use the desired version of Intel MKL:
      source /<MKLpath>/tools/environment/mklvarsem64t.sh
   2. Build the DLL:
      cd /<MKLpath>/tools/builder
make em64t name=~/libmkl4py export=cblas_list


2. Add library paths to LD_LIBRARY_PATH: All the Intel MKL libraries needed must be in directories contained in the LD_LIBRARY_PATH environment variable. The library as built above will depend on the OpenMP* threading runtime library used by Intel MKL (libiomp5.so) so you should make sure that both libraries, libmkl4py.so and libiomp5.so, are in a directory specified in the LD_LIBRARY_PATH environment variable. If you're using Intel MKL 10.3 you need to add the directories for both libmkl_rt.so and libiomp5.so (if you want it to run on multiple cores).


3. Call Intel MKL in your Python script: The following is a simple script (also available here) that loads the shared library just created and calls the matrix function.
   

   from ctypes import *
   
   # Load the share library
   mkl = cdll.LoadLibrary("./libmkl_rt.so")
   # For Intel MKL prior to version 10.3 us the created .so as below
   # mkl = dll.LoadLibrary("./libmkl4py.so")
   cblas_dgemm = mkl.cblas_dgemm
   
   
   def print_mat(mat, m, n):
     for i in xrange(0,m):
       print " ",
       for j in xrange(0,n):
         print mat[i*n+j],
       print 
   
   # Initialize scalar data
   Order = 101  # 101 for row-major, 102 for column major data structures
   TransA = 111 # 111 for no transpose, 112 for transpose, and 113 for conjugate transpose
   TransB = 111
   m = 2
   n = 4
   k = 3
   lda = k
   ldb = n
   ldc = n
   alpha = 1.0
   beta = -1.0
   
   # Create contiguous space for the double precision array
   amat = c_double * 6      
   bmat = c_double * 12
   cmat = c_double * 8
   
   # Initialize the data arrays
   a = amat(1,2,3, 4,5,6)
   b = bmat(0,1,0,1, 1,0,0,1, 1,0,1,0)
   c = cmat(5,1,3,3, 11,4,6,9)
   
   print "\nMatrix A ="
   print_mat(a,2,3) 
   print "\nMatrix B ="
   print_mat(b,3,4)
   print "\nMatrix C ="
   print_mat(c,2,4)
   
   print "\nCompute", alpha, "* A * B + ", beta, "* C"
   
   # Call Intel MKL by casting scalar parameters and passing arrays by reference
   cblas_dgemm( c_int(Order), c_int(TransA), c_int(TransB), \
                c_int(m), c_int(n), c_int(k), c_double(alpha), byref(a), c_int(lda), \
                byref(b), c_int(ldb), c_double(beta), byref(c), c_int(ldc))
   
   print_mat(c,2,4)
   print

4. A few notes:
   • Matrices in the BLAS and LAPACK parts of Intel MKL are stored in one dimensional arrays and integers are used to specify their geometry.
   • I've actually loaded here CBLAS interface to the general matrix multiply function which allows you to choose how the matrix is specified. In my script I've listed the matrix by rows (row-major ordering). If you do not use the cblas interface to the BLAS or if you use LAPACK you should keep in mind that these functions assume the Fortran method of listing matrices by columns (column-major ordering).

We extended the list of examples demonstrate how possible to call different ( not only widespread example like dgemm ) from the Python program:

See the list of 3 different examples attached:
dft.zip  - shows the Python program calls 1D DFTI API
spblas.zip - shows how to call  matrix-matrix multiplication routine for a sparse matrix stored in the block compressed format (BSR)
vsl.zip - shows how to call vdRngGaussian routine ( generates normally distributed random numbers)  from VSL domain.

Notes:
Each zip file contains  *.res and *_list files mean input file and file for custom library building correspondingly