VASP 6.6.0: Internal Compiler Error (ICE) in elphon_accumulators.f90

[hanhsu]

Dear VASP developers and users,

I tried to install VASP 6.6.0 on my HPC system but was unsuccessful. Internal Compiler Error (ICE) in elphon_accumulators.f90 occurred during compilation. I fixed this by reducing the optimization of elphon_accumulators.o, but I am not sure if this is a good idea. Further details are described below. Any advice or guidance are appreciated!!

VASP 6.6.0
Intel Fortran 2022.1.0 (oneAPI 2022.2.0)
Intel mpi 2021.6.0
mkl 2022.1.0
makefile.include.intel

The compilation stopped when the following error message popped up:

catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
compilation aborted for elphon_accumulators.f90 (code 1)
make[2]: *** [makefile:195: elphon_accumulators.o] Error 1
make[2]: Leaving directory '/home/hanhsu/VASP/6.6.0-intel/build/std'
cp: cannot stat 'vasp': No such file or directory
make[1]: *** [makefile:150: all] Error 1
make[1]: Leaving directory '/home/hanhsu/VASP/6.6.0-intel/build/std'
make: *** [makefile:17: std] Error 2

My temporary fix:

I added an additional line to makefile.include.intel, as below:
OBJECTS_O1 += elphon_accumulators.o

After this modification, VASP 6.6.0 was successfully compiled and can run like 6.5.1 installed in the same environment compiled with makefile.include.intel.

One final note:
This problem of 6.6.0 did not occur when I compiled with makefile.include.oneapi. Nevertheless, the performance of oneapi compilation is not as good as the intel compilation, in terms of the convergence in sci calculations: Many more iterations (nearly 50% more) are necessary.

Thank you all for your advice and guidance!!

Best regards,

Han Hsu
Department of Physics
National Central University
Taiwan

[henrique_miranda]

Dear Han Hsu,

Lowering the optimization level for that file in particular should not be very problematic.
Usually for production electron-phonon calculations the bottleneck is the computation of the electron-phonon matrix elements.
Of course this should be seen as a workaround and not as the best solution.

Here you can find a list of validated toolchains that we test in our CI:
https://vasp.at/wiki/Toolchains
These should in principle work correctly, wherever things can change if the target hardware differs.
Using "-xHOST" means that the compiler will try to optimize the compilation for the current machine which might be different from the one your are using.

Hope this helps somehow

[henrique_miranda]

Actually, regarding the second point you make in your question: it is very strange that you get that behaviour with oneapi.
I would recomend that you try running the tests from our testsuite:
https://vasp.at/wiki/Validation_tests
Probably the compilation is more broken than just taking more iterations to converge.