Dear Forum,

We are trying to bring up the license manager (lmgrd) for Intel Cluster Studio which we have purchased recently. There is already a lmgrd of Intel compiler is running on our server. we have ensured port numbers are not clashing between the two compilers. The log file is pasted below.

We also don't know how to combine the two license files if that is the solution

Please help us to solve this issue.

./lmgrd -c /opt/intel/serverlicenses/COM_L__xxxxxxxx.lic -l
15:38:35 (lmgrd) -----------------------------------------------
15:38:35 (lmgrd)   Please Note:
15:38:35 (lmgrd)
15:38:35 (lmgrd)   This log is intended for debug purposes only.
15:38:35 (lmgrd)   In order to capture accurate license
15:38:35 (lmgrd)   usage data into an organized repository,
15:38:35 (lmgrd)   please enable report logging. Use Flexera Software LLC's
15:38:35 (lmgrd)   software license administration  solution,
15:38:35 (lmgrd)   FlexNet Manager, to  readily gain visibility
15:38:35 (lmgrd)   into license usage data and to create
15:38:35 (lmgrd)   insightful reports on critical information like
15:38:35 (lmgrd)   license availability and usage. FlexNet Manager
15:38:35 (lmgrd)   can be fully automated to run these reports on
15:38:35 (lmgrd)   schedule and can be used to track license
15:38:35 (lmgrd)   servers and usage across a heterogeneous
15:38:35 (lmgrd)   network of servers including Windows NT, Linux
15:38:35 (lmgrd)   and UNIX.
15:38:35 (lmgrd)
15:38:35 (lmgrd) -----------------------------------------------
15:38:35 (lmgrd)
15:38:35 (lmgrd)
15:38:35 (lmgrd) Server's System Date and Time: Fri Apr 13 2018 15:38:35 IST
15:38:35 (lmgrd) SLOG: Summary LOG statistics is enabled.
15:38:35 (lmgrd) The license server manager (lmgrd) running as root:
15:38:35 (lmgrd)        This is a potential security problem
15:38:35 (lmgrd)        and is not recommended.
 (lmgrd) FlexNet Licensing (v11.14.1.1 build 201886 x64_lsb) started on ***@***.com (linux) (4/13/2018)
15:38:35 (lmgrd) Copyright (c) 1988-2017 Flexera Software LLC. All Rights Reserved.
15:38:35 (lmgrd) World Wide Web:  http://www.flexerasoftware.com
15:38:35 (lmgrd) License file(s): /opt/intel/serverlicenses/COM_xxxxxxx.lic
15:38:35 (lmgrd) lmgrd tcp-port 27200
15:38:35 (lmgrd) (@lmgrd-SLOG@) ===============================================
15:38:35 (lmgrd) (@lmgrd-SLOG@) === LMGRD ===
15:38:35 (lmgrd) (@lmgrd-SLOG@) Start-Date: Fri Apr 13 2018 15:38:35 IST
15:38:35 (lmgrd) (@lmgrd-SLOG@) PID: 32295
15:38:35 (lmgrd) (@lmgrd-SLOG@) LMGRD Version: v11.14.1.1 build 201886 x64_lsb ( build 201886 (ipv6))
15:38:35 (lmgrd) (@lmgrd-SLOG@)
15:38:35 (lmgrd) (@lmgrd-SLOG@) === Network Info ===
15:38:35 (lmgrd) (@lmgrd-SLOG@) Listening port: 27200
15:38:35 (lmgrd) (@lmgrd-SLOG@)
15:38:35 (lmgrd) (@lmgrd-SLOG@) === Startup Info ===
15:38:35 (lmgrd) (@lmgrd-SLOG@) Server Configuration: Single Server
15:38:35 (lmgrd) (@lmgrd-SLOG@) Command-line options used at LS startup: -c /opt/intel/serverlicenses/COM_xxxxxxxxx.lic -l
15:38:35 (lmgrd) (@lmgrd-SLOG@) License file(s) used:  /opt/intel/serverlicenses/COM_L___xxxxxxxxx.lic
15:38:35 (lmgrd) (@lmgrd-SLOG@) ===============================================
15:38:35 (lmgrd) Starting vendor daemons ...
15:38:35 (lmgrd) Using vendor daemon port 27201 specified in license file
15:38:35 (lmgrd) Started INTEL (internet tcp_port 27201 pid 32296)
15:38:35 (INTEL) Unable to initialize access to trusted storage: 2
15:38:35 (INTEL) FlexNet Licensing version v11.14.1.1 build 201886 x64_lsb
15:38:35 (INTEL) Cannot open lock file. errno=11 (/var/tmp/lockINTEL): Resource temporarily unavailable
15:38:35 (INTEL) EXITING DUE TO SIGNAL 41 Exit reason 9
15:38:35 (lmgrd) INTEL exited with status 41 (Exited because another server was running)
15:38:35 (lmgrd) MULTIPLE "INTEL" license server systems running.
15:38:35 (lmgrd) Please kill, and run lmreread
15:38:35 (lmgrd)
15:38:35 (lmgrd) This error probably results from either:
15:38:35 (lmgrd)   1. Another copy of the license server manager (lmgrd) is running.
15:38:35 (lmgrd)   2. A prior license server manager (lmgrd) was killed with "kill -9"
15:38:35 (lmgrd)       (which would leave the vendor daemon running).
15:38:35 (lmgrd) To correct this, do a "ps -ax | grep INTEL"
15:38:35 (lmgrd)   (or equivalent "ps" command)
15:38:35 (lmgrd) and kill the "INTEL" process.
15:38:35 (lmgrd)

Hi

Is icc (for C and C++) automitically installed while installing parallel-studio_xe-2018. after installing ifort when i looked for icc, i get

icc: command not found

i read, following are also needed

libstdc++5,   libstdc++   libstdc ++5   libgcc   glibc

are these too automatically installed alongwith fortran intel parallel studio XE edition. in their absence, segmentation fault can arise

thanks

anand

In the documentation of the Intel Fortran 16.0 (and also in the newer manuals) it is stated:

Excluding Coverage at the Line and Function Level
You can mark individual lines for exclusion my passing string values to the -onelinedsbl option. For
example, assume that you have some code similar to the following:
Sample code

print*, "ERROR: n = ", n ! NO_COVER

and for "Excluding Code by Defining Arbitrary Boundaries":

! /* BINF */
print*, "ERROR: n = ", n
print*, " n2 = ", n2
! // EINF

For the multi line version this is working but the single line isn't. A small experiment showed that:

print*, "ERROR: n = ", n // NO_COVER

and

print*, "ERROR: n = ", n /* NO_COVER */

are working.

Did we make a mistake or is this an omission in the manual?

Hi all,

Is there a way to setup multiple license files on one license server? We use Intel Software License Manager 2.6 for Linux and have 4 separate license files for different Windows/Linux compilers, but, it seems the license manager can be started only with one license file.

Best regards,

Petr

hello

i ma an undergrad student learning computational skils. recently, i compiled a binary using intel (R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.2.199 Build 20180210 running on ubuntu 14.04 64 bits OS.

test             0000000000418BBD  Unknown               Unknown  Unknown
libpthread-2.19.s  00002ADBE4BDD330  Unknown               Unknown  Unknown
test             00000000004D5356  Unknown               Unknown  Unknown
test            000000000043580F  Unknown               Unknown  Unknown
test              00000000004037BC  orddrv_                   221  test.f
test             00000000004032D8  MAIN__                     66  test.f
test              000000000040325E  Unknown               Unknown  Unknown
libc-2.19.so       00002ADBE4E0CF45  __libc_start_main     Unknown  Unknown
test             0000000000403169  Unknown               Unknown  Unknown

i understand its related to stack size in prog test. but what does the higlighted lines mean. besides am i missing some files required during run time ?

i have given  2 commands to increase stack size in bashrc file but i found no difference.

ulimit -s unlimited
export OMP_STACKSIZE=500M

i have also given following commands in .bashrc file to set environment
export PATH=$PATH:/opt/intel/bin
export PATH=$PATH:/usr/bin:/usr/local/bin

source /opt/intel/bin/compilervars.sh intel64
#source /opt/intel/bin/compilervars.sh ia32
export LD_LIBRARY_PATH=/usr/lib/:$LD_LIBRARY_PATH
export LIBRARY_PATH=/usr/lib:$LIBRARY_PATH

export LD_LIBRARY_PATH=/opt/intel/lib:$LD_LIBRARY_PATH

export LIBRARY_PATH=/opt/intel/mkl/lib/intel64:$LIBRARY_PATH

export MANPATH="/opt/intel/man"

export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH

what should i do ? kindly assists

shubham

export LD_LIBRARY_PATH=/opt/intel/mkl/lib/intel64:$LD_LIBRARY_PATH

Dear,

Below is a Coarray Fortran program that gives me some troubles:

A large vector (x) is updated in two different ways. For large sizes of x, the updates of x is wrong WHEN each image is on a different node. WHEN all images are on the same node, results are always fine, whatever the size of x.

When size(x)=10^6, exchanging the full array across images on different nodes led to wrong results. However, exchanging small subsets of x led to correct results.

When size(x)>2*10^7, exchanging the full array across images on different nodes led to wrong results, AND exchanging subsets of x  (size(subset) > 6*10^6) led to wrong results too.

My troubles seem to be linked to the size of the array that is exchanged across images on different nodes. So, am I doing something wrong? Could it be a bug?

I use ifort 17.0.0 with -coarray=distributed.

Here is the program that mimicks the problem (it may be stupid, with too many sync all, .... , but it is to replicate my issue):

program testcoarray
 implicit none
 integer(kind=4)::i,j,k,neq
 integer(kind=4)::startrow[*],endrow[*]
 real(kind=8)::val[*]
 real(kind=8),allocatable::x(:)[:]

 neq=1000000
 neq=25806732

 if(this_image().eq.1)then
  write(*,'(/a,i0)')' Size of the array: ',neq
  write(*,'(a,i0/)')' Number of images : ',num_images()
 endif

 !INITIALISATION
 i=neq/num_images()
 startrow=(this_image()-1)*i+1
 endrow=this_image()*i
 if(this_image().eq.num_images())endrow=neq

 allocate(x(neq)[*])

 sync all

 !FIRST UPDATE
 x=0.d0
 x(startrow:endrow)=real(this_image(),8)

 sync all

 if(this_image().eq.1)then
  do i=2,num_images()
   x=x+x(:)[i]
  enddo
  write(*,*)' First update : ',sum(x)
 endif

 sync all

 !SECOND UPDATE
 x=0.d0
 x(startrow:endrow)=real(this_image(),8)

 sync all

 if(this_image().eq.1)then
  do i=2,num_images()
   j=startrow[i]
   k=endrow[i]
   x(j:k)=x(j:k)+x(j:k)[i]
  enddo
  write(*,*)' Second update: ',sum(x)
 endif

 sync all

 !CORRECT ANSWER
 x=0.d0
 x(startrow:endrow)=real(this_image(),8)
 val=sum(x)

 sync all

 if(this_image().eq.1)then
  do i=2,num_images()
   val=val+val[i]
  enddo
  write(*,*)' Correct value: ',val
 endif

 sync all

end program

And here are the output for neq=1000000

*With all images on the same node:

 Size of the array: 1000000
 Number of images : 4

  First update :    2500000.00000000     
  Second update:    2500000.00000000     
  Correct value:    2500000.00000000

*With each image on a different node:

 Size of the array: 1000000
 Number of images : 4

  First update :    750000.000000000     
  Second update:    2500000.00000000     
  Correct value:    2500000.00000000 

And here are the output for neq=25806732

*With all images on the same node:

 Size of the array: 25806732
 Number of images : 4

  First update :    64516830.0000000     
  Second update:    64516830.0000000     
  Correct value:    64516830.0000000 

*With each image on a different node:

 Size of the array: 25806732
 Number of images : 4

  First update :    19355049.0000000     
  Second update:    6451727.00000000     
  Correct value:    64516830.0000000     

 

In advance thank you for your help.

Jeremie

The intrinsic function PACK is undefined when working on unlimited polymorphic allocatable arrays with ifort (IFORT) 18.0.1 20171018.

Can anybody explain whether this is an undefined behavior in Fortran language or it is a bug in the compiler?

The following code does not return a result as expected:

Program main

  integer :: a(4) = (/0, 1, 2, 3/)
  logical :: b(4) = (/.True., .True., .False., .False./)
  class(*), allocatable :: c(:)

  call array_pack(arrIn=a, arrOut=c, logic=b)

  select type(c)
  type is(integer)
     print*, 'c: ', c
  type is(real)
     print*, 'c: ', c
  end select

contains

  subroutine array_pack(arrIn, arrOut, logic)

    class(*), intent(inout) :: arrIn(:)
    class(*), intent(out), allocatable, target :: arrOut(:)
    logical, intent(in) :: logic(:)
    ! class(*), pointer :: arrOutLocal(:) => null()

    allocate(arrOut, source=arrIn)

    select type(arrOut)
    type is(integer)
       print*, 'arrOut: ', arrOut
    end select
    print*, logic
    arrOut = pack(arrIn, logic)
    select type(arrOut)
    type is(integer)
       print*, 'arrOut: ', arrOut
    end select

    print*, 'pack((/0, 1, 2, 3/), (/.True., .True., .False., .False./))', pack((/0, 1, 2, 3/), (/.True., .True., .False., .False./))

  end subroutine array_pack

end Program main

The expected result would be: 2, 3. as given by the last print line in the subroutine. However, with ifort 18, it fails to execute the second select type statement which indicates that the type of the array arrOut is unknown after the execution of PACK function. With gfortran-7, it still considers arrOut as an integer array but it also failed to give the expected result. What it prints is the original arrIn value, i.e., 0, 1, 2, 3, which indicates it failed in executing the PACK function.

Hi

I've been having trouble with declared subarray types, so am trying to switch my code over to using the direct subarray notation that's now allowed by the mpi_f08 module.

Using lines like:

    call MPI_Irecv(Array(0, 1:ksizey_l), ksizey_l, MPI_Real, ip_xdn, 0 + tag_offset, comm, reqs(2))
    call MPI_Isend(Array(1, 1:ksizey_l), ksizey_l, MPI_Real, ip_xdn, 1 + tag_offset, comm, reqs(3))

give warnings along the lines of:

test_mpif08.F90(51): warning #8100: The actual argument is an array section or assumed-shape array, corresponding dummy argument that has either the VOLATILE or ASYNCHRONOUS attribute shall be an assumed-shape array.   [ARRAY]
    call MPI_Irecv(Array(0, 1:ksizey_l), ksizey_l, MPI_Real, ip_xdn, 0 + tag_offset, comm, reqs(2))

(I've gisted a full minimal working example here.)

While I can't find much documentation on mpi_f08, reading examples like this suggest that what I'm doing should be fine - can anyone tell me why am I getting this warning, and how I can avoid it (without just suppressing it with a flag)?

Thanks

Ed

Join the Intel® Parallel Studio XE 2019 Beta Program today and—for a limited time—get early access to new features and get an open invitation to tell us what you really think.

We want YOU to tell us what to improve so we can create high-quality software tools that meet your development needs.

Sign Up Now >

Top New Features in Intel® Parallel Studio XE 2019 Beta

• Scale and perform on the path to exascale. Enable greater scalability and improve latency with the latest Intel^® MPI Library.
• Get better answers with less overhead. Focus more fully on useful data, CPU utilization of physical cores, and more using new data-selection support from Intel^® VTune^™ Amplifier’s Application Performance Snapshot.
• Visualize parallelism. Interactively build, validate, and visualize algorithms using Intel® Advisor’s Flow Graph Analyzer.
• Stay up-to-date with the latest standards:
  • Expanded C++17 and Fortran 2018 support
  • Full OpenMP* 4.5 and expanded OpenMP* 5.0 [DRAFT] support
  • Python* 3.6 and 2.7

New Features in Intel® Fortran Compiler

• User-defined reductions, completing support for OpenMP* 4.5
• BLOCK construct inside an OpenMP parallel region
• Array shape checking
• Coarray Events for synchronization of different coarray images

To learn more, visit Intel^® Parallel Studio XE 2019 Beta page.

Then sign up to get started.

Trying out for the first time ifort (19 beta) on MAC OS X with the trial version, up to now I had our software built only on Linux. On Darwin 17.5.0 using gcc (from my own build, not clang) as a CCLD C linker, I get unresolved symbols in my library (cf. below).

On Linux there is one more line

U isoc99 sscanf@@GLIBC 2.7  

but the executable does not bother that there are these undefined symbols in the main library. Before I post any more details (let me know which ones you want): any ideas? 

00000000060c71c0 s _isl

                 U _iso_c_binding_mp_c_associated_funptr_

                 U _iso_c_binding_mp_c_associated_ptr_

                 U _iso_c_binding_mp_c_loc_private_

                 U _iso_c_binding_mp_c_null_funptr_

                 U _iso_c_binding_mp_c_null_ptr_

Dear All

I have a library I am trying to port to ifort on MacOS, and about half way through, the following happens:

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; color: #34bc26; background-color: #ffffff}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; color: #000000; background-color: #ffffff}
span.s1 {font-variant-ligatures: no-common-ligatures; color: #000000}
span.s2 {font-variant-ligatures: no-common-ligatures}

[ 47%] Building Fortran object CMakeFiles/common.dir/WR_RECORDER.f90.o

[ 48%] Building Fortran object CMakeFiles/common.dir/WRITE_HTML_TEST.f90.o

[ 48%] Building Fortran object CMakeFiles/common.dir/COMMON_MODS.f90.o

[ 48%] Building Fortran object CMakeFiles/common.dir/SPECIAL_CONSTANTS_subm.f90.o

Error copying Fortran module "recursive".  Tried "RECURSIVE.mod" and "recursive.mod".

make[2]: *** [CMakeFiles/common.dir/recursive.mod.stamp] Error 1

make[1]: *** [CMakeFiles/common.dir/all] Error 2

make: *** [all] Error 2

The slight problem is that I have no idea what this Fortran module "recursive" is!

On my Mac I am using CMake to create a make file which contains no reference to a recursive.mod.  I have no file called recursive.f90 or a module called recursive.

I do use small number of recursive routines, and many of these seem to have compiled just fine.

I have no idea what to do next, I am using

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; color: #000000; background-color: #ffffff}
span.s1 {font-variant-ligatures: no-common-ligatures}

ifort (IFORT) 17.0.5 20170817

Thanks in advance

Norman

I ran into the following problem when using the Intel Fortran 2018 Update 1 Compiler.  I implemented a block algorithm to compute  an out-of-place triangular matrix-matrix product  C := alpha * A * B + beta *C, where A is a upper triangular matrix. Since the matrix matrix product has a great potential for parallelization I did this using OpenMP tasks and task dependencies. Ending up with the following code:

SUBROUTINE DTRMM3(M,N,ALPHA,A,LDA,B,LDB,BETA,C,LDC)
    USE OMP_LIB
    IMPLICIT NONE
    DOUBLE PRECISION ALPHA,BETA
    INTEGER LDA,LDB,LDC,M,N
    DOUBLE PRECISION A(LDA,*),B(LDB,*),C(LDC,*)
    EXTERNAL DGEMM, DTRMM
    INTRINSIC MAX
    INTEGER K,KB,L,LB,J,JB
    !     .. Parameters ..
    DOUBLE PRECISION DONE,DZERO
    PARAMETER (DONE=1.0D+0,DZERO=0.0D+0)
    INTEGER NB
    PARAMETER(NB=256)
    !     .. Local Work...
    DOUBLE PRECISION TMP(NB,NB)

    IF (M.EQ.0 .OR. N.EQ.0) RETURN

    IF (ALPHA.EQ.DZERO) THEN
        DO J = 1,N
            !$omp simd safelen(64)
            DO K = 1,M
                C(K,J) = BETA * C(K,J)
            END DO
            !$omp end simd
        END DO
        RETURN
    END IF

    DO L = 1,N,NB
        LB = MIN(NB,N - L + 1)
        DO K = 1,M,NB
            KB = MIN(NB, M - K + 1)
            !$omp task firstprivate(K,KB,L,LB) depend(inout: C(K:K+KB-1,L:L+LB-1)) shared(C,BETA)
            C(K:K+KB-1, L:L+LB-1) = BETA * C(K:K+KB-1,L:L+LB-1)
            !$omp end task
            DO J = K, M, NB
                JB = MIN(NB, M - J + 1)
                !$omp task firstprivate(K,KB,L,LB, J, JB) private(TMP) &
                !$omp& depend(in:A(K:K+KB-1,J:J+JB-1), B(J:J+JB+1,L:L+LB-1)) depend(inout: C(K:K+KB-1,L:L+LB-1)) &
                !$omp& shared(ALPHA,A,B,LDA,LDB,LDC) default(none)
                IF ( K .EQ. J ) THEN
                    TMP(1:KB,1:LB) = B(K:K+KB-1,L:L+LB-1)
                    CALL DTRMM("L","U","N","U", KB, LB, ALPHA, A(K,K), LDA, TMP, NB)
                    C(K:K+KB-1, L:L+LB-1) = C(K:K+KB-1,L:L+LB-1) + TMP(1:KB,1:LB)
                ELSE
                    CALL DGEMM("N", "N", KB, LB, JB, ALPHA, A(K,J), LDA, B(J,L), LDB, DONE, C(K,L),LDC)
                END IF
                !$omp end task
            END DO

        END DO
    END DO
    RETURN
END SUBROUTINE

and execute it using:

    !$omp parallel
    !$omp master
    CALL DTRMM3(M, N, ALPHA, A, LDA, B, LDB, BETA, C2, LDC)
    !$omp end master
    !$omp taskwait
    !$omp end parallel

The attached file contains the whole example.

I compiled the code using

 ifort -xHost -O3 dtrmm3_test.f90  -qopenmp -mkl -g

and executing it on a 16-core Xeon Silver 4110 leads to a segmentation fault:

./a.out 
   512   786     0.00000000D+00   0.00000000D+00   0.00000000D+00  T
   512   786     0.00000000D+00   0.10000000D+01   0.00000000D+00  T
   512   786     0.00000000D+00   0.20000000D+01   0.00000000D+00  T
forrtl: severe (174): SIGSEGV, segmentation fault occurred
forrtl: severe (174): SIGSEGV, segmentation fault occurred
forrtl: severe (174): SIGSEGV, segmentation fault occurred

The first three lines show that the path ALPHA=0.0 works and it only crashes when the task-based part of the algorithm is called.

Uisng GCC 7.3 and Netlib BLAS everything works fine without an error.

OS: CentOS 7.4 , Intel Fortran 2018 Update 1, MKL 2018 Update 1

I have an issue understanding automatic arrays, especially where in between stack or heap it is stored.

I have the following main program.

program myprog
use mymod
implicit none
integer, parameter :: N = 477, M = 4
complex*16, parameter :: imnum = dcmplx(1.0d0,1.0d0)
complex*16 :: A(N,N,M), B(N,N,M-1), C(N,N,2:M), X(M*N), Y(M*N)
integer :: i, j, k

do k = 1,M
   do i = 1,N
      do j = 1,N
         A(i,j,k) = i*j/dble(N)
         if (k < M) then
            B(i,j,k) = 1.0d0 + imnum/(i+j)
            C(i,j,k+1) = 1.0d0 - imnum/(i+j)
         end if
      end do
   end do
end do

do i = 1,M*N
   X(i) = dble(i)
end do

call mysub('G', N, M, A, B, C, X, Y)

end program

Subroutine mysub is located inside module mymod.f90.

! =============================================================                                                                                                                                                                                                                                                                                                             
subroutine mysub(ulh, N, M, diag, udiag, ldiag, vinp, vout)
implicit none
integer :: i, il, ic, ir
character, intent(in) :: ulh*1
integer, intent(in) :: N, M
complex*16, intent(in) :: diag(:,:,:), udiag(:,:,:), vinp(:) 
complex*16, intent(in), optional :: ldiag(:,:,2:)
complex*16, intent(out) :: vout(M*N)
complex*16, allocatable :: ldiag1(:,:,:)        
complex*16 :: v_l(size(diag,1)), v_c(size(diag,1)), v_r(size(diag,1))


allocate(ldiag1(N,N,2:M))

if (ulh == "G") then
   if (present(ldiag)) then
      ldiag1 = ldiag
   else
      stop "In subroutine tribl_matmul, argument ldiag is required when argument ulh = 'G'."
   end if
end if


!allocate(v_l(N), v_c(N), v_r(N))
!call omp_set_num_threads(2)    
!!$OMP PARALLEL DO PRIVATE(ic, il, ir, v_l, v_r, v_c)
do i = 1,M                                    
   ic = (i-1)*N+1
   il = (i-1-1)*N+1
   ir = (i+1-1)*N+1

   if (i == 1) then
      v_l = dcmplx(0.0d0,0.0d0)
      call zgemv('n', N, N, 1.0d0, udiag(:,:,i), N, vinp(ir:ir+N-1), 1, 0.0d0, v_r, 1)
   else if (i == M) then
      call zgemv('n', N, N, 1.0d0, ldiag1(:,:,i), N, vinp(il:il+N-1), 1, 0.0d0, v_l, 1)
      v_r = dcmplx(0.0d0,0.0d0)
   else
      call zgemv('n', N, N, 1.0d0, ldiag1(:,:,i), N, vinp(il:il+N-1), 1, 0.0d0, v_l, 1)
      call zgemv('n', N, N, 1.0d0, udiag(:,:,i), N, vinp(ir:ir+N-1), 1, 0.0d0, v_r, 1)
   end if
                                                                                                                                                                                                                                                                                             
   call zgemv('n', N, N, 1.0d0, diag(:,:,i), N, vinp(ic:ic+N-1), 1, 0.0d0, v_c, 1)    
   write(*,"(a25,i3,3(f20.3,2x))") "problem, v_l, v_c, v_r", i, abs(sum(v_l)), abs(sum(v_c)), abs(sum(v_r)) 
   vout(ic:ic+N-1) = v_l + v_c + v_r
end do
!!$OMP END PARALLEL DO
!deallocate(v_l, v_c, v_r) 
deallocate(ldiag1)

end subroutine

I compiled and ran it using these commands

#!/bin/sh                                                                                                                                                                                                  
ulimit -s unlimited
longflag="-L/opt/intel/composerxe-2011/mkl/10.2.3.029/lib/em64t -lmkl_solver_ilp64_sequential -lmkl_intel_ilp64 -lmkl_core -lmkl_sequential -lpthread -lm"
ifort -openmp -check arg_temp_created -i8 -c ./mymod.f90 ${longflag}
ifort -openmp -check arg_temp_created -i8 ./myprog.f90 mymod.o ${longflag}
./a.out

The calculation was erroneous as it prints out

   problem, v_l, v_c, v_r  1               0.000        8673538245.000                   NaN
   problem, v_l, v_c, v_r  2        54265785.750       23341568032.702                   NaN
   problem, v_l, v_c, v_r  3       171280368.928       33841597383.353                   NaN
   problem, v_l, v_c, v_r  4       270608107.622       36760173582.811                 0.000

Then if I add -heap-arrays flag in the compilation of mymod.f90, the problem is remedied and those NaN values become just valid numbers. This means without heap-arrays all automatic arrays (no temporary arrays were created) are most likely located in stack. But I have removed the stack limit so I expected the execution should be fine without heap-arrays flag. So, where are automatic arrays located actually? 

As for which arrays are automatic inside mysub, they must be v_l, v_c, and v_r. This is because when I declared them as allocatable and remove the comment marks in the allocatable and deallocatable statements of these arrays, without heap-arrays flag, the calculation didn't yield NaN. The reason I prefer these three arrays to be automatic rather than allocatable is that when I went with the latter and run the program with those openmp directives activated, the program did not print anything, not even error or warning flags, which I interpreted as an error anyway.

This concerns the recently published ifort19 beta release.

The following piece of code crashs with SIGSEGV. Trying various versions it is clear that the combination of block and the omp do loop causes the problem. Moving declaration of variable x out of the block (and for example move declaration of k into the block) avoids the crash.

The code has been compiled with "ifort -qopenmp test.f90 -o test". The crash occurs regardless of optimisation level (tested -O0 and -O3).

I should also note that valgrind reports use of an uninitialised value of size 8 (with option -O0).

program test

   integer(4) :: k

   block
     integer(4), dimension(:), pointer :: x

     allocate(x(1:100))

!$omp parallel do schedule(dynamic, 10) default(shared) private(k)
     do k = 1,100
        x(k) = k
     end do
!$omp end parallel do

     deallocate(x)
   end block

end program test

It seems to be allowed to declare derived types within the specification-part of a subroutine (or function for that matter) and use this type for local variables. However, if I add type-bound procedures to the derived type, I do not know how to provide an implementation for these methods. Putting it into the contains section does not seem to be allowed. Is having a derived type with type-bound procedures not allowed or do I need to implement it differently. I did not find anything on that topic in a couple of fortran books.

Here is a small example code, of what is not compiling, but it should convey the idea. Once the two lines marked by ' ! comment out' are commented out or removed, it compiles and works as expected).

module modderived

implicit none
private

public sub

contains

   subroutine sub(x)
      integer :: x

      type :: t
         integer :: x
      contains
         procedure :: w => sub_w     ! comment out
      end type t

      type(t) :: tt

      print *, 'here: ', x
      tt%x = x
      call tt%w(4)     ! comment out

   contains

      subroutine sub_w(self, y)
         class(t) :: self
         integer  :: y

         print *, 'there: ', self%x + y
      end subroutine sub_w

   end subroutine sub

end module modderived

pl let me whether intel fortran parallel_studio_xe_2017_update6 can be installed on ubuntu 14.04 ? the PSXE2017Update6_ReLEase_Notes_en_US_Lin_Win says so but when i try to install it says OS not supported ? i have ubunty 64 bits OS

what essential prerequisites are required before installing this this version of fortran ?

sd

For ifort 18.0.2 I get the following messages in attempting to compile one of my codes:

ifort -c sbox_hashes.f90

sbox_hashes.f90(321): error #6384: The INTEGER(KIND=4) value is out-of-range.

              ] - 2_int64**32, kind=int64 ), int(                 & 

-------------------------^

sbox_hashes.f90(450): error #6384: The INTEGER(KIND=4) value is out-of-range.

              ], kind=int64 ) >= 2_int64**31 ), kind=int32 )

----------------------------------------^

sbox_hashes.f90(63): error #7747: Invalid parameter expression.   [INT]

        mulvey_maps(0:255) = int( merge( int(                     &

-----------------------------^

compilation aborted for sbox_hashes.f90 (code 1)

 I suspect the third message is caused by the other two. I had expected that in mixing integer kind values in an expression the result would have the kind value with the largest number of digits. In that case the indicated expression should result in an in range value. Am I mistaken about the effect of mixing kind values?

I think I saw discussions on this topic already on c.l.f. I am having the following subroutine (and the recursive attribute doesn't play a role)

recursive function constr_quark_loopline(ho,sho) result(cl)
    integer, dimension(sho), intent(in) :: ho
    integer, dimension(sho)             :: hor
    integer, intent(in)                 :: sho
    [...]
end function constr_quark_loopline 

Intel gives an error message error #6415: This name cannot be assigned this data type because it conflicts with prior uses of the name.   [SHO]

in the case this is an external procedure, or a module procedure with or without 'implicit none' in the head of the module.

First of all, I would like to get it confirmed that this is really a contradiction of the standard, and that the order of the declarations matters. In case this is a module procedure without implicit none or an external procedure, implicit typing rules apply and sho would be considered to be a real, such that later specifying it as an integer is a contradiction. gfortran and nagfor complain:

   integer, intent(in)                 :: sho  
                                            1
Error: Symbol ‘sho’ at (1) already has basic type of REAL

and

Error: rec.f90, line 8: Symbol SHO has already been implicitly typed
       detected at SHO@<end-of-statement>

The strange thing (which seems a compiler bug to me) is that gfortran compiles this code when it is a module procedure with 'implicit none'. This seems a  (gfortran) compiler bug to me. Comments are appreciated.

And yes, of course, I know that having the declaration of sho first solves all the problems, but this is 3rd-party code.

Hi,

I have just installed the Intel Fortran compiler and libraries on my iMac (High Sierra) but I am having issues calling an executable from within an executable via the systtemqq line, say x=systemqq('./executable.x'). So, the call.x program below simply tells the command line to run executable.x

I consistently get the error:

dyld: Library not loaded: @rpath/libiomp5.dylib

  Referenced from: /Users/username/folder/./call.x

  Reason: image not found

However, if I check what libraries call.x and executable.x are both searching for, via 'stool -L xxxxx' they are exactly the same:

@rpath/libiomp5.dylib (compatibility version 5.0.0, current version 5.0.0)

    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)

Now, the fun part, if I simply do: ./executable.x from the terminal, it runs fine, no issues. 

Clearly there is something strange occurring with calling the system. There is a workaround, but I do not see the logical sense in typing:

install_name_tool -change @rpath/libiomp5.dylib /opt/intel/compilers_and_libraries_2018.2.xxx/mac/compiler/lib/libiomp5.dylib executable.x

install_name_tool -change @rpath/libiomp5.dylib /opt/intel/compilers_and_libraries_2018.2.xxx/mac/compiler/lib/libiomp5.dylib call.x

every time I need to run a program. 

There are no issues given out with compiling these. My bash_profile has already been edited to include the compiler and mkl libraries. 

export DYLD_LIBRARY_PATH=/opt/intel/compilers_and_libraries_2018.2.164/mac/compiler/lib:/opt/intel/compilers_and_libraries_    2018.2.xxx/mac/mkl/lib:$DYLD_LIBRARY_PATH

Surely there is a better option than manually redefining the location of @rpath/libiomp5.dylib every time.

I would be extremely grateful for any insight or help on this. 

Best,

Eamon.

I have a moderate size code and I will run into seg fault if I don't set ulimit -s unlimited. From this observation I guess it's stack overflow issue. I make sure that no array temps were created by using -check arg_temp_created in all compilation lines. Now what I cannot 100% tell is whether there are any automatic arrays. AFAIK, automatic arrays are array in a subroutine or function whose dimensions cannot be determined during compile time, e.g. if the dimension is itself one of the dummy arguments of that subroutine. I have not yet gone through my source code entirely to see if there are such arrays but I am almost sure there aren't. However most of my local arrays and dummy array arguments have dimensions which are constant expression, i.e. the dimensions are declared in another module with parameter attribute. Are these arrays also classified as automatic? If not what could possibly cause stack overflow? Is it just because my data are too large, just FYI some arrays are 3D complex*16 arrays with dimension of about 700x700x40. Also my codes are compiled with openmp directives, if that is worth considering. I need to not be reliant on unlimiting the stack because this program of mine will need to be made public and I don't want the user to need to set ulimit -s unlimited them self when executing my program.