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

[Sebastian Hütter]

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
>