Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Get older ifort version


Dear all,

I’m a PhD Student and I work on a finite-element solver (LS-Dyna). It features user-defined subroutines with Fortran programming. In order to use my own subroutine, I need to compile the solver again with their pre-compiled libraries and my added Fortran code.

I need to use a specific compiler version ex : ifort130/ifort170 pgi165... If I don’t use the correct version, I get errors :
"error #7614: A common block name may appear in an OpenMP THREADPRIVATE directive only after the last COMMON statement which specifies the same common block name."
I don’t fully comprehend the issue and I don’t have the background knowledge on THREADPRIVATE behavior nor the time to investigate.

Basically I use their pre-coded Fortran file (made for a specific Fortran compiler version) files and I add my code and it work perfectly. I fear that changing some part of this file might lead to issues with the rest of the code.

The issue I got is that with the new Intel license policy I only get the latest Fortran Compiler version with the new OneAPI software. I also happen to have a still running licence for PS XE for Linux, but don't have access to older ifort version.

I would like to know if Intel gives access to the previous older ifort version, when I get a proper paid license? This would be the easiest way, as LS-Dyna didn’t update their files to the latest versions.

0 Kudos
9 Replies
Black Belt

Please read this recent thread about almost the same question.


Unfortunately, it didn't work for me. I still get block error, even using the same files as in this thread... 


The only solution for me is to get the ifort 170. 

0 Kudos
Black Belt

*** Intel support: Search is broken in online document

Search for common in online IFV (


You apparently have the same named common block listed in multiple places in the same scope of a procedure. This is fine and this results in the subsequent same named common blocks (in the same procedure) being concatenated. OpenMP (now) requires that should any such concatenation be in effect, that the threadprivate declaration be placed after the last such concatenation. IOW this may require of you to simply position the !$OMP THREADPRIVATE(...) after the last COMMON declaration of the common block name (enclosed in "/../') of the name specified in that THREADPRIVATE.

Note, same named common blocks present in separate procedures effectively produce a UNION with the common blocks of same name of other procedures.

Jim Dempsey





Unfortunately, I can't change the files use to compile a new version of LS-Dyna. The error seems to come from block used in pre-compiled files, perhaps ?

I think the best solution for me is to Install the recommended version of the compiler (ifort 170) 

0 Kudos
Black Belt Retired Employee

Unless you have paid support, old versions are not available. Fix your code.

0 Kudos
Black Belt

Did you add OpenMP support...


Was OpenMP support part of the pre-coded Fortran file?


Jim Dempsey

0 Kudos

Dear all,

Thanks you for your time. But unfortunately, I don't have access to the rest of the code to make it compatible with the latest compiler version.

However, I managed to compile both MPP and SMP version of the solver. If someone else have the same issues here are the steps with a virtual machine (Ubuntu 20.04.02) :


As of now, LSTC released "sharedlib" version of the MPP solver. Meaning, we only need to compile the FORTRAN subroutines with any compiler.
I managed to do it with the latest OneAPI version. Here are the steps :

For MPP ls-dyna version : ls-dyna_mpp_d_r10_1_123355_x64_centos65_ifort160_avx2_openmpi1.10.7 (sharedlib version)

1) Install MPI library and define the correct path
eg : openmpi-1.10.7 (build tar from ftp lstc : )
eg : put openmpi-1.10.7 folder in /opt/

add openMPI folders to PATH and LD_LIBRARY_PATH temporarily (run command each time ) or permanently in starting bash file eg /
 export PATH=$/opt//openmpi-1.10.7/bin:$PATH

2) install FORTRAN compiler
eg oneapi base + oneapi HPC

3) configure env variables :
 source /opt/intel/oneapi/

4) make mpif90 use ifort instead of gfortran
 export I_MPI_F90=ifort

5) compile

6) install ls-dyna mpp sharelib (sh extractor from lSTC or DynaS+)
6.1) put in a folder and add to the library path (
       export LD_LIBRARY_PATH /path/to/my_own/usermat/lib:$LD_LIBRARY_PATH



However, as I have a still running Parallel Studio XE licence for Linux, I tried with the oldest version I had in my archives : PSXE 2017 Update 8

In this version, there is the ifort 2017. The latest files from LS-Dyna are for the ifort160. By changing just the way INTEGER*8 is declared in the UMAT code, I managed to compile a working version of the SMP solver (ls-dyna_smp_d_R12_0_0_x64_redhat65_ifort160).


1) install Parallel XE 2017 (Parallel XE has been replaced by oneAPI
2) Each time you need to compile, you have to add environment variables :
source opt/intel/parallel_studio_XE_2017.8.066/bin/

3) Install libX11-dev
sudo apt-get install libx11-dev

4) change makefile paths as :
#FC=/opt/intel/compilers_and_libraries_2016/linux/bin/intel64/ifort -qopenmp
FC=/opt/intel/compilers_and_libraries_2017.8.262/linux/bin/intel64/ifort -qopenmp

#LD=/opt/intel/compilers_and_libraries_2016/linux/bin/intel64/ifort -qopenmp -sox
LD=//opt/intel/compilers_and_libraries_2017.8.262/linux/bin/intel64/ifort -qopenmp -sox

#LF= -static-intel -L/usr/X11R6/lib64 -lX11 -qopenmp -lrt -lstdc++ -lpthread -lstdc++ -lpthread
LF= -static-intel -L/usr/lib64 -lX11 -qopenmp -lrt -lstdc++ -lpthread -lstdc++ -lpthread



It is important to note that most of these steps are described in the README files in LSTC ftp server.


Mohamed Maamir

0 Kudos

Thanks MMaamir for your sharing, I can installed the LS DYNA and compiled user subroutine in window system. However, I can not run user subroutine solver. Can you give me the guidance how you can do that in Linux system

0 Kudos

I have the same problem but on Windows. When I compile on Ubuntu, I do not experience this problem.

0 Kudos