Intel compiler on ARCHER

Author: Adrian Jackson
Posted: 26 Apr 2016 | 13:07

Bug

I had a recent query from some users with a problem with the default version of the Intel Fortran compiler on ARCHER (v15.0.2.164).  It was a nice query to get because the users had done all the work already; they'd identified the problem, found a test code that demonstrated it, and told me what the solution would be for them.

Fortunately, the solution was easy, this bug has been fixed in a newer version of the compiler (16.0.2.181), which is installed and available on ARCHER, but just isn't the default (we tend to keep the default version slightly behind the latest release but as new as possible), so they simply have to swap the compiler modules then their code can compile and run correctly.

For those interested, the bug is associated with the vectorisation undertaken by ifort (the Intel Fortran compiler) when compiler optimisation is enabled (as it is by default with the Intel compiler). It's actually identified and discussed on the Intel forum, and the code that can reproduce it is below (this code is taken from the forum post):

program bug_test
implicit none

    integer :: nmtdata=240,nmtfreq=60,i,j,k

    integer :: imtfreqnum(240),indexmtfreq(60)

    data imtfreqnum/                                                   &
      1, 1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3, 4, 4, 4, 4, 5, 5, 5, 5,      &
      6, 6, 6, 6, 7, 7, 7, 7, 8, 8, 8, 8, 9, 9, 9, 9,10,10,10,10,      &
     11,11,11,11,12,12,12,12,13,13,13,13,14,14,14,14,15,15,15,15,      &
     16,16,16,16,17,17,17,17,18,18,18,18,19,19,19,19,20,20,20,20,      &
     21,21,21,21,22,22,22,22,23,23,23,23,24,24,24,24,25,25,25,25,      &
     26,26,26,26,27,27,27,27,28,28,28,28,29,29,29,29,30,30,30,30,      &
     31,31,31,31,32,32,32,32,33,33,33,33,34,34,34,34,35,35,35,35,      &
     36,36,36,36,37,37,37,37,38,38,38,38,39,39,39,39,40,40,40,40,      &
     41,41,41,41,42,42,42,42,43,43,43,43,44,44,44,44,45,45,45,45,      &
     46,46,46,46,47,47,47,47,48,48,48,48,49,49,49,49,50,50,50,50,      &
     51,51,51,51,52,52,52,52,53,53,53,53,54,54,54,54,55,55,55,55,      &
     56,56,56,56,57,57,57,57,58,58,58,58,59,59,59,59,60,60,60,60/
!
    data indexmtfreq/                                                  &
      1, 2, 3, 5, 6, 7, 9,10,11,13,14,15,17,18,19,21,22,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,53,54,55,56,57,58,59,60,61,62,63,64,65,66/
!
    do i=1,nMTdata
        k=iMTFreqNum(i)
        do j=1,nMTFreq
            if(k==j)then
                iMTFreqNum(i)=indexMTfreq(j)
            endif
        enddo
    enddo

    write(*,'(A,/,(20i5))')'iMTFreqNum  ',iMTFreqNum(1:nMTData)

end program bug_test

It's not likely that many codes will run into this bug, but if you have nested loops where you have conditional statements (ie if) dependent on parameters from the outer loop, or your inner loops are not necessarily contigious, it could be that your code would see this problem.

It's another reminder that if you have problems with a code not performing as you'd expect, it's always sensible to try different compilers, or different versions of the same compiler, to see if it is a problem with the compiler. Indeed, it's probably always sensible, when developing code, to compare results with different versions of compilers or different compilers, to check your code is stable and performing as expected. Fortunately we have 3 different compilers on ARCHER (GNU, Intel, and Cray) so it's generally straightforward to do this.

Thanks to Dr Nicolas Niasse and Prof. Jeremy Chittenden from Imperial (and part of the Plasma Physics Consortium on ARCHER) for the query!

You can also read this post on our Medium account.

Author

Adrian Jackson, EPCC
You can often find Adrian on Twitter.