[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