<html>Dear Sebastian, dear Stephano<br />This is because when you do a restart, you generally rerun a previous job with exactelly the same positions,<br />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)<br />In some cases, as during dynamic molecular, or atomic relaxations, the atomic positions slighly change.<br />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.<br />This is done by using the 'hidden variable' (not in a namelist) input_drho="rho.in" that must only have the scf charge.<br />This file can be generated by the 'hidden variable' output_drho="rho.out" that does the scf=total-atomic charge<br /><br />However, I'am wondering if this is really what is done in my case.<br />Please Stephano can you confirm that in PW/src/potinit.f90 the lines<br /> IF ( input_drho /= ' ' ) THEN [...]<br /> rho%of_g = rho%of_g + v%of_g<br /> END IF<br />do this trick?<br />and that I do not need to go through the PW/src/update_pot.f90 subroutine:<br />that<br /> "Initial potential from superposition of free atoms"<br /> + "a scf correction to at. rho is read from "rho.in"<br /> + "Starting wfcs from file"<br />is equivalent to what is done during the relaxation:<br /> " NEW-OLD atomic charge density approx. for the potential"<br /><br />Regards,<br /><br />Antoine<br /><br /><br /><br /><br />Le Lundi, Août 17, 2020 16:37 CEST, Sebastian Hütter <sebastian.huetter@ovgu.de> a écrit:<br /> <blockquote type="cite" cite="ce1fcf01-280a-ad66-26e4-e4ad1de8de71@ovgu.de">Am 17.08.2020 um 09:15 schrieb Antoine Jay:<br />> Please note that I start from the wfcs of exactely the same configuration and parameters by using startingwfc='file',<br />> but I do not use startingpot='file'.<br />> Instead I have activated input_drho='rho.in'<br /><br />This may be a novice question, but what actually is the interaction between these? The manual says about "restart_mode",<br />"Overrides startingwfc and startingpot." - but that is clearly not the case (i.e. WARNING: "startingwfc" set to atomic<br />may spoil restart -- and it actually does). Are there any other options that need to be set to their end-of-run values?<br />Maybe some more are missing?<br /><br /><br />Best,<br /><br />Sebastian<br /><br /><br />> This 'rho.in' file is a copy of the file 'rho.out' that have been created by activating the parameter input_drho='rho.out'.<br />> This trick is done because sometimes, the atomic positions have a small variation (but not in this case).<br />><br />> Please note that I already tried this trick on smaller systems plenty of times and I never saw this problem,<br />> 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<br />> bad performed when some PAW data are deallocated:<br />> " Checking if some PAW data can be deallocated...<br />> PAW data deallocated on 4 nodes for type: 1<br />> PAW data deallocated on 32 nodes for type: 2<br />> PAW data deallocated on 35 nodes for type: 3"<br />><br />><br />> Regards,<br />><br />> Antoine Jay<br />> LAAS-CNRS<br />> Toulouse, France<br />><br />><br />><br />><br />><br />><br />><br />><br />> Le Dimanche, Août 16, 2020 23:20 CEST, Stefano de Gironcoli <degironc@sissa.it> a écrit:<br />><br />> 6.d-9 is still too large.. it should be something like 1d-13 to aim at a smaller scf estimate.<br />><br />> are you really starting from the scf charge and wfcs of the same conficuration ?<br />><br />> stefano<br />><br />> On 16/08/20 22:05, Antoine Jay wrote:<br />>> Dear Stephano,<br />>> adding diago_thr_int=1.0D-8 does not change the first conv_thr (exept the average#of iterations)<br />>> 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<br />>> manually the first value would change something if it is already automatically changed...<br />>><br />>> Antoine Jay<br />>> LAAS-CNRS<br />>> Toulouse, France<br />>><br />>> Le Samedi, Août 15, 2020 17:10 CEST, Stefano de Gironcoli <degironc@sissa.it> a écrit:<br />>><br />>> Hi Antoine,<br />>><br />>> 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<br />>> the first diagonalization is pushed tighter (if the wfcs are already very good it should not take too many iterations)<br />>> and the computed dr2 estimate should be more faithful<br />>><br />>> now diag_thr_int is 1.d-2 then updated to 6.e-9 which is consistent with conv_thr ~6.d-5...<br />>><br />>> idk. you can try<br />>><br />>> stefano<br />>><br />>> On 14/08/20 17:09, Antoine Jay wrote:<br />>>> Dear all,<br />>>><br />>>> I'am doing two consecutive scf calculations with exactly the same structure and parameters by calling qe6.5 as a<br />>>> library (attached output files).<br />>>> For the second call, I use the options:<br />>>> startingwfc='file' and input_rho ='rho.in'<br />>>> where these inputs are the converged wfc1.dat and charge-density.dat of the first step.<br />>>> Here I face two problems:<br />>>><br />>>> -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.<br />>>> How is it possible to explain such a decrease? I generally loose only 2 orders of magnitude by doing this.<br />>>><br />>>> -Even with less scf iterations, the cpu time is greater.<br />>>> Is it possible that some extra memory is allocated by qe when input rho and wfc are asked, and not desallocated?<br />>>><br />>>> Note that until now, I have these troubles only when I use paw pseudopotentials on big systems.<br />>>><br />>>> Regards,<br />>>><br />>>> Antoine Jay<br />>>> LAAS-CNRS<br />>>> Toulouse France<br />>>><br />>>><br />>>><br />>>><br />>>><br />>>> _______________________________________________<br />>>> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)<br />>>> users mailing listusers@lists.quantum-espresso.org<br />>>> https://lists.quantum-espresso.org/mailman/listinfo/users<br />>><br />>><br />>><br />>> _______________________________________________<br />>> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)<br />>> users mailing listusers@lists.quantum-espresso.org<br />>> https://lists.quantum-espresso.org/mailman/listinfo/users<br />><br />><br />><br />><br />><br />> _______________________________________________<br />> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)<br />> users mailing list users@lists.quantum-espresso.org<br />> https://lists.quantum-espresso.org/mailman/listinfo/users<br />><br />_______________________________________________<br />Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)<br />users mailing list users@lists.quantum-espresso.org<br />https://lists.quantum-espresso.org/mailman/listinfo/users<br /> </blockquote><br /><br /><br /> </html>