Results 1 to 4 of 4

Thread: IMSL compatibility with Visual Studio and Intel Parallel Studio

  1. #1

    IMSL compatibility with Visual Studio and Intel Parallel Studio

    Hello everyone,

    I have just activated and installed my new student version of IMSL for Fortran. I would like to use the libraries within existing models that I used to run perfectly in the past with Intel Composer using Visual Studio as IDE.

    Since this is my first time that I use IMSL which were not directly included into a Intel Composer package, I am struggling to find the appropriate combination of VS-Intel Parallel Studio versions. In particular, I am able to compile correctly codes that do not make use of IMSL routines using VS Community 2017 and Intel Parallel Studio 2019 Update 1 Cluster Edition. However, with the same combination, other codes which use IMSL calls report the error:

    error #7881: This module file was generated for a different platform or by an incompatible compiler or compiler release. It cannot be read.
    On the other hand, if I use Intel Parallel Studio 2017, the following occurs:

    error #7002: Error in opening the compiled module file. Check INCLUDE paths.
    Prior compiling these projects I had set up the correct env. variables in VS for both libraries and include directories.

    Also, if I try to build the examples in the IMSL installation directory, e.g., eiat, the libraries can't be found and the error, "ifort" is not recognised. So my question is: since I used to compile correctly the same code when I used to have an Intel Composer with included the IMSL, is there a specific combination of version of VS and Intel Parallel Studio that I should use to be compatible with my version of IMSL.

    Any help is appreciated.

    Thank you in advance.
    Luca

  2. #2
    Senior Member mecej4's Avatar
    Join Date
    Dec 2009
    Posts
    128
    The error #7881 that you encountered is probably the result of using MOD files intended for 32-bit compilations with a 64-bit target build, or vice versa. What you have to do is to make sure that the target type is properly matched with the paths specified for include files, module files, libraries and DLLs.

    The Intel Fortran compiler is very good at keeping the module file format compatible with as many releases as possible. I find, for example, that the 19.0.1 compiler works fine with module files produced with the 14.0.6 compiler. Therefore, you should not have to pick a specific version of the compiler to be able to work with IMSL.

    The other error (#7002) can be fixed by configuring Visual Studio and Parallel Studio 2017 to use IMSL.

    You probably have IMSL 2018, yes? The Intel guide at https://software.intel.com/en-us/art...imsl-libraries applies to IMSL 7, but may contain useful information for you. The installation guide for IMSL should also help you with this issue.
    Last edited by mecej4; 02-23-2019 at 03:35 PM.

  3. #3
    Thank you mecej4. That was helpful. I now have installed VS Community 2017 and Parallel Studio xe 17.2.

    I believe now the problem is that I only have the 64-bit eval version of IMSL. I have verified that if I compile my files in 64-bit, mod files are generated correctly for some of the modules (meaning the IMSL routines are accessed correctly), however errors like "#6683: A kind type parameter must be a compile-time constant. [IKIND]" or "error #7061: The characteristics of dummy argument 1 of the associated actual procedure differ from the characteristics of dummy argument 1 of the dummy procedure." pops up for some modules, thus not allowing me to compile the whole project.

    I have defined ikind like this for the whole project: integer, parameter :: ikind = selected_real_kind(8,99)

    Do you think having the IMSL routines for 32-bit might help with these issues? (Knowing that this project was able to compile correctly in the past without any other changes in the code).

    Thank you again for your help!

    Luca

  4. #4
    Senior Member mecej4's Avatar
    Join Date
    Dec 2009
    Posts
    128
    Luca, it is not clear what the problem is unless you show the declaration of the interface to the dummy routine as well as the declaration of the arguments to the actual routine that is being passed. The problem may be that your declaration of the parameter IKIND is not visible inside an interface body. On the other hand, if you declare the interface in a module or place the subroutine itself inside a module, you need to USE that module.

    It would help if you showed the relevant parts of the code.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •