Fortran compilers compatibility

[Mirela_M_]

Hi, my name is Mirela and I am a PhD student in Economics.

 I have to replicate a preexisting code compiled  with Intel 64, Version 11.0.061. The codes also use IMSL Fortran Numerical 
Library, Version 6.0.

I have downloaded Parallel studio 2017 and Visual studio 2017 . However, I cannot build the project as I receive several errors during the building step. Do you think this is caused by the different compilers? If I buy the license for IMSL library can you see any compatibility issues between what I have and the codes I have to replicate?

Thanks

Mirela

[Lorri_M_Intel]

Without seeing the errors, there is no way we can help you.

Please attach the build log from your failing build.

                   --Lorri

[mecej4]

If you do not have IMSL installed, you are going to see error messages when you attempt to build an application that requires the missing IMSL support.

If, on the other hand, you do have the older version of IMSL, and you configured your build process (in Visual Studio, or at the command line), there is a very slight likelihood of running into problems related to mixing a current compiler and a seven year old version of IMSL, and in this case, as Lorri said, you should report the actual error messages.

In my experience, IMSL has been very stable. If your code does not use IMSL features that were absent in IMSL-6, you should be able to use IMSL-6 or IMSL-7.

[Mirela_M_]

Hi Lorri, thanks a lot for your reply. 

I have now installed the IMSL 6 IA 32 to Visual Studio 2017  following the steps described on intel website. However, in the building phase of the project, I receive the following error:

1>------ Build started: Project: Project1, Configuration: Debug Win32 ------

1>Compiling with Intel(R) Visual Fortran Compiler 18.0.0.124 [IA-32]...

1>MainProg.f90

1>C:\Users\Mirela Miescu\Downloads\int_rec\international_recessions_data_codes\codes\Figures 1-5 and Tables 3-12\1. LaborElasticity - Data  Figure 1 & Tables 3\MainProg.f90(104): internal error: Please visit 'http://www.intel.com/software/products/support' for assistance.

1> CALL ERSET (0, 0, 0)

1>^

1>[ Aborting due to internal error. ]

1>compilation aborted for C:\Users\Mirela Miescu\Downloads\int_rec\international_recessions_data_codes\codes\Figures 1-5 and Tables 3-12\1. LaborElasticity - Data  Figure 1 & Tables 3\MainProg.f90 (code 1)

1>

1>Build log written to  "file://C:\Users\Mirela%20Miescu\Downloads\int_rec\international_recessions_data_codes\codes\Figures%201-5%20and%20Tables%203-12\1.%20LaborElasticity%20-%20Data%20Figure%201%20&%20Tables%203\Debug\BuildLog.htm"

1>Project1 - 1 error(s), 0 warning(s)

========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Thanks a lot and looking forward to have news from you!

Regards,

Mirela

[mecej4]

There is no single cure for internal compiler errors (ICE). To enable investigation and solution for an ICE, please provide the source file that provoked the ICE -- MainProg.f90.

[Mirela_M_]

Here it is one of the mainprog. example.

They all give the same error call  erset(0 0 0)

Many thanks!

Mirela

[mecej4]

The file that you provided includes numerous include directives, and cannot be compiled unless the included files are available. You will have to provide all the include files needed, or construct and provide a simplified source code that causes an ICE similar to the one that you saw.

I noticed one instance where an attempt is made to surround an include directive with an IF (SimType ==1) THEN ... ENDIF. This is possibly wrong, even if SimType is a named constant in one of the missing include files. Here is an example that should illustrate this point.

program tst
implicit none
integer, parameter :: SimType = 2
integer :: i,j,k
!
i=0
if(SimType == 1)then
   include 'xyz.inc'
endif
print *,SimType, i
end program

File xyz.inc contains the single line

i=1

The indentation and the usual meaning of an IF block seems to suggest that the file xyz.inc does not get included since the condition is not satisfied.

If you compile and run the program, what would you expect it to print, and what does it actually print? Can you explain the result?

Hint: File xyz.inc is included regardless of the value of SimType; in fact, the inclusion occurs regardless of whether SimType has been declared or has a value assigned, and could happen before the statements in the code have been parsed by the compiler.

[Mirela_M_]

Thanks, I am going to try your test.  I cannot understand if the problem is the library which is incompatible with the rest of the code or the compiler. The codes should run in theory.

The folder of all codes can be found at  http://www.fperri.net/research_pap.htm    next to International recessions. As for now I cannot build any of the programs and I cannot understand why.

Thanks a lot, you have been of a great help!

Mirela

[jimdempseyatthecove]

Mirela,

I am not sure if you fully comprehended mecej4's post.

The include 'xyz.inc' happens at compile time, not at run time (as can be done with interpreter languages, and/or JIT compilers). What this means is after a build, you copy the executable to some user's folder, then then cannot supply there own xyz.inc file and affect changes in the runtime. If this is what you require your program to do, then you need to a) read/parse an xyz.ini data file, or b) use environment variables, or c) use command line arguments (or a bunch of other techniques to pass in initialization  values).

Jim Dempsey

[mecej4 · Accepted solution]

Mirela, I think that the problems that you are seeing are caused by an incompatibility with the IMSL modules that came with your IMSL-6 and the Intel 2017 compiler. For details, please see https://software.intel.com/en-us/articles/do-not-use-older-versions-of-imsl-with-intel-visual-fortran-compiler-version-12?wapkw=imsl .

Program RiskAve can be built and run with no problems when the 17.0 or 18.0 compilers are used with IMSL 7.0.1.

The choices for you are:

1. Obtain and install the old 11.1.072 Intel Fortran compiler, which is compatible with your IMSL-6,
2. Obtain the current version 7.0.1 of IMSL from Intel, or version 7.1 from Roguewave.
3. Modify your code such that no IMSL modules are needed and such that the implicit interfaces to IMSL routines are correct.

Since your source codes USE the IMSL linear operators module, Choice 3 would require a lot of work. Choice 2 may not be available if you do not wish to pay for a newer version of IMSL. Choice 1 may be the easiest for you, if Intel lets you download the older Fortran compiler.and use it.

[Mirela_M_]

Thanks a lot, this was my intuition too that the library was incompatible with the compiler and needed confirmation in case I want to buy the IMSL 7 that it works.

Many thanks, you have been of great help! I will go for either 1 or 2 and update the post!

Mirela

[mecej4]

Mirela, here is a minor point: the library (*.LIB), by itself, is compatible; it is the modules (.MOD) files that are incompatible. However, if by "library" one means "the IMSL library package taken as a whole, consisting of .F90, .MOD and .LIB files", yes, there is an incompatibility.

[mecej4]

After posting #12, I ran some additional tests to identify the points of incompatibility.

I restored IMSL-6 from archives that I had saved. I compiled using the Intel IMSL 7.0.1 modules, but linked with the IMSL-6 libraries from Roguewave. The program ran fine.

I ran the RiskAve program using CVF 6.6C and IMSL-4. This time, I had to use the IMSL-4 module files for CVF, of course. Again, the program could be built and run without problems.

Therefore, the problem is with the module files that you have, which were compatible with IFort 11, but are now incompatible with IFort 17 and 18.

This additional information may be of little help in what you have to do, unless you are able to obtain the older IFort 11 compiler from Intel.

[Steve_Lionel]

There were certainly some issues with old IMSL modules that could leas to internal compiler errors. Intel Fortran tries to allow use of old modules, but sometimes older bugs that were fixed require the modules to be recompiled.