Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29237 Discussions

Intel series 16 FC lead to segmentation faults and inaccurate numerics in VASP 5.4 (intel 15 series works fine)

Baris_M_
Beginner
1,003 Views

I would like to mention that VASP 5.4.1 compiled using intel compilers lead to segmentation faults (i.e. with electric fields), and/or inaccurate numerics (i.e. with GW). Reducing the optimization level from the default -o2 to -o1, even -o0 does not help.

The same VASP scenarios, using intel 15 compilers, run without any segmentation faults, or numerical drifts.

Is there a way to replicate intel 15 like behaviour in 16?

 

0 Kudos
4 Replies
Steven_L_Intel1
Employee
1,003 Views

First guess - fix the errors in the code. Without an explicit test case, that's the best I can suggest.

0 Kudos
Baris_M_
Beginner
1,003 Views

Dear Mr. Lionel,

VASP is quite a diffuse software in theoretical condensed matter society. It is used in many HPC centers as a benchmark, and one of the main reasons why the research groups push the universities to pay for Intel compilers (it is a tricky piece of software to compile correctly, and many other compilers fail)  

I am not a developer of VASP, and I am not interested in bugfixing for a commercialized software.

The official response from VASP is "don't use intel compilers v16". I interpret this as the group responsible for development is not interested in modfying their code due to new intel compilers. which is a problem because I am limited to 16 series for this case.

I am attaching you the INCAR, if you are interested in testing yourself, but it is nothing out of the ordinary. 

So my question remains: Can I make Intel 16 series compiler behave like intel 15 series compiler? (so that I can have a working binary) 

Sincerely,

Baris

SYSTEM = test

# run from scratch
ISTART =   0
ICHARG =   2
ISPIN = 1
#Things to do
#LWAVE=.TRUE.
#LVHAR=.TRUE.
#LORBIT=11

#HSE06
LHFCALC  = .TRUE.
HFSCREEN = 0.2
AEXX=0.25
AGGAX=0.75
AGGAC=1.0
ALDAC=1.0

# no. of bands

# to produce tetrahedron
ISMEAR = 0
#SIGMA = 0.001

# Electric Field
EFIELD_PEAD = 0.033333333 0.0 0.0


# Electronic relaxation

ALGO = N
LREAL=A
PREC=Normal
PRECFOCK=FAST
ENCUT = 600
ENAUG = 2400
#LPLANE = .TRUE.
EDIFF =   1E-05  #    stopping criterion

# Ionic relaxations
NSW = 100
IBRION = 2         CG optimization
POTIM =0.2
ISIF = 2           change the ions and cell shape (2: only ions)
EDIFFG = -1E-04    stopping criterium for relaxation


# Other parameters
NWRITE = 2          most of the important information is written

0 Kudos
Steven_L_Intel1
Employee
1,003 Views

Sorry, but your question is not answerable unless we know what in particular triggers the error. Each release of the compiler changes optimization features and fixes bugs, which means that the executable code will almost certainly vary somewhat when recompiled in the new release.

If disabling optimizations does not help, the most likely cause is a coding error in the application. perhaps relying on an uninitialized variable. Since VASP is commercial, licensed software and we don't have a copy, as far as I know, there's nothing further we can do here. We'd be happy to work with the VASP developers through Intel Premier Support if they are interested in resolving the problem.

0 Kudos
Steven_L_Intel1
Employee
1,003 Views

One of our other support engineers does have access to VASP, but will need more details as to what goes wrong. It may be some weeks before he can look at this in detail.

0 Kudos
Reply