1) in cl_shift.F line 916 (in Vasp.6.2.0)
Code: Select all
CALL vtutor%error("CORE_WAVE_FKT: solution not found within " // str(NTRIES) // " attempts\n "&
"n=" // str(N) // " l=" // str(L) // " j=" // str(J) // " energy interval: " // str(EMIN) // &
" " // str(EMAX))
On the other hand if the first thing the compiler does is to interpret the newline \n , then you get legal code.
You can make it more robust by inserting an extra string concatenation
Code: Select all
CALL vtutor%error("CORE_WAVE_FKT: solution not found within " // str(NTRIES) // " attempts\n " \\ &
"n=" // str(N) // " l=" // str(L) // " j=" // str(J) // " energy interval: " // str(EMIN) // &
" " // str(EMAX))
Code: Select all
COMPLEX(q),ALLOCATABLE :: P(:),Q(:)
Code: Select all
INTEGER, PARAMETER :: q =SELECTED_REAL_KIND(10)
3) in tet.F line 367 you have this,
Code: Select all
fermiWeights(iband, kit, ispin) = &
fermiWeights(iband, kit, ispin) + (weights(:,1) + weights(:,2))
Code: Select all
kit => kpointIndexTetra(:, itet)
This is very dangerous and breaks the Fortran 2003/2008 standard which says you are not allowed to do that if the elements of the index repeat. You get away with this with
the Intel compilers because, if you look at how they implement this, they take the original statement and rewrite it as a loop - a serial loop not a vector one.
GFORTRAN8 gets this wrong, as does the Fujitsu Arm compiler, as would any compiler that treats the statement as the equivalent of a vector loop.
You should rewrite this as an explicit loop to prevent this. The reason it is particularly dangerous is that it compiles, but gives wrong answers.