Hello,

               After successfully compiling this code - https://software.intel.com/en-us/comment/1798317#comment-1798317 (thanks to Tim Prince) when I run this I get the error below. I know there is nothing with the data. So I am enclosing the f90 file and maybe somebody can help me what is the error with it.

Regards,

Ashwin.

program geogrid

      use iso_c_binding

      implicit none

      integer :: j

      integer :: isigned, endian, wordsize

      integer :: nx, ny, nz

      real :: scalefactor

      real*8 :: xllcorner, yllcorner, cellsize, missvalue

      character :: head12

      real, allocatable :: rarray(:,:), iarray(:,:)

      character(len=255) :: pathToFile

      LOGICAL :: file_exists

      isigned = 1

      endian = 0

      wordsize = 4

      scalefactor = 1.0

      nz = 1

      CALL getarg(1, pathToFile)

      INQUIRE(FILE=pathToFile, EXIST=file_exists)

    

      if (file_exists .eqv. .FALSE.) then

        write(0,*) "ERROR: no valid path to  *.asc SRTM file"

        CALL exit(-1)

      end if

      

      open (10, file = pathToFile)

      read(10,*) head12, nx

      read(10,*) head12, ny

      read(10,*) head12, xllcorner

      read(10,*) head12, yllcorner

      read(10,*) head12, cellsize

      read(10,*) head12, missvalue

      allocate(rarray(nx,1))

      allocate(iarray(nx,ny))

      do j = 1,ny

      read(10,*) iarray(:,j)

      end do

      ! reverse the data so that it begins at the lower-left corner

      do j = 1,ny/2

        rarray(:,1) = iarray(:,ny-(j-1))

        iarray(:,ny-(j-1)) = iarray(:,j)

        iarray(:,j) = rarray(:,1)

      end do

      deallocate(rarray)

        

      call write_geogrid(iarray, nx, ny, nz, isigned, endian, scalefactor, wordsize)

end program geogrid

forrtl: severe (59): list-directed I/O syntax error, unit 10, file /home/an/test/geogrid/./N13E079.hgt

Image              PC                Routine            Line        Source             

ConvSRTM           000000000041ABAA  Unknown               Unknown  Unknown

ConvSRTM           0000000000402826  Unknown               Unknown  Unknown

ConvSRTM           0000000000402386  Unknown               Unknown  Unknown

libc.so.6          00007F1F051A9EC5  Unknown               Unknown  Unknown

ConvSRTM           0000000000402269  Unknown               Unknown  Unknown

Hi

I always got the same error when I rebuilding the project in in fortran complier on Visual Studio. And It seems that the .EXE in debug folder couldn't be delected when I rebuild the project, thus the error occurs.

I using Microsoft Visual Studio 2008 Tools for Office, and Intel(R) Visual Fortran Composer XE 2013 Update 3 Integration for Microsoft Visual Studio* 2008, 13.0.3624.2008, Copyright (C) 2002-2013 Intel Corporation.

thanks

Youwei

MOVE_ALLOC requires that `to` be type compatible with `from`.  Could the compiler please diagnose when this requirement is not met.

MODULE m
  IMPLICIT NONE
  TYPE :: NotMyParent
  END TYPE NotMyParent
  TYPE :: NotAnExtension
  END TYPE NotAnExtension
CONTAINS
  SUBROUTINE proc
    CLASS(NotMyParent), ALLOCATABLE :: to
    TYPE(NotAnExtension), ALLOCATABLE :: from
    !****
    CALL MOVE_ALLOC(from, to)
  END SUBROUTINE proc
END MODULE m

>ifort /c /check:all /warn:all /standard-semantics move-alloc-not-an-extension.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.108 Build 201407
26
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

(... hours of fun and games begin here...)

This right click menu option in Visual studio used to do what it says and just link.  Now it deletes intermediate files first and then of course can not possibly do a link.  Using VS2010 with Fortran Compiler XE 13.1.3.198.

Hi,

I have an error message forrtl: severe(170): Program exception - stack overflow

My program is doing some grid search.  It ran with a small number of grids, but then I got this message when I increase the number of grids to the realistic level.  I read the topic https://software.intel.com/en-us/forums/topic/299402 but I still don't understand.  ( I use Intel Visual Fortran Compiler with IMSL libraries (use include 'link_fnl_static_hpc.h') and I ran the program by clicking Start without debugging so I don't know what  "ifort" is.



Anyone could suggest me the way out of this ?



Thank you very much.

I am using Intel Parallel Studio XE 2015 in Visual Studio 2010 Professional on Windows 7 64-bit Professional. I uninstalled all version of Intel products and installed just Parallel Studio XE 2015 today, but I am still having problems with the VS integration.

I have a console application and the source code is in fixed form .for files. There are several minor problem I am experiencing:

Problem 1:

I have a .for file that contains several simple modules, let's say:

      module Fields

      integer(kind=4), allocatable, dimension(:,:) :: fieldInt2D
      real(kind=8), allocatable, dimension(:,:) :: fieldDouble2D

      end module Fields

      module Properties

      real(kind=8) :: propertyDouble

      end module Properties

If I start typing "use" anywhere in the code, a list pops up, but it only contains the name of the first module (Fields) and other items in the list that probably correspond to the other modules, but these other items have empty names, so it is not possible to know which one should be selected from the list.

Problem 2:

It often happens that if I hove the mouse pointer over a subroutine call, the list of this subroutine's arguments contains "NONE :: argument1" even though the argument type is specified in the subroutine. It is difficult to give an example as I was not able to find any rule for situations with this problem, but one example would be:

      subroutine write_2D_field_double ( x, iunx, finame )

      use ifport
      use ifwin

      include 'frequent.inc' ! contains nx, ny declared as integer(4)

      real(8), dimension(nx,ny) :: x
      integer(4) :: iunx
      character(20) :: finame
      ...
      return
      end

Hovering over the subroutine or its call shows "NONE :: x"; the other arguments are OK.

Problem 3:

Local variables declared as "logical(4) :: logVar" do not show any tool tip when the mouse pointer hovers over their names in the code. The statement "logical" is shown as the intrinsic function in the tooltip, but the compiler understands it is a declaration of a logical variable. Changing the declaration to "logical(kind=4) :: logVar" does not help.

Dear Intel support team,

when I try to read an integer value with the I integer descriptor into a real variable, ifort returns an incorrect value and no error status. You will find below my ifort version and the demonstration program.

Quoting the Fortran standard 2008 (section 10.7.2.2): "Integer editing: Iw [...] The specified input/output list item shall be of type integer". Obviously, I violate this rule, so I would expect an error status. Or if you want to extend the standard, you could implicitly convert the integer value to the real variable. Anyway, my worry is that an incorrect value is returned with no detection possible.

May be I should add that in my real use case, the string to be read and the format used are NOT known at compilation time. Only the list items (type real) are known.

Sebastien

$ ifort --version
ifort (IFORT) 14.0.2 20140120
Copyright (C) 1985-2014 Intel Corporation. All rights reserved.

$ cat read_inte_into_real.f90
program test
implicit none
real(kind=8) :: work(2)
integer(kind=4) :: ier
character(len=32) :: string
!
string = "1 48216 0.10763 0.12938 0.05432 "
read(string,'(I1,1X,I5)',iostat=ier) work
if (ier.ne.0) then
print *,"Error"
else
print *,work
endif
end program test

$ ifort read_inte_into_real.f90 -o test && ./test
4.940656458412465E-324 2.382186917988154E-319

Hi guys,

another issue related to the new V15 version of your Fortran compiler.

The following statement worked fine up until the latest V14, but crashed with a stack overflow using V15:

REAL, POINTER :: BUFFRB(:,:,:,:)

ALLOCATE(BUFFRB(200,200,4,2))

mt_pklv = PACK(BUFFRB(1:200,1:200,1:4,2),.TRUE.)

Do you have any idea, what happened here. I guess, that PACK uses some temporaries on the stack instead of the heap and therefore crashes.

mt_pklv is an REAL vector huge enough to hold all elements of BUFFRB().

Thanks & regards,

Andreas 

 

Hi

Attached file when compiled with "ifort /Qsave /Qinit:snan /Qinit:arrays" gives a catastrophic error with XE 2015 (package 108); i.e. the latest release.

Abhi

Hi,

I was working with your library (Intel OpenMP Runtime Library) and I was wondering how the "#pragma" directives in the code are expanded. What I mean is that since you have mentioned in your Reference document, the pragma directives are expanded to some line of codes? Is that correct? If so, where can I look into the code and find it?

Let me give your an example: Consider below line of C code,

#pragma omp parallel

What will be the equivalent C code in your framework that would be replaced with above line of code? And, where can I find it?

Best Regards,

Millad

I am wondering if in the following DO-loop, the introduction of the new INTEGER variable upper_index in place of the two identical calculations x_index(i,l) + N will have a benefit to the performance?  I have already timed this loop and compared it to the original loop, and the runtime ratio indicates ~1.40 performance gain.

  DO i = 1,N
    upper_index = x_index(i,l)+N
    coef(i) = 0.5 * vz(x_index(i,l),l)
    g2(i) = 2. * ( a(upper_index,k,l) - a(x_index(i,l),k,l) ) / ( dz(x_index(i,l)) * (1.0 + az1(x_index(i,l)) ) )
    IF (s(x_index(i,l),l) <= p1 .OR. s(upper_index,l) <= p1) g2(i)=0.0
  END DO

This loop is nested in loops over K and L

However, when I tested the same idea in the following simple loop, I did not see meaningful difference in the speed of the code.

do i = 1,nloop1
  do j = 1,nloop2
    k = i+j
    variable(k) = k
  end do
end do

Which one of the above two observations I can possibly trust?

Also, I noticed that the use of IF-ELSEIF construct is noticeably less efficient than using multiple IF statements in a DO-loop.  Is this observation correct? I am using Intel Fortran compiler 2015, with O2 optimization flag.

Thanks you in advance,

I am using Visual Fortran Compiler XE 15.0.0.108 [IA-32]

I am doing a simple assignment like this:

satfln(:,:,:,app) = fulsln(:,:,:,app)

Both satfln and fulsln are explicit size and shape arrays, both defined in the same module as real, dimension(0:2,2,20,8).

This assignment works fine in a debug build but when I compile with all the optimisation turned on, some elements are not assigned, e.g.

satfln(:,:,1,app) are assigned but satfln(:,:,2,app) aren't.  

Also, satfln(:,:,1:3,app) = fulsln(:,:,1:3,app) works but satfln(:,:,1:20,app) = fulsln(:,:,1:20,app) does not.  I feel like this has to be a bug in the latest Version 15.  

Can anyone shed any light on this?

Mark Besley

Hi.

Sure that this question was asked already, but I have troubles with finding answer. So,

I'm planning to purchase fortran compiler and now are using trial version.

(download full install package of Intel Parallel Studio XE 2015 from https://registrationcenter.intel.com through registration procedure.)

Problem is that there is no any version of Visual Studio in my system so I can't integrate fortran compiler into it.

I skim some pages in here and realize that free express version of VS doesn't support work with fortran compiler. Well, I uninstall it, after that fortran wizard notes that VS 2010 shell can be installed, but that option is unactive because valid license is not found. I suppose that reason is trial version of Parallel Studio, only after buying license installation of VS Shell becomes possible. But in that case it doesn't make any sense to use trial version, I just can't start working to evaluate this.

My main question is

1), that VS 2010 Shell, is it full development enviroment which allows to create, build and debug application from scratch, if I'm using fortran language only?

if yes, then

2), Is it really possible to create any fortran application with trial version of Parallel Studio and without any Visual Studio installed before? I know about starting from command line, but that option seems ineligible for me.

My operating system is Windows 7 x64 and I'm planning to use Windows 8 in future.

Thanks in advance.

I have a quick question regarding the OpenMP. Usually one can do a section parallel like this (written in fortran, and has two sections):

!$OMP PARALLEL SECTIONS

!$OMP SECTION

< Fortran code block A>

!$OMP SECTION

< Fortran code block B>

!$OMP END SECTIONS

Now what I really want to run fortran code block A and B within a do loop, which itself should not be parallelized, because this do-loop is a time-dependent loop that every new step depend on previous step’s results. And before the parallel section, I need to run a serial code (let's call it block C). Now both block A, B, C are function of do loop variable t. Then naively one might propose such code by simply embedded this parallel within a do loop:

do t=1:tmax

    < Fortran serial code block C>

    !$OMP PARALLEL SECTIONS

    !$OMP SECTION

    < Fortran code block A>

    !$OMP SECTION

    < Fortran code block B>

    !$OMP END SECTIONS

end do

However, it is obvious that the creation of the thread overheads will largely decelerate this speed, which even possibly make it slower than a standard serial code. Therefore, one might come up with smarter idea to solve this. 

I was wondering whether you can help me on giving some hints on how to do this. What's the best approach (fastest computation) on this? Thanks a lot for your help! 

I have a product with the following internal structure: 1) a Root_Solver module to have all the root solving routines necessary to solve problems; 2) a base class FuncBase used by the Root_Solver module so that it may access functions to solve; 3) children of the base class to encompass individual needs in the program.

I am running into an implementation problem that has to do with some of the child classes requiring specific solver routines for internal calculations.  Obviously this may lead to circular referencing.  So how might one handle this?

Specifically, child FuncOne requires a routine from the Root_Solver to solve for an internal variable.  At the same time, child FuncOne has class functions used to solve for other variables using another Call.  I get no build problems when I create the output, but when run the program complains vehemently after the internal solver routine is called that the FuncOne class variables are all undefined.

Hi,

I just noticed that in the Intel Fortran/C++ Composer Edition for Linux, the Intel Debugger is not there any more. I was advised to use the IDB from the older versions. Is this true for all of the products? What were the reasons? Thank you.

Hossein

Could some consideration be given to splitting out variables that are dummy arguments from the "This variable has not been used" warning. 

Failing that, could we have a "!DEC$ PLEASE_PRETEND_THIS_IS_USED(xxxx)" or similar directive that suppresses this warning for the variable named xxxx in the scope of the directive.

Procedures that implement a binding for a derived type often have arguments that are superfluous to that particular type, so the general nature of /warn:unused is a bit chatty.  It is still quite handy for non-dummy variables though, so I don't want to disable it entirely.  Being able to specify /warn:all /warn:nounused_dummy would be quite useful.

Intel^® Composer XE 2015 for Linux
"Silent" or non-interactive Installation Instructions

Navigation:

Linux and Mac OS X Compilers Installation Help Center: /en-us/articles/intel-compilers-linux-installation-help

Contents of this document:

• Silent Command Line Installations
• RPM Command Line Installations
• LSB Support
• Redistribution Package Installations
• Uninstall Instructions
• Links of Interest

Silent Command Line Installations

Starting with release 11.0, the Linux installation programs for Compiler Professional are built using the PSET (Program Startup Experience Technologies) 2.0 core.  This PSET core is a framework of tools built by Intel to provide a robust set of installation and licensing features that are consistent across Intel product lines.  A similar PSET core is used for the Windows* and Mac OS* X installation packages as well.

One feature provided in the PSET core is support for the "silent" install.  Historically, "silent" really meant "non-interactive".  At this point, "silent" also means "does not report copious amounts of information", assuming there are no problems during the installation.  The silent install method allows the user to perform a command line installation of an entire package with no need to answer prompts or make product selections.

A historical note specific to Linux installs: there has been a "silent" install capability in the Linux Compiler products since version 9.0.  This legacy version, included in versions 9.1, 10.0, 10.1, and 11.0 as well, performed the same function.  But starting with version 11.1, the legacy silent install embedded in the "inner install components" has been removed.  The new PSET core silent install is the only method still supported - that is, older silent installation tools in v11.0 and older are no longer supported other than the RPM command line install method (see details on RPM-based installs below).

Silent Install Steps: "From Scratch"

To run the silent install, follow these steps:

• For reasons outlined below we recommend that a working product license or server license is in place before beginning.  The file should be world-readable and located in a standard Intel license file directory, such as the default linux license directory /opt/intel/licenses.  For more details, keep reading.
• Create or edit an existing silent install configuration file.  This file controls the behavior of the installation.  Here is an example file.  A similar file can be edited and placed in any directory on the target system.  After this example we explain the configuration file contents.

# silent.cfg
# Patterns used to check silent configuration file
#
# anythingpat - any string
# filepat     - the file location pattern (/file/location/to/license.lic)
# lspat       - the license server address pattern (0123@hostname)
# snpat      - the serial number pattern (ABCD-01234567)

# accept EULA, valid values are: {accept, decline}
ACCEPT_EULA=accept

# install mode for RPM system, valid values are: {RPM, NONRPM}
INSTALL_MODE=RPM

# optional error behavior, valid values are: {yes, no}
CONTINUE_WITH_OPTIONAL_ERROR=yes

# install location, valid values are: {/opt/intel, filepat}
PSET_INSTALL_DIR=/opt/intel

# continue with overwrite of existing installation directory, valid values are: {yes, no}
CONTINUE_WITH_INSTALLDIR_OVERWRITE=yes

# list of components to install, valid values are: {ALL, DEFAULTS, anythingpat}
COMPONENTS=DEFAULTS

# installation mode, valid values are: {install, modify, repair, uninstall}
PSET_MODE=install

# this one is optional
# directory for non-RPM database, valid values are: {filepat}
#NONRPM_DB_DIR=filepat

# Choose 1 of the 2 activation options - either serial or license
# license is needed if system does not have internet connectivity to Intel
#
# Serial number, valid values are: {snpat}
#ACTIVATION_SERIAL_NUMBER=snpat
#
# License file or license server, valid values are: {lspat, filepat}
#ACTIVATION_LICENSE_FILE=/put/a/full/path/and/licensefile.lic
#
# and based on the above, set the activation type: again, recommend using a license_file.
# exist_lic will look in the normal places for an existing license.
# Activation type, valid values are: {exist_lic, license_server, license_file, trial_lic, serial_number}
ACTIVATION_TYPE=exist_lic

# the next block is for Cluster Edition installations.  Leave commented for non-cluster installs
# Select 'yes' if head node installation can be used from compute nodes, valid values are: {yes, no}
#CLUSTER_INSTALL_AUTOMOUNT=yes
#
# Path to the cluster description file, valid values are: {filepat}
#CLUSTER_INSTALL_MACHINES_FILE=filepat

# Intel(R) Software Improvement Program opt-in, valid values are: {yes, no}
PHONEHOME_SEND_USAGE_DATA=no

# Perform validation of digital signatures of RPM files, valid values are: {yes, no}
SIGNING_ENABLED=yes

Running the Silent Installation

Once you have created your silent installation configuration file, installation is quite simple.  First, extract the compiler full package tar file in a temporary directory.  For purposes of this example we use /tmp as our temporary directory.  You may use any directory in which you have full file permissions.  Do not untar the package in the directory where you intend to install the compiler, the temporary directory should be disjoint from your final target installation directory.

Untar the compiler package (assumes the package is copied to /tmp).  Your compiler version and package name may differ than that shown below:

1. cd /tmp
2. tar -zxvf  l_ccompxe_2015.0.090.tgz or
3. tar -zxvf l_fcompxe_2015.0.090.tgz

Now cd to the extracted directory

1. cd l_ccompxe_2015.0.090  or
2. cd l_fcompxe_2015.0.090

Run  the install.sh installer program, passing the full path to your configuration file with the --silent option

1. ./install.sh --silent /tmp/silent.cfg

where "silent.cfg" is replaced by the name you used to create your silent configuration file.   You may use any name for this file.

DONE.  If your configuration file is accepted the installer will now progress with the installation without further input from you, and no output will appear unless there is an error.

CONFIGURATION FILE FORMAT

A few comments on the directives inside the silent install configuration file:

ACCEPT_EULA=accept

• This directive tells the install program that the invoking user has agreed to the End User License Agreement or EULA.  This is a mandatory option and MUST be set to 'accept'. If this is not present in the configuration file, the installation will not complete.  By using the silent installation program you are accepting the EULA.
• The EULA is in a plain text file in the same directory as the installer.  It has file name "license".  Read this before proceeding as using the silent installer means you have read and agree to the EULA.  If you have questions, go to our user forum: https://software.intel.com/en-us/forums/intel-software-development-products-download-registration-licensing

INSTALL_MODE=RPM

• This directive tells the install program that the RPM method should be used to install the software.  This will only work if the install user is "root" or has full root priveleges and your distribution support RPM for package management.  In some cases, where the operating system of the target system does not support RPM or if the install program detects that the version of RPM supported by the operating system is flawed or otherwise incompatible with the install program, the installation will proceed but will switch to non-RPM mode automatically.  This is the case for certain legacy operating systems (e.g. SLES9) and for operating systems that provide an RPM utility, but do not use RPM to store or manage system-installed operating system infrastructure (e.g. Ubuntu, Debian).  THUS, Ubuntu and Debian users set this to INSTALL_MODE=NONRPM.

• If the you do not want to use RPM, then this line should read "INSTALL_MODE=NONRPM".  In this case, the products will be installed to the same location, but instead of storing product information in the system's RPM database, the Intel product install information will be stored in a flat file called "intel_sdp_products.db", usually stored in /opt/intel (or in $HOME/intel for non-root users).  To override this default, use configuration file directive NONRPM_DB_DIR

​NONRPM_DB_DIR

• If INSTALL_MODE=NONRPM the directive NONRPM_DB_DIR can be used to override the default directory for the installation database.  The default is /opt/intel or in $HOME/intel for non-root users.  The format for this directive is:
• NONRPM_DB_DIR=/path/to/your/db/directory

ACTIVATION=exist_lic

• This directive tells the install program to look for an existing license during the install process.  This is the preferred method for silent installs.  Take the time to register your serial number and get a license file (see below).  Having a license file on the system simplifies the process.  In addition, as an administrator it is good practice to know WHERE your licenses are saved on your system.  License files are plain text files with a .lic extension.  By default these are saved in /opt/intel/licenses which is searched by default.  If you save your license elsewhere, perhaps under an NFS folder, set environment variable INTEL_LICENSE_FILE to the full path to your license file prior to starting the installation or use the configuration file directive ACTIVATION_LICENSE_FILE to specify the full pathname to the license file.
• Options for ACTIVATION are { exist_lic, license_file, server_lic, serial_number, trial_lic }
  • exist_lic directs the installer to search for a valid license on the server.  Searches will utilize the environment variable INTEL_LICENSE_FILE, search the default license directory /opt/intel/licenses, or use the ACTIVATION_LICENSE_FILE directive to find a valid license file.
  • license_file is similar to exist_lic but directs the installer to use ACTIVATION_LICENSE_FILE to find the license file.
  • server_lic is similar to exist_lic and exist_lic but directs the installer that this is a client installation and a floating license server will be contacted to active the product.  This option will contact your floating license server on your network to retrieve the license information.  BEFORE using this option make sure your client is correctly set up for your network including all networking, routing, name service, and firewall configuration.  Insure that your client has direct access to your floating license server and that firewalls are set up to allow TCP/IP access for the 2 license server ports.  server_lic will use INTEL_LICENSE_FILE containing a port@host format OR a client license file.  The formats for these are described here https://software.intel.com/en-us/articles/licensing-setting-up-the-client-floating-license
  • serial_number directs the installer to use directive ACTIVATION_SERIAL_NUMBER for activation.  This method will require the installer to contact an external Intel activation server over the Internet to confirm your serial number.  Due to user and company firewalls, this method is more complex and hence error prone of the available activation methods.  We highly recommend using a license file or license server for activation instead.
  • trial_lic is used only if you do not have an existing license and intend to temporarily evaluate the compiler.  This method creates a temporary trial license in Trusted Storage on your system.
• No license file but you have a serial number? If you have only a serial number, please visit https://registrationcenter.intel.com to register your serial number.  As part of registration, you will receive email with an attached license file.  If your serial is already registered and you need to retrieve a license file, read this:  https://software.intel.com/en-us/articles/how-do-i-manage-my-licenses
• Save the license file in /opt/intel/licenses/ directory, or in your preferred directory and set INTEL_LICENSE_FILE environment variable to this non-default location.  If you have already registered your serial number but have lost the license file, revisit https://registrationcenter.intel.com and click on the hyperlinked product name to get to a screen where you can cut and paste or mail yourself a copy of your registered license file.
• Still confused about licensing?  Go to our licensing FAQS page https://software.intel.com/en-us/articles/licensing-faq

ACTIVATION_LICENSE_FILE

• This directive instructs the installer where to find your named-user or client license.  The format is:
• ACTIVATION_LICENSE_FILE=/use/a/path/to/your/licensefile.lic  where licensefile.lic is the name of your license file.

CONTINUE_WITH_OPTIONAL_ERROR

• This directive controls behavior when the compiler encounters an "optional" error.  These errors are non-fatal errors and will not prevent the installation to proceed if the user has set CONTINUE_WITH_OPTIONAL_ERROR=yes.  Examples of optional errors include an unrecognized or unsupported linux distribution or version or certain prerequisites for a product cannot be found at the time of installation (such as a supported Java runtime or missing 32bit development libraries for 32bit tool installation).   Fatal errors found during installation will cause the installer to abort with appropriate messages printed.
• CONTINUE_WITH_OPTIONAL_ERROR=yes directs the installer to ignore non-fatal installation issues and continue with the installation.
• CONTINUE_WITH_OPTIONAL_ERROR=no directs the installer to abort with appropriate warning messages for the non-fatal error found during the installation.

PSET_INSTALL_DIR

• This directive specifies the target directory for the installation.  The Intel Compilers default to /opt/intel for installation target.  Set this directive to the root directory for the final compiler installation.

CONTINUE_WITH_INSTALLDIR_OVERWRITE

• Determines the behavior of the installer if the PSET_INSTALL_DIR already contains a existing installation of this specific compiler version. The Intel compiler allows co-existence of multiple versions on a system.  This directive does not affect this behavior, each version of the compiler will have a unique installation structure that does not overwrite other versions.  This directive dictates behavior when the SAME VERSION is already installed in the PSET_INSTALL_DIR.
• CONTINUE_WITH_INSTALLDIR_OVERWRITE=yes directs the installer to overwrite the existing compiler version of the SAME VERSION
• CONTINUE_WITH_INSTALLDIR_OVERWRITE=no directs the installer to exit if an existing compiler installation of the SAME VERSION already exists in PSET_INSTALL_DIR

COMPONENTS

• A typical compiler package contains multiple sub-packages, such as MKL, IPP, TBB, Debugger, etc.  This directive allows the user to control which sub-packages to install.
• COMPONENTS=DEFAULTS directs the installer to install the pre-determined default packages for the compiler (recommended setting).  The defaults may not include some sub-packages deemed non-essential or special purpose.  An example is the cluster components of MKL, which are only needed in a distributed memory installation.  If you're not sure of the defaults you can do a trial installation of the compiler in interactive mode and select CUSTOMIZE installation to see and select components.
• COMPONENTS=ALL directs the installer to install all packages for the compiler.
• COMPONENTS=<pattern> allows the user to specify which components to install.  The components vary by compiler version and package.  For example, pattern can be "mkl,ipp,tbb.composer"

PSET_MODE

• Sets the installer mode.  The installer can install, remove, modify, or repair an installation.
• PSET_MODE=install directs the installer to perform an installation
• PSET_MODE=remove directs the installer to remove a previous installation.  If multiple versions of the compiler are installed, the installer removes the most recent installation.  This information is kept in the RPM database or the non-rpm database depending on the mode used for the installation.
• PSET_MODE=modify allows the user to redo an installation.  The most common scenario is to overwrite an existing installation with more COMPONENTS set or unset.
• PSET_MODE=repair directs the installer to retry an installation again, checking for missing or damaged files, directories, and symbolic links, permissions, etc.

CLUSTER_INSTALL_AUTOMOUNT (optional)

• This directive is only needed for installation of the Intel(R) Parallel Studio XE 2015 Cluster Edition product.  For Composer and Professional Editions leave this directive commented out.
• CLUSTER_INSTALL_AUTOMOUNT=yes tells the installer to only perform the main package installation on a cluster head node or admin node in a directory that is remote mounted on all the cluster compute nodes.  This prevents the cluster installation from replicating all files on all nodes.  The head or admin nodes has the tools installed whereas compute nodes assume the PSET_INSTALL_DIR is  remote mounted - hence they do not need a full installation and just a few symbolic links and other small changes as necessary.
• CLUSTER_INSTALL_AUTOMOUNT=no directs the installer to use CLUSTER_INSTALL_MACHINES_FILES to find all cluster nodes and perform local installations as if those nodes were stand-alone servers.  This requires additional time and replicates files on all nodes.

CLUSTER_INSTALL_MACHINES_FILE (optional)

• This directive is only needed for installation of the Intel(R) Parallel Studio XE 2015 Cluster Edition product.  For Composer and Professional Editions leave this directive commented out.
• This directive instructs the installer where to find the machines file for a cluster installation.  The machines file is any text file with the names of all the cluster hosts on which to install the compiler.  The work performed on each host depends on CLUSTER_INSTALL_AUTOMOUNT (see above)
• CLUSTER_INSTALL_MACHINES_FILE=/your/path/to/your/machinefile/machinefile.txt

PHONEHOME_SEND_USAGE_DATA

• This directive guides the installer in the user's intent for the optional Intel Software Improvement Program.  This setting determines whether or not the compiler periodically sends customer usage information back to Intel.  The intent is for Intel to gather information on what compiler options are being used, amongst other information.  More information on the Intel Software Improvement Program can be found here: https://software.intel.com/en-us/articles/software-improvement-program.
• PHONEHOME_SEND_USAGE_DATA=no directs the installer to configure the compiler to not send usage data back to the Intel Software Improvement Program.
• PHONEHOME_SEND_USAGE_DATA=yes directs the installer to configure the compiler to send usage data back to the Intel Software Improvement Program.  Setting this to YES is your consent to opt-into this program.

SIGNING_ENABLED

• Directs the installer whether or not to check RPM digital signatures.  Checking signatures is recommended.  It allows the installer to find data corruption from such things as incomplete downloads of compiler packages or damaged RPMs.
• SIGNING_ENABLED=yes directs the installer to check RPM digital signatures.
• SIGNING_ENABLED=no directs the installer to skip the checking of RPM digital signatures.

Silent Install Steps: "Copy and Repeat" Method for Silent Configuration File Creation

If you need to make the same sort of installation over and over again, one way to get the silent installation configuration file right the first time is to run the installation program once interactively, using the options that meet the local needs, and record these options into a configuration file that can be used to replicate this same install via silent install for future installations.

To do this, the user simply needs to add the "duplicate" option to the script invocation, and run a normal interactive install, as follows:

• prompt> ./install.sh --duplicate /tmp/silent.cfg

This "dash dash duplicate" option will put the choices made by you into the file specified on the command line.  You can modify this recorded configuration file as appropriate and use it to perform future silent installations. 

RPM Command Line Installations

The files associated the Linux Compiler Professional products are stored in "RPM" files.  RPMs (short for Red Hat Package Manager).  They are grouped according to certain file type guidelines.  Each major product component will consist of one more or of these RPMs.  For non-RPM systems and for users who choose to install the product without using the RPM database of their target systems, an "underneath the hood" utility is embedded inside the installation program tools to extract the contents of the RPM files.

RPM Embedded Installation Functionality

Starting with the  version 11.1 packages, the Linux Compiler Professional packaging includes RPM files that also contain embedded installation functionality.  This means that key install behaviors such as environment script updating and symbolic link creation, which used to be only in the install program itself, are now embedded in the RPM files.  As a result, the experienced user can make use of the RPM files directly in order to install and remove Intel Composer XE 2011 for Linux and intel Compiler Professional 11.1 for Linux products.

Warning: this is truly for the experienced, Linux system savvy user.  Most RPM command capabilities require root privileges.  Improper use of rpm commands can corrupt and destroy a working system.

The changes done for the Linux compiler products are intended to ease the job of deploying in enterprise deployments, including cluster environments. 

Product Layout for Composer XE 2015

Here is an example (for C++ package 2011.2.137)

Top directory contents of l_ccompxe_2011.2.137 package:

• cd_eject.sh - CD eject script used by install.sh
• install.sh - install script
• install_GUI.sh - GUI front-end to the installer using X11. Only used for interactive, graphical installation method.
• license - end user license agreement
• support.txt - package version and contents information
• pset - installation and licensing content directory used by the Intel installers
• rpm - directory containing all product content in RPM file format, plus the EULA and LPGL license

This is an example Composer XE 2015  rpm directory.  This directory listing is for the initial Composer XE 2015 C++ release, your version strings will vary by compiler versions: https://software.intel.com/en-us/articles/intel-compiler-and-composer-update-version-numbers-to-compiler-version-number-mapping   NOTE:  this is not intended to be a comprehensive list for every compiler.  RPMs vary by compiler edition, components, and may vary by release.  Please list your 'rpm' directory for a list specific to your compiler.  The following is intended as a representative list:

EULA.txt                                             intel-ipp-sc-090-8.2-0.i486.rpm
intel-ccompxe-090-15.0-0.noarch.rpm                  intel-ipp-sc-090-8.2-0.x86_64.rpm
intel-compilerproc-090-15.0-0.i486.rpm               intel-ipp-sc-common-090-8.2-0.noarch.rpm
intel-compilerproc-090-15.0-0.x86_64.rpm             intel-ipp-st-090-8.2-0.i486.rpm
intel-compilerproc-common-090-15.0-0.noarch.rpm      intel-ipp-st-090-8.2-0.x86_64.rpm
intel-compilerproc-devel-090-15.0-0.i486.rpm         intel-ipp-st-devel-090-8.2-0.i486.rpm
intel-compilerproc-devel-090-15.0-0.x86_64.rpm       intel-ipp-st-devel-090-8.2-0.x86_64.rpm
intel-compilerpro-common-090-15.0-0.noarch.rpm       intel-ipp-st-devel-common-090-8.2-0.noarch.rpm
intel-compilerpro-common-pset-090-15.0-0.noarch.rpm  intel-ipp-vc-090-8.2-0.i486.rpm
intel-compilerproc-vars-090-15.0-0.noarch.rpm        intel-ipp-vc-090-8.2-0.x86_64.rpm
intel-compilerpro-devel-090-15.0-0.i486.rpm          intel-ipp-vc-common-090-8.2-0.noarch.rpm
intel-compilerpro-devel-090-15.0-0.x86_64.rpm        intel-mkl-090-11.2-0.i486.rpm
intel-compilerpro-vars-090-15.0-0.noarch.rpm         intel-mkl-090-11.2-0.x86_64.rpm
intel-gdb-090-7.7-0.i486.rpm                         intel-mkl-cluster-090-11.2-0.i486.rpm
intel-gdb-090-7.7-0.x86_64.rpm                       intel-mkl-cluster-090-11.2-0.x86_64.rpm
intel-gdb-cdt-090-7.7-0.x86_64.rpm                   intel-mkl-cluster-common-090-11.2-0.noarch.rpm
intel-gdb-cdt-source-090-7.7-0.x86_64.rpm            intel-mkl-cluster-devel-090-11.2-0.i486.rpm
intel-gdb-common-090-7.7-0.noarch.rpm                intel-mkl-cluster-devel-090-11.2-0.x86_64.rpm
intel-gdb-mic-090-7.7-0.x86_64.rpm                   intel-mkl-common-090-11.2-0.noarch.rpm
intel-gdb-mpm-090-7.7-0.x86_64.rpm                   intel-mkl-devel-090-11.2-0.i486.rpm
intel-gdb-python-source-090-7.7-0.noarch.rpm         intel-mkl-devel-090-11.2-0.x86_64.rpm
intel-gdb-source-090-7.7-0.noarch.rpm                intel-mkl-f95-common-090-11.2-0.noarch.rpm
intel-gdb-toplevel-090-7.7-0.noarch.rpm              intel-mkl-f95-devel-090-11.2-0.i486.rpm
intel-ipp-ac-090-8.2-0.i486.rpm                      intel-mkl-f95-devel-090-11.2-0.x86_64.rpm
intel-ipp-ac-090-8.2-0.x86_64.rpm                    intel-mkl-gnu-090-11.2-0.i486.rpm
intel-ipp-ac-common-090-8.2-0.noarch.rpm             intel-mkl-gnu-090-11.2-0.x86_64.rpm
intel-ipp-common-090-8.2-0.noarch.rpm                intel-mkl-gnu-devel-090-11.2-0.i486.rpm
intel-ipp-di-090-8.2-0.i486.rpm                      intel-mkl-gnu-devel-090-11.2-0.x86_64.rpm
intel-ipp-di-090-8.2-0.x86_64.rpm                    intel-mkl-mic-090-11.2-0.x86_64.rpm
intel-ipp-di-common-090-8.2-0.noarch.rpm             intel-mkl-mic-devel-090-11.2-0.x86_64.rpm
intel-ipp-gen-090-8.2-0.i486.rpm                     intel-mkl-pgi-090-11.2-0.i486.rpm
intel-ipp-gen-090-8.2-0.x86_64.rpm                   intel-mkl-pgi-090-11.2-0.x86_64.rpm
intel-ipp-gen-common-090-8.2-0.noarch.rpm            intel-mkl-pgi-devel-090-11.2-0.i486.rpm
intel-ipp-jp-090-8.2-0.i486.rpm                      intel-mkl-pgi-devel-090-11.2-0.x86_64.rpm
intel-ipp-jp-090-8.2-0.x86_64.rpm                    intel-mkl-sp2dp-090-11.2-0.x86_64.rpm
intel-ipp-jp-common-090-8.2-0.noarch.rpm             intel-mkl-sp2dp-devel-090-11.2-0.x86_64.rpm
intel-ipp-mt-090-8.2-0.i486.rpm                      intel-openmp-090-15.0-0.i486.rpm
intel-ipp-mt-090-8.2-0.x86_64.rpm                    intel-openmp-090-15.0-0.x86_64.rpm
intel-ipp-mt-devel-090-8.2-0.i486.rpm                intel-openmp-devel-090-15.0-0.i486.rpm
intel-ipp-mt-devel-090-8.2-0.x86_64.rpm              intel-openmp-devel-090-15.0-0.x86_64.rpm
intel-ipp-mx-090-8.2-0.i486.rpm                      intel-sourcechecker-common-090-15.0-0.noarch.rpm
intel-ipp-mx-090-8.2-0.x86_64.rpm                    intel-sourcechecker-devel-090-15.0-0.i486.rpm
intel-ipp-mx-common-090-8.2-0.noarch.rpm             intel-sourcechecker-devel-090-15.0-0.x86_64.rpm
intel-ipp-rr-090-8.2-0.i486.rpm                      intel-tbb-090-4.3-0.noarch.rpm
intel-ipp-rr-090-8.2-0.x86_64.rpm                    intel-tbb-devel-090-4.3-0.noarch.rpm
intel-ipp-rr-common-090-8.2-0.noarch.rpm

Other Special RPM Install Cases

If you are installing RPMs using the rpm command line, but using a multi-architecture package (such as the "combo" IA-32 / Intel64 package or a DVD package), you may want to install all of the RPMs that match their specific target machine's architecture.  Or, if you are installing onto an Intel64 system and want to include both the IA-32 and Intel64 components, you may want both of these included.  Here are some example rpm command line invocations:

• prompt>  rpm  -i  *.noarch.rpm  *.486.rpm
  • ​installs all components needed for operation on IA-32 architecture
• prompt>  rpm  -i  *.noarch.rpm  *.i486.rpm   *.x86_64.rpm
  • installs all components needed for operation on both IA-32 and Intel 64 architecture

Certain Linux distributions do not like the idea of two RPM files having the same base name.  For example, the rpm versions of certain distros might complain that there is more than one instance of  intel-cproc023-11.1-1 on the command line when installing both the IA-32 and Intel64 RPMs onto the same machine.  For these distros, use the "--force" ( dash dash force ) command line switch:

• prompt>  rpm  -i  --force  *.noarch.rpm  *.i486.rpm  *.x86_64.rpm

Customizing the RPM Command Line

The rpm command has a long list of available options, including hooks to install from FTP and HTTP RPM repositories, features to examine contents of installed RPM-based programs and uninstalled RPM package files, etc.  Most of these are beyond the scope of this document.  See the Links section for references to external documentation on RPM.  Here are a couple of additional RPM switches, however, which may be routinely useful.

• prompt>  rpm  -i  --prefix  /my_NFS_dir/intel_compiler_directory/this_version *.rpm
  • ​instructs rpm to use directory /my_NFS_dir/intel_compiler_directory/this_version as the root installation directory
• ​prompt>  rpm  -i --replacefiles  *.rpm
  • ​directs rpm to replace any existing files using the new rpm files
• ​prompt>  rpm  -i --replacepkgs  *.rpm 
  • directs ​rpm to replace any existing package on the system using the new RPM files, even if they are already installed ... this may be useful in test applications where newer versions of a package with the same name are being tested

Uninstallation Using RPM

Since the installation of Intel Linux compiler packages includes in its deliver all of the uninstall scripts, the easiest way to perform a product uninstall is to simply run the uninstall script that is created by the install process.  If you have a need to automate rpm-based uninstalls, however, a couple of "tricks" can be employed to make this simpler.  These should be used with caution, as with any system command performed from a privileged account.

Here is an example command line that will remove all RPM packages from a Linux Composer XE 2015 package number "090":

• rpm  -e  --allmatches `rpm -qa | grep intel- | grep 090`
  • ​note use of back-quotes
  • note that this only removes compiler packages.  You may wish to use a similar method to remove intel-mkl, intel-ipp, intel-gdb, intel-openmp and other intel packages

Some Linux distributions will also complain about "multiple matches" during the uninstall process.  In this case, the "--allmatches" switch mentioned above can also be employed here.

A Short Word on Updates

The rpm structure and command set support the application of updates or "patches" to existing installations.  For example a util-1.1-2.rpm package may be issued that adds fixed content to some pre-existing util-1.1-1.rpm.   The existing release process for Linux Composer XE includes support for "version co-existence" or multiple installs of separate product versions.  So each new iteration of the product is unique from the previous version.  This means that Intel compiler packages are not available in "patch" form.  All product releases are stand-alone versions.  So use of the 'rpm -U' upgrade capability is not supported by our product delivery model at this time. 

LSB Support

LSB, or Linux Standard Base, is an effort sponsored by the Linux Foundation (http://www.linuxfoundation.org) to improve the interoperability of Linux operating systems and application software.  Intel is a major participant in Linux Foundation activities and has embraced LSB as a viable means of improving our products and our customers' use of those products.  To that end, we have included establishing LSB compliance as a part of our goals for our products and software packages in the future.

For the purposes of the Intel Composer XE 2015 for Linux our primary objective is to product packages that adhere to LSB packaging requirements.  Most of the RPM changes mentioned above were done for this purpose.  To be specific, however, we should draw a distinction between product compliance and package compliance.  Because our compiler products must support a vast array of legacy constructs, the applications themselves may or may not be "certifiable" within the LSB guidelines, but our packages, i.e. our RPMs and install programs should be.  This is the primary reason for inclusion of the "lsb >= 3.0" embedded requirements being added to our RPMs.

Some of these Linux distributions come with LSB support already included in the operating system by default (e.g. SLES11).  For others, an external or optional package must be installed.  If supporting an environment that is using RPM command line installation and want to enable that site / system / systems to be able to install without using the dreaded "--nodeps" option, the best best is to acquire and install the companion LSB solution for that operating system.

The Linux Foundation website contains links to download resources for LSB, as to many of the vendor-specific support sites.  Check out these sites for information on adding LSB support to an existing operating system.

For RPM-based systems, a user can check on the status of LSB for their system, using a command like this:

• prompt>  rpm -q --provides lsb

This will tell if an 'lsb' RPM package is already installed and, if so, what version.

For our non-RPM supported operating systems, Ubuntu and Debian, the privileged user can use the Debian 'apt-get' facility to easily install the latest version of LSB supported by the specific distribution:

• prompt> apt-get install lsb

Redistribution Package Installations

Redistribution packages allow applicaitons built with the Intel compilers to be run on client systems that do not have the Intel compilers installed (i.e. end-user systems).  These are ONLY needed on systems without the Intel compilers installed. A redistribution package has all the Intel dynamic libraries possibly needed for a dynamically linked application.  Alternatively, you can explore to -static-intel compiler switch to statically link all required Intel libraries into an application.  Redistribution packages were officially supported with the 11.0 release and beyond. 

Installation is simple.  Once you extract the contents of the downloaded tarball (or accessing the redist contents of a DVD/image directory or media), you should simply invoke the "install.sh" script provided.  The user is instructed to accept a EULA, but there is no run-time license enforcement or any other software licensing included in the redist packages.  An uninstall script is produced during the redist install process, which provided for removal of the contents.

A note of caution: if the redist packages are installed on top of an existing Compiler package of the same release, it will land on and replace existing files in that compiler installation by default.  Similarly, if the redist uninstall operation is run and the redist and compiler packages are sharing the same directory space, removing the redist package will break the compiler installation.  Since the redist packages are not intended for use by compiler users on their development machines, this should not be an issue in most environments.  But it is mentioned here in case situations come up where this might explain problems that have occurred.

Uninstall Instructions

As mentioned above, a standard uninstall script is included with each product installation, regardless of whether the install was performed using menu installs, RPM command line installs, or "silent" installs.  In all cases, using the provided uninstall script should work and is the usual preferred method of removing installed product..  There is one uninstall feature, however, that is undocumented and can be used to make life a little easier.  Here's an example invocation of that feature:

• prompt>  /opt/intel/composer_xe_2015.<update>.<build>/bin/uninstall.sh  --default

This "--default" ( dash dash default ) option tells the uninstall script to use the "remove all" option and remove any compiler components associated with the specific package (in this case all  components, including C/C++, Fortran, IDB, MKL, TBB, and IPP, if installed).  There is no uninstall program interaction when this switch is used.

Note

As noted in the Intel® Software Development Product End User License Agreement, the Intel® Software Development Product you install will send Intel the product’s serial number and other system information to help Intel improve the product and validate license compliance. No personal information will be transmitted.

Links of Interest

The following links are provided for reference information.

• Maximum RPM - http://www.rpm.org/max-rpm/

Excellent on-line resource for understanding RPMs and their usage.

• Linux Foundation - http://www.linuxfoundation.org

Navigation:

• Linux and Mac OS X Compilers Installation Help: /en-us/articles/intel-compilers-linux-installation-help

• Licensing FAQS https://software.intel.com/en-us/articles/licensing-faq

• Question:  User Forums https://software.intel.com/en-us/forum

This may sound a bit complex, but here is my problem.  I am in the process of building a project that needs to use netcdf.  I'm using an older build (3.6.3), which, when I build it with Fortran bindings requires the compiler switch '/iface:mixed_str_len_arg' to work correctly.  I'm building them into static libraries so I can then include these in another project where I build a fortran DLL that.  I then call this new DLL from a C# program.  Passed variables all work now, except for arrays.  They get passed into the C# program at the correct length, but the elements in the array are all 'Undefined address'.  If I leave off the '/iface:mixed_str_len_arg' compiler switch, the NETCDF libraries won't work, and the string then get clobbered in the pass.  And none of these problems existed until I added in these NETCDF libraries...without them everything works fine - except I need them for my project.  Any thoughts?  Am I going about this totally backwards?  I am using Visual Fortran Composer XE 2011 with Visual Studio 2010.

Hi: We have two floating licenses for the Intel Fortran compiler. Previously, say with Composer 2013 and earlier, I was able to forward the license server ports with ssh to my local machine and check out a license. However, this has recently stopped working. Was it something on our end? Or some change to the way FlexLM works in new versions of Composer? I'm at a total loss how to troubleshoot this. I've checked the obvious things: I can ping the license server and telnet to the server ports. Any suggestions would be appreciated.

Thanks,