My Community

I am getting out of bounds errors detected at runtime in fft3dfurth. Patched up to 14032016, compiling with gfortran 5.3.0 with -fbounds-check and -O0 everywhere gives:

vasp.5.4.1 05Feb16 (build Apr 12 2016 16:11:45) complex
POSCAR found type information on POSCAR Ti O
POSCAR found : 2 types and 6 ions
LDA part: xc-table for Pade appr. of Perdew
POSCAR, INCAR and KPOINTS ok, starting setup
WARNING: small aliasing (wrap around) errors must be expected
FFT: planning ...
WAVECAR not read
At line 393 of file fft3dfurth.f90
Fortran runtime error: Index '57' of dimension 1 of array 'c' above upper bound of 1

Clearly, I'm not using FFTW. Is this a known bug? It seems like something someone should have noticed by now. I got the same result when only patched to 27082015.



My test job:

INCAR:
SYSTEM = TiO2
ISTART = 0
EDIFF = 1E-5
NELMIN = 6
LWAVE=.TRUE.
LCHARG=.FALSE.
RWIGS = 1.2 1.0
ENCUT = 500.00 eV
ISMEAR = -5;

KPOINTS:
Automatic generation
0
MP
8 8 8
0 0 0

POSCAR:
TiO2 rutile
1.00000000000000
4.6657111379066052 -0.0000000000000000 0.0000000000000000
0.0000000000000000 4.6657111379066052 0.0000000000000000
0.0000000000000000 0.0000000000000000 3.0512741952786513
Ti O
2 4
Direct
-0.0000000000000000 0.0000000000000000 0.0000000000000000
0.5000000000000000 0.5000000000000000 0.5000000000000000
0.3052252303203911 0.3052252303203911 -0.0000000000000000
0.6947747475664178 0.6947747475664178 0.0000000000000000
0.1947747674682863 0.8052252413769901 0.5000000000000000
0.8052252413769901 0.1947747674682863 0.5000000000000000

POTCAR is PAW_PBE, Ti_sv and O.

Is vasp installed with correct CACHE_SIZE?
http://cms.mpi.univie.ac.at/vasp/guide/node39.html

CACHE_SIZE was 4000. Changing it to 16000 in makefile.include (256kB cache) and recompiling makes no difference, still out of bounds crash.

(I would have been surprised if a tuning parameter crashed the code, rather than making it run sub-optimally.)

I've been testing on another machine (still under linux, E5 cpus). Compiling with gfortran 4.7.3 using -O0 -fbounds-check halts at the same point. But ifort 14.0.3 using -O0 -check bounds does NOT detect any such error. (But using -check pointers results in "forrtl: severe (408): fort: (7): Attempt to use pointer KINEDEN when it is not associated with a target".) Running the ifort build under the valgrind memchecker returns a lot of errors, but none seem to be obviously associated with fft code.

Can anyone else confirm what I am seeing?