VASP hangs when LAECHG=true

[placeb0]

Hello,

I am running VASP.4.6.35. on the CSM Ra server (8 procs per node). My system is a converged 1x1 TiO2(110) slab with 5 bulk trilayers and 12 Angstroms vacuum. Kpoints are on a 5x10x1 grid. PAW PBE's are utilized. Single node SCF calculations run fine, but when I try to use 2 nodes (16 procs) VASP hangs. I've tried NPAR=1 and NPAR=2 but no joy. Here is the end of the OUTCAR:
...............................................
k-point 16 : 0.00000.50000.0000 plane waves: 14114
k-point 17 : 0.20000.50000.0000 plane waves: 14118
k-point 18 : 0.40000.50000.0000 plane waves: 14142

maximum and minimum number of plane-waves per node : 621 565

maximum number of plane-waves: 14272
maximal index in each direction:
IXMAX= 12 IYMAX= 5 IZMAX= 51
IXMIN=-12 IYMIN= -5 IZMIN=-51

WARNING: wrap around error must be expected set NGX to 50
NGY is ok and might be reduce to 22
NGZ is ok and might be reduce to 206

parallel 3dFFT wavefunction:
minimum data exchange during FFTs selected (reduces bandwidth)
parallel 3dFFT charge:
minimum data exchange during FFTs selected (reduces bandwidth)

For storing wavefunctions 392.20 MBYTES are necessary
For predicting wavefunctions 46.82 MBYTES are necessary
Broyden mixing: mesh for mixing (old mesh)
NGX = 25 NGY = 11 NGZ =103
(NGX = 96 NGY = 48 NGZ =420)
gives a total of 28325 points
............................................


After the walltime expires, the first two lines in the stderr file read:
............................................
forrtl: File exists
forrtl: severe (10): cannot overwrite existing file, unit 99, file /lustre/scratch/wmaddox/Rutile/1x1_dualsurface/GGAU_c28.5_U0J0/2nodes/AECCAR1
............................................

I've browsed the forums and found a similar post from someone using NEB but there was no resolution.
I am probably missing something very obvious here. Any suggestions would be welcome.

Thanks,

[graeme]

I don't see how this could be related to the NEB.

Perhaps try following the suggestion and delete the AECCAR* files if they exist.

You can try debugging this by setting LAECHG=.FALSE. Perhaps both machines are trying to write to the same charge density file.

Anyway, it is very unlikely that this problem is related to our code.