[QE-users] Structure optimization using rvv10-scan

Paolo Giannozzi p.giannozzi at gmail.com
Fri Apr 26 22:12:11 CEST 2019


Correcting myself: stress for meta-GGA is implemented, but only in the
spin-unpolarized case

Paolo

On Thu, Apr 25, 2019 at 8:48 AM Paolo Giannozzi <p.giannozzi at gmail.com>
wrote:

> I am not sure that the calculation of stress is implemented with meta-GGA.
>
> SCAN behaves better than other meta-GGA, but still it is numerically
> unstable. See for instance here:  https://gitlab.com/QEF/q-e/issues/32.
> Before trying difficult calculations with SCAN you should verify whether
> you can do simple ones.
>
> Paolo
>
>
> On Sat, Apr 20, 2019 at 3:33 AM Giovani Rech <gio.pi.rech at gmail.com>
> wrote:
>
>> Hello all,
>>
>> Have anyone tried structure optimization using rvv10-scan?
>>
>> I'm trying to optimize a structure (graphite) at 0.0 kbar taking into
>> account van der Waals interactions. For such, I'm using the SCAN+rVV10 by
>> setting "input_dft = 'rvv10-scan'". What I'm getting as a result makes no
>> sense, with unreasonable pressures. Here's a plot of the pressure and
>> volume as a function of optimization step:
>> [image: image.png]
>>
>> When I got this values I was using version 6.4.0 and then tried again
>> with 6.3 and finally with the latest version, 6.4.1, and got the same
>> values (plotted above). Here's the input that I used:
>>
>> &CONTROL
>>>                        title = "graphite_rvv10_vcrelax" ,
>>>                  calculation = 'vc-relax' ,
>>>                 restart_mode = "from_scratch" ,
>>>                       outdir = "./" ,
>>>                   pseudo_dir = "/home/giovani/graphite/pseudo" ,
>>>                       prefix = "gC" ,
>>>                      disk_io = 'default' ,
>>>                    verbosity = 'default' ,
>>>                etot_conv_thr = 1.0D-4 ,
>>>                forc_conv_thr = 1.0D-3 ,
>>>                        nstep = 400 ,
>>>                      tstress = .true. ,
>>>                      tprnfor = .true. ,
>>>  /
>>>  &SYSTEM
>>>                            A = 2.47000e+00 ,
>>>                            C = 8.68000e+00 ,
>>>                          nat = 4,
>>>                         ntyp = 1,
>>>                      ecutwfc = 80 ,
>>>                      ecutrho = 320 ,
>>>                    input_dft = 'rvv10-scan' ,
>>>                        ibrav = 4 ,
>>>  /
>>>  &ELECTRONS
>>>             electron_maxstep = 200,
>>>                     conv_thr = 1.00000e-06 ,
>>>                  startingpot = "atomic" ,
>>>                  startingwfc = 'atomic' ,
>>>                  mixing_mode = "plain" ,
>>>                  mixing_beta = 7.00000e-01 ,
>>>                  mixing_ndim = 8,
>>>              diagonalization = 'david' ,
>>>               diago_thr_init = 1e-4 ,
>>>  /
>>>  &IONS
>>>                 ion_dynamics = 'bfgs' ,
>>>                ion_positions = 'from_input' ,
>>>                      upscale = 100 ,
>>>             trust_radius_max = 1.0D-3 ,
>>>  /
>>>  &CELL
>>>                cell_dynamics = 'bfgs' ,
>>>                        press = 0.0 ,
>>>               press_conv_thr = 0.05 ,
>>>                  cell_factor = 1.2 ,
>>>  /
>>> ATOMIC_SPECIES
>>>     C  12.0107  C.SR.ONCVPSP.PBEsol.stringent.upf
>>> ATOMIC_POSITIONS crystal
>>> C 0.0000000000 0.0000000000 0.000000000
>>> C 1/3          2/3          0.000000000
>>> C 1/3          2/3          1/2
>>> C 2/3          1/3          1/2
>>> K_POINTS automatic
>>>   6 6 2   0 0 0
>>
>>
>> I then tried the same optimization using PBE, by just commenting the
>> 'input_dft' line, and got values of both pressure and volume converging to
>> fairly reasonable values (as plotted below) which makes me think that the
>> problem might be with the rVV10-scan option. Have anyone else had this kind
>> of problem? Any ideas on how this could be fixed?
>> [image: image.png]
>>
>> Also, when testing and comparing the results of both approaches with
>> verbosity=high to investigate which contribution to the pressure was wack,
>> I noticed that almost all the pressure matrices were more or less similar,
>> except for 'exc-cor stress', that was of the same order of magnitude but
>> opposite signs, and 'core-core stress', which was off both in magnitude and
>> in sign. I'm not sure if this is relevant to the problem, but I thought it
>> could help in finding a solution.
>>
>> Thank you for your attention,
>> Best regards,
>> Giovani Rech
>>
>> Universidade de Caxias do Sul,
>> Caxias do Sul - RS, Brazil
>>
>> _______________________________________________
>> Quantum Espresso is supported by MaX (www.max-centre.eu/quantum-espresso)
>> users mailing list users at lists.quantum-espresso.org
>> https://lists.quantum-espresso.org/mailman/listinfo/users
>
>
>
> --
> 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
>
>

-- 
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/users/attachments/20190426/f68ab2ef/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 33073 bytes
Desc: not available
URL: <http://lists.quantum-espresso.org/pipermail/users/attachments/20190426/f68ab2ef/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 71488 bytes
Desc: not available
URL: <http://lists.quantum-espresso.org/pipermail/users/attachments/20190426/f68ab2ef/attachment-0001.png>


More information about the users mailing list