[QE-users] ?==?utf-8?q? ?==?utf-8?q? ?= Same run not accelerated when starting from converged rho and wf

Mon Aug 17 18:59:59 CEST 2020

Dear Sebastian, dear Stephano
This is because when you do a restart, you generally rerun a previous job with exactelly the same positions,
it is then relevant to begin the wfcs (starting wfc=file that read wfc.#k) and total potential (startingpot='file' that read charg-density.dat)
In some cases, as during dynamic molecular, or atomic relaxations, the atomic positions slighly change.
In these cases, the potential can be extrapolated (see PW/src/update_pot.f90) by using the previous scf charge but the new atomic charge obtain instantaneously by applying the pseudo on the new atomic positions.
This is done by using the 'hidden variable' (not in a namelist) input_drho="rho.in" that must only have the scf charge.
This file can be generated by the 'hidden variable' output_drho="rho.out" that does the scf=total-atomic charge

However, I'am wondering if this is really what is done in my case.
Please Stephano can you confirm that in PW/src/potinit.f90 the lines
     IF ( input_drho /= ' ' ) THEN [...]
        rho%of_g = rho%of_g + v%of_g
    END IF
do this trick?
and that I do not need to go through the PW/src/update_pot.f90 subroutine:
that
     "Initial potential from superposition of free atoms"
     + "a scf correction to at. rho is read from "rho.in"
     + "Starting wfcs from file"
is equivalent to what is done during the relaxation:
    " NEW-OLD atomic charge density approx. for the potential"

Regards,

Antoine

Le Lundi, Août 17, 2020 16:37 CEST, Sebastian Hütter <sebastian.huetter at ovgu.de> a écrit:
 Am 17.08.2020 um 09:15 schrieb Antoine Jay:
> Please note that I start from the wfcs of exactely the same configuration and parameters by using startingwfc='file',
> but I do not use startingpot='file'.
> Instead I have activated input_drho='rho.in'

This may be a novice question, but what actually is the interaction between these? The manual says about "restart_mode",
"Overrides startingwfc and startingpot." - but that is clearly not the case (i.e. WARNING: "startingwfc" set to atomic
may spoil restart -- and it actually does). Are there any other options that need to be set to their end-of-run values?
Maybe some more are missing?

Best,

Sebastian

> This 'rho.in' file is a copy of the file 'rho.out' that have been created by activating the parameter input_drho='rho.out'.
> This trick is done because sometimes, the atomic positions have a small variation (but not in this case).
>
> Please note that I already tried this trick on smaller systems plenty of times and I never saw this problem,
> this is why I wonder if it is a problem of the system size or of the PAW pseudo for wich for example the becsum couldbe
> bad performed when some PAW data are deallocated:
> " Checking if some PAW data can be deallocated...
>        PAW data deallocated on    4 nodes for type:  1
>        PAW data deallocated on   32 nodes for type:  2
>        PAW data deallocated on   35 nodes for type:  3"
>
>
> Regards,
>
> Antoine Jay
> LAAS-CNRS
> Toulouse, France
>
>
>
>
>
>
>
>
> Le Dimanche, Août 16, 2020 23:20 CEST, Stefano de Gironcoli <degironc at sissa.it> a écrit:
>
> 6.d-9 is still too large.. it should be something like 1d-13 to aim at a smaller scf estimate.
>
> are you really starting from the scf charge and wfcs of the same conficuration ?
>
> stefano
>
> On 16/08/20 22:05, Antoine Jay wrote:
>> Dear Stephano,
>> adding diago_thr_int=1.0D-8 does not change the first conv_thr (exept the average#of iterations)
>> As you said, the first value 1.0D-2 is detected to  be too large and is updated to 6.0D-9 so I don't see why changing
>> manually the first value would change something if it is already automatically changed...
>>
>> Antoine Jay
>> LAAS-CNRS
>> Toulouse, France
>>
>> Le Samedi, Août 15, 2020 17:10 CEST, Stefano de Gironcoli <degironc at sissa.it> a écrit:
>>
>> Hi Antoine,
>>
>>   don't know exactly why you get this result but one thing you can try is to set diag_thr_init ~ conv_thr/Nelec/10 so
>> the first diagonalization is pushed tighter (if the wfcs are already very good it should not take too many iterations)
>> and the computed dr2 estimate should be more faithful
>>
>>   now diag_thr_int is 1.d-2 then updated to 6.e-9 which is consistent with conv_thr ~6.d-5...
>>
>>   idk. you can try
>>
>>   stefano
>>
>> On 14/08/20 17:09, Antoine Jay wrote:
>>> Dear all,
>>>
>>> I'am doing two consecutive scf calculations with exactly the same structure and parameters by calling qe6.5 as a
>>> library (attached output files).
>>> For the second call, I use the options:
>>> startingwfc='file' and input_rho ='rho.in'
>>> where these inputs are the converged wfc1.dat and charge-density.dat of the first step.
>>> Here I face two problems:
>>>
>>> -I expected that the initial scf accuracy is 10^-11 as obtained at the end of the first step, but it is only 10^-4.
>>> How is it possible to explain such a decrease? I generally loose only 2 orders of magnitude by doing this.
>>>
>>> -Even with less scf iterations, the cpu time is greater.
>>> Is it possible that some extra memory is allocated by qe when input rho and wfc are asked, and not desallocated?
>>>
>>> Note that until now, I have these troubles only when I use paw pseudopotentials on big systems.
>>>
>>> Regards,
>>>
>>> Antoine Jay
>>> LAAS-CNRS
>>> Toulouse France
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
>>> users mailing listusers at lists.quantum-espresso.org
>>> https://lists.quantum-espresso.org/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
>> users mailing listusers at lists.quantum-espresso.org
>> https://lists.quantum-espresso.org/mailman/listinfo/users
>
>
>
>
>
> _______________________________________________
> 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
>
_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/users/attachments/20200817/45cf2863/attachment.html>