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 <[email protected]>
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 <[email protected]> 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 [email protected]
https://lists.quantum-espresso.org/mailman/listinfo/users
_______________________________________________
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing [email protected]
https://lists.quantum-espresso.org/mailman/listinfo/users
_______________________________________________
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list [email protected]
https://lists.quantum-espresso.org/mailman/listinfo/users
_______________________________________________
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list [email protected]
https://lists.quantum-espresso.org/mailman/listinfo/users
