[QE-developers] TR: Bugs in cp.x from QE 7.2 affecting stresses calculated with US pseudos and CG

RABONE Jeremy jeremy.rabone at get.omp.eu
Mon Oct 14 12:59:12 CEST 2024


Hello,


  The input you sent does not produce the error (the pseudos aren't ultrasoft, at least in the internal sense of cp that would otherwise demand that nr1b, nr2b and nr3b are set). Attached are the inputs that produce the error, although the exact error is machine dependent the matrix of  "constraints contribution to stress" is incorrect. I have just got:


    -0.01479      0.00001      0.00000
      0.00001     -0.01406      0.00000
     -0.01319      0.00000      0.00000


      6.21877     -0.00527      0.00000
     -0.00527      5.90848      0.00000
      5.54368      0.00000      0.00000

but this contribution should of course be diagonal.


________________________________
De : Paolo Giannozzi <paolo.giannozzi at uniud.it>
Envoyé : lundi 14 octobre 2024 11:53
À : RABONE Jeremy
Cc : General discussion list for Quantum ESPRESSO developers
Objet : Re: [QE-developers] TR: Bugs in cp.x from QE 7.2 affecting stresses calculated with US pseudos and CG

On 10/14/24 10:57, RABONE Jeremy wrote:

> Any calculation I have run on the 3 clusters I use produced the error -
> a water molecule in vacuum using US pseudos and cg gives impossible
> stresses from the first step.

there is a recently added test in test-suite/cp_h2o/h2o-mt-blyp-cg.in. I
do not see any difference in the output with and without the change. Is
the output of that test correct, wrong, and if so, what is the correct
output?

Paolo

>
>
>    iii) Yes, the stress is correct after the changes.
>
>
> i) The thing is there shouldn't be a problem, but it seems that the
> declared array sizes in cg_sub cause the compiler to rearrange the
> arrays anyway. You are correct, changing cg_sub to:
>
>
>       CHARACTER(LEN=80) :: uname
>        CHARACTER(LEN=6), EXTERNAL :: int_to_char
>        integer :: nfi, nlam
>        logical :: tfirst, tlast
>        complex(dp) :: eigr(:, :)
>        real(dp) :: bec(:, :)
>        real(dp) :: becdr(:, :, :)
>        integer :: irb(:, :)
>        complex(dp) :: eigrb(:, :)
>        real(dp) :: rhor(:, :)
>        real(dp) :: vpot(:, :)
>        complex(dp) :: rhog(:, :)
>        real(dp) :: rhos(:, :)
>        real(dp) :: rhoc(:)
>        complex(dp) :: ei1(:, :)
>        complex(dp) :: ei2(:, :)
>        complex(dp) :: ei3(:, :)
>        complex(dp) :: sfac(:, :)
>        real(dp) :: fion(:, :)
>        real(dp) :: ema0bg(:)
>        real(dp) :: lambdap(:, :, :)
>        real(dp) :: lambda(:, :, :)
>        complex(dp) :: c0(:, :)
>        complex(dp) :: c0_d(:, :)
>        complex(dp) :: cm(:, :)
>        complex(dp) :: phi(:, :)
>        complex(dp) :: phi_tmp(ngw, nbspx)
>        real(dp) :: dbec(:, :, :, :)
>
> solved this part of the problem on one of the clusters I use. However,
> the sysadmins of the other 2 clusters I use don't want to make arbitrary
> changes without an official patch since there are other users of QE and,
> as the rest of the world is so apt to point out, I apparently don't have
> a clue. The introduction of random values is probably also solved by
> this since they only get mixed into the matrix by the rearrangement, but
> zeroing the array after allocation would have stopped the other half of
> WTF arising in the stress matrix.
>
>
> ii) It probably isn't that important, but moving the call "if ( tstress
> ) CALL nlfh( stress, bec_bgrp, dbec, lambda, idesc )" to just after dbec
> is  calculated "if ( tstress ) CALL caldbec_bgrp( eigr, cm_bgrp, dbec,
> idesc )" about 15 lines below seems like a good idea if only to avoid
> random crap in the stress matrix on the first pass.
>
>
> Kind regards,
>
>
> Jeremy
>
>
>
> ------------------------------------------------------------------------
> *De :* Paolo Giannozzi <paolo.giannozzi at uniud.it>
> *Envoyé :* samedi 12 octobre 2024 10:53
> *À :* RABONE Jeremy
> *Cc :* General discussion list for Quantum ESPRESSO developers
> *Objet :* Re: [QE-developers] TR: Bugs in cp.x from QE 7.2 affecting
> stresses calculated with US pseudos and CG
> Thank you for reporting.
>
> i) nkb and nhsa are actually the same variable. Not sure what "nrcx" is,
> but in any case, the called routine is in a module so one can just write
>      real(dp) :: dbec(:,:,:,:)
> and stop worrying about the correctness of the
>
> ii) almost no code is executed for CG calculations (tcg=.true.) in
> from_scra.f90; for tcg=.false., the needed call is present, it seems to
> me. What did you change exactly?
>
> iii) Is stress working after your changes? can you provide a simple example?
>
> Paolo
>
> On 04/10/2024 09:41, RABONE Jeremy wrote:
>>
>> ------------------------------------------------------------------------
>> *De :* RABONE Jeremy
>> *Envoyé :* jeudi 3 octobre 2024 13:04
>> *À :* users at lists.quantum-espresso.org
>> *Objet :* Bugs in cp.x from QE 7.2 affecting stresses calculated with US
>> pseudos and CG
>>
>> Hello,
>>
>>    I have been getting some weird stress values in MD calculations using
>> cp.x from QE 7.2 with ultrasoft pseudopotentials and after some
>> rummaging I have found a couple of bugs:
>>
>>      i) The dbec array gets inadvertantly altered through the call to
>> cg_sub.f90 where is is assigned a different size "real(dp) :: dbec(nkb,
>> nbspx, 3, 3)" than initially allocated in mainvar.f90
>> "ALLOCATE( dbec( nhsa, 2*nrcx, 3, 3 ), STAT=ierr )". The upshot of this
>> is that the values of dbec get jumbled and the resulting stress tensor
>> is messed up (and physically nonsensical). Also, since dbec is not
>> zeroed and the initially allocated size does not seem to correspond to
>> the used size, this also has the effect of introducing random values
>> into the stress tensor, although zeroing dbec after the allocation in
>> mainvar.f90 fixes this.
>>
>>     ii) In fromscra.f90 the constraints contribution to the stress is
>> calculated "if ( tstress ) CALL nlfh( stress, bec_bgrp, dbec, lambda,
>> idesc )" before the dbec array has been calculated "if ( tstress ) CALL
>> caldbec_bgrp( eigr, cm_bgrp, dbec, idesc )".
>>
>>
>> Kind regards,
>>
>> Jeremy
>>
>>
>> ________________________________________________
>> The Quantum ESPRESSO community stands by the Ukrainian people
>>   and expresses its concerns about the devastating effects that
>> the Russian military offensive has on their country and on the
>> free and peaceful scientific, cultural, and economic cooperation
>> amongst peoples.
>> _______________________________________________
>> developers mailing list
>> developers at lists.quantum-espresso.org
>> https://lists.quantum-espresso.org/mailman/listinfo/developers
> <https://lists.quantum-espresso.org/mailman/listinfo/developers>
>
> --
> Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
> Univ. Udine, via delle Scienze 206, 33100 Udine Italy, +39-0432-558216
>

--
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 206, 33100 Udine Italy, +39-0432-558216
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20241014/e4b6d300/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h_pbe_v1.4.uspp.F.UPF
Type: application/octet-stream
Size: 112487 bytes
Desc: h_pbe_v1.4.uspp.F.UPF
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20241014/e4b6d300/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: o_pbe_v1.2.uspp.F.UPF
Type: application/octet-stream
Size: 376733 bytes
Desc: o_pbe_v1.2.uspp.F.UPF
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20241014/e4b6d300/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mol_H2O.in
Type: application/octet-stream
Size: 1604 bytes
Desc: Mol_H2O.in
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20241014/e4b6d300/attachment-0005.obj>


More information about the developers mailing list