[Pw_forum] Error in routine scale_h (1)
as your cell shrinks the energy cutoff corresponding to your set of plane wave increases and it this exceeds a the maximum values in the precalculated psedopotential table (some 20% higher than the specified ecut by default if i remember correctly) the code stops. You can increase this limit with the cell_factor variable. However if this keeps happening it means that your cell was way too large ! stefano On 09/23/2012 11:42 PM, Alexey Akimov wrote: > my unit cell is not oscillating, but rather shrinking. shouldn't the basis > size (number of plane waves) be bigger for larger cell, so the bigger cell > would determine the maximal amount of memory for simulation even if the cell > contracts? > > - Original Message - > From: "Paolo Giannozzi" > To: "PWSCF Forum" > Sent: Sunday, September 23, 2012 1:19:05 PM > Subject: Re: [Pw_forum] Error in routine scale_h (1) > > > On Sep 23, 2012, at 16:43 , Alexey Akimov wrote: > >> If i restart the calculations with the latest (most optimal) >> configuration of the system and the same amount of memory >> allocated, the further optimization can proceed some more time >> (also ~50 - 70 steps) before next crash. > this should not happen, unless your optimization procedure keeps > oscillating between large and > small volumes. > > P. > --- > Paolo Giannozzi, Dept of Chemistry&Physics&Environment, > Univ. Udine, via delle Scienze 208, 33100 Udine, Italy > Phone +39-0432-558216, fax +39-0432-558222 > > > > > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum >
[Pw_forum] 'hse' in pw run can not converges
On Sep 21, 2012, at 19:43 , Bramha Pandey wrote: > Can please give a clue to obtained the Al.pz-bhs.UPF (Al LDA with > bhs funtionals essentially NormConversing) pseudopotential as i am > very poor to generate it myself and not obtained it in pslibrary. can you please write understandable sentences? Al.pz-bhs.UPF = Aluminium, Perdew-Zunger functional (LDA), Bachelet-Hamann-Schlueter: Phys.Rev. B 26, 4199 (1982) P. --- Paolo Giannozzi, Dept of Chemistry&Physics&Environment, Univ. Udine, via delle Scienze 208, 33100 Udine, Italy Phone +39-0432-558216, fax +39-0432-558222
[Pw_forum] Error in routine scale_h (1)
On Sep 23, 2012, at 16:43 , Alexey Akimov wrote: > If i restart the calculations with the latest (most optimal) > configuration of the system and the same amount of memory > allocated, the further optimization can proceed some more time > (also ~50 - 70 steps) before next crash. this should not happen, unless your optimization procedure keeps oscillating between large and small volumes. P. --- Paolo Giannozzi, Dept of Chemistry&Physics&Environment, Univ. Udine, via delle Scienze 208, 33100 Udine, Italy Phone +39-0432-558216, fax +39-0432-558222
[Pw_forum] Error in routine scale_h (1)
I see. Thank you for the explanation! Alexey - Original Message - From: "Stefano de Gironcoli" To: "pw forum" Sent: Sunday, September 23, 2012 2:58:47 PM Subject: Re: [Pw_forum] Error in routine scale_h (1) as your cell shrinks the energy cutoff corresponding to your set of plane wave increases and it this exceeds a the maximum values in the precalculated psedopotential table (some 20% higher than the specified ecut by default if i remember correctly) the code stops. You can increase this limit with the cell_factor variable. However if this keeps happening it means that your cell was way too large ! stefano On 09/23/2012 11:42 PM, Alexey Akimov wrote: > my unit cell is not oscillating, but rather shrinking. shouldn't the basis > size (number of plane waves) be bigger for larger cell, so the bigger cell > would determine the maximal amount of memory for simulation even if the cell > contracts? > > - Original Message - > From: "Paolo Giannozzi" > To: "PWSCF Forum" > Sent: Sunday, September 23, 2012 1:19:05 PM > Subject: Re: [Pw_forum] Error in routine scale_h (1) > > > On Sep 23, 2012, at 16:43 , Alexey Akimov wrote: > >> If i restart the calculations with the latest (most optimal) >> configuration of the system and the same amount of memory >> allocated, the further optimization can proceed some more time >> (also ~50 - 70 steps) before next crash. > this should not happen, unless your optimization procedure keeps > oscillating between large and > small volumes. > > P. > --- > Paolo Giannozzi, Dept of Chemistry&Physics&Environment, > Univ. Udine, via delle Scienze 208, 33100 Udine, Italy > Phone +39-0432-558216, fax +39-0432-558222 > > > > > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > ___ Pw_forum mailing list Pw_forum at pwscf.org http://www.democritos.it/mailman/listinfo/pw_forum -- Dr. Alexey V. Akimov Postdoctoral Research Associate Department of Chemistry University of Rochester aakimov at z.rochester.edu
[Pw_forum] info regarding r.x code
Thank you very much Dear Chen Sir for your kind help. On Sun, Sep 23, 2012 at 8:38 PM, Peng Chen wrote: > Dear Pandey, > > You can find r.x in the exercises of "Matteo Cococcioni,Examples of > spin-polarized and DFT+U calculations" in the link: > http://media.quantum-espresso.org/santa_barbara_2009_07/index.php. And > you can follow the "instructions of LDA+U" to calculate U. > > > > On Sun, Sep 23, 2012 at 1:13 AM, Bramha Pandey gmail.com>wrote: > >> Dear Users and Developers, >> How can i get the r.x code for the calculation of U parameter in quantum >> espresso-5.0.1. >> Any kind of help is heartily appreciable. >> >> -- >> Thanks and Regards >> Bramha Prasad Pandey >> Ph.D Student Indian School of Mines(ISM) >> Dhanbad, INDIA. >> >> >> ___ >> Pw_forum mailing list >> Pw_forum at pwscf.org >> http://www.democritos.it/mailman/listinfo/pw_forum >> >> > > > -- > Best Regards. > Peng > > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > > -- Thanks and Regards Bramha Prasad Pandey Ph.D Student Indian School of Mines(ISM) Dhanbad, INDIA. -- next part -- An HTML attachment was scrubbed... URL: http://www.democritos.it/pipermail/pw_forum/attachments/20120923/72111707/attachment.htm
[Pw_forum] Error in routine scale_h (1)
Set cell_factor (in &cell) to a number higher than the default like suggested... That should work. Cheers, Martin Andersson University of Copenhagen Den 2012-09-23 4:43 PM, Alexey Akimov skrev: > Dear all, > > I'm trying to optimize a relatively large system such as 2 C60 / unit cell. > So i start with relatively large cell dimensions. I'm doing vc-relax > calculations with either 'damp'&'damp-pr' or 'bfgs'&'bfgs' for ionic and cell > dynamics options. However, after some number (~50-70) of successful > (ionic/cell) steps the calculations crash with the error: > > Error in routine scale_h (1): > Not enough space allocated for radial FFT: try restarting with a larger > cell_factor. > > It seems like this happens when the size of the simulation cell changes by > some notable amount with respect to the starting one. Perhaps, the program > automatically changes the plane wave basis set (increases). If i restart the > calculations with the latest (most optimal) configuration of the system and > the same amount of memory allocated, the further optimization can proceed > some more time (also ~50 - 70 steps) before next crash. So in principle it is > still possible to achieve the convergence with this sequence of operations, > but it is quite inconvenient to reset the calculations every 50-70 steps. > > So my question: is there any way to avoid this and get optimized results > without intermediate crashes (apart from increasing the amount of memory > reserved in the beginning)? > > Thank you, > Alexey > >
[Pw_forum] Error in routine scale_h (1)
Ok. I'll try this option, thank you for suggestion. In conjunction to this feature, will the memory required for calculation increase with increased cell_factor? how fast? - Original Message - From: "Martin Andersson" To: "PWSCF Forum" Sent: Sunday, September 23, 2012 12:33:15 PM Subject: Re: [Pw_forum] Error in routine scale_h (1) Set cell_factor (in &cell) to a number higher than the default like suggested... That should work. Cheers, Martin Andersson University of Copenhagen Den 2012-09-23 4:43 PM, Alexey Akimov skrev: > Dear all, > > I'm trying to optimize a relatively large system such as 2 C60 / unit cell. > So i start with relatively large cell dimensions. I'm doing vc-relax > calculations with either 'damp'&'damp-pr' or 'bfgs'&'bfgs' for ionic and cell > dynamics options. However, after some number (~50-70) of successful > (ionic/cell) steps the calculations crash with the error: > > Error in routine scale_h (1): > Not enough space allocated for radial FFT: try restarting with a larger > cell_factor. > > It seems like this happens when the size of the simulation cell changes by > some notable amount with respect to the starting one. Perhaps, the program > automatically changes the plane wave basis set (increases). If i restart the > calculations with the latest (most optimal) configuration of the system and > the same amount of memory allocated, the further optimization can proceed > some more time (also ~50 - 70 steps) before next crash. So in principle it is > still possible to achieve the convergence with this sequence of operations, > but it is quite inconvenient to reset the calculations every 50-70 steps. > > So my question: is there any way to avoid this and get optimized results > without intermediate crashes (apart from increasing the amount of memory > reserved in the beginning)? > > Thank you, > Alexey > > ___ Pw_forum mailing list Pw_forum at pwscf.org http://www.democritos.it/mailman/listinfo/pw_forum -- Dr. Alexey V. Akimov Postdoctoral Research Associate Department of Chemistry University of Rochester aakimov at z.rochester.edu
[Pw_forum] Error in routine scale_h (1)
my unit cell is not oscillating, but rather shrinking. shouldn't the basis size (number of plane waves) be bigger for larger cell, so the bigger cell would determine the maximal amount of memory for simulation even if the cell contracts? - Original Message - From: "Paolo Giannozzi" To: "PWSCF Forum" Sent: Sunday, September 23, 2012 1:19:05 PM Subject: Re: [Pw_forum] Error in routine scale_h (1) On Sep 23, 2012, at 16:43 , Alexey Akimov wrote: > If i restart the calculations with the latest (most optimal) > configuration of the system and the same amount of memory > allocated, the further optimization can proceed some more time > (also ~50 - 70 steps) before next crash. this should not happen, unless your optimization procedure keeps oscillating between large and small volumes. P. --- Paolo Giannozzi, Dept of Chemistry&Physics&Environment, Univ. Udine, via delle Scienze 208, 33100 Udine, Italy Phone +39-0432-558216, fax +39-0432-558222 ___ Pw_forum mailing list Pw_forum at pwscf.org http://www.democritos.it/mailman/listinfo/pw_forum -- Dr. Alexey V. Akimov Postdoctoral Research Associate Department of Chemistry University of Rochester aakimov at z.rochester.edu
[Pw_forum] How to calculate the adsorption energy of ion (charged particle) on the surface of semiconductor?
Dear Yavar, take a look at the following link of a post from Paolo: http://www.democritos.it/pipermail/pw_forum/2007-January/005694.html mahmoud -Original Message- From: yavar pour azar To: PWSCF Forum Date: Mon, 17 Sep 2012 11:58:29 +0430 Subject: [Pw_forum] How to calculate the adsorption energy of ion (charged particle) on the surface of semiconductor? Dear QE users I want to calculate adsorption energy and structural parameters for the adsorption of some ions on the surface of semiconductor, is this similar to calculation of neutral particle or other procedure is required? I would be appreciate if anyone refer me to detailed reference to do this. Thanks in advance - Yavar Taghipour Azar Physics Group, AEOI Tehran, Iran -- next part -- An HTML attachment was scrubbed... URL: http://www.democritos.it/pipermail/pw_forum/attachments/20120923/3b11f099/attachment.htm
[Pw_forum] info regarding r.x code
Dear Pandey, You can find r.x in the exercises of "Matteo Cococcioni,Examples of spin-polarized and DFT+U calculations" in the link: http://media.quantum-espresso.org/santa_barbara_2009_07/index.php. And you can follow the "instructions of LDA+U" to calculate U. On Sun, Sep 23, 2012 at 1:13 AM, Bramha Pandey wrote: > Dear Users and Developers, > How can i get the r.x code for the calculation of U parameter in quantum > espresso-5.0.1. > Any kind of help is heartily appreciable. > > -- > Thanks and Regards > Bramha Prasad Pandey > Ph.D Student Indian School of Mines(ISM) > Dhanbad, INDIA. > > > ___ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > > -- Best Regards. Peng -- next part -- An HTML attachment was scrubbed... URL: http://www.democritos.it/pipermail/pw_forum/attachments/20120923/b9505960/attachment.htm
[Pw_forum] info regarding r.x code
Dear Users and Developers, How can i get the r.x code for the calculation of U parameter in quantum espresso-5.0.1. Any kind of help is heartily appreciable. -- Thanks and Regards Bramha Prasad Pandey Ph.D Student Indian School of Mines(ISM) Dhanbad, INDIA. -- next part -- An HTML attachment was scrubbed... URL: http://www.democritos.it/pipermail/pw_forum/attachments/20120923/1daf03f9/attachment.htm
[Pw_forum] Error in routine scale_h (1)
Dear all, I'm trying to optimize a relatively large system such as 2 C60 / unit cell. So i start with relatively large cell dimensions. I'm doing vc-relax calculations with either 'damp'&'damp-pr' or 'bfgs'&'bfgs' for ionic and cell dynamics options. However, after some number (~50-70) of successful (ionic/cell) steps the calculations crash with the error: Error in routine scale_h (1): Not enough space allocated for radial FFT: try restarting with a larger cell_factor. It seems like this happens when the size of the simulation cell changes by some notable amount with respect to the starting one. Perhaps, the program automatically changes the plane wave basis set (increases). If i restart the calculations with the latest (most optimal) configuration of the system and the same amount of memory allocated, the further optimization can proceed some more time (also ~50 - 70 steps) before next crash. So in principle it is still possible to achieve the convergence with this sequence of operations, but it is quite inconvenient to reset the calculations every 50-70 steps. So my question: is there any way to avoid this and get optimized results without intermediate crashes (apart from increasing the amount of memory reserved in the beginning)? Thank you, Alexey -- Dr. Alexey V. Akimov Postdoctoral Research Associate Department of Chemistry University of Rochester aakimov at z.rochester.edu
