[QE-developers] Bug in non self-consistent calculation
Lorenzo Monacelli
mesonepigreco at gmail.com
Wed Jun 12 12:29:23 CEST 2019
Dear QE developers,
I think I found a bad bug in the non self-consistent calculation of pw.x
While the self consistent calculation ends properly, when running a non
self-consistent calculation results in a crash with the error:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
task # 0
from cdiaghg : error # 40
S matrix not positive definite
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
I checked the cdiaghg subroutine, the S matrix should be the overlap
matrix for the eigenvalue problem Hv = eSv
That, in case of local Norm Conserving pseudo of Hydrogen (my
calculation) I suppose it should be the identity, however, if I enforce
it to be the indentity at the beginning of cdiaghg the code says that it
is not able to converge the scf caclulation either.
I attach the input of the scf calculation (that converges) and the one
of the non-self-consistent calculation (that produces this output).
I also tried to switch the diagonalization method to cg as suggested as
fix, but nothing changes.
I modified also the cdiaghg subroutine, to print the S matrix, that you
find attached (random numbers, seems to be uninitialized).
In both the diagonalization methods if I enforce S to be the identity
matrix the code crashes by saying that it was not able to converge.
The problem seems to arise especially if I request for more bands with
the nbnd flag in system (but sometimes it occurs even if no extra band
is required).
The QE version I used is the current version in the develop branch of
gitlab, but I noticed the same error occurring also with 6.3 and 6.2 in
other cases.
If I ask for exactly the same input file a scf calculation (instead of a
nscf) everything goes fine (same K points, same diagonalization, same
number of extrabands), but indeed, this is not what I would like to do...
I I run the nscf calculation after a scf calculation with exactly the
same input (that works), the nscf calculation fails (this means that the
crash is not caused by a bad starting point for the density).
All these make me really think of a bug in the nscf calculation, rather
than a wrong input.
Best regards,
Lorenzo Monacelli
P.S.
In the attached file the pw_* are the nscf input and output, the scf*
are the scf input and output. I run
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug_report.tar.gz
Type: application/gzip
Size: 50147 bytes
Desc: not available
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20190612/1ea00533/attachment-0001.gz>
More information about the developers
mailing list