My Community

W recently compiled vasp 5.4.4 with the same source code on two different clusters (expanse-sdsc and bridges2-psc). However, expanse doesn't update the OSIZCAR until the end of calculation while bridges2 does. Updating of OSIZCAR doesn't affect our calculation but I wonder if there is a deeper issue with writing other OUTPUT files which might get discovered in future.
Both of them use slurm scheduler. Expanse uses gcc/9.2.0 and opempi complier while Bridges2 use Intel compiler and Intel MPI. Their individual makefile.include were supplied to us from the people managing the clusters, and that is the only thing which separates the build of vasp so suspected problem might be there. However, with the builds I created, I could not find any difference in parts of the source code(the fortran files) where it writes OSZICAR.

I found a post remotely resemblinghttps://triqs.github.io/dft_tools/lates ... _vasp.html to what I am facing (text below in italic excrept from the web) from web but after implementing the solution as it gave me an error(The following floating-point exceptions are signaling: IEEE_INVALID_FLAG)
Furthermore, there is a bug in fileio.F around line 1710 where VASP tries to print “reading the density matrix from Gamma”. This should be done only by the master node, and VASP gets stuck sometimes. Adding a

IF (IO%IU0>=0) THEN
...
ENDIF
statement resolves this issue. A similar problem occurs, when VASP writes the OSZICAR file and a buffer is stuck. Adding a flush to the buffer in electron.F around line 580 after

CALL STOP_TIMING("G",IO%IU6,"DOS")
flush(17)
print *, ' '
resolves this issue. Otherwise the OSZICAR file is not written properly.

Any help would be appreciated in diagnosing the issue would be appreciated as we routinely use OSZICAR to look at scf convergence issue and the possibility of developing this into some other issue. Let me know if any other specific information might be helpful.

Thanks
Naveen Agrawal
nua155@psu.edu

Thank you for bringing up this issue. I have never seen any such behaviour before, although I compiled with many different compilers. So it is definitely not easy to reproduce this problem.

Have you tried using the suggestion from the post with flush?

I talked to colleagues and indeed it can happen that the buffers are delayed and OSZICAR is written on the end. This is highly setup and machine dependent. The choice is with respect to high performance machines, where flushing is significantly affecting the performance. Since high performance centers are an important user base, this compromise was made.

Nevertheless the output is written at the end of the calculation.
The suggested fix with the "FLUSH" works, but inside VASP there is a routine called "WFORCE" which is a proper wrapper for flush statements and we would advice to rather use that over "FLUSH" if someone wants to tweak VASP himself.

It turns out the flush solution actually works. The mistake probably was to directly change the source code after the compilation, I did it pre-compilation and then recompiled and it worked perfectly. I haven't tried using WFORCE yet but might give it a shot too. Thanks for your suggestion and sorry for the late follow-up.

Naveen