[QE-developers] Bug in non self-consistent calculation

[Paolo Giannozzi]

It seems to disappear if one sets "diago_david_ndim=2". This option sets
the maximum size of wavefunctions + correction vectors packet to 2 x number
of wavefunctions. I suspect that this should be the default instead of the
current one (4) but I haven't enough tests to make a definite statement

Paolo

On Wed, Jun 12, 2019 at 12:30 PM Lorenzo Monacelli <mesonepigreco at gmail.com>
wrote:

> 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
>
>
> _______________________________________________
> developers mailing list
> developers at lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/developers
>


-- 
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20190621/c30678c2/attachment.html>