Consider:

    ! the interface part in the module which compiles OK

    module function double_it(A)
       REAL(KIND=IRK), intent(in) :: A(3)
       REAL(KIND=IRK)             :: double_it(3)
    end function double_it

    ! the implementation part in the submodule.
    ! error #6833: The RESULT data type is  multiply specified: on function statement and result name.   [B]
    ! error #6834: Array specifications must be given for result name, not function.   [B]
    ! both errors relate to the line below
    module function double_it(A) result(B)
       implicit none
       REAL(KIND=IRK), intent(in) :: A(3)
       REAL(KIND=IRK)             :: B(3)
       B=2._IRK*A
    end function double_it

Can one use result with module function? If so what is the correct syntax I have spend some time trying to find enlightenment and have failed again :-(

.

I am having some trouble understanding the need for and use of FINAL routines in Fortran 2003.  I have a TYPE (or CLASS) which has a second TYPE extending it.  The second TYPE and the first TYPE each have FINAL routines.  I explicitly CALL the FINAL routine for the second TYPE.  According to the F2003 standard, should it be the case that the first FINAL routine gets called as well?  I can run the application in debug and put a break in the first FINAL routine and note it is never reached.

Now here is the heart of the matter.  What is the use of the FINAL routine?  In the deep dark past of which I am accustomed, final-like routines were mainly used to prevent memory leaks.  The current Fortran standard seems to have memory "management" which does not explicitly require a DEALLOCATE statement for every ALLOCATE.  So, what is the use of FINAL?

I have installed Intel Compiler for Windows v.10 to ASUS notebook with OS Windows 8.1.

IT does not work. When I try to run some simple program (chit.f90)

The message was the following

LINK:  fatal error LINK1104: cannot open file "chit.exe"

If I click on ifort.exe and try to run the compiler from the command prompt window appear the following message

"The program can't start because mspdb80.dll is missing from your computer. Try to reinstall the program to fix this problem."

I reinstalled compiler two times with the same result.

:

I have installed Intel Compiler for Windows v.10 to ASUS notebook with OS Windows 8.1.

IT does not work. When I try to run some simple program (chit.f90)

The message was the following

LINK:  fatal error LINK1104: cannot open file "chit.exe"

If I click on ifort.exe and try to run the compiler from the command prompt window appear the following message

"The program can't start because mspdb80.dll is missing from your computer. Try to reinstall the program to fix this problem."

I reinstalled compiler two times with the same result.

:

Hi,

I was blocked by a problem when I try to program with Fortran in VS 2008 Pro. Even a simple test fortran program cannot be run:

Program test

print *, "hello"

end

Error as follows:

LIBCMTD.lib(close.obj): error LNK2001

LIBCMTD.lib(open.obj): error LNK2001

Who will be kindly provide solutions? Thanks in advance.

Hi,

I have the following 1-D PIC Code from the Livermore Fortran Kernels. The following options with the compiler version 15.0.3 where used: ifort -O3 -mavx -align array64byte -ansi-alias -qopt-report=5 livermore.f

               fw= 1.000d0
c
 1014 DO   141  k= 1,n
            VX(k)= 0.0d0
            XX(k)= 0.0d0
            IX(k)= INT(  GRD(k))
            XI(k)= REAL( IX(k))
           EX1(k)= EX   ( IX(k))
          DEX1(k)= DEX  ( IX(k))
 141  CONTINUE
c
      DO   142  k= 1,n
            VX(k)= VX(k) + EX1(k) + (XX(k) - XI(k))*DEX1(k)
            XX(k)= XX(k) + VX(k)  + FLX
            IR(k)= XX(k)
            RX(k)= XX(k) - IR(k)
            IR(k)= MOD2N(  IR(k),2048) + 1
            XX(k)= RX(k) + IR(k)
 142  CONTINUE
c
      DO  14    k= 1,n
      RH(IR(k)  )= RH(IR(k)  ) + fw - RX(k)
      RH(IR(k)+1)= RH(IR(k)+1) + RX(k)
  14  CONTINUE
c
c...................
      IF( TEST(14) .GT. 0) GO TO 1014

The compiler merges the three inner loops into one. This is fine since they have the same length and also the operations do not conflict. However the vectorization fails because of a dependence betwwen RH in the last two lines.

  LOOP BEGIN at livermore_cray.f(2207,12)
      remark #25045: Fused Loops: ( 2207 2216 2225 )

      remark #15344: loop was not vectorized: vector dependence prevents vectorization
      remark #15346: vector dependence: assumed OUTPUT dependence between rh line 2226 and rh line 2227
      remark #15346: vector dependence: assumed OUTPUT dependence between rh line 2227 and rh line 2226
      remark #25015: Estimate of max trip count of loop=1001
   LOOP END

But the indices are definitely different because IR(k) and IR(k)+1 cannot be the same value. The only thing I can image is, that between two iterations these operations may be in conflict. But why is vectorization not possible? Shouldn't the iterations be somewhat independent even with loop unrolling?

I have defined Types in my Fortran program. In those Types there are 1-D and 2-D arrays defined. But when I try to call a routine defined in a C++ DLL I get an "Unhandled Exception" error. 

To better explain my issue I've written a basic Fortran code and basic C++ code that demonstrates the issue.

The Fortran code calling the C++ DLL is:

 
   IMPLICIT NONE
   
   TYPE :: ProbType
      INTEGER*4 :: mxw
      INTEGER*4 :: npr
      INTEGER*4, DIMENSION(:), POINTER :: pr
   END TYPE ProbType
   
   TYPE :: SolType
      INTEGER*4 :: npt
      INTEGER*4, DIMENSION(:), POINTER :: sc
      INTEGER*4, DIMENSION(:), POINTER :: nro
      INTEGER*4, DIMENSION(:,:), POINTER :: pt
   END TYPE SolType
 
   INTERFACE
      SUBROUTINE CPPRoutine(prob, solinit, solresult, action)
         import :: ProbType, SolType
         IMPLICIT NONE
         !DEC$ ATTRIBUTES STDCALL, DECORATE, ALIAS:"CPPRoutine" :: CPPRoutine
         !DEC$ATTRIBUTES VALUE :: action
         !DEC$ATTRIBUTES REFERENCE :: prob, solinit, solresult
         TYPE(ProbType)  prob
         TYPE(SolType) solinit
         TYPE(SolType) solresult
         INTEGER*4 action
      END SUBROUTINE CPPRoutine
   END INTERFACE
   
   TYPE(ProbType) :: prob
   TYPE(SolType)  :: solinit
   TYPE(SolType)  :: solresult
   INTEGER*4      :: action
   INTEGER*4      :: i, j
        
   
   prob%mxw = 600000
   prob%npr = 80 
   ALLOCATE (prob%pr(prob%npr))
   DO i = 1, prob%npr
      prob%pr(i) = i * 75
   ENDDO
   
   solinit%npt = 8
   ALLOCATE (solinit%sc(solinit%npt))
   ALLOCATE (solinit%nro(solinit%npt))
   ALLOCATE (solinit%pt(solinit%npt,prob%npr))
   DO i = 1, solinit%npt
      solinit%sc(i) = i*3
      solinit%nro(i) = i+1
      DO j = 1, solinit%nro(i)
         solinit%pt(i,j) = i * j
      ENDDO
   ENDDO
   
   CALL CPPRoutine(prob, solinit, solresult, action)
   
   DEALLOCATE(prob%pr)
   DEALLOCATE(solinit%sc)
   DEALLOCATE(solinit%nro)
   DEALLOCATE(solinit%pt)
    
   RETURN
    
   END

The C++ code inside the DLL is:

The KBP.cpp file contains:

#include "KBP.h"

#include <algorithm>
#include <fstream>
#include <iostream>
using namespace std;

void __declspec(dllexport) _stdcall CPPRoutine(Prob* prob, Sol* sol, Sol* result, int action)
{

    ofstream file("c:\\input.txt");
    file << "mxw = "<< prob->mxw << endl;
    file << "npr = "<< prob->npr << endl;

    file << "pr = ";
    for (int i = 0; i < prob->npr; ++i) file << prob->pr[i] << "";
    file << endl;

    file << "npt = "<< sol->npt << endl;
    file << "sc = ";
    for (int i = 0; i < sol->npt; ++i) file << sol->sc[i] << "";
    file << endl;
    file << "nro = ";
    for (int i = 0; i < sol->npt; ++i) file << sol->nro[i] << "";
    file << endl;

    for (int i = 0; i < sol->npt; ++i)
    {
        file << "pt["<< i << "] = ";
        for (int j = 0; j < sol->nro[i]; ++j)
            file << sol->pt[i][j] << "";
        file << endl;
    }
    file << endl;
    file.close();

    int npt = sol->npt - 1;

    result->npt = npt;
    result->sc = new int[npt];
    result->nro = new int[npt];
    result->pt = new int*[npt];

    for (int i = 0; i < npt; ++i)
    {
        result->sc[i] = sol->sc[i];
        result->nro[i] = sol->nro[i];
        result->pt[i] = new int[sol->nro[i]];
        for (int j = 0; j < sol->nro[i]; ++j)
            result->pt[i][j] = sol->pt[i][j];
    }

    return;
    
}

The KBP.h file contains:

extern "C"
{
    struct Prob
    {
        int mxw;
        int npr;
        int* pr;
    };

    struct Sol
    {
        int npt;
        int* sc;
        int* nro;
        int** pt;
    };

    void __declspec(dllexport) _stdcall CPPRoutine(Prob* prob, Sol* sol, Sol* result, int action);
}

What am I doing wrong? Any help is much appreciated. 

Thanks,

Denis

PS: For your info, I'm running Intel Parallel Studio XE 2015 Composer Edition For Fortran Windows and Visual Studio 2013  

Hello Intel,

ifort 15.0.3 (with no options given) aborts with an error on the code below. The error seems to be related to the intent(out) attribute on a "class" polymorphic dummy argument (which is not declared allocatable). I encountered the problem with intent(out) passed dummy arguments, but it doesn't have to be a passed dummy to trigger the error (e.g. as in my example).

I am using

Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.3.187 Build 20150407

Best regards,
Ferdinand

module m
	implicit none
	public

	! Some derived type
	type :: t
	end type

contains

	! Derived type is polymorphic intent(out) dummy arg.
	subroutine sub(arg)
		class(t), intent(out) :: arg
	end subroutine
end module


program p
	implicit none

	! Error:

	! /scratch/ifort857Jqq.o: In function `sub':
	! [...]/test.f90:12: undefined reference to `for_dealloc_all_nopdtlen'

end program

PS: I searched the forum but couldn't find any post related to this issue, even though it seems to be very basic.

I am writing a Fortran Console application that uses a single dialog box. The box contains a variable number of checkbox controls; i.e. the program must add and remove checkboxes. Not having much experience with this--and not even sure it is possible--I am contemplating a brute force approach where my program directly edits the resource.rc file. An excerpt from this file (an example dialog that contains two checkbox controls) is

IDD_DIALOG1 DIALOG DISCARDABLE 0, 0, 362, 230
STYLE DS_MODALFRAME ! WS_POPUP ! WS_CAPTION ! WS_SYSMENU
CAPTION "Keyword list"
FONT 8, "Ms Sans Serif"
BEGIN
    CONTROL         "Check1",IDC_CHECK1,"Button",BS_AUTOCHECKBOX |
                    WS_TABSTOP,15,30,68,13
    CONTROL         "Check2",IDC_CHECK2,"Button",BS_AUTOCHECKBOX |
                    WS_TABSTOP,15,42,64,12
END

So, it appears that all my program has to do is manipulate the text in this Begin-End block, adding and removing lines. Right?

What worries me is that there is also an associated Resource.fd include file, and a Resource.h header file, which also contain similar information. Does my program also need to modify these? This would become much more burdensome. And, there is a statement in the "Digital Visual Fortran Programmer's Guide" (the only reference I have with info on this topic) warning that this may not work.

Or maybe there is a better way?

I am trying to compile source code utilising the Intel Math Kernel Library Version 11.3 and the latest Parallel Studio V16.0. When I add the following statement:

include 'lapack.f90'

in the variable declaration section of the file and try to compile the file I get the following error messages:

C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016\windows\mkl\include\lapack.f90(31): error #6617: The END statement for a CONTAINed procedure is missing.
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016\windows\mkl\include\lapack.f90(31): error #6702: END statement confusion.
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016\windows\mkl\include\lapack.f90(39): error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [F95_PRECISION]
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016\windows\mkl\include\lapack.f90(41): error #6683: A kind type parameter must be a compile-time constant.   [WP]
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016\windows\mkl\include\lapack.f90(39): error #6581: Unresolved rename.   [WP]
C

etc 

What am I doing wrong?

When compiling a submodule I get some errors of the type.....

....ubs.f90: error #7257: The characteristics of the procedure's arguments differ from those of the same procedure's arguments that are redefined in the INTERFACE statement.   [HWND]

The error is pretty clear cut, a simple type mismatch between the routine implementation and its interface. Some indication of line number would be nice. In a module full of windows API call wrappers spanning a few thousand lines of code the dummy arg variable Hwnd occurs quite a few times and I spent quite some time looking at all references to find the miscreant.   If you click on the error it jumps to line 1 of the Fortran source file BTW.

Hi,

while running executable cras.x i am getting -

"forrtl: severe (64): input conversion error"

this error is coming while reading crastat.in file -

while reading following line -

  ABCD 20120625     2   309 33.901 22.521 20.000 28.048 79.924 -0.004 67.332******* 99.062 38.765

since while reading i have specified f7.3 format and in file crastat.in its ******* there .

Please help me as to how i can ignore this input conversion in ifort.

When i am compiling same program using xlf_r or f77 its ignoring input conversion and running fine.

Regards,
Shivali

Hi,

I'm reading a little bit about RMA operations and I'm trying to play with. However, I do not find some working examples of FORTRAN code, so that I can progress. If someone has some simple working examples in FORTRAN, please share :)

For the moment I only found the subroutines SUM and MAPVALS from mpi-forum.org. And I have some difficulties:

program test_MPI_RMA
use mpi

integer, parameter :: m=10

INTEGER i,map(m),comm,ierr,nproc,rank
REAL*8 A(m),B(m)

call MPI_INIT(ierr)
call MPI_COMM_SIZE(MPI_COMM_WORLD, nproc, ierr)
call MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr)

PRINT*,"nproc=",nproc,"rank=",rank

do i=1,m
   A(i)=rank*0.1d0
   B(i)=0.d0
   if (rank==0) then
      map(i)=1
   else
      map(i)=0
   endif
   print*, 'node', rank, A(i), map(i)
enddo

call MPI_BARRIER(MPI_COMM_WORLD, ierr)

call SUM(A, B, map, m, MPI_COMM_WORLD, nproc)

call MPI_FINALIZE(ierr)

end program test_MPI_RMA



SUBROUTINE SUM(A, B, map, m, comm, p)
USE MPI

INTEGER m, map(m), comm, p, sizeofreal, win, ierr
REAL*8 A(m), B(m)

CALL MPI_TYPE_EXTENT(MPI_DOUBLE_PRECISION, sizeofreal, ierr)

CALL MPI_WIN_CREATE(B, m*sizeofreal, sizeofreal, MPI_INFO_NULL,  &
                    comm, win, ierr)

CALL MPI_WIN_FENCE(0, win, ierr)
DO i=1,m
  j = map(i)/m
  k = MOD(map(i),m)
  CALL MPI_ACCUMULATE(A(i), 1, MPI_DOUBLE_PRECISION, j, k, 1, MPI_DOUBLE_PRECISION,   &
                      MPI_SUM, win, ierr)
END DO
CALL MPI_WIN_FENCE(0, win, ierr)

CALL MPI_WIN_FREE(win, ierr)
RETURN
END

I compile this code with mpif90 and intel compiler 15.0.0 without problem. However, when I run it, I get this error:

Fatal error in MPI_Win_create: Invalid size argument in RMA call, error stack:
MPI_Win_create(201): MPI_Win_create(base=0x6a98a0, size=80, disp_unit=8, MPI_INFO_NULL, MPI_COMM_WORLD, win=0x7fff89a00384) failed
MPI_Win_create(146): Invalid size argument in RMA call (value is 80)

In others words I need help :)

Could someone tell me what is wrong in these lines of code?

Best regards,

Guillaume

I have installed the Intel compiler using two files

w_fc_c_10.0.027.exe and w_mkl_p_10.0.5.025.exe 

on the ASUS notebook with OS Windows 8.1.

The process of installation has not any problem.

There are two new applications appear in the Start menu

"Fortran Build Environment for applications running on IA-32" and similar for IA-64

When I click on this button a black window with prompt command appears

I print "ifort c:\program.f90" (as usual I did on the old computer with the old compiler)

and compiler answers with the standard lines and 

at the end a new line appear:  "LINK:  fatal error LINK1104: cannot open file "program.exe""

I do not know how to compile and run the program inside the Visual Studio 8.

Also I do not know how to print correctly the command "tasklist | findstr / | program.exe"

after the line "ifort c:\program.f90" or as the new line?

Also I do not know how to reply on the comments. I want to discuss the problem with 

some specialist in details. How to find the possible error and remove it.  

The ideas that problem may be due to the fact that the windows is new and compiler is old

are interesting, but I can not investigate it using many computers with different windows

and different compilers. I want to know the answer on the simple question

Should the compiler  w_fc_c_10.0.027.exe work under the windows 8.1?

If not, I will search another way.

Hi,

Im running into another openmp problem, i cannot get any debug information out of it. I got a an "allocatable array is already allocated" but right before the allocatable the result of allocated() is false, gdb is giving me no stack information. without openmp everything works fine, in gcc with openmp no allocation problem, and this problem is also apparent with 1 thread.

It looks very similar to this one, but cant reproduce in simple case for now. https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux...

The closest simple case i have is this one, multiple way of removing this bug, uncomment the print in the second task or remove the argument target of the subroutine, compiled with ifort -O0 -C -g -traceback -fopenmp  :

module tata
implicit none
type t
double precision,dimension(:),allocatable :: f
end type
end module tata
program foo
use omp_lib
use tata
implicit none
type(t) :: f1
!$omp parallel
!$omp master
call toto(f1)
!$omp end master
!$omp end parallel
contains
subroutine toto(f)
use tata
class(t),target :: f
class(t),allocatable :: f1,f2
class(t),pointer :: temp

temp=>f
!$omp task default(shared) private(f1,f2)
print *,omp_get_thread_num()
allocate(f2,f1)
allocate(f1.f(10),temp.f(10))
f1.f=1d0
print *,f1.f
deallocate(f1,f2)
!$omp end task
!$omp task default(shared) private(f1,f2)
!print *,omp_get_thread_num()!,'here 2'  ! UNCOMMENT TO REMOVE BUG
!print *,allocated(f2),allocated(f1)
allocate(f2,f1)
allocate(f1.f(10))
f1.f=1d0
print *,f1.f
!$omp end task

!$omp taskwait
print *,'tototata'
end subroutine
end program foo

Thanks.

Hello

Our software that that we have been selling for years uses Intel Fortran to compile simulations. The problem I am having is that when customers come in for support, we have to sometimes trouble shoot problems with their Intel/Visual studio installation. We have a utility that helps us determine the customers setup and we would like to add to ability to see which version of Visual Studio is currently integrated with Intel.

So for example, a user might have Intel 12.1 installed and they may have Visual studio 2008 and 2010 installed. We would like our utility to be able to determine which visual studio is currently integrated with Intel.

Does anyone know where this information is stored ?  Registry?

Thanks

George W

www.pscad.com

I am having trouble creating a generic interface.  I have a module that has something like this:

interface do_something
   module procedure do_something_real4
   module procedure do_something_char
end interface do_something

In my source directory, I have separate source files for subroutines do_something_real and do_something_char.  When I compile my library, I get the error #7950: Procedure name in MODULE PROCEDURE statement must be the name of accessible module procedure.

I have tried creating interfaces for these subroutines in the same module source, much like:

interface
   subroutine do_something_real4
   ...
   end subroutine do_something_real4
   subroutine do_something_char
   ...
   end subroutine do_something_char
end interface

but I still get compiler issues.  Any help is greatly appreciated.

Hello,

I am compiling numpy and scipy with the intel compiler and with MKL. I am following this guide: https://software.intel.com/en-us/articles/numpyscipy-with-intel-mkl

I am posting to confirm that the bug that plagued older versions of scipy is still present and that optimizations still prevent scipy from passing all tests. (See, e.g., https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux...)

Numpy passes all self tests. But scipy has the following failures:

======================================================================
FAIL: test_definition (test_basic.TestIfftnSingle)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/nfs/galaxy/unixhome/jmiller/scipy-test/lib/python2.7/site-packages/scipy/fftpack/tests/test_basic.py", line 657, in test_definition
    assert_array_almost_equal_nulp(y,direct_idftn(x),self.maxnlp)
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 1358, in assert_array_almost_equal_nulp
    raise AssertionError(msg)
AssertionError: X and Y are not equal to 3500 ULP

======================================================================
FAIL: test_lorentz (test_odr.TestODR)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/nfs/galaxy/unixhome/jmiller/scipy-test/lib/python2.7/site-packages/scipy/odr/tests/test_odr.py", line 293, in test_lorentz
    3.7798193600109009e+00]),
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 842, in assert_array_almost_equal
    precision=decimal)
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 665, in assert_array_compare
    raise AssertionError(msg)
AssertionError:
Arrays are not almost equal to 6 decimals

(mismatch 100.0%)
 x: array([  1.000000e+03,   1.000000e-01,   3.800000e+00])
 y: array([  1.430678e+03,   1.339051e-01,   3.779819e+00])

======================================================================
FAIL: test_multi (test_odr.TestODR)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/nfs/galaxy/unixhome/jmiller/scipy-test/lib/python2.7/site-packages/scipy/odr/tests/test_odr.py", line 190, in test_multi
    0.5101147161764654, 0.5173902330489161]),
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 842, in assert_array_almost_equal
    precision=decimal)
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 665, in assert_array_compare
    raise AssertionError(msg)
AssertionError:
Arrays are not almost equal to 6 decimals

(mismatch 100.0%)
 x: array([ 4. ,  2. ,  7. ,  0.4,  0.5])
 y: array([ 4.379988,  2.433306,  8.002885,  0.510115,  0.51739 ])

======================================================================
FAIL: test_pearson (test_odr.TestODR)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/nfs/galaxy/unixhome/jmiller/scipy-test/lib/python2.7/site-packages/scipy/odr/tests/test_odr.py", line 236, in test_pearson
    np.array([5.4767400299231674, -0.4796082367610305]),
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 842, in assert_array_almost_equal
    precision=decimal)
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 665, in assert_array_compare
    raise AssertionError(msg)
AssertionError:
Arrays are not almost equal to 6 decimals

(mismatch 100.0%)
 x: array([ 1.,  1.])
 y: array([ 5.47674 , -0.479608])

======================================================================
FAIL: test_qhull.TestDelaunay.test_incremental('pathological-1-chunk-1',)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/nfs/galaxy/unixhome/jmiller/scipy-test/lib/python2.7/site-packages/scipy/spatial/tests/test_qhull.py", line 507, in check
    np.arange(points.shape[0]))
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 739, in assert_array_equal
    verbose=verbose, header='Arrays are not equal')
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 620, in assert_array_compare
    raise AssertionError(msg)
AssertionError:
Arrays are not equal

(shapes (79,), (81,) mismatch)
 x: array([ 0,  2,  3,  4,  5,  6,  7,  8,  9, 11, 12, 13, 14, 15, 16, 17, 18,
       19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35,
       36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52,...
 y: array([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15, 16,
       17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,
       34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50,...

======================================================================
FAIL: test_qhull.TestUtilities.test_degenerate_barycentric_transforms
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/decorators.py", line 146, in skipper_func
    return f(*args, **kwargs)
  File "/nfs/galaxy/unixhome/jmiller/scipy-test/lib/python2.7/site-packages/scipy/spatial/tests/test_qhull.py", line 296, in test_degenerate_barycentric_transforms
    assert_(bad_count < 20, bad_count)
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 53, in assert_
    raise AssertionError(smsg)
AssertionError: 26

======================================================================
FAIL: test_bdtrc (test_basic.TestCephes)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/nfs/galaxy/unixhome/jmiller/scipy-test/lib/python2.7/site-packages/scipy/special/tests/test_basic.py", line 118, in test_bdtrc
    assert_equal(cephes.bdtrc(1,3,0.5),0.5)
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 334, in assert_equal
    raise AssertionError(msg)
AssertionError:
Items are not equal:
 ACTUAL: 0.50000000000000011
 DESIRED: 0.5

======================================================================
FAIL: test_bdtri (test_basic.TestCephes)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/nfs/galaxy/unixhome/jmiller/scipy-test/lib/python2.7/site-packages/scipy/special/tests/test_basic.py", line 115, in test_bdtri
    assert_equal(cephes.bdtri(1,3,0.5),0.5)
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 334, in assert_equal
    raise AssertionError(msg)
AssertionError:
Items are not equal:
 ACTUAL: 0.49999999999999994
 DESIRED: 0.5

======================================================================
FAIL: test_cosm1 (test_basic.TestCephes)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/nfs/galaxy/unixhome/jmiller/scipy-test/lib/python2.7/site-packages/scipy/special/tests/test_basic.py", line 214, in test_cosm1
    assert_equal(cephes.cosm1(0),0.0)
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 326, in assert_equal
    raise AssertionError(msg)
AssertionError:
Items are not equal:
 ACTUAL: -0.0
 DESIRED: 0.0

======================================================================
FAIL: test_data.test_boost(<Data for eval_legendre_ld: legendre_p_ipp-legendre_p>,)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/nfs/galaxy/unixhome/jmiller/scipy-test/lib/python2.7/site-packages/scipy/special/tests/test_data.py", line 481, in _test_factory
    test.check(dtype=dtype)
  File "/nfs/galaxy/unixhome/jmiller/scipy-test/lib/python2.7/site-packages/scipy/special/_testutils.py", line 292, in check
    assert_(False, "\n".join(msg))
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 53, in assert_
    raise AssertionError(smsg)
AssertionError:
Max |adiff|: 7.49401e-16
Max |rdiff|: 7.92476e-14
Bad results (1 out of 140) for the following points (in output 0):
                          18.0             -0.8049191832542419 =>          -0.009106206044325216 !=          -0.009106206044324494  (rdiff          7.924759910919454e-14)

======================================================================
FAIL: test_data.test_boost(<Data for gammaincc: igamma_int_data_ipp-igamma_int_data>,)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/nfs/galaxy/unixhome/jmiller/scipy-test/lib/python2.7/site-packages/scipy/special/tests/test_data.py", line 481, in _test_factory
    test.check(dtype=dtype)
  File "/nfs/galaxy/unixhome/jmiller/scipy-test/lib/python2.7/site-packages/scipy/special/_testutils.py", line 292, in check
    assert_(False, "\n".join(msg))
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 53, in assert_
    raise AssertionError(smsg)
AssertionError:
Max |adiff|: 1.21569e-14
Max |rdiff|: 4.27465e-14
Bad results (1 out of 140) for the following points (in output 0):
                          36.5                            73.0 =>          8.570090512692315e-07 !=          8.570090512692681e-07  (rdiff          4.274654382528594e-14)

======================================================================
FAIL: test_data.test_boost(<Data for gdtrc_: igamma_int_data_ipp-igamma_int_data>,)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/nfs/galaxy/unixhome/jmiller/scipy-test/lib/python2.7/site-packages/scipy/special/tests/test_data.py", line 481, in _test_factory
    test.check(dtype=dtype)
  File "/nfs/galaxy/unixhome/jmiller/scipy-test/lib/python2.7/site-packages/scipy/special/_testutils.py", line 292, in check
    assert_(False, "\n".join(msg))
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 53, in assert_
    raise AssertionError(smsg)
AssertionError:
Max |adiff|: 1.21569e-14
Max |rdiff|: 4.27465e-14
Bad results (1 out of 140) for the following points (in output 0):
                          36.5                            73.0 =>          8.570090512692315e-07 !=          8.570090512692681e-07  (rdiff          4.274654382528594e-14)

======================================================================
FAIL: test_orthogonal.test_js_roots
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/nfs/galaxy/unixhome/jmiller/scipy-test/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal.py", line 371, in test_js_roots
    verify_gauss_quad(roots(68.9, 2.25), evalf(68.9, 2.25), 5, atol=2e-14)
  File "/nfs/galaxy/unixhome/jmiller/scipy-test/lib/python2.7/site-packages/scipy/special/tests/test_orthogonal.py", line 283, in verify_gauss_quad
    assert_allclose(vv, np.eye(N), rtol, atol)
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 1297, in assert_allclose
    verbose=verbose, header=header)
  File "/nfs/galaxy/unixhome/jmiller/numpy-test/lib/python2.7/site-packages/numpy/testing/utils.py", line 665, in assert_array_compare
    raise AssertionError(msg)
AssertionError:
Not equal to tolerance rtol=1e-15, atol=2e-14

(mismatch 100.0%)
 x: array([[  1.000000e+00,  -2.932083e-14,   1.628550e-14,  -5.973276e-15,
         -1.360751e-15],
       [ -2.932083e-14,   1.000000e+00,  -1.985946e-14,   1.119072e-14,...
 y: array([[ 1.,  0.,  0.,  0.,  0.],
       [ 0.,  1.,  0.,  0.,  0.],
       [ 0.,  0.,  1.,  0.,  0.],...

----------------------------------------------------------------------
Ran 17005 tests in 117.640s

FAILED (KNOWNFAIL=97, SKIP=1181, failures=13)
<nose.result.TextTestResult run=17005 errors=0 failures=13>

However if I change "-O3" flag to "-O1" in both in both "numpy/distutils/intelcompiler.py" and "numpy/distutils/fcompiler/intel.py",  both libraries pass all tests.

Scipy is mostly written in fortran. So the issue is with the fortran compiler.

Thanks.

I am experimenting a bit with the DO CONCURRENT construct to see if it would improve the performance of one of our programs. Currently I am using Intel Fortran 15, so perhaps the observations I have made are no longer true.

Anyway, here is the basic code I use:

program doconcurrent
    implicit none

    integer, parameter  :: sz = 10000000
    real, dimension(sz) :: array
    integer             :: i, j, chunk, ibgn, iend, tstart, tstop

    call system_clock( tstart )
    do j = 1,10000
        do concurrent (i = 1:sz)
            array(i) = 10.0 * i * j
        enddo
    enddo
    call system_clock( tstop )

    write(*,*) array(1)
    write(*,*) tstop - tstart

end program doconcurrent

It does not do anything useful except exercise the DO CONCURRENT construct. But:

- Compiling it with and without -Qparallel gives roughly the same runtime, about 25 seconds. So no improvement whatsoever

- I can see that the program runs in 9 threads if I compile it with -Qparallel and with only one thread if I leave out that flag. Also the -Qpar-report flag indicates the loop is parallellized.

- If I insert a write statement to see if the iterations are run in a non-deterministic way, the loop is no longer parallellized.

- My theory was that the runtime is determined by the storing of the new values of the array and that the threads get in each other's ways. So instead of this one loop, I used an outer loop that split the loop in large chunks, something like:

    do j = 1,10000
        do concurrent (chunk = 1:8)
            ibgn = 1 + (chunk-1) * (sz+7)/8
            iend = min( chunk * (sz+7)/8, sz )
            do concurrent (i = ibgn:iend)
                array(i) = 10.0 * i * j
            enddo
        enddo
    enddo

But then only the inner loop is parallellized - if I use an ordinary do-loop for the inner one, nothing gets parallellized.

Any comments? An alternative - in this case - would be to use OpenMP, but the drawback of that is that I have define the "privateness" and "sharedness" of the variables involved myself ;).

Greetings,

I've got a new PC with Windows 10. The IT staff has installed Intel Fortran Compiler 16.0 before I could get my hands on, so that Visual Studio (Community 2015) was installed later and the compiler is not integrated. I have tried following the instructions at http://software.intel.com/en-us/node/159008?wapkw=fortran

cd %VS140COMNTOOLS%
cd ..\..\Intel Fortran\VFPackages
integrate.bat "%VS140COMNTOOLS%" /u
integrate.bat "%VS140COMNTOOLS%"

but I get immediately an error message saying "The system cannot find the path specified". Any idea of how I can get the compiler integrated in VS? Below are detailed information about my VS installation.

Thanks in advance.

Microsoft Visual Studio Community 2015
Version 14.0.23107.0 D14REL
Microsoft .NET Framework
Version 4.6.00079

Installed Version: Community

Visual Basic 2015   00322-20000-00000-AA924
Microsoft Visual Basic 2015

Visual C# 2015   00322-20000-00000-AA924
Microsoft Visual C# 2015

Visual C++ 2015   00322-20000-00000-AA924
Microsoft Visual C++ 2015

Visual F# 2015 RC   00322-20000-00000-AA924
Microsoft Visual F# 2015 RC

Application Insights Tools for Visual Studio Package   1.0
Application Insights Tools for Visual Studio

ASP.NET and Web Tools   14.0.20626.0
ASP.NET and Web Tools

ASP.NET Web Frameworks and Tools 2013   5.2.30624.0
For additional information, visit http://www.asp.net/

Common Azure Tools   1.5
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

GenerateUnitTest   1.0
Generates unit test code for methods in classes under test.

Microsoft Azure Mobile Services Tools   1.4
Microsoft Azure Mobile Services Tools

NuGet Package Manager   3.0.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.

PreEmptive Analytics Visualizer   1.2
Microsoft Visual Studio extension to visualize aggregated summaries from the PreEmptive Analytics product.

Python Tools for Visual Studio   2.2.30718.00
Python Tools for Visual Studio provides IntelliSense, projects, templates, Interactive windows, and other support for Python developers.

Python Tools for Visual Studio - Django Integration   2.2.30718.00
Provides templates and integration for the Django web framework.

Python Tools for Visual Studio - Profiling Support   2.2.30718.00
Profiling support for Python projects.

SQL Server Data Tools   14.0.50616.0
Microsoft SQL Server Data Tools