From liyanpcl at yahoo.com.cn Sun Jan 1 02:40:42 2006 From: liyanpcl at yahoo.com.cn (li yan) Date: Sun, 1 Jan 2006 09:40:42 +0800 (CST) Subject: [Pw_forum] =?gb2312?q?=BB=D8=B8=B4=A3=BA=20Re:=20[Pw=5Fforum]=20questions=20about=20?= =?gb2312?q?the=20ph.x?= In-Reply-To: <200512311540.59214.giannozz@nest.sns.it> Message-ID: <20060101014042.36278.qmail@web15602.mail.cnb.yahoo.com> i am so silly! thank you! __________________________________________________ ??????????????? http://cn.mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060101/27c73898/attachment.htm From liyanpcl at yahoo.com.cn Sun Jan 1 03:17:50 2006 From: liyanpcl at yahoo.com.cn (li yan) Date: Sun, 1 Jan 2006 10:17:50 +0800 (CST) Subject: [Pw_forum] negtive values for TA when using q2r.x Message-ID: <20060101021750.40970.qmail@web15601.mail.cnb.yahoo.com> dear all, i use q2r.x to calculate the phonon dispersion curves for AgF. at 3GPa, there are many negtive values for TA in the brillion zone. then i just calculated one of these points, but i got a positive values. then i used 6*6*6 q mesh, no improvement is found. what can i do next? ragards __________________________________________________ ??????????????? http://cn.mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060101/199c7062/attachment.htm From leoant21 at hotmail.com Sun Jan 1 04:35:17 2006 From: leoant21 at hotmail.com (=?gb2312?B?1cUguumx8g==?=) Date: Sun, 01 Jan 2006 03:35:17 +0000 Subject: [Pw_forum] Question on the pseudopotential generation using LD1 Message-ID: Dear all, Wish you have a happy New Year first. Now I want to do some Virtual Crystal Approximation calculation where Mg pseudopotentials must be generated, however I am a little confused with those parameters showed in the INPUT_LD1, thus my first question is where can I find some general introduction on pseudopotential generation? please refer me to some papers. Following the example of al.in, I wrote an input file for pseudo-gen of Mg, but there is an error as follows: no error in all electron calculation __________________________________________________________________________ Generating local potential, lloc =-1 (while =2 there's the same error) Local pseudo, rcloc= 1.500 Estimated cut-off energy= 10.49Ry %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from compute phi :error # -1 negative determinant %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 1 ld = 1.168338 f2ae -0.660044 faenor 0.060527 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from gener_pseudo : error # 1 too many nodes %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% If I change "rcut" from 1.50(which resulted in the error above) to 2.00 or 3.00, there would be an error massege said that at the begginning like this: This function has 0 nodes for 0 < r < 1.994 While " too many nodes" shows too, so what's the problem? Further more, if I want to consider transition metal doping of Mg, it is obvious that d electrons should be considered, then can I inculde d electron in Mg electron configuration, which may like this: [Ne] 3S1 3d0.5 4S1 and correspondingly zed=(1-x)* 12 + x* Z , where Z is the nuclear charge of the doped element, x is the doping percentage. Is this correct? Thank you very much and have a nice day. Best regards Hongbin Zhang PS: input file for Mg pseudo-gen &input title='Mg', zed=12.0, rel=0, beta=0.5, rlderiv=2.4, eminld=-4.0, emaxld=8.0, deld=0.02d0, nld=3, config='[Ne] 3s2 3p-1 ', iswitch=3, dft='LDA', / &test pseudotype=1, nconf=1, / 1 3S 1 0 2.00 0.00 2.00 2.00 1 &inputp lloc=-1, file_pseudopw='Mg.rrkj3', zval=2.d0, / 2 3S 1 0 2.00 0.00 1.50 1.50 3P 2 1 -1.00 0.00 2.90 2.90 _________________________________________________________________ ?????????????? MSN Messenger: http://messenger.msn.com/cn From leoant21 at hotmail.com Sun Jan 1 04:35:16 2006 From: leoant21 at hotmail.com (=?gb2312?B?1cUguumx8g==?=) Date: Sun, 01 Jan 2006 03:35:16 +0000 Subject: [Pw_forum] Question on the pseudopotential generation using LD1 Message-ID: Dear all, Wish you have a happy New Year first. Now I want to do some Virtual Crystal Approximation calculation where Mg pseudopotentials must be generated, however I am a little confused with those parameters showed in the INPUT_LD1, thus my first question is where can I find some general introduction on pseudopotential generation? please refer me to some papers. Following the example of al.in, I wrote an input file for pseudo-gen of Mg, but there is an error as follows: no error in all electron calculation __________________________________________________________________________ Generating local potential, lloc =-1 (while =2 there's the same error) Local pseudo, rcloc= 1.500 Estimated cut-off energy= 10.49Ry %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from compute phi :error # -1 negative determinant %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 1 ld = 1.168338 f2ae -0.660044 faenor 0.060527 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from gener_pseudo : error # 1 too many nodes %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% If I change "rcut" from 1.50(which resulted in the error above) to 2.00 or 3.00, there would be an error massege said that at the begginning like this: This function has 0 nodes for 0 < r < 1.994 While " too many nodes" shows too, so what's the problem? Further more, if I want to consider transition metal doping of Mg, it is obvious that d electrons should be considered, then can I inculde d electron in Mg electron configuration, which may like this: [Ne] 3S1 3d0.5 4S1 and correspondingly zed=(1-x)* 12 + x* Z , where Z is the nuclear charge of the doped element, x is the doping percentage. Is this correct? Thank you very much and have a nice day. Best regards Hongbin Zhang PS: input file for Mg pseudo-gen &input title='Mg', zed=12.0, rel=0, beta=0.5, rlderiv=2.4, eminld=-4.0, emaxld=8.0, deld=0.02d0, nld=3, config='[Ne] 3s2 3p-1 ', iswitch=3, dft='LDA', / &test pseudotype=1, nconf=1, / 1 3S 1 0 2.00 0.00 2.00 2.00 1 &inputp lloc=-1, file_pseudopw='Mg.rrkj3', zval=2.d0, / 2 3S 1 0 2.00 0.00 1.50 1.50 3P 2 1 -1.00 0.00 2.90 2.90 _________________________________________________________________ ??????????????? MSN Hotmail? http://www.hotmail.com From jasonsun98 at hotmail.com Sun Jan 1 15:28:11 2006 From: jasonsun98 at hotmail.com (sun jason) Date: Sun, 01 Jan 2006 14:28:11 +0000 Subject: [Pw_forum] parallel in q2r.x In-Reply-To: <20060101063545.3730.99267.Mailman@democritos.sissa.it> Message-ID: Dear all, Happy New Year! I encounter some problems when I use q2r.x in espresso-3.0. the pw.x and ph.x can run in parallel, but when I type $~/espresso-3.0/bin/q2r.x < q2r.in > q2r.out or $mpirun -np 1 ~/espresso-3.0/bin/q2r.x < q2r.in > q2r.out q2r.x will not work, the error message always says, [0] MPI Abort by user Aborting program ! [0] Aborting program! I try to compile q2r.f90 in sequential. but I failed. It seems that the q2r.f90 must be compiled into parallel. It seems that the example06 in espresso-3.0 is not updated. the input files for q2r.x and matdyn.x are not right. any help would be appreciated. Best regards, Jian Sun From hushujun at mail.sdu.edu.cn Mon Jan 2 07:53:54 2006 From: hushujun at mail.sdu.edu.cn (Shujun Hu) Date: Mon, 02 Jan 2006 14:53:54 +0800 Subject: [Pw_forum] Spin-orbital effects and relativistic US-PPs Message-ID: <336184834.13538@mail.sdu.edu.cn> Dear Drs, I want to perform one calculation of Sn-O-Co compound including spin-orbital effects, which need fully or scalar relativistic US-PPs. But I cannt find the PPs of above three elements with the same functional, such as PBE or PW91, on the PPs download webpage. Could you guide me to find such data or transform the non-US-PPs to the ultrasoft ones? Another question, does the spin-orbital effect calculation need all the PPs of elements to be fully relativistic ones, or scalar relativistic, or partial elements? If partial are needed, which is more important in the Sn-O-Co compound? Best wishes. Shujun Hu ------------------------------ -- Shujun Hu e-mail: hushujun at 163.com Shandong university Phone: +86/0531-88375097 Jinan, Shandong Province, China, 250100 From ykanai at Princeton.EDU Tue Jan 3 04:53:15 2006 From: ykanai at Princeton.EDU (Yosuke Kanai (ykanai@Princeton.EDU)) Date: Tue, 03 Jan 2006 12:53:15 +0900 Subject: [Pw_forum] About neb and smd In-Reply-To: <005401c60dbe$8d1f1690$1d00a8c0@solarflare> References: <005401c60dbe$8d1f1690$1d00a8c0@solarflare> Message-ID: Hi Huiqun Zhou In regular implementation of these methods as in the present version of the code, it does not make sense to study the pressure-induced transition. There was, however, an interesting and possibly useful paper about extending the NEB to the case of phase transtions (I believe) by Emily Carter in PNAS. I cannot remember the exact reference (Sorry, I am out of town and cannot check it for you) but very recent. Yosuke > > Could anyone give me a pointer whether it's theoretically > reasonable to investigate solid state > transition induced by pressure using NEB or string method? > > Any references are appreciated. > > Happy New Year! > > Huiqun Zhou -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060103/7fc63922/attachment.htm From katalin.gaal-nagy at physik.uni-regensburg.de Tue Jan 3 10:04:31 2006 From: katalin.gaal-nagy at physik.uni-regensburg.de (Katalin Gaal-Nagy) Date: Tue, 3 Jan 2006 10:04:31 +0100 (CET) Subject: [Pw_forum] About neb and smd In-Reply-To: References: <005401c60dbe$8d1f1690$1d00a8c0@solarflare> Message-ID: Dear Yosuke, first I wish a happy new year to everyone! By chance, the paper you mentioned, is it this one? "Finding transition states for crystalline solid-solid phase transformations" by Caspersen, K.J.; Carter, E.A. in Proceedings of the National Academy of Sciences of the United States of America vol.102, no.19 : 6738-43 , 10 May 2005 Best wishes, Katalin > Hi Huiqun Zhou > In regular implementation of these methods as in the present version of the code, it does not make sense to study the pressure-induced transition. > There was, however, an interesting and possibly useful paper about extending the NEB to the case of phase transtions (I believe) by Emily Carter in PNAS. I cannot remember the exact reference (Sorry, I am out of town and cannot check it for you) but very recent. > Yosuke > >> >> Could anyone give me a pointer whether it's theoretically >> reasonable to investigate solid state >> transition induced by pressure using NEB or string method? >> >> Any references are appreciated. >> >> Happy New Year! >> >> Huiqun Zhou > From naromero at gmail.com Tue Jan 3 23:35:05 2006 From: naromero at gmail.com (Nichols A. Romero) Date: Tue, 3 Jan 2006 17:35:05 -0500 Subject: [Pw_forum] variable-cell optimizations Message-ID: <6ac064b60601031435p7a427e22ud39cc5dd6a4736be@mail.gmail.com> Hi, How does PWSCF handle the number of planewaves during a variable-cell optimizations? Are the planewaves or energy cutoff kept constant? Does it use the method of Bernasconi et. al Phys. Chem. Solids, 56 501 (1995)? Thanks, -- Dr. Nichols A. Romero, PhD. 1613 Denise Dr. Apt. D Forest Hill, MD 21050 443-567-8328 (C) 410-306-0709 (O) From giannozz at nest.sns.it Wed Jan 4 11:58:39 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 4 Jan 2006 11:58:39 +0100 Subject: [Pw_forum] variable-cell optimizations In-Reply-To: <6ac064b60601031435p7a427e22ud39cc5dd6a4736be@mail.gmail.com> References: <6ac064b60601031435p7a427e22ud39cc5dd6a4736be@mail.gmail.com> Message-ID: <200601041158.39806.giannozz@nest.sns.it> On Tuesday 03 January 2006 23:35, Nichols A. Romero wrote: > How does PWSCF handle the number of planewaves during a variable-cell > optimizations? Are the planewaves or energy cutoff kept constant? the energy cutoff is kept constant > Does it use the method of Bernasconi et. al Phys. Chem. Solids, 56 501 > (1995)? I don't know about the specific reference ("J. Phys. Chem. Solids", by the way) but I think so. It uses a modified functional in which the kinetic energy (the electronic one appearing in the Kohn-Sham equations) is calculated by replacing (k+G)^2 with (k+G)^2 + qcutz * (1 + erf( ((k+G)^2 - ecfixed ) / q2sigma ) ) . P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Wed Jan 4 12:01:38 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 4 Jan 2006 12:01:38 +0100 Subject: [Pw_forum] Spin-orbital effects and relativistic US-PPs In-Reply-To: <336184834.13538@mail.sdu.edu.cn> References: <336184834.13538@mail.sdu.edu.cn> Message-ID: <200601041201.38839.giannozz@nest.sns.it> On Monday 02 January 2006 07:53, Shujun Hu wrote: > Another question, does the spin-orbital effect calculation need all the > PPs of elements to be fully relativistic ones, or scalar relativistic, or > partial elements? in the present version of the code, all PPs must be fully relativistic in order to perform a calculation with spin-orbit effects included. In the CVS version this restriction has been lifted > If partial are needed, which is more important in the Sn-O-Co compound? the heaviest atom, I guess P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Wed Jan 4 12:49:38 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 4 Jan 2006 12:49:38 +0100 Subject: [Pw_forum] alkali metal pseudopotentials In-Reply-To: References: <20051231051120.65709.qmail@web51006.mail.yahoo.com> Message-ID: <200601041249.38339.giannozz@nest.sns.it> > On Saturday 31 December 2005 23:15 wow, that's an alternative way of spending new year's eve: writing about pseudopotentials on pw_forum > Axel Kohlmeyer wrote: > last time i checked, the FHI converter did not support NLCC well...the converter reads the 'partial core charge', issues a triumphant message 'Pseudopotential with NLCC successfully read', writes down a guess of what the corresponding quantity for the UPF format should be, but it is just a guess: nobody knows whether th partial core charge in the FHI is rho(r), or 4pi*rho(r), or 4pi/r^2 rho(r) ... apparently it isn't documented anywhere. Anybody interested in experimenting? By the way: I also heard reports that not all FHI pseudopotentials are correctly converted, even in absence of core corrections, because the radial grid isn't always what it is expected to be. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Wed Jan 4 13:10:50 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 4 Jan 2006 13:10:50 +0100 Subject: [Pw_forum] Question on the pseudopotential generation using LD1 In-Reply-To: References: Message-ID: <200601041310.50195.giannozz@nest.sns.it> On Sunday 01 January 2006 04:35, ? ?? wrote: > I am a little confused with those parameters showed in the INPUT_LD1, > thus my first question is where can I find some general introduction on > pseudopotential generation? please refer me to some papers. there is a pseudo-documentation in atomic_doc/pseudo-gen.tex . It contains also a few references Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Wed Jan 4 13:18:08 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 4 Jan 2006 13:18:08 +0100 Subject: [Pw_forum] alkali metal pseudopotentials In-Reply-To: <20051231051120.65709.qmail@web51006.mail.yahoo.com> References: <20051231051120.65709.qmail@web51006.mail.yahoo.com> Message-ID: <200601041318.08107.giannozz@nest.sns.it> On Saturday 31 December 2005 06:11, W. YU wrote: > 2. I did some calculations on alkali hydrides such as > LiH and NaH. For LiH, the LDA using Von Barth and Car > scheme give a much smaller lattice constant I am not sure what PP was used in this paper: G. Roma et al, Solid State Commun. 98, p.203 (1996), but it might well be the same that one finds on www.pwscf.org. They get -5.1% for the lattice constant, -2.5% taking into account finite temperature and zero-point effects. Is this what you get? it is nothing to write home about, but it is a decent result. GGA should yield a larger lattice parameter. > For NaH system, the VBC LDA gives a lattice constant very > close to the experimental one and the GGA gives larger lattice > constant. nothing surprising here > When the vibrating effect [...] is taken into account, the resulting > lattice constant is much larger than the experiment. I don't expect finite-temperature and zero-point effects to be larger in NaH than in LiH, so with LDA you will get something in the order of +2% for the lattice constant. It is not very good but it isn't very bad either Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From proffess at yandex.ru Wed Jan 4 17:32:47 2006 From: proffess at yandex.ru (Sergey Lisenkov) Date: Wed, 4 Jan 2006 19:32:47 +0300 (MSK) Subject: [Pw_forum] variable-cell optimizations In-Reply-To: <200601041158.39806.giannozz@nest.sns.it> References: <6ac064b60601031435p7a427e22ud39cc5dd6a4736be@mail.gmail.com> <200601041158.39806.giannozz@nest.sns.it> Message-ID: <43BBF8AF.000001.04229@pantene.yandex.ru> Dear Paolo, >On Tuesday 03 January 2006 23:35, Nichols A. Romero wrote: > >> How does PWSCF handle the number of planewaves during a variable-cell >> optimizations? Are the planewaves or energy cutoff kept constant? > >the energy cutoff is kept constant So, does it mean that it is not neccesary to increase energy cutoff (like at VASP, ABINIT - they use constant plane wave basis in varible cell calculations) during vc-relax to get correct stress tensor? Sergey From giannozz at nest.sns.it Wed Jan 4 18:33:31 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 4 Jan 2006 18:33:31 +0100 Subject: [Pw_forum] parallel in q2r.x In-Reply-To: References: Message-ID: <200601041833.31277.giannozz@nest.sns.it> On Sunday 01 January 2006 15:28, sun jason wrote: > q2r.x will not work, the error message always says, > [0] MPI Abort by user Aborting program ! > [0] Aborting program! this is the error message from MPI saying "I am crashing". Run the code interactively and look at the error message from the code itself. There is a quite long discussion in the users' guide on problems with parallel execution. > I try to compile q2r.f90 in sequential. but I failed. It seems > that the q2r.f90 must be compiled into parallel. the distribution can be compiled either for serial or for parallel execution, but you cannot mix the two ways of compiling > It seems that the example06 in espresso-3.0 is not updated. > the input files for q2r.x and matdyn.x are not right. they work for me P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Wed Jan 4 18:40:46 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 4 Jan 2006 18:40:46 +0100 Subject: [Pw_forum] negtive values for TA when using q2r.x In-Reply-To: <20060101021750.40970.qmail@web15601.mail.cnb.yahoo.com> References: <20060101021750.40970.qmail@web15601.mail.cnb.yahoo.com> Message-ID: <200601041840.46429.giannozz@nest.sns.it> On Sunday 01 January 2006 03:17, li yan wrote: > i use q2r.x to calculate the phonon dispersion curves for AgF. > at 3GPa, there are many negative values for TA in the brillouin zone. > then i just calculated one of these points, but i got a positive values. > then i used 6*6*6 q mesh, no improvement is found. the Fourier interpolation performed by q2r.x yields the original phonon frequencies at the q-points of the grid in q-space. If it doesn't, there is something wrong somewhere in the procedure P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From hqzhou at nju.edu.cn Thu Jan 5 02:31:49 2006 From: hqzhou at nju.edu.cn (hqzhou at nju.edu.cn) Date: Thu, 5 Jan 2006 09:31:49 +0800 Subject: [Pw_forum] About neb and smd Message-ID: <200601050131.k051VnEu020537@mail1.nju.edu.cn> Thank you very much, Katalin and Yoseke! Huiqun Zhou Katalin Gaal-Nagy ??????? .. > Dear Yosuke, > > first I wish a happy new year to everyone! > > By chance, the paper you mentioned, is it this one? > > "Finding transition states for crystalline solid-solid phase > transformations" > by Caspersen, K.J.; Carter, E.A. > in > Proceedings of the National Academy of Sciences of the United States of > America vol.102, no.19 : 6738-43 , 10 May 2005 > > Best wishes, > Katalin > > > Hi Huiqun Zhou > > In regular implementation of these methods as in the present version > of the code, it does not make sense to study the pressure-induced transition. > > There was, however, an interesting and possibly useful paper about extending > the NEB to the case of phase transtions (I believe) by Emily Carter in > PNAS. I cannot remember the exact reference (Sorry, I am out of town and > cannot check it for you) but very recent. > > Yosuke > > > >> > >> Could anyone give me a pointer whether it's theoretically > >> reasonable to investigate solid state > >> transition induced by pressure using NEB or string method? > >> > >> Any references are appreciated. > >> > >> Happy New Year! > >> > >> Huiqun Zhou > > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum From liyanpcl at yahoo.com.cn Thu Jan 5 03:08:36 2006 From: liyanpcl at yahoo.com.cn (li yan) Date: Thu, 5 Jan 2006 10:08:36 +0800 (CST) Subject: [Pw_forum] =?gb2312?q?=BB=D8=B8=B4=A3=BA=20Re:=20[Pw=5Fforum]=20Spin-orbital=20effec?= =?gb2312?q?ts=20and=20relativistic=20US-PPs?= In-Reply-To: <200601041201.38839.giannozz@nest.sns.it> Message-ID: <20060105020836.38691.qmail@web15604.mail.cnb.yahoo.com> I also want to do some calculations including spin-orbital effects.I used the fully relativistic PPs which are generated by program LD1.But there are something wrong with it.My input and output files are followed: -------------------------input file----------------------------------- &control calculation='scf', restart_mode='from_scratch', prefix='2H-NbSe2' pseudo_dir = '/home/cpmd/yanming/xy/pwscf/pseudo//', outdir='/home/cpmd/yanming/xy/pwscf/tmp/tmp_5/' tstress=.t., tprnfor=.t. / &system ibrav = 4, celldm(1) = 6.50066,celldm(3) = 3.62849 nat= 6, ntyp= 2, ecutwfc= 60, occupations='smearing', smearing='mp', degauss=0.05, noncolin=.true.,lspinorb=.true.,starting_magnetization=0.0, / &electrons mixing_beta = 0.7 conv_thr = 1.0d-8 / ATOMIC_SPECIES Nb 92.90638 Nb.UPF Se 78.96000 Se.UPF ATOMIC_POSITIONS {crystal} Nb 0.0000000 0.0000000 0.2500000 Nb 0.0000000 0.0000000 0.7500000 Se 0.3333333 0.6666667 0.1163000 Se 0.6666667 0.3333333 0.6163000 Se 0.6666667 0.3333333 0.8837000 Se 0.3333333 0.6666667 0.3837000 K_POINTS { automatic } 4 4 1 0 0 0 -----------------------------output file--------------------------- Program PWSCF v.3.0 starts ... Today is 26Dec2005 at 14: 2:50 Ultrasoft (Vanderbilt) Pseudopotentials Current dimensions of program pwscf are: ntypx = 10 npk = 40000 lmax = 3 nchix = 6 ndmx = 2000 nbrx = 14 nqfx = 8 non-colinear magnetization allowed Generating pointlists ... new r_m : 0.3110708210382721 bravais-lattice index = 4 lattice parameter (a_0) = 6.5007 a.u. unit-cell volume = 863.2348 (a.u.)^3 number of atoms/cell = 6 number of atomic types = 2 kinetic-energy cutoff = 60.0000 Ry charge density cutoff = 240.0000 Ry convergence threshold = 1.0E-08 beta = 0.7000 number of iterations used = 8 plain mixing Exchange-correlation = SLA PW NOGX NOGC (1400) Noncollinear calculation with spin-orbit . . . . . the Fermi energy is 7.4586 ev ! total energy = -97.34336003 ryd estimated scf accuracy < 7.4E-09 ryd band energy sum = 5.93867982 ryd one-electron contribution = 18.12432792 ryd hartree contribution = 8.68735812 ryd xc contribution = -22.64271643 ryd ewald contribution = -101.50165600 ryd correction for metals = -0.01067366 ryd convergence has been achieved Forces acting on atoms (Ry/au): atom 1 type 1 force = 0.00000000 0.00000000 0.00000000 atom 2 type 1 force = 0.00000000 0.00000000 0.00000000 atom 3 type 2 force = 0.00000000 0.00000000 0.05065528 atom 4 type 2 force = 0.00000000 0.00000000 0.05065528 atom 5 type 2 force = 0.00000000 0.00000000 -0.05065528 atom 6 type 2 force = 0.00000000 0.00000000 -0.05065528 Total force = 0.101311 Total SCF correction = 0.000124 from stress : info # -1 non-colinear case not implemented Writing output data file 2H-NbSe2.save PWSCF : 13m52.13s CPU time Best wishes Li yan __________________________________________________ ??????????????? http://cn.mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060105/941f2bbb/attachment.htm From konstantin_kudin at yahoo.com Thu Jan 5 04:20:32 2006 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Wed, 4 Jan 2006 19:20:32 -0800 (PST) Subject: [Pw_forum] Voronoi polyhedra volume In-Reply-To: <200601041840.46429.giannozz@nest.sns.it> Message-ID: <20060105032032.1656.qmail@web52001.mail.yahoo.com> Hi all, Does anybody know where I could find a program to compute Voronoi polyhedra volume for something like water ? Thanks! Kostya __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From marzari at MIT.EDU Thu Jan 5 07:15:11 2006 From: marzari at MIT.EDU (Nicola Marzari) Date: Thu, 05 Jan 2006 01:15:11 -0500 Subject: [Pw_forum] Voronoi polyhedra volume In-Reply-To: <20060105032032.1656.qmail@web52001.mail.yahoo.com> References: <20060105032032.1656.qmail@web52001.mail.yahoo.com> Message-ID: <43BCB96F.3040100@mit.edu> Hi Kostya, a few possibilities, although I'm not sure they work with periodic boundary conditions: http://netlib.bell-labs.com/netlib/voronoi/hull.html http://www.csb.yale.edu/userguides/datamanip/volume/volume_descrip.html http://www.qhull.org/ nicola Konstantin Kudin wrote: > Hi all, > > Does anybody know where I could find a program to compute Voronoi > polyhedra volume for something like water ? > > Thanks! > Kostya --------------------------------------------------------------------- Prof Nicola Marzari Department of Materials Science and Engineering 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu From goranka.bilalbegovic at zg.htnet.hr Thu Jan 5 08:49:35 2006 From: goranka.bilalbegovic at zg.htnet.hr (Goranka Bilalbegovic) Date: Thu, 05 Jan 2006 08:49:35 +0100 Subject: [Pw_forum] Voronoi polyhedra volume In-Reply-To: <43BCB96F.3040100@mit.edu> References: <20060105032032.1656.qmail@web52001.mail.yahoo.com> <43BCB96F.3040100@mit.edu> Message-ID: <43BCCF8F.9070506@zg.htnet.hr> Nicola Marzari wrote: > > > Hi Kostya, > > a few possibilities, although I'm not sure they work with > periodic boundary conditions: > > http://netlib.bell-labs.com/netlib/voronoi/hull.html > > http://www.csb.yale.edu/userguides/datamanip/volume/volume_descrip.html > > http://www.qhull.org/ > > > nicola > > > > Konstantin Kudin wrote: > >> Hi all, >> >> Does anybody know where I could find a program to compute Voronoi >> polyhedra volume for something like water ? >> >> Thanks! >> Kostya > Hi, There is also an example (F35.F, A (2D) and B(3D), programs on microfiche) in the book M. P. Allen, D. J. Tildesley, Computer Simulation of Liquids. This is for a cubic box with periodic boundary conditions. Best regards, Goranka From giannozz at nest.sns.it Thu Jan 5 09:17:31 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 5 Jan 2006 09:17:31 +0100 Subject: [Pw_forum] =?utf-8?q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_Re=3A_=5BPw=5Fforum=5D_Spin-orbital?= =?utf-8?q?_effects_and_relativistic?= US-PPs In-Reply-To: <20060105020836.38691.qmail@web15604.mail.cnb.yahoo.com> References: <20060105020836.38691.qmail@web15604.mail.cnb.yahoo.com> Message-ID: <200601050917.32097.giannozz@nest.sns.it> On Thursday 05 January 2006 03:08, li yan wrote: > I also want to do some calculations including spin-orbital effects. > I used the fully relativistic PPs which are generated by program > LD1. But there are something wrong with it. > [...] > tstress=.t., > [...] > from stress : info # -1 > non-colinear case not implemented can't you read ??? the stress calculation is not implemented in this case. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Thu Jan 5 10:15:50 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 5 Jan 2006 10:15:50 +0100 Subject: [Pw_forum] variable-cell optimizations In-Reply-To: <43BBF8AF.000001.04229@pantene.yandex.ru> References: <6ac064b60601031435p7a427e22ud39cc5dd6a4736be@mail.gmail.com> <200601041158.39806.giannozz@nest.sns.it> <43BBF8AF.000001.04229@pantene.yandex.ru> Message-ID: <200601051015.50951.giannozz@nest.sns.it> On Wednesday 04 January 2006 17:32, Sergey Lisenkov wrote: > So, does it mean that it is not necessary to increase energy cutoff > (like at VASP, ABINIT - they use constant plane wave basis in variable > cell calculations) during vc-relax to get correct stress tensor? if you use a constant plane-wave basis set, you have smooth results, but bad convergence with cutoff (due to "Pulay stress", i.e. the dependence of the basis set upon the volume). If you use a constant cutoff, you have better convergence with cutoff but "rough" stress (because the number of plane waves changes when the volume changes). With a suitable choice of parameters for the modified functional, you get smooth results with constant cutoff. More details are in the paper that was mentioned earlier. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From katalin.gaal-nagy at physik.uni-regensburg.de Thu Jan 5 13:48:05 2006 From: katalin.gaal-nagy at physik.uni-regensburg.de (Katalin Gaal-Nagy) Date: Thu, 5 Jan 2006 13:48:05 +0100 (CET) Subject: [Pw_forum] alkali metal pseudopotentials In-Reply-To: <200601041249.38339.giannozz@nest.sns.it> References: <20051231051120.65709.qmail@web51006.mail.yahoo.com> <200601041249.38339.giannozz@nest.sns.it> Message-ID: >> On Saturday 31 December 2005 23:15 > wow, that's an alternative way of spending new year's eve: > writing about pseudopotentials on pw_forum Well ... if I would have been allowed to remain at university, I would have done the same ... Regards, Katalin From hushujun at mail.sdu.edu.cn Thu Jan 5 14:27:49 2006 From: hushujun at mail.sdu.edu.cn (Shujun Hu) Date: Thu, 05 Jan 2006 21:27:49 +0800 Subject: [Pw_forum] Spin-orbital effects and relativistic US-PPs Message-ID: <336467669.28089@mail.sdu.edu.cn> Dear Drs, I need the fully relativistic PPs of Tin (Sn), some transition elements Fe, Co and Ni, with the same functional, like PBE or PW91. How can i find them? Only scalar relativistic ones are valid on the PPs download webpage. Should i generate them myself? I find it's a terrible job to adjust lots of parameters. Shujun Hu From katalin.gaal-nagy at physik.uni-regensburg.de Thu Jan 5 14:18:12 2006 From: katalin.gaal-nagy at physik.uni-regensburg.de (Katalin Gaal-Nagy) Date: Thu, 5 Jan 2006 14:18:12 +0100 (CET) Subject: [Pw_forum] negtive values for TA when using q2r.x In-Reply-To: <200601041840.46429.giannozz@nest.sns.it> References: <20060101021750.40970.qmail@web15601.mail.cnb.yahoo.com> <200601041840.46429.giannozz@nest.sns.it> Message-ID: Dear Li Yan, dear Paolo, for me it is not clear what Le Yan exactly did (of course, I agree with you, Paolo!), thus, maybe some questions to Li Yan: Which was the first grid, which you used to calculate the dispersion? Does the 6x6x6 mesh include also the points you calculated for checking the negavive values? I had a similar problem many years ago with a high-pressure phase of silicon, where an irregular softening appeared near Gamma, and I should have used a finer grid in z-direction, meaning instead of 4x4x4 something like 4x4x6 or 4x4x8, bcause of c/a=0.55. At least, it was not enough to go from a 2x2x2 to a 4x4x4 mesh. Thus, maybe you could optimize the choice of your grid with respect to the lattice constants... Best wishes, Katalin >> i use q2r.x to calculate the phonon dispersion curves for AgF. >> at 3GPa, there are many negative values for TA in the brillouin zone. >> then i just calculated one of these points, but i got a positive values. >> then i used 6*6*6 q mesh, no improvement is found. > > the Fourier interpolation performed by q2r.x yields the original phonon > frequencies at the q-points of the grid in q-space. If it doesn't, there is > something wrong somewhere in the procedure > > P. > -- > Paolo Giannozzi e-mail: giannozz at nest.sns.it > Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 > Piazza dei Cavalieri 7 I-56126 Pisa, Italy > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From L.Boeri at fkf.mpg.de Thu Jan 5 16:28:35 2006 From: L.Boeri at fkf.mpg.de (Lilia Boeri) Date: Thu, 5 Jan 2006 16:28:35 +0100 (CET) Subject: [Pw_forum] more on variable-cell optimizations In-Reply-To: <200601051015.50951.giannozz@nest.sns.it> References: <6ac064b60601031435p7a427e22ud39cc5dd6a4736be@mail.gmail.com> <200601041158.39806.giannozz@nest.sns.it> <43BBF8AF.000001.04229@pantene.yandex.ru> <200601051015.50951.giannozz@nest.sns.it> Message-ID: Dear PWSCF users, I was wondering whether it is possible with PWSCF to optimize the unit cell while keeping the internal degrees of freedom (i.e. the reduced coordinates in the unit cell) fixed. If this is not possible, I would like to ask you the following question: if I have, for example, an hexagonal system and I want to find how the c/a ratio evolves with pressure, I suppose I should calculate, for different volumes, the total energy as a function of c/a keeping the volume fixed. Then I would take the minimum point for each volume and with this build a E(V) curve, differentiate and calculate the P(V) curve. Is it correct to expect that at the c/a value at which, for each volume, the total energy is minimum, the stress tensor should be isotropic ? (i.e. the x,y,z components should be the same)? I expect that if I want to reproduce or compare with an experiment done at isotropic pressure I should perform my calculations at some values at which the stress tensor calculated from first-priciples is isotropic... is the above procedure correct? Thank you in advance for your response, Lilia From konstantin_kudin at yahoo.com Thu Jan 5 22:19:01 2006 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Thu, 5 Jan 2006 13:19:01 -0800 (PST) Subject: [Pw_forum] Voronoi polyhedra volume In-Reply-To: <43BCCF8F.9070506@zg.htnet.hr> Message-ID: <20060105211901.9793.qmail@web52002.mail.yahoo.com> Nicola and Goranka, Thanks for suggestions! My further question is if anybody actually used any of these programs :-) Specifically, the one from bell-labs has troubles compiling with recent GCC, while giving highly criptic error message: 'pasting "seen" and "->" does not give a valid preprocessing token' The stuff from Yale's website does not have any code, just the description. Finally, the description for "qhul" does not mention that it would compute volumes. Any extra information here? Thanks! Kostya --- Goranka Bilalbegovic wrote: > Nicola Marzari wrote: > > > > > > > Hi Kostya, > > > > a few possibilities, although I'm not sure they work with > > periodic boundary conditions: > > > > http://netlib.bell-labs.com/netlib/voronoi/hull.html > > > > > http://www.csb.yale.edu/userguides/datamanip/volume/volume_descrip.html > > > > http://www.qhull.org/ > > > > > > nicola > > > > > > > > Konstantin Kudin wrote: > > > >> Hi all, > >> > >> Does anybody know where I could find a program to compute Voronoi > >> polyhedra volume for something like water ? > >> > >> Thanks! > >> Kostya > > > > Hi, > > There is also an example (F35.F, A (2D) and B(3D), programs on > microfiche) in the book M. P. Allen, D. J. Tildesley, Computer > Simulation of Liquids. This is for a cubic box with periodic boundary > > conditions. > > Best regards, > Goranka > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From liyanpcl at yahoo.com.cn Fri Jan 6 14:46:07 2006 From: liyanpcl at yahoo.com.cn (li yan) Date: Fri, 6 Jan 2006 21:46:07 +0800 (CST) Subject: [Pw_forum] =?gb2312?q?=BB=D8=B8=B4=A3=BA=20Re:=20[Pw=5Fforum]=20negtive=20values=20f?= =?gb2312?q?or=20TA=20=20when=20using=20q2r.x?= In-Reply-To: Message-ID: <20060106134612.71344.qmail@web15608.mail.cnb.yahoo.com> Dear katalin, I want to find the reason of the phase transiton for AgF by calculating the phonon dispersion curves. My intent is finding the soft mode at high pressure. >Which was the first grid, which you used to calculate the dispersion? AgF is fcc strcture, c/a is 1, so the mesh was initially chosen as 4*4*4. At 3GPa, after calculating the eight special points, i found only one of them (0,0,1) has a negative mode. Then i did the calculation of the phonon disperion curves with q2r.x, the frequences of TA near the gama point are negtive. Near gama point, i just selected one q, whose TA is negtive, to calculate the phonon, but the value of the TA is positive. I thought the q mesh is small, so i chose 6*6*6 mesh. > Does the 6x6x6 mesh include also the points you calculated for checking. The 6*6*6 mesh dosen't include the above modes which has negtive values, but i cannot find other ways to avoid the unexpected negtive values. thank you for your advice. best regards Li Yan --------------------------------- ?????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060106/85f5aae8/attachment.htm From pwscfklt at gmail.com Fri Jan 6 16:16:04 2006 From: pwscfklt at gmail.com (Konzern) Date: Fri, 6 Jan 2006 10:16:04 -0500 Subject: [Pw_forum] which file is a must for continueing ph.x run if time_max is reached? Message-ID: I am using a cluster with queueing system to do calculations with pwscf, because of the massive i/o load, I have to distribute the $TMP_DIR on each node. Therefore, it is not practical for me to collect all the files in $TMP_DIR and then re-distribute them in the subsequent run if time_max is reached in a previous run. I guess the necessary file should be the .save or recover, but recover is written for each cpu used, if I am not wrong. Could anyone who is familiar with this code tell me which files are necessary for a continueous run? In that case I can collet the necessary files and then re-distribute them for the subsequent run. Thanks. Konzern -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060106/ac836cf2/attachment.htm From eyvaz_isaev at yahoo.com Fri Jan 6 23:16:12 2006 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Fri, 6 Jan 2006 14:16:12 -0800 (PST) Subject: [Pw_forum] »Ø¸´£º Re: [Pw_forum] negtive values for TA when using q2r.x In-Reply-To: <20060106134612.71344.qmail@web15608.mail.cnb.yahoo.com> Message-ID: <20060106221612.33795.qmail@web60313.mail.yahoo.com> Hi, If I understood correctly, you have got imaginary (but not negative!, as you mentioned) frequences for X(100) point using 4x4x4 q-mesh. If so, the use of 6x6x6 mesh which also has (100) point is hopeless. Appearance of imaginary frequency at (100) point is a usual case for unstable compounds within NaCl structure. I suggest, it is somewhat strange to do FFT (q2r.x) having an imaginary frequency and then expect a stable structure. These imaginary frequences near Gamma point you found using q2r.x, are, presumably, connected to X(100) point instability. So, I guess, the problem might be due to: a) low cutoff energy b) insufficent k-points mesh c) quality of a pseudopotential d) check carefully your input file Best regards, Eyvaz. --- li yan wrote: > Dear katalin, > > I want to find the reason of the phase > transiton for AgF by calculating the phonon > dispersion curves. My intent is finding the soft > mode at high pressure. > > >Which was the first grid, which you used to > calculate the dispersion? > > AgF is fcc strcture, c/a is 1, so the mesh was > initially chosen as 4*4*4. > > At 3GPa, after calculating the eight special > points, i found only one of them (0,0,1) has a > negative mode. Then i did the calculation of the > phonon disperion curves with q2r.x, the frequences > of TA near the gama point are negtive. Near gama > point, i just selected one q, whose TA is negtive, > to calculate the phonon, but the value of the TA is > positive. I thought the q mesh is small, so i > chose 6*6*6 mesh. > > > Does the 6x6x6 mesh include also the points you > calculated for checking. > > The 6*6*6 mesh dosen't include the above > modes which has negtive values, but i cannot find > other ways to avoid the unexpected negtive values. > > thank you for your advice. > best regards > Li Yan > > > > > > > > --------------------------------- > ???????????????????????????????????????????????????? __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From katalin.gaal-nagy at physik.uni-regensburg.de Sat Jan 7 12:30:48 2006 From: katalin.gaal-nagy at physik.uni-regensburg.de (Katalin Gaal-Nagy) Date: Sat, 7 Jan 2006 12:30:48 +0100 (CET) Subject: [Pw_forum] =?iso-8859-1?Q?Re=3A_=5BPw=5Fforum=5D_=BB=D8=B8=B4=A3=BA_Re=3A_?= =?iso-8859-1?Q?=5BPw=5Fforum=5D_negtive_values_for_TA__when?= =?iso-8859-1?Q?_using_q2r=2Ex?= In-Reply-To: <20060106221612.33795.qmail@web60313.mail.yahoo.com> References: <20060106221612.33795.qmail@web60313.mail.yahoo.com> Message-ID: Hi Eyvaz, I am a little bit lost with your answer, what has some "real" instability at (100) to do with some "numerical" instability close to Gamma? Best, Katalin > Hi, > > If I understood correctly, you have got imaginary (but > not negative!, as you mentioned) frequences for X(100) > point using 4x4x4 q-mesh. If so, the use of 6x6x6 mesh > which also has (100) point is hopeless. > Appearance of imaginary frequency at (100) point is a > usual case for unstable compounds within NaCl > structure. > > I suggest, it is somewhat strange to do FFT (q2r.x) > having an imaginary frequency and then expect a stable > structure. These imaginary frequences near Gamma point > you found using q2r.x, are, presumably, connected to > X(100) point instability. > > So, I guess, the problem might be due to: > a) low cutoff energy > b) insufficent k-points mesh > c) quality of a pseudopotential > d) check carefully your input file > > Best regards, > Eyvaz. > > > --- li yan wrote: > >> Dear katalin, >> >> I want to find the reason of the phase >> transiton for AgF by calculating the phonon >> dispersion curves. My intent is finding the soft >> mode at high pressure. >> >> >Which was the first grid, which you used to >> calculate the dispersion? >> >> AgF is fcc strcture, c/a is 1, so the mesh was >> initially chosen as 4*4*4. >> >> At 3GPa, after calculating the eight special >> points, i found only one of them (0,0,1) has a >> negative mode. Then i did the calculation of the >> phonon disperion curves with q2r.x, the frequences >> of TA near the gama point are negtive. Near gama >> point, i just selected one q, whose TA is negtive, >> to calculate the phonon, but the value of the TA is >> positive. I thought the q mesh is small, so i >> chose 6*6*6 mesh. >> >> > Does the 6x6x6 mesh include also the points you >> calculated for checking. >> >> The 6*6*6 mesh dosen't include the above >> modes which has negtive values, but i cannot find >> other ways to avoid the unexpected negtive values. >> >> thank you for your advice. >> best regards >> Li Yan >> >> >> >> >> >> >> >> --------------------------------- >> ???????????????????????????????????????????????????? > > > > > > __________________________________________ > Yahoo! DSL ? Something to write home about. > Just $16.99/mo. or less. > dsl.yahoo.com > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From katalin.gaal-nagy at physik.uni-regensburg.de Sat Jan 7 12:47:19 2006 From: katalin.gaal-nagy at physik.uni-regensburg.de (Katalin Gaal-Nagy) Date: Sat, 7 Jan 2006 12:47:19 +0100 (CET) Subject: [Pw_forum] =?gb2312?q?=BB=D8=B8=B4=A3=BA=20Re:=20[Pw=5Fforum]=20negtive=20values=20f?= =?gb2312?q?or=20TA=20=20when=20using=20q2r.x?= In-Reply-To: <20060106134612.71344.qmail@web15608.mail.cnb.yahoo.com> References: <20060106134612.71344.qmail@web15608.mail.cnb.yahoo.com> Message-ID: Dear Li Yan, I was checking my very old work today (it was my diploma work, I am sorry, it is not published and it is in German), and the final solution of my former problem with my numerical instability was an increase of the k-points of the Ground state together with an increase of the number of q-points for the phonons. On Monday I can send you some figures. It was not enough just to increase the number of q-points. Have a nice weekend, best wishes, Katalin > Dear katalin, > > I want to find the reason of the phase transiton for AgF by > calculating the phonon dispersion curves. My intent is finding the soft > mode at high pressure. > > >Which was the first grid, which you used to calculate the dispersion? > > AgF is fcc strcture, c/a is 1, so the mesh was initially chosen as > 4*4*4. > > At 3GPa, after calculating the eight special points, i found only one > of them (0,0,1) has a negative mode. Then i did the calculation of > the phonon disperion curves with q2r.x, the frequences of TA near the > gama point are negtive. Near gama point, i just selected one q, whose > TA is negtive, to calculate the phonon, but the value of the TA is > positive. I thought the q mesh is small, so i chose 6*6*6 mesh. > > > Does the 6x6x6 mesh include also the points you calculated for checking. > > The 6*6*6 mesh dosen't include the above modes which has negtive > values, but i cannot find other ways to avoid the unexpected negtive > A values. > > thank you for your advice. > best regards > Li Yan > > > > > > > > --------------------------------- > ???????????????????????????????????????????????????? From eyvaz_isaev at yahoo.com Sat Jan 7 15:04:51 2006 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Sat, 7 Jan 2006 06:04:51 -0800 (PST) Subject: [Pw_forum] Re: [Pw_forum] »Ø¸´£º Re: [Pw_forum] negtive values for TA when using q2r.x In-Reply-To: Message-ID: <20060107140451.49768.qmail@web60321.mail.yahoo.com> Hi Katalin, I just suggested that an unstable mode near Gamma point might be a result of incorrectly determined dynamical matrix (and then unstable mode) at X point, and consequently, force constants obtained by q2r.x are also not correct. I am not sure that you will be able to get correct behavior of the phonon spectrum (obtained using matdyn.x) with wrong interatomic force constants. Are not you agree with this? The ways how to try avoiding an unstable mode at X point were done in my previous mail. Bests, Eyvaz. --- Katalin Gaal-Nagy wrote: > Hi Eyvaz, > > I am a little bit lost with your answer, what has > some "real" instability > at (100) to do with some "numerical" instability > close to Gamma? > > Best, Katalin > > > > Hi, > > > > If I understood correctly, you have got imaginary > (but > > not negative!, as you mentioned) frequences for > X(100) > > point using 4x4x4 q-mesh. If so, the use of 6x6x6 > mesh > > which also has (100) point is hopeless. > > Appearance of imaginary frequency at (100) point > is a > > usual case for unstable compounds within NaCl > > structure. > > > > I suggest, it is somewhat strange to do FFT > (q2r.x) > > having an imaginary frequency and then expect a > stable > > structure. These imaginary frequences near Gamma > point > > you found using q2r.x, are, presumably, connected > to > > X(100) point instability. > > > > So, I guess, the problem might be due to: > > a) low cutoff energy > > b) insufficent k-points mesh > > c) quality of a pseudopotential > > d) check carefully your input file > > > > Best regards, > > Eyvaz. > > > > > > --- li yan wrote: > > > >> Dear katalin, > >> > >> I want to find the reason of the phase > >> transiton for AgF by calculating the phonon > >> dispersion curves. My intent is finding the soft > >> mode at high pressure. > >> > >> >Which was the first grid, which you used to > >> calculate the dispersion? > >> > >> AgF is fcc strcture, c/a is 1, so the mesh > was > >> initially chosen as 4*4*4. > >> > >> At 3GPa, after calculating the eight special > >> points, i found only one of them (0,0,1) has a > >> negative mode. Then i did the calculation of > the > >> phonon disperion curves with q2r.x, the > frequences > >> of TA near the gama point are negtive. Near > gama > >> point, i just selected one q, whose TA is > negtive, > >> to calculate the phonon, but the value of the TA > is > >> positive. I thought the q mesh is small, so i > >> chose 6*6*6 mesh. > >> > >> > Does the 6x6x6 mesh include also the points > you > >> calculated for checking. > >> > >> The 6*6*6 mesh dosen't include the above > >> modes which has negtive values, but i cannot find > >> other ways to avoid the unexpected negtive > values. > >> > >> thank you for your advice. > >> best regards > >> Li Yan > >> > >> > >> > >> > >> > >> > >> > >> --------------------------------- > >> > ???????????????????????????????????????????????????? > > > > > > > > > > > > __________________________________________ > > Yahoo! DSL ? Something to write home about. > > Just $16.99/mo. or less. > > dsl.yahoo.com > > > > _______________________________________________ > > Pw_forum mailing list > > Pw_forum at pwscf.org > > http://www.democritos.it/mailman/listinfo/pw_forum > > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From yuwen_66 at yahoo.com Sat Jan 7 17:15:17 2006 From: yuwen_66 at yahoo.com (W. YU) Date: Sat, 7 Jan 2006 08:15:17 -0800 (PST) Subject: [Pw_forum] phonon modes assignment and others In-Reply-To: <20060107063520.3038.29500.Mailman@democritos.sissa.it> Message-ID: <20060107161517.43309.qmail@web51015.mail.yahoo.com> Thanks to Axel, Paolo and other pw members for answering my quesitons on the Alkali pseudopotentials. I have just checked this forum and found the new answers. I will be back to this question later when I have my results available next Monday. Now I have some other quesitons concerning the phonon calculations and the symmetry modes assignment: 1. Is there an easy or not so easy way to assign the different modes from the phonon calculation results to the various irreducible representations? From the correlation between site and factor groups, some information about which atom contributes to which irreducible representation or not can be found as well as some polarizibility characters. Any better way to do this job? 2. When I use dynmat.x to extract normal mode eigen vectors for the Gamma point, the results seems to be different from those given by the phonon output. What's the difference between the eigen vectors printed out by dynmat.x and Phonon codes (if there are, besides the dropping of phase factors in the dynmat.x output)? 3. When doing phonon calculation, we are not using supercell, but I know q2r does account for the interactions among different neighbours. Then is it possible for me to know exactly up to which nearest neighbour is included in the calculation? Sorry for too many quesitons, I just hope to make it a whole. Best regards, W. YU __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From natalie at wfu.edu Sat Jan 7 21:50:32 2006 From: natalie at wfu.edu (Natalie Holzwarth) Date: Sat, 7 Jan 2006 15:50:32 -0500 (EST) Subject: [Pw_forum] Variable-cell optimization with constraints In-Reply-To: <20060107161517.43309.qmail@web51015.mail.yahoo.com> References: <20060107161517.43309.qmail@web51015.mail.yahoo.com> Message-ID: Dear Pw_forum, As a new PWscf user, I appreciate its many capabilities. My question has to do with the use of the Parrinello-Rahman dynamics to optimize a cell while keeping the symmetry. In particular, we have hexagonal symmetry (ibrav=4) which apparently requires the lattice vectors to have the form (a,0,0), (-a/2, a*sqrt(3)/2,0) (0,0,c). On the first lattice move, this symmetry is broken and the program stops with the error message ' from checkallsym : error # 2 not orthogonal operation I am able to get past this error by making a slight change to vcsmd.f90, restoring the correct symmetry to the lattice vectors after the new ones have been calculated. However, this seems like cheating and hopefully there is a better method available. Thanks in advance for your advice. Natalie Holzwarth N. A. W. Holzwarth email: natalie at wfu.edu Department of Physics www: http://www.wfu.edu/~natalie Wake Forest University voice: 336-758-5510 Winston-Salem, NC 27109-7507 fax: 336-758-6142 U. S. A. From jasonsun98 at hotmail.com Sun Jan 8 08:01:14 2006 From: jasonsun98 at hotmail.com (sun jason) Date: Sun, 08 Jan 2006 07:01:14 +0000 Subject: [Pw_forum] about born effective charge tensors In-Reply-To: <20060108063516.3842.1629.Mailman@democritos.sissa.it> Message-ID: Dear all, I calculated the born effective charges of some crystals, I find in high symmetric systems, such as zincblende or wurtzite, the effective charge tensors are symmetric, but in the hexagonal crystal, the effective charge tensors of some atoms are not symmetric, the non-digonal components of the tensors are nonzero, as follow, atom13 and atom14 are symmetric but the others are not, does it bring by numerical errors ? the structure are fully relaxed. does it mean that the optimization is not accurate enough ? I'm not sure about whether the born effective charge tensor should be symmetric in crystals. Does it dependent on the structural symmetry of crystal itself ? ---------------------------------------------------------------------------- Effective charges E-U in cartesian axis atom 1 ( 2.74126 0.04349 0.00000 ) ( -0.01156 2.12774 0.00000 ) ( 0.00000 0.00000 2.00705 ) atom 2 ( 2.74535 0.04826 0.00000 ) ( -0.00889 2.12477 0.00000 ) ( 0.00000 0.00000 2.00768 ) atom 3 ( 2.29495 -0.24612 0.00000 ) ( -0.30117 2.57405 0.00000 ) ( 0.00000 0.00000 2.00705 ) atom 4 ( 2.29697 -0.24998 0.00000 ) ( -0.30714 2.57316 0.00000 ) ( 0.00000 0.00000 2.00768 ) atom 5 ( 2.26729 0.28520 0.00000 ) ( 0.23015 2.60171 0.00000 ) ( 0.00000 0.00000 2.00705 ) atom 6 ( 2.26287 0.28745 0.00000 ) ( 0.23030 2.60725 0.00000 ) ( 0.00000 0.00000 2.00768 ) atom 7 ( -1.89044 -0.46772 0.00000 ) ( -0.58373 -1.49548 0.00000 ) ( 0.00000 0.00000 -1.65545 ) atom 8 ( -1.88988 -0.46559 0.00000 ) ( -0.57784 -1.49690 0.00000 ) ( 0.00000 0.00000 -1.65530 ) atom 9 ( -2.04951 0.49189 0.00000 ) ( 0.37588 -1.33642 0.00000 ) ( 0.00000 0.00000 -1.65545 ) atom 10 ( -2.04696 0.48715 0.00000 ) ( 0.37490 -1.33982 0.00000 ) ( 0.00000 0.00000 -1.65530 ) atom 11 ( -1.13893 0.14984 0.00000 ) ( 0.03383 -2.24699 0.00000 ) ( 0.00000 0.00000 -1.65545 ) atom 12 ( -1.14332 0.14681 0.00000 ) ( 0.03457 -2.24346 0.00000 ) ( 0.00000 0.00000 -1.65530 ) atom 13 ( -2.21608 -0.24947 0.00000 ) ( 0.24947 -2.21608 0.00000 ) ( 0.00000 0.00000 -1.05841 ) atom 14 ( -2.21688 -0.25857 0.00000 ) ( 0.25857 -2.21688 0.00000 ) ( 0.00000 0.00000 -1.06086 ) ------------------------------------------------------------------------------ Thank you very much! Best regards, Jian SUN From haiw201 at gmail.com Mon Jan 9 04:19:15 2006 From: haiw201 at gmail.com (hai wang) Date: Mon, 9 Jan 2006 11:19:15 +0800 Subject: [Pw_forum] about born effective charge tensors In-Reply-To: References: <20060108063516.3842.1629.Mailman@democritos.sissa.it> Message-ID: <5641bb5d0601081919q79be9fft@mail.gmail.com> > > I'm not sure about whether the born effective charge tensor should be > symmetric in crystals. Does it dependent on the structural symmetry of > crystal itself ? ~~~~~~~~~ Born effective charge, alias transverse charge, can be computed from three different techniques (linear response, difference of polarization under finite atomic displacement, and difference of force under finite electric field ). Linear-response methods provide an efficient means for computing quantities that an be expressed as derivatives of the total energy E with respect to a perturbation, such as that produced by displacement via of an atom or a homogeneous electric field E. The effective charges are somewhat sensitive to the structural details, include the symmetric of crystals. Cubic local environments imply diagonal, isotropic Born effective charge. In non-cubic structures, it may be with off-diagonal components. For example, in the orthorhombic CaTiO3 structures, the relatively large off-diagonal components of the Ti Born effective charge tensors and their asymmetries were unexpected because the TiO6 octahedra are nearly ideal. The large offdiagonal components show that Born effective charge is not determined solely by nearest-neighbor Ti-O interactions, but is strongly influenced by further-neighbor interactions which more strongly break cubic symmetry(PRB62,3735). -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060109/346cfab5/attachment.htm From giannozz at nest.sns.it Mon Jan 9 09:30:48 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 9 Jan 2006 09:30:48 +0100 Subject: [Pw_forum] about born effective charge tensors In-Reply-To: References: Message-ID: <200601090930.48932.giannozz@nest.sns.it> On Sunday 08 January 2006 08:01, sun jason wrote: > I'm not sure about whether the born effective charge tensor > should be symmetric in crystals. in general they aren't. Note that the two indices refer to different things: the first to electric field polarization, the second to atomic displacement. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From resul at ibu.edu.tr Mon Jan 9 09:48:18 2006 From: resul at ibu.edu.tr (Resul Eryigit) Date: Mon, 9 Jan 2006 10:48:18 +0200 Subject: [Pw_forum] about born effective charge tensors References: Message-ID: <002001c614f9$705dde50$b001190a@aibu13bddvokde> > I'm not sure about whether the born effective charge tensor should be > symmetric in crystals. Does it dependent on the structural symmetry of > crystal itself ? > the exact form of the Born effective charge tensor is determined by the site symmetry of the atom..if you have site symmetry information, you can check,for example, A. S. Nowick's Crystal Properties via Group Theory to see if the form of the tensor you have calculated is whats supposed to be on the symmetry grounds. From giannozz at nest.sns.it Mon Jan 9 10:07:39 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 9 Jan 2006 10:07:39 +0100 Subject: [Pw_forum] Variable-cell optimization with constraints In-Reply-To: References: <20060107161517.43309.qmail@web51015.mail.yahoo.com> Message-ID: <200601091007.39329.giannozz@nest.sns.it> On Saturday 07 January 2006 21:50, Natalie Holzwarth wrote: > My question has to do with the use of the Parrinello-Rahman dynamics > to optimize a cell while keeping the symmetry. In particular, we have > hexagonal symmetry (ibrav=4) which apparently requires the lattice > vectors to have the form (a,0,0), (-a/2, a*sqrt(3)/2,0) (0,0,c). On the > first lattice move, this symmetry is broken and the program stops with > the error message > from checkallsym : error # 2 > not orthogonal operation from the users'guide: -- Variable-cell optimization may occasionally break the starting symmetry of the cell. When this happen, the run is stopped because the number of k-points calculated for the starting configuration may no longer be suitable. Possible solutions: - start with a nonsymmetric cell - use a symmetry-conserving algorithm: the Wentzcovitch algorithm ("cell_dynamics='damp-w'") shouldn't break the symmetry. -- Note that the current 'stable' version has a bug that causes this same 'non orthogonal operation' error when restarting from a previous run in a variable-cell optimization. This should be fixed in the CVS version. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From mutombo at fzu.cz Mon Jan 9 16:34:00 2006 From: mutombo at fzu.cz (Pingo Mutombo) Date: Mon, 09 Jan 2006 10:34:00 -0500 Subject: [Pw_forum] syntax error In-Reply-To: <200601090930.48932.giannozz@nest.sns.it> References: <200601090930.48932.giannozz@nest.sns.it> Message-ID: <43C28268.9050305@fzu.cz> Hello, I am trying to compile the new espresso package at a workstation with a SUN architecture . I am getting the following syntax error message connected with "addusdens.F90" : test -d bin || mkdir bin if test -d iotk ; then \ ( cd iotk ; if test "" = "" ; then make TLDEPS= libiotk.a ; \ else TLDEPS= libiotk.a ; fi ) ; fi cd src ; make libiotk.a `libiotk.a' is up to date. ( cd Modules ; if test "" = "" ; then make TLDEPS= all ; \ else TLDEPS= all ; fi ) ( cd clib ; if test "" = "" ; then make TLDEPS= all ; \ else TLDEPS= all ; fi ) ( cd flib ; if test "" = "" ; then make TLDEPS= all ; \ else TLDEPS= all ; fi ) if test -d PW ; then \ ( cd PW ; if test "" = "" ; then make TLDEPS= all ; \ else TLDEPS= all ; fi ) ; fi fpp -P -D__SUN -D__PARA -D__MPI -DHAS_ZHEGVX -I../include addusdens.f90 addusdens.F 90 f90 -I/opt/SUNWhpc/include -fast -xchip=ultra3 -xarch=v8plusb -stackvar -xlic_lib=s unperf -M../Modules -M../PW -M../PH -c addusdens.F90 -o addusdens.o rho (:, is) = rho (:, is) + @@_use_DBLE_instead@@& ^ "addusdens.F90", Line = 202, Column = 34: ERROR: Unexpected syntax: "operand" was expected but found "@". f90comp: 210 SOURCE LINES f90comp: 1 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 0 ANSI *** Error code 1 make: Fatal error: Command failed for target `addusdens.o' Any help will be greatly appreciated. Best wishes, Pingo From giannozz at nest.sns.it Mon Jan 9 10:42:58 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 9 Jan 2006 10:42:58 +0100 Subject: [Pw_forum] phonon modes assignment and others In-Reply-To: <20060107161517.43309.qmail@web51015.mail.yahoo.com> References: <20060107161517.43309.qmail@web51015.mail.yahoo.com> Message-ID: <200601091042.58128.giannozz@nest.sns.it> On Saturday 07 January 2006 17:15, W. YU wrote: > 1. Is there an easy or not so easy way to assign the > different modes from the phonon calculation results to > the various irreducible representations? no easy way, only not-so-easy ways. Once upon a time I wrote a small code that did exactly that for molecular fullerene C60, but it is a special case in which most modes can be identified by their parity and degeneracy; the remaining ones by some simple tricks. I vaguely remember that somebody sent a pointer to some general code for irrep calculation, but I couldn't find the message. > 2. When I use dynmat.x to extract normal mode eigen > vectors for the Gamma point, the results seems to be > different from those given by the phonon output. dynmat.x writes the eigendisplacements (u = v/M^{-1/2}), not the eigenmodes (v) > 3. When doing phonon calculation, we are not using > supercell, but I know q2r does account for the > interactions among different neighbours. Then is it > possible for me to know exactly up to which nearest > neighbour is included in the calculation? your q-point grid is equivalent to (i.e. it is the reciprocal lattice of) a supercell in R-space. The range of neighbours included in the calculation depends on the size of this supercell Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From katalin.gaal-nagy at physik.uni-regensburg.de Mon Jan 9 11:27:25 2006 From: katalin.gaal-nagy at physik.uni-regensburg.de (Katalin Gaal-Nagy) Date: Mon, 9 Jan 2006 11:27:25 +0100 (CET) Subject: [Pw_forum] =?iso-8859-1?Q?Re=3A_=5BPw=5Fforum=5D_Re=3A_=5BPw=5Fforum=5D_=BB?= =?iso-8859-1?Q?=D8=B8=B4=A3=BA_Re=3A_=5BPw=5Fforum=5D_negtive_val?= =?iso-8859-1?Q?ues_for_TA__when_using_q2r=2Ex?= In-Reply-To: <20060107140451.49768.qmail@web60321.mail.yahoo.com> References: <20060107140451.49768.qmail@web60321.mail.yahoo.com> Message-ID: Hi Eyvaz, thanks for the answer! > I just suggested that an unstable mode near Gamma > point might be a result of incorrectly determined > dynamical matrix (and then unstable mode) at X point, > and consequently, force constants obtained by q2r.x > are also not correct. I am not sure that you will be > able to get correct behavior of the phonon spectrum > (obtained using matdyn.x) with wrong interatomic force > constants. Are not you agree with this? Of course, I agree with this. I just assumed that the unstable mode at X is correct and the error is just close to Gamma, which can be quite reasonable (it was like this in my case). But of course, I was overlooking that it could be seen also in the opposite way. Best wishes, Katalin From sclauzer at sissa.it Mon Jan 9 11:11:53 2006 From: sclauzer at sissa.it (Gabriele Sclauzero) Date: Mon, 09 Jan 2006 11:11:53 +0100 Subject: [Pw_forum] about phonon calculations In-Reply-To: <200512241928464948382@pku.edu.cn> References: <200512241928464948382@pku.edu.cn> Message-ID: <43C236E9.7090806@sissa.it> The same happened to me when running ph.x on parallel AMD machines at SISSA's opteron cluster. I tried to run "example06" in the examples that come with the 3.0 espresso package: the ph calculation works when using a single cpu, but hangs up while calculating alas.dyn3 as soon as I try to use more then 1 cpu. Regards, Gabriele Hai-Ping Lan wrote: > Dear Colleagues : > > I have compiled ESPRESSO 2.1.5 package in AMD operon workstations. > But i cannot perform phonon calculations parallelly. > Would anyone else have happened to this problem? From giannozz at nest.sns.it Mon Jan 9 12:10:26 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 9 Jan 2006 12:10:26 +0100 Subject: [Pw_forum] syntax error In-Reply-To: <43C28268.9050305@fzu.cz> References: <200601090930.48932.giannozz@nest.sns.it> <43C28268.9050305@fzu.cz> Message-ID: <200601091210.26488.giannozz@nest.sns.it> On Monday 09 January 2006 16:34, Pingo Mutombo wrote: > I am getting the following syntax error message connected with > "addusdens.F90" : [...] > rho (:, is) = rho (:, is) + @@_use_DBLE_instead@@& do not mix different versions unless you know what you are doing -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From yonasb at yahoo.com Mon Jan 9 16:02:04 2006 From: yonasb at yahoo.com (Yonas Abraham) Date: Mon, 9 Jan 2006 07:02:04 -0800 (PST) Subject: [Pw_forum] Variable-cell optimization with constraints In-Reply-To: <200601091007.39329.giannozz@nest.sns.it> Message-ID: <20060109150204.14154.qmail@web32002.mail.mud.yahoo.com> > > from the users'guide: > -- > Variable-cell optimization may occasionally break > the starting > symmetry of the cell. When this happen, the run is > stopped > because the number of k-points calculated for the > starting > configuration may no longer be suitable. Possible > solutions: > - start with a nonsymmetric cell > - use a symmetry-conserving algorithm: the > Wentzcovitch > algorithm ("cell_dynamics='damp-w'") shouldn't break > the symmetry. > -- Hi Paolo, Your replay is very helpful, But I am not sure if your quote actually exist on the user guide. I have searched at http://www.pwscf.org/guide/3.0/html-single/manual.html and on the tex files included with the release and can't find it either. Just curious that there are not more than one user-guides. thanks /yonas From giannozz at nest.sns.it Mon Jan 9 16:25:53 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 9 Jan 2006 16:25:53 +0100 Subject: [Pw_forum] Variable-cell optimization with constraints In-Reply-To: <20060109150204.14154.qmail@web32002.mail.mud.yahoo.com> References: <20060109150204.14154.qmail@web32002.mail.mud.yahoo.com> Message-ID: <200601091625.53178.giannozz@nest.sns.it> On Monday 09 January 2006 16:02, Yonas Abraham wrote: > I have searched at > http://www.pwscf.org/guide/3.0/html-single/manual.html > and on the tex files included with the release and > can't find it either. Just curious that there are not > more than one user-guides. it is in the CVS version of the users' guide P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From naromero at gmail.com Mon Jan 9 23:54:26 2006 From: naromero at gmail.com (Nichols A. Romero) Date: Mon, 9 Jan 2006 17:54:26 -0500 Subject: [Pw_forum] cp with metals In-Reply-To: <20051123165142.61986.qmail@web52014.mail.yahoo.com> References: <438345A0.5050205@sissa.it> <20051123165142.61986.qmail@web52014.mail.yahoo.com> Message-ID: <6ac064b60601091454l5c588289o91afb737b0ad7faa@mail.gmail.com> Nicola, A couple of questions and comments In example 29, 1. The example runs, but gives the message: degauss is not use in CP Is it ignoring the flag completely in the ensemble DFT? 2. The example does not work when emass and emass_cutoff are commented out. Those arguments shouldn't be necessary if you are doing BO instead of CP in the ensemble DFT. 3. Hypothetically speaking, I should be able to do BO without the ensemble DFT in the CP code if I was dealing with an insulator. Using the Gram-Schmidt and CG, diagonalization options. Thanks, On 11/23/05, Konstantin Kudin wrote: > Hi all, > > I'd like to point out that electronic thermostats is a pretty > dangeorous thing to use for any production calculations unless one > really knows what is going on there. > > The main issue is that there is usually some "natural" fictitious > kinetic energy that electrons gain from the ionic motion ("drag"). One > could easily quantify how much of the fictitious energy comes from this > drag by doing a CP run, then a couple of CG (same as BO) steps, and > then going back to CP. The fictitious electronic energy at the last CP > restart will be purely due to the drag effect. > > The thermostat on electrons will either try to overexcite the > otherwise "cold" electrons, or, will try to take them down to an > unnaturally cold state where their fictitious kinetic energy is even > below what would be just due pure drag. Neither of this is good. > > I think the only workable regime with an electronic thermostat is a > mild overexcitation of the electrons, however, to do this one will need > to know rather precisely what is the fictititious kinetic energy due to > the drag. > > Kostya > > > --- Davide Ceresoli wrote: > > > Nichols A. Romero wrote: > > > Hi, > > > > > > How does the Car-Parinello MD code in the ESPRESSO package handle > > > metallic cases? Does it implement the method by Blochl et. al PRB > > 45, > > > 9413 (1992). > > > > > Yes, in namelist &electrons: > > electron_temperature = 'nose' or 'rescaling' > > > > Best, > > Davide > > > > > __________________________________ > Yahoo! FareChase: Search multiple travel sites in one click. > http://farechase.yahoo.com > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > -- Dr. Nichols A. Romero, PhD. 1613 Denise Dr. Apt. D Forest Hill, MD 21050 443-567-8328 (C) 410-306-0709 (O) From eyvaz_isaev at yahoo.com Tue Jan 10 00:10:12 2006 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Mon, 9 Jan 2006 15:10:12 -0800 (PST) Subject: [Pw_forum] phonon modes assignment and others In-Reply-To: <200601091042.58128.giannozz@nest.sns.it> Message-ID: <20060109231012.75216.qmail@web60311.mail.yahoo.com> Hi Paolo, --- Paolo Giannozzi wrote: > I vaguely remember that somebody sent > a pointer to some general code for irrep calculation, but I > couldn't find the message. Presumably you mean the ISOTROPY code from http://stokes.byu.edu/iso/isotropy.html Bests, Eyvaz. __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From yuss at jlu.edu.cn Tue Jan 10 10:49:22 2006 From: yuss at jlu.edu.cn (yuss at jlu.edu.cn) Date: Tue, 10 Jan 2006 17:49:22 +0800 Subject: [Pw_forum] Comparison between PWSCFand WanT? Message-ID: <1136886562.43c3832230e48@mail.ctosoft.com> Dear all: I know that PWSCF can study the transport of nanostructure using PWCOND.X, but what are difference between it and WanT? Thanks, s.s.yu From yuwen_66 at yahoo.com Tue Jan 10 09:04:46 2006 From: yuwen_66 at yahoo.com (W. YU) Date: Tue, 10 Jan 2006 00:04:46 -0800 (PST) Subject: [Pw_forum] Re: phonon modes assignment and others In-Reply-To: <20060109063510.5142.6507.Mailman@democritos.sissa.it> Message-ID: <20060110080446.4370.qmail@web51004.mail.yahoo.com> Thanks to Paolo and Eyvaz, >> 1. Is there an easy or not so easy way to assign the >> different modes from the phonon calculation results to >> the various irreducible representations? > no easy way, only not-so-easy ways. Once upon a time I wrote > a small code that did exactly that for molecular fullerene C60, > but it is a special case in which most modes can be identified > by their parity and degeneracy; the remaining ones by some > simple tricks. I vaguely remember that somebody sent a pointer > to some general code for irrep calculation, but I couldn't find the > message Any further remarks on the method you used would be much appreciated.! It seems completely two different things for me to have a space group in mind and know what irreducible representations are associated with it or on the contrary, to have a set of mormal vectors for specific lattice mode and find to which irreducible representation they belongs. Best regards, Wen YU __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From ferretti.andrea at unimore.it Tue Jan 10 12:30:04 2006 From: ferretti.andrea at unimore.it (Andrea Ferretti) Date: Tue, 10 Jan 2006 12:30:04 +0100 (CET) Subject: [Pw_forum] Comparison between PWSCFand WanT? In-Reply-To: <1136886562.43c3832230e48@mail.ctosoft.com> References: <1136886562.43c3832230e48@mail.ctosoft.com> Message-ID: On Tue, 10 Jan 2006 yuss at jlu.edu.cn wrote: > Dear all: > I know that PWSCF can study the transport of nanostructure using PWCOND.X, > but what are difference between it and WanT? > Thanks, > s.s.yu > _______________________________________________ Hi all, as far as I know, the two methods compute ballistic transport according to landauer formalism... this means that transport is directly related to the scattering probelm which should be solved... while PWCOND.X performs this task by computing the complex band structure of the "conductor region" (in the plane-wave pseudopot approach of espresso), WanT adopts Marzari-Vanderbilt "maximally localized" Wannier functions as a localized basis set and manages a real-space matrix green function approach (according to the Fisher-Lee expression for Landauer formula) basically WanT starts from the standard (kohn-sham) electronic structure as computed by espresso and performs the calculation of Waniner functions as well as of the KS hamiltonian representation on this basis... At this point you are able to match the conductor region to the lead regions, compute lead self-energies and final evaluate the transmittance across the conductor.. I am sure that Andrea Dal Corso or Francesco Antoniella (and probably many others) can add much more detail about the pwcond.x approach... regards Andrea From degironc at sissa.it Tue Jan 10 12:22:48 2006 From: degironc at sissa.it (Stefano de Gironcoli) Date: Tue, 10 Jan 2006 12:22:48 +0100 Subject: [Pw_forum] Re: phonon modes assignment and others References: <20060110080446.4370.qmail@web51004.mail.yahoo.com> Message-ID: <43C39908.1090805@sissa.it> Please take a book on group theory and look for irreducible representations ... If you have a set of patterns that belong to an irreducible representation (say U^mu_i, where i is the atom index and mu the partner index in the representation) what you need to do in general is to compute the way they transform under symmetry operations. If S is the symmetry operation , its action on a given pattern will transform it in a linear combination of its partners S ( U^mu_i) = \sum_nu D(S)_mu,nu U^nu_i Compute the trace of D(S) (the characteristics of the representation) and apply the orthogonality theorem you find in group theory books to discover which representation you are dealing with. stefano W. YU wrote >Any further remarks on the method you used would be >much appreciated.! It seems completely two different >things for me to have a space group in mind and know >what irreducible representations are associated with >it or on the contrary, to have a set of mormal vectors >for specific lattice mode and find to which >irreducible representation they belongs. > > > From ferretti.andrea at unimore.it Tue Jan 10 16:36:15 2006 From: ferretti.andrea at unimore.it (Andrea Ferretti) Date: Tue, 10 Jan 2006 16:36:15 +0100 (CET) Subject: [Pw_forum] symmetries in pw.x Message-ID: Dear all, I went through a problem with symmetries and I would like to better understand how they actually work in espresso (pw.x particularly): as far as I understand, in scf calculation both time-reversal and space-group symmetries are used to define the irreducible wedge in the BZ in order to compute BZ sums (total energy, charge density etc...). my question is about non-self consistent calculations: what I expected is that no symmetrization should be performed (e.g. when I compute band structure for silicon along a specific symmetry line it makes no sense to me to define weights and so on...). therefore I guess that nosym = .TRUE. should be effectiveless in nscf calculations, while I have been reported about the contrary... the problem seems to be connected with weights, which, even if not used (I guess) in nscf are anyway internally calculated and reported in the output file... is it an expected behavior ?? (sorry, at the moment I have no input file at hand demonstrating the fact, but if needed I will provide it as soon as possible...) my question is at this point about the actual implementation of symmetrization (and nosym) both in scf and nscf calculations... can anyone comment on this point ?? by the way: setting nosym = .TRUE. together with automatic generated kpt meshes make some symmetry reduction in kptnumber anyway: I guess it is due to the time-reversal symmetrization which is still around... is it true ?? sorry for the long email, and thanks for any support... cheers Andrea -- Andrea Ferretti INFM National Research Center on nanoStructures and bioSystems at Surfaces (S3) Dipartimento di Fisica, Universita' di Modena e Reggio Emilia Via Campi 213/A I-41100 Modena, Italy Tel: +39 059 2055283 Fax: +39 059 374794 E-mail: ferretti.andrea at unimore.it URL: http://www.nanoscience.unimo.it Please, if possible, don't send me MS Word or PowerPoint attachments Why? See: http://www.gnu.org/philosophy/no-word-attachments.html From giannozz at nest.sns.it Tue Jan 10 19:15:35 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 10 Jan 2006 19:15:35 +0100 Subject: [Pw_forum] symmetries in pw.x In-Reply-To: References: Message-ID: <200601101915.35199.giannozz@nest.sns.it> On Tuesday 10 January 2006 16:36, Andrea Ferretti wrote: > my question is about non-self consistent calculations: > what I expected is that no symmetrization should be performed > (e.g. when I compute band structure for silicon along a specific > symmetry line it makes no sense to me to define weights and so on...). it is not that simple: there are cases in which you may want a grid in the IBZ, such as for instance to calculate the DOS, or phonons at a finite q-vector. Presently the number of input k-points is left unchanged if there is no evidence of further processing, such as tetrahedron, gaussian broadening, q-vector for phonons etc, in the input data for the nonscf run > therefore I guess that nosym = .TRUE. should be effectiveless 'effective' or 'effectless'? nosym=.true. does not do what its name would suggest, i.e. increase the number of k-points because symmetry is not used; it actually prevents the increase of the number of k-points with reduced symmetry. It does, or should do, what is explicitly stated in the INPUT_PW file. I am quite dissatisfied with the present implementation of the k-point+symmetry stuff: it is a stratification of different approaches, and it shows. If you want to try to disentangle this mess, PW/setup.f90 is the place to start from Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From naromero at gmail.com Tue Jan 10 23:57:36 2006 From: naromero at gmail.com (Nichols A. Romero) Date: Tue, 10 Jan 2006 17:57:36 -0500 Subject: [Pw_forum] BO dynamics in CP code Message-ID: <6ac064b60601101457x3ce1b1acu32d94b994d6eafdf@mail.gmail.com> Hi, This may seem like an odd question to ask, but is one doing BO dynamics instead of Car-Parinello by setting the following in the CP input file electron_dynamics = 'cg' orthogonzaliation = 'Gram-Schmidt' tcg = true Thanks, -- Dr. Nichols A. Romero, PhD. 1613 Denise Dr. Apt. D Forest Hill, MD 21050 443-567-8328 (C) 410-306-0709 (O) From chaohao2002 at 163.com Wed Jan 11 03:11:37 2006 From: chaohao2002 at 163.com (Chaohao Hu) Date: Wed, 11 Jan 2006 10:11:37 +0800 Subject: [Pw_forum] Be pseudopotential Message-ID: <43C46C20.0A84AF.05870> Dear Espresso users, Can anybody provide me an ultrasoft pseudopotential for Beryllium(Be) in GGA approximation? Now I need it, but I can not find it in PWSCF web. From giannozz at nest.sns.it Wed Jan 11 18:27:57 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 11 Jan 2006 18:27:57 +0100 Subject: [Pw_forum] problem with ph.x In-Reply-To: References: Message-ID: <200601111827.57468.giannozz@nest.sns.it> On Thursday 08 December 2005 16:19, Konzern wrote: > when I tried to run the example in example06, something unexpected > happened [..] I am running the program with 4 cpus On Saturday 24 December 2005 12:28, Hai-Ping Lan wrote: > > I have compiled ESPRESSO 2.1.5 package in AMD operon > workstations. But i cannot perform phonon calculations parallely. On Monday 09 January 2006 11:11, Gabriele Sclauzero wrote: > I tried to run "example06" in the examples that come with the 3.0 > espresso package: the ph calculation works when using a single cpu, > but hangs up while calculating alas.dyn3 as soon as I try to use more > then 1 cpu. there was a subtle bug in the phonon code that could lead to crashes in parallel execution (and some loss of precision in serial execution). Save the attached file to the root directory of the 3.0 distribution (the one containing PH/) and use command "patch -p0 < phonon.diff". This should produce a patched version of PH/phonon.f90 that fixes the problem with example06. I don't know about the second case, but I think that the 2.1.5 version has the same problem (but needs a different fix) Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy -------------- next part -------------- A non-text attachment was scrubbed... Name: phonon.diff Type: text/x-diff Size: 1263 bytes Desc: not available Url : /pipermail/attachments/20060111/d7f6c2a0/attachment.diff From stewart at cnf.cornell.edu Wed Jan 11 20:56:37 2006 From: stewart at cnf.cornell.edu (stewart at cnf.cornell.edu) Date: Wed, 11 Jan 2006 14:56:37 -0500 Subject: [Pw_forum] Run-time error with pw.x when compiled with Intel 9.0 In-Reply-To: <200601101915.35199.giannozz@nest.sns.it> References: <200601101915.35199.giannozz@nest.sns.it> Message-ID: <20060111195637.5386.qmail@xuxa.iecc.com> Hi all, I am trying to get the espresso 3.0 package to work with the Intel 9.0 compilers. I have been able to get everything to compile correctly, but then I run into a problem when I run pw.x on the simple systems in example 1. Basically, the scf calculation stops with the complaint: from cfts_3 : error # 1 routine called by wrong architecture Looking back through the archive, it appears that Sergey Lisenkov had this same problem and was able to solve it by using the gnu cpp for preprocessing during the compile. I have tried this and I still run into the same problem. If someone has a sucessful make.sys file that has worked with Intel 9.0 compilers, I would be interested in seeing it. Thanks, Derek ################################ Derek Stewart, Ph. D. Scientific Computation Associate 250 Duffield Hall Cornell Nanoscale Facility (CNF) Ithaca, NY 14853 stewart (at) cnf.cornell.edu (607) 255-2856 From proffess at yandex.ru Wed Jan 11 21:04:45 2006 From: proffess at yandex.ru (Sergey Lisenkov) Date: Wed, 11 Jan 2006 23:04:45 +0300 (MSK) Subject: [Pw_forum] Run-time error with pw.x when compiled with Intel 9.0 In-Reply-To: <20060111195637.5386.qmail@xuxa.iecc.com> References: <20060111195637.5386.qmail@xuxa.iecc.com> Message-ID: <43C564DD.000006.12909@webmail9.yandex.ru> Hi, Derek! Yes, I had this problem some times ago with using Intel 9.0 compiler (latest patch) on all machines where Intel fortran 9.0 can be used (Xeon, Opteron, Altix). But using "/lib/cpp" and these settings: .SUFFIXES : .SUFFIXES : .o .c .f .f90 .f90.o: $(CPP) $(CPPFLAGS) $< -o $*.F90 $(MPIF90) $(F90FLAGS) -c $*.F90 -o $*.o CPP = /lib/cpp CPPFLAGS = -P -C -traditional $(DFLAGS) $(IFLAGS) everything is working correctly. Thanks, Sergey From stewart at cnf.cornell.edu Wed Jan 11 21:30:36 2006 From: stewart at cnf.cornell.edu (stewart at cnf.cornell.edu) Date: Wed, 11 Jan 2006 15:30:36 -0500 Subject: [Pw_forum] Re: Run-time error with pw.x when compiled with Intel 9.0 In-Reply-To: <43C564DD.000006.12909@webmail9.yandex.ru> References: <20060111195637.5386.qmail@xuxa.iecc.com> <43C564DD.000006.12909@webmail9.yandex.ru> Message-ID: <20060111203036.18305.qmail@xuxa.iecc.com> Hi Sergey, Thanks for the fast response. Those changes to the make.sys file appear to have done the trick! Derek Sergey Lisenkov writes: > Hi, Derek! > > Yes, I had this problem some times ago with using Intel 9.0 compiler (latest patch) on all machines where Intel fortran 9.0 can be used (Xeon, Opteron, Altix). > > But using "/lib/cpp" and these settings: > > .SUFFIXES : > .SUFFIXES : .o .c .f .f90 > > .f90.o: > $(CPP) $(CPPFLAGS) $< -o $*.F90 > $(MPIF90) $(F90FLAGS) -c $*.F90 -o $*.o > > CPP = /lib/cpp > CPPFLAGS = -P -C -traditional $(DFLAGS) $(IFLAGS) > > everything is working correctly. > > Thanks, > Sergey > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum ################################ Derek Stewart, Ph. D. Scientific Computation Associate 250 Duffield Hall Cornell Nanoscale Facility (CNF) Ithaca, NY 14853 stewart (at) cnf.cornell.edu (607) 255-2856 From yuwen_66 at yahoo.com Thu Jan 12 04:24:46 2006 From: yuwen_66 at yahoo.com (W. YU) Date: Wed, 11 Jan 2006 19:24:46 -0800 (PST) Subject: [Pw_forum] phonon branch crossing problem In-Reply-To: <20060110063510.10326.94659.Mailman@democritos.sissa.it> Message-ID: <20060112032446.37056.qmail@web51012.mail.yahoo.com> Thank you stefano for answering my questions. Now I have a question about the crossing of the phonon branches. I know there are some rules govening the phonon branch crossing such as branches belonging to the same irrep will not cross each other. I don't know how PHONON manages this problem. I have never seen any crossing(in the sense of my understanding) of the dispersion curves calculated by PHONON, only tangent touching. But some of the experimental results did indicate crossing of the curves. Could anyone give some comments on this? Thanks! W. YU __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From yuwen_66 at yahoo.com Thu Jan 12 04:59:37 2006 From: yuwen_66 at yahoo.com (W. YU) Date: Wed, 11 Jan 2006 19:59:37 -0800 (PST) Subject: [Pw_forum] difference from the output of dynmat.x and Phonon dyn file In-Reply-To: <20060111063509.24942.1571.Mailman@democritos.sissa.it> Message-ID: <20060112035937.54851.qmail@web51011.mail.yahoo.com> >> 2. When I use dynmat.x to extract normal mode eigen >> vectors for the Gamma point, the results seems to be >> different from those given by the phonon output. >dynmat.x writes the eigendisplacements (u = v/M^{-1/2}), >not the eigenmodes (v) >Paolo Dear Paolo, from the results of my calcualtion, I found the difference between the two outputs are not connected by a factor of M^{-1/2}). For some modes they are almost the same, such as modes 12. But for others they differ a lot, such as mode 4. The subtle difference in mode 4 may come from the accoustic sum rule. These two modes from the two different outputs are attached as follows: omega( 4) = 3.079894 [THz] = 102.734886 [cm-1] ( 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 ) ( 0.000000 0.000000 -0.671017 0.000000 -0.106563 0.000000 ) ( 0.195909 0.000000 0.000000 0.000000 0.106563 0.000000 ) ( -0.195909 0.000000 0.671017 0.000000 0.000000 0.000000 ) *************************************************************************** omega( 4) = 2.991272 [THz] = 99.778750 [cm-1] ( 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 ) ( 0.000000 0.000000 0.314642 0.000000 0.443209 0.000000 ) ( 0.452290 0.000000 0.000000 0.000000 -0.443209 0.000000 ) ( -0.452290 0.000000 -0.314642 0.000000 0.000000 0.000000 ) =========================================================================== ************************************************************************** omega(12) = 24.349582 [THz] = 812.220022 [cm-1] ( 0.973708 0.000000 0.003713 0.000000 0.000000 0.000000 ) ( -0.227577 0.000000 0.000025 0.000000 0.000000 0.000000 ) ( 0.006581 0.000000 -0.000868 0.000000 0.000000 0.000000 ) ( 0.006581 0.000000 0.000025 0.000000 0.000000 0.000000 ) ************************************************************************** omega(12) = 24.337573 [THz] = 811.819463 [cm-1] ( 0.973665 0.000000 -0.001802 0.000000 0.000000 0.000000 ) ( -0.227786 0.000000 -0.000012 0.000000 0.000000 0.000000 ) ( 0.006586 0.000000 0.000422 0.000000 0.000000 0.000000 ) ( 0.006586 0.000000 -0.000012 0.000000 0.000000 0.000000 ) ************************************************************************** Thanks, W. YU __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From giannozz at nest.sns.it Thu Jan 12 10:10:26 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 12 Jan 2006 10:10:26 +0100 Subject: [Pw_forum] phonon branch crossing problem In-Reply-To: <20060112032446.37056.qmail@web51012.mail.yahoo.com> References: <20060112032446.37056.qmail@web51012.mail.yahoo.com> Message-ID: <200601121010.26932.giannozz@nest.sns.it> On Thursday 12 January 2006 04:24, W. YU wrote: > I know there are some rules govening the phonon branch crossing > such as branches belonging to the same irrep will not cross each other. > I don't know how PHONON manages this problem. it doesn't. Once you have the force constants, you can calculate eigenvalues with the correct symmetry at any q-vector. How to connect the points into lines of well-defined symmetry is a different problem. There is a tool that does this for electonic band structures, but not for phonons. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Thu Jan 12 10:16:37 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 12 Jan 2006 10:16:37 +0100 Subject: [Pw_forum] difference from the output of dynmat.x and Phonon dyn file In-Reply-To: <20060112035937.54851.qmail@web51011.mail.yahoo.com> References: <20060112035937.54851.qmail@web51011.mail.yahoo.com> Message-ID: <200601121016.37071.giannozz@nest.sns.it> On Thursday 12 January 2006 04:59, W. YU wrote: > I found the difference between the two outputs are not > connected by a factor of M^{-1/2}). For some modes they > are almost the same, such as modes 12. But for others > they differ a lot, such as mode 4. The subtle difference in > mode 4 may come from the accoustic sum rule. low-lying modes with low energy tend to have a sizable admixture of the zero-ferquency translational mode, so it is quite likely that upon application of the acoustic sum rule they look somewhat different. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From marzari at MIT.EDU Thu Jan 12 14:02:14 2006 From: marzari at MIT.EDU (Nicola Marzari) Date: Thu, 12 Jan 2006 08:02:14 -0500 Subject: [Pw_forum] cp with metals In-Reply-To: References: <438345A0.5050205@sissa.it> <20051123165142.61986.qmail@web52014.mail.yahoo.com> <6ac064b60601091454l5c588289o91afb737b0ad7faa@mail.gmail.com> <43C6463E.60707@mit.edu> Message-ID: <43C65356.7060501@mit.edu> Dear Nicholas, et al - thanks for pointing out some of the inconsistencies in the CG/CP parser - it's being updated, so hopefully with the new release we'll be in good shape. As always, do let us know of any problems you might find. Best, nicola Paolo Umari wrote: > Dear all, > > these are some minor problems due to the double CG/CP > nature of the parser: > In any case they do not affect the results of calculations > > 1- degauss is effectively used in CG+eDFT > the warning was intended only for CP runs > > 2- this is because CP needs them and the parser is the same > However, emass_cutoff is required in CG for setting > the kinetic energy preconditioning > > 3-Yes > > > The parser will be updated with the new verison of the code, > which should be release during the following week. > This version will contain a much faster CG algorithm for > BO simulation with and without eDFT, which is > already available in the CVS. > > > Paolo > --------------------------------------------------------------------- Prof Nicola Marzari Department of Materials Science and Engineering 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu From swblelia at sw.ehu.es Thu Jan 12 16:17:21 2006 From: swblelia at sw.ehu.es (Aritz Leonardo) Date: Thu, 12 Jan 2006 16:17:21 +0100 Subject: [Pw_forum] execution error Message-ID: <1137079041.19618.12.camel@swpc50.sw.ehu.es> Hello all: I am running for the first time ESPRESSO in a cluster of xserveG5 with MAC OSX. The compilation went ok, I am able to run the examples of the package. Then I try to run other very simple 'scf' scripts WHICH I AM COMPLETELY SURE THAT they are correctly typed and I find the following error at execution. I am 99% sure that it is an error of the cluster configuration but in order to fix it I would like to know... What is the meaning of error#1 ?????? Parallel version (MPI) Number of processors in use: 1 Ultrasoft (Vanderbilt) Pseudopotentials Current dimensions of program pwscf are: ntypx = 10 npk = 40000 lmax = 3 nchix = 6 ndmx = 2000 nbrx = 14 nqfx = 8 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from read_namelists : error # 1 reading namelist control %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% THANKS!!!!!!! From Alain.Allouche at up.univ-mrs.fr Thu Jan 12 16:34:00 2006 From: Alain.Allouche at up.univ-mrs.fr (Alain Allouche) Date: Thu, 12 Jan 2006 16:34:00 +0100 Subject: [Pw_forum] (no subject) Message-ID: <43C676E8.9000708@up.univ-mrs.fr> Dear all, I am trying to perform a temperature rescaling MD with PWscf &IONS ion_dynamics = 'verlet' ion_temperature = 'rescaling' tempw = 500.0 nraise = 1 tolp = 1.d-8 wfc_extrapolation = 'first_order' / The starting temperature is correct but it decreases very rapidly 358: Starting temperature = 500.00 K 405: temperature = 496.70493449 K 693: temperature = 0.24166052 K 903: temperature = 0.21332563 K 1113: temperature = 0.18863928 K 1323: temperature = 0.16711531 K 1533: temperature = 0.14835294 K 1743: temperature = 0.13194319 K 1953: temperature = 0.11759977 K 2163: temperature = 0.10503616 K 2373: temperature = 0.09401538 K 2583: temperature = 0.08433571 K 2793: temperature = 0.07582100 K 3003: temperature = 0.06832018 K 3213: temperature = 0.06170251 K 3423: temperature = 0.05585484 K 3633: temperature = 0.05067925 K 3843: temperature = 0.04609150 K 4053: temperature = 0.04201768 K 4263: temperature = 0.03839409 K 4473: temperature = 0.03516576 K 4683: temperature = 0.03228480 K The question is: what is the printed values ? the real scaled temperature, the temperature "before" scaling, the difference between the the calculated and the wanted temperature ? Thanks for your help -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060112/d92c67ff/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Alain.Allouche.vcf Type: text/x-vcard Size: 530 bytes Desc: not available Url : /pipermail/attachments/20060112/d92c67ff/attachment.vcf From sclauzer at sissa.it Thu Jan 12 16:47:01 2006 From: sclauzer at sissa.it (Gabriele Sclauzero) Date: Thu, 12 Jan 2006 16:47:01 +0100 Subject: [Pw_forum] problem with ph.x In-Reply-To: <200601111827.57468.giannozz@nest.sns.it> References: <200601111827.57468.giannozz@nest.sns.it> Message-ID: <43C679F5.7030905@sissa.it> I tried to patch as you gently suggested, Paolo, but one of the two hungs was rejected: #patch -p0 On Thursday 08 December 2005 16:19, Konzern wrote: > > >>when I tried to run the example in example06, something unexpected >>happened [..] I am running the program with 4 cpus > > > On Saturday 24 December 2005 12:28, Hai-Ping Lan wrote: > >> I have compiled ESPRESSO 2.1.5 package in AMD operon >>workstations. But i cannot perform phonon calculations parallely. > > > On Monday 09 January 2006 11:11, Gabriele Sclauzero wrote: > > >> I tried to run "example06" in the examples that come with the 3.0 >> espresso package: the ph calculation works when using a single cpu, >> but hangs up while calculating alas.dyn3 as soon as I try to use more >> then 1 cpu. > > > there was a subtle bug in the phonon code that could lead to crashes > in parallel execution (and some loss of precision in serial execution). > Save the attached file to the root directory of the 3.0 distribution (the > one containing PH/) and use command "patch -p0 < phonon.diff". This > should produce a patched version of PH/phonon.f90 that fixes the > problem with example06. > > I don't know about the second case, but I think that the 2.1.5 version > has the same problem (but needs a different fix) > > Paolo > > > ------------------------------------------------------------------------ > > Index: PH/phonon.f90 > =================================================================== > RCS file: /home/cvs/O-sesame/PH/phonon.f90,v > retrieving revision 1.33 > diff -c -r1.33 phonon.f90 > *** PH/phonon.f90 13 Dec 2005 14:45:35 -0000 1.33 > --- PH/phonon.f90 11 Jan 2006 17:12:30 -0000 > *************** > *** 28,34 **** > USE lsda_mod, ONLY : nspin > USE gvect, ONLY : nrx1, nrx2, nrx3 > USE parser, ONLY : int_to_char > ! USE control_flags, ONLY : restart, lphonon, tr2, & > mixing_beta, lscf, david, isolve > USE qpoint, ONLY : xq, nksq > USE disp, ONLY : nqs, x_q > --- 28,34 ---- > USE lsda_mod, ONLY : nspin > USE gvect, ONLY : nrx1, nrx2, nrx3 > USE parser, ONLY : int_to_char > ! USE control_flags, ONLY : restart, lphonon, tr2, wg_set, & > mixing_beta, lscf, david, isolve > USE qpoint, ONLY : xq, nksq > USE disp, ONLY : nqs, x_q > *************** > *** 222,227 **** > --- 222,228 ---- > startingconfig = 'input' > startingpot = 'file' > startingwfc = 'atomic' > + wg_set=.false. > ! > ! ... tr2 is set to a default value of 1.D-8 > ! From giannozz at nest.sns.it Thu Jan 12 16:44:37 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 12 Jan 2006 16:44:37 +0100 Subject: [Pw_forum] execution error In-Reply-To: <1137079041.19618.12.camel@swpc50.sw.ehu.es> References: <1137079041.19618.12.camel@swpc50.sw.ehu.es> Message-ID: <200601121644.37388.giannozz@nest.sns.it> On Thursday 12 January 2006 16:17, Aritz Leonardo wrote: > I am 99% sure that it is an error of the cluster configuration but in > order to fix it I would like to know... > What is the meaning of error#1 ?????? it is a game. If you waste your time trying to find out what "error # N" means, you lose. If you disregard the number (which has basically no meaning) and understand what causes the error, you win. You lost :-) > from read_namelists : error # 1 > reading namelist control See here: http://www.pwscf.org/guide/3.0/html-node/node45.html and http://www.pwscf.org/guide/3.0/html-node/node25.html towards the end (option "-inp"). If nothing is wrong in namelist &control, the only possible explanation is that you are not reading it. P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From akohlmey at vitae.cmm.upenn.edu Thu Jan 12 16:54:05 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Thu, 12 Jan 2006 10:54:05 -0500 (EST) Subject: [Pw_forum] execution error In-Reply-To: <1137079041.19618.12.camel@swpc50.sw.ehu.es> Message-ID: On Thu, 12 Jan 2006, Aritz Leonardo wrote: AL> Hello all: ... AL> Then I try to run other very simple 'scf' scripts WHICH I AM COMPLETELY AL> SURE THAT they are correctly typed and I find the following error at AL> execution. aritz, a) please do post the input example, so we can all see that it is correct. the error message indicates, that the program could not read the &control namelist. this can have multiple reasons. b) does your input work with a serial executable? that would give proof that in fact the cluster configuration ist to blame. if the job is too big, you can always - for debugging purposes - set plane wave (and density cutoff) to ridiculously low values just to see whether the input is read correctly. AL> I am 99% sure that it is an error of the cluster configuration but in AL> order to fix it I would like to know... AL> What is the meaning of error#1 ?????? c) please describe how you started the job. some MPI implementations do not support reading from STDIN, so that you have to use the -inp flag. see the corresponding section in the manual. regards, axel. AL> AL> AL> AL> Parallel version (MPI) AL> AL> Number of processors in use: 1 AL> AL> Ultrasoft (Vanderbilt) Pseudopotentials AL> AL> Current dimensions of program pwscf are: AL> AL> ntypx = 10 npk = 40000 lmax = 3 AL> nchix = 6 ndmx = 2000 nbrx = 14 nqfx = 8 AL> AL> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% AL> from read_namelists : error # 1 AL> reading namelist control AL> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% AL> AL> THANKS!!!!!!! AL> AL> _______________________________________________ AL> Pw_forum mailing list AL> Pw_forum at pwscf.org AL> http://www.democritos.it/mailman/listinfo/pw_forum AL> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From akohlmey at vitae.cmm.upenn.edu Thu Jan 12 17:01:50 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Thu, 12 Jan 2006 11:01:50 -0500 (EST) Subject: [Pw_forum] (no subject) In-Reply-To: <43C676E8.9000708@up.univ-mrs.fr> Message-ID: On Thu, 12 Jan 2006, Alain Allouche wrote: AA> Dear all, dear alain, AA> I am trying to perform a temperature rescaling MD with PWscf AA> AA> &IONS AA> ion_dynamics = 'verlet' AA> ion_temperature = 'rescaling' AA> tempw = 500.0 AA> nraise = 1 AA> tolp = 1.d-8 AA> wfc_extrapolation = 'first_order' AA> / AA> AA> The starting temperature is correct but it decreases very rapidly AA> AA> 358: Starting temperature = 500.00 K AA> 405: temperature = 496.70493449 K AA> 693: temperature = 0.24166052 K i've seen the same. going from the 3.0 release version to the current CVS seems to 'fix' the rapid decay, however, the rescaling at each nraise still does not occur. my suspicion so far was, that there was a problem distributing the values across all nodes (in my case this was a pretty large system with several k-points run across ~750 processors with one pool per k-point), but i could not find the time to look into this yet. regards, axel. AA> AA> The question is: what is the printed values ? the real scaled AA> temperature, the temperature "before" scaling, the difference between AA> the the calculated and the wanted temperature ? AA> Thanks for your help AA> AA> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From g.ballabio at cineca.it Thu Jan 12 17:43:23 2006 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Thu, 12 Jan 2006 17:43:23 +0100 (MET) Subject: [Pw_forum] execution error In-Reply-To: <1137079041.19618.12.camel@swpc50.sw.ehu.es> (from swblelia@sw.ehu.es on Thu Jan 12 16:17:21 2006) References: <1137079041.19618.12.camel@swpc50.sw.ehu.es> Message-ID: <1137084202l.6131l.1l@nb-ballabio.cineca.it> On 01/12/2006 04:17:21 PM, Aritz Leonardo wrote: > I am running for the first time ESPRESSO in a cluster of xserveG5 > with MAC OSX. Are you using the XLF compiler? If I remember correctly, while namelists normally end with a slash, with that compiler there is an environment variable such that, when it's set, namelists end with "&end" (for backward compatibility, I guess). I don't remember how it's called, sorry. Gerardo From swblelia at sw.ehu.es Thu Jan 12 17:53:59 2006 From: swblelia at sw.ehu.es (Aritz Leonardo) Date: Thu, 12 Jan 2006 17:53:59 +0100 Subject: [Pw_forum] execution error Message-ID: <1137084839.19618.19.camel@swpc50.sw.ehu.es> Dear Axel and Paolo: thanks a lot for the reply. This is the script that crashes #!/bin/sh ########################################### #PBS -q parallel #PBS -l pmem=2gb #PBS -l nodes=1:ppn=1 #PBS -l cput=200:00:00 PATH=$PATH:/software/lam-7.1.1-xlf/bin NPROCS=`wc -l < $PBS_NODEFILE` lamboot -v $PBS_NODEFILE tping -c1 C cd /scratch/aritz/MONOLAYERS/C/PHONONS/ # check whether ECHO has the -e option if test "`echo -e`" = "-e" ; then ECHO=echo ; else ECHO="echo -e" ; fi PSEUDO_LIST="C.pbe-rrkjus.UPF" TMP_DIR=/scratch/aritz/tmp # clean TMP_DIR $ECHO " cleaning $TMP_DIR...\c" rm -rf $TMP_DIR/* $ECHO " done" E=20.0 ca=6.5 a=4.65 # %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% for PARAM in `cat qPOINTS2`; do QX="`echo $PARAM | awk -F: '{print $1}'`"; QY="`echo $PARAM | awk -F: '{print $2}'`"; QZ="`echo $PARAM | awk -F: '{print $3}'`"; echo "$QX, $QY, $QZ, $a"; # self-consistent calculation cat > $a.scf.in << EOF &control calculation='scf', restart_mode='from_scratch', prefix='C' tstress = .true. tprnfor = .true. pseudo_dir = '/lscratch/aritz', outdir='$TMP_DIR/' / &system ibrav = 4, celldm(1) =$a,celldm(3)=$ca, nat= 2, ntyp= 1, ecutwfc = $E,occupations='smearing',smearing='m-p',degauss=0.007 / &electrons mixing_beta = 0.5 conv_thr = 1.0d-6 / ATOMIC_SPECIES C 12.01 C.pbe-rrkjus.UPF ATOMIC_POSITIONS C 0.00 0.000000000 0.00 C 0.00 0.577350269 0.00 K_POINTS {automatic} 20 20 1 1 1 0 EOF $ECHO " running the scf calculation...\c" mpirun C -np $NPROCS /scratch/aritz/pw_root/bin/pw.x < $a.scf.in >> $a.scf.out $ECHO " done" From swblelia at sw.ehu.es Thu Jan 12 18:12:09 2006 From: swblelia at sw.ehu.es (Aritz Leonardo) Date: Thu, 12 Jan 2006 18:12:09 +0100 Subject: [Pw_forum] execution error Message-ID: <1137085929.19618.26.camel@swpc50.sw.ehu.es> Hello Gerardo. Thanks a lot for the reply. YES I compiled ESPRESSO with XLF, and what you told me is very helpful. But the rarest thing is that I am able to run example01 of espresso and not the script that I previously sent. thanks a lot again From schwegler at llnl.gov Thu Jan 12 18:23:53 2006 From: schwegler at llnl.gov (Eric Schwegler) Date: Thu, 12 Jan 2006 09:23:53 -0800 Subject: [Pw_forum] temperature control in PWscf Message-ID: Alain, I've run into this as well. It seems to me that in version 3.0, dynamics.f90 does not save the velocities between MD timesteps. So after the initial velocity scaling they are basically set to zero. Simply adding the vel array to the unit=4 read and write statements in dynamics.f90 seems to fix the problem for me. Is this a known bug? -Eric Schwegler > Dear all, > I am trying to perform a temperature rescaling MD with PWscf > > &IONS > ion_dynamics = 'verlet' > ion_temperature = 'rescaling' > tempw = 500.0 > nraise = 1 > tolp = 1.d-8 > wfc_extrapolation = 'first_order' > / > > The starting temperature is correct but it decreases very rapidly > > 358: Starting temperature = 500.00 K > 405: temperature = 496.70493449 K > 693: temperature = 0.24166052 K > 903: temperature = 0.21332563 K > 1113: temperature = 0.18863928 K > 1323: temperature = 0.16711531 K > 1533: temperature = 0.14835294 K > 1743: temperature = 0.13194319 K > 1953: temperature = 0.11759977 K From swblelia at sw.ehu.es Thu Jan 12 18:37:04 2006 From: swblelia at sw.ehu.es (Aritz Leonardo) Date: Thu, 12 Jan 2006 18:37:04 +0100 Subject: [Fwd: Re: [Pw_forum] execution error] Message-ID: <1137087424.19618.35.camel@swpc50.sw.ehu.es> Thanks for the reply Marino 2 short questions: 1.- Did you have any problem with the slash sign? 2.- Did you use the compiler XLF? thanks again -------------- next part -------------- An embedded message was scrubbed... From: Marino Vetuschi Zuccolini Subject: Re: [Pw_forum] execution error Date: Thu, 12 Jan 2006 18:13:46 +0100 Size: 4395 Url: /pipermail/attachments/20060112/7b917c7d/attachment.eml From zucco at dipteris.unige.it Thu Jan 12 18:37:36 2006 From: zucco at dipteris.unige.it (Marino Vetuschi Zuccolini) Date: Thu, 12 Jan 2006 18:37:36 +0100 Subject: [Fwd: Re: [Pw_forum] execution error] In-Reply-To: <1137087424.19618.35.camel@swpc50.sw.ehu.es> References: <1137087424.19618.35.camel@swpc50.sw.ehu.es> Message-ID: Dear Aritz, On 12 Jan 2006, at 6:37 PM, Aritz Leonardo wrote: > Thanks for the reply Marino > > 2 short questions: > > 1.- Did you have any problem with the slash sign? Apparently not > 2.- Did you use the compiler XLF? > Yes. m. > thanks again > > From: Marino Vetuschi Zuccolini > Date: 12 January 2006 6:13:46 PM CET > To: Aritz Leonardo > Subject: Re: [Pw_forum] execution error > > > Dear Aritz, > some time ago I did the same problem and the only solution was for me > to re-type the file, or to use without modify it, the file which is > output of the PWSCFGui. > Try to see the input file with vi, maybe some char at the end of line > can be visible. But I cannot hide my faithful act... > > Good luck > > m. > > On 12 Jan 2006, at 6:12 PM, Aritz Leonardo wrote: > >> Hello Gerardo. Thanks a lot for the reply. >> >> YES I compiled ESPRESSO with XLF, and what you told me is very >> helpful. >> But the rarest thing is that I am able to run example01 of espresso >> and >> not the script that I previously sent. >> >> thanks a lot again >> >> _______________________________________________ >> Pw_forum mailing list >> Pw_forum at pwscf.org >> http://www.democritos.it/mailman/listinfo/pw_forum >> >> > > ******************************************************* > Marino Vetuschi Zuccolini > zucco at dipteris.unige.it > PhD / Geochemist > Laboratory of Geochemistry > http://www.dipteris.unige.it/geochimica > > Visit our BAXEICO computing cluster homepage > http://qed.dipteris.unige.it/ganglia -- out of service > > DIPartimento per lo studio della TErra e delle sue RISorse - > Universit? di Genova > Tel. ++39 010 3538136 Fax. ++39 010 352169 > Corso Europa 26, 16132 - Genova - Italy > > > ******************************************************* Marino Vetuschi Zuccolini zucco at dipteris.unige.it PhD / Geochemist Laboratory of Geochemistry http://www.dipteris.unige.it/geochimica Visit our BAXEICO computing cluster homepage http://qed.dipteris.unige.it/ganglia -- out of service DIPartimento per lo studio della TErra e delle sue RISorse - Universit? di Genova Tel. ++39 010 3538136 Fax. ++39 010 352169 Corso Europa 26, 16132 - Genova - Italy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2724 bytes Desc: not available Url : /pipermail/attachments/20060112/8608dacf/attachment.bin From giannozz at nest.sns.it Thu Jan 12 19:25:49 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 12 Jan 2006 19:25:49 +0100 Subject: [Pw_forum] execution error In-Reply-To: <1137084839.19618.19.camel@swpc50.sw.ehu.es> References: <1137084839.19618.19.camel@swpc50.sw.ehu.es> Message-ID: <200601121925.49788.giannozz@nest.sns.it> On Thursday 12 January 2006 17:53, Aritz Leonardo wrote: > mpirun C -np $NPROCS /scratch/aritz/pw_root/bin/pw.x < $a.scf.in >> $a.scf.out why "mpirun C" ? Anyway: computers are deterministic objects, even if sometimes it is really hard to believe that. If you cannot run your script, there is either something in your input data that the code doesn't like (check for invisible control characters, & in the first column, / vs &end, missing end-of-line; all these are real-life cases); or the code is not reading the input data (check option -inp 'file'); or the code is not running under the same environment of the example that works (environmental variables, library path, batch vs interactive, whatever) P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Thu Jan 12 21:06:39 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 12 Jan 2006 21:06:39 +0100 Subject: [Pw_forum] problem with ph.x In-Reply-To: <43C679F5.7030905@sissa.it> References: <200601111827.57468.giannozz@nest.sns.it> <43C679F5.7030905@sissa.it> Message-ID: <200601122106.39345.giannozz@nest.sns.it> On Thursday 12 January 2006 16:47, Gabriele Sclauzero wrote: > I tried to patch as you gently suggested, Paolo, but one of the two > hungs was rejected: [...] I suppose it's because the row to be > substituted in my distribution (3.0) is: > USE control_flags, ONLY : restart, lphonon, tr2, & > mixing_beta, lscf, david, isolve, modenum oops...my patch was against a more recent version > Is it OK if I add manually in the ONLY list that "wg_set" from the > patch, and should I leave "modenum" where it is? yes it is. "modenum" is actually never used there. P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From akohlmey at vitae.cmm.upenn.edu Thu Jan 12 22:07:54 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Thu, 12 Jan 2006 16:07:54 -0500 (EST) Subject: [Pw_forum] execution error In-Reply-To: <1137084839.19618.19.camel@swpc50.sw.ehu.es> Message-ID: On Thu, 12 Jan 2006, Aritz Leonardo wrote: artiz, your input works fine for me, both on a linux machine and on an (older) mac. so there indeed seems to be a AL> 20 20 1 1 1 0 AL> EOF AL> $ECHO " running the scf calculation...\c" AL> mpirun C -np $NPROCS /scratch/aritz/pw_root/bin/pw.x < $a.scf.in >> AL> $a.scf.out please note that using 'C' and '-np $NPROCS' is redundant. with LAM/MPI (which you seem to be using) plain 'C' is sufficient and the preferred way as it will tell mpirun to start just one MPI-thread per allocated processor. however, i still will work as you were using it, with the '-np' taking precedence over 'C'. one thing you may want to check is the carriage-return/ linefeed conventions used on the file. on some machines, the (fortran) parser for the input file will choke on text files that have additional carriage-return characters in them (sometimes visible as ^M or control-M) as they are needed for dos/windows but not for unix-like machines. so if you created the script on a different machine, or converted it somehow to dos/windows text. that may be another explanation. regards, axel. AL> $ECHO " done" AL> AL> AL> AL> _______________________________________________ AL> Pw_forum mailing list AL> Pw_forum at pwscf.org AL> http://www.democritos.it/mailman/listinfo/pw_forum AL> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From giannozz at nest.sns.it Fri Jan 13 09:38:24 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 13 Jan 2006 09:38:24 +0100 Subject: [Pw_forum] which file is a must for continueing ph.x run if time_max is reached? In-Reply-To: References: Message-ID: <200601130938.24039.giannozz@nest.sns.it> On Friday 06 January 2006 16:16, Konzern wrote: > I am using a cluster with queueing system to do calculations with > pwscf, because of the massive i/o load, I have to distribute the > $TMP_DIR on each node. Therefore, it is not practical for me to > collect all the files in $TMP_DIR and then re-distribute them in the > subsequent run if time_max is reached in a previous run. practical or unpractical, there is no other way to restart the phonon code. The problem is that it is impossible to distribute processes across different processors in a predictable way, so the only safe and simple solution is to have all files accessible from all processes. > I guess the necessary file should be the .save or recover both: *.save and recover*, I think. P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From glaweh at physik.fu-berlin.de Fri Jan 13 10:05:04 2006 From: glaweh at physik.fu-berlin.de (Henning Glawe) Date: Fri, 13 Jan 2006 10:05:04 +0100 Subject: [Pw_forum] ph.x does not react on prefix.EXIT Message-ID: <20060113090504.GA15890@ruprecht.simpsons.bogus> Moin, just one small bug report: the phonon code ph.x (version 2.1.5) does not seem to check for the prefix.EXIT file to allow 'clean' shutdowns of jobs to be resumed later. Sending the jobs a TERM and resuming them later on worked though, but treating a job already running for one week like this gives a bit bad feeling in the stomach ;) -- c u henning From giannozz at nest.sns.it Fri Jan 13 12:42:55 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 13 Jan 2006 12:42:55 +0100 Subject: [Pw_forum] ph.x does not react on prefix.EXIT In-Reply-To: <20060113090504.GA15890@ruprecht.simpsons.bogus> References: <20060113090504.GA15890@ruprecht.simpsons.bogus> Message-ID: <200601131242.56021.giannozz@nest.sns.it> On Friday 13 January 2006 10:05, Henning Glawe wrote: > just one small bug report: the phonon code ph.x (version 2.1.5) > does not seem to check for the prefix.EXIT file to allow 'clean' > shutdowns of jobs to be resumed later. just two small comments: 1) this is not a bug: it was never implemented for the phonon code. It will be in the next version if somebody implements it. 2) version 2.1.5 is no longer maintained P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Fri Jan 13 16:24:33 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 13 Jan 2006 16:24:33 +0100 Subject: [Pw_forum] (no subject) In-Reply-To: References: Message-ID: <200601131624.33162.giannozz@nest.sns.it> On Thursday 12 January 2006 17:01, Axel Kohlmeyer wrote: > i've seen the same. going from the 3.0 release version to the current > CVS seems to 'fix' the rapid decay, however, the rescaling at each > nraise still does not occur. it should be fixed now. P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From konstantin_kudin at yahoo.com Fri Jan 13 18:32:08 2006 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Fri, 13 Jan 2006 09:32:08 -0800 (PST) Subject: [Pw_forum] which file is a must for continueing ph.x run if time_max is reached? In-Reply-To: <200601130938.24039.giannozz@nest.sns.it> Message-ID: <20060113173209.18834.qmail@web52002.mail.yahoo.com> --- Paolo Giannozzi wrote: > > practical or unpractical, there is no other way to restart the phonon > > code. The problem is that it is impossible to distribute processes > across different processors in a predictable way, so the only safe > and simple solution is to have all files accessible from all > processes. Actually, suppose the job is restarted on the same nodes as before, but the process ordering got screwed up. Would it be possible to do something like this: -upon a restart probe for the existence of the restartable files (the names are generally known!) on each node, and make a list of what is available -figure out if each process can see some unique file, and create a 1-to-1 mapping from process numbers to file numbers -then upon read/write simply remap the sequential file numbers into the other ordering Kostya __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From giannozz at nest.sns.it Fri Jan 13 19:22:13 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 13 Jan 2006 19:22:13 +0100 Subject: [Pw_forum] more on variable-cell optimizations In-Reply-To: References: <6ac064b60601031435p7a427e22ud39cc5dd6a4736be@mail.gmail.com> <200601051015.50951.giannozz@nest.sns.it> Message-ID: <200601131922.13937.giannozz@nest.sns.it> On Thursday 05 January 2006 16:28, Lilia Boeri wrote: > I was wondering whether it is possible with PWSCF to optimize the unit > cell while keeping the internal degrees of freedom (i.e. the reduced > coordinates in the unit cell) fixed. you may try to set the force on atoms to 0: in variable-cell dynamics, atomic positions are automatically scaled with the crystal axis. Not sure at all it will work, and even less that it will do what you hope for. > if I have, for example, an hexagonal system and I want to find how the c/a > ratio evolves with pressure, I suppose I should calculate, for different > volumes, the total energy as a function of c/a keeping the volume fixed. > Then I would take the minimum point for each volume and with this build > a E(V) curve, differentiate and calculate the P(V) curve. > [...] is the above procedure correct? I hope so: this is how I calculated the equilibrium lattice parameter of MgB_2, once upon a time... see attached script and fortran code. And yes, at equilibrium the stress is isotropic (it should be 0 but its diagonal part, i.e. the pressure, won't be 0 until you go to very high cutoffs) Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy -------------- next part -------------- A non-text attachment was scrubbed... Name: mgb2.j Type: application/x-shellscript Size: 1356 bytes Desc: not available Url : /pipermail/attachments/20060113/798a24d6/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: minsq.f Type: text/x-fortran Size: 1233 bytes Desc: not available Url : /pipermail/attachments/20060113/798a24d6/attachment-0001.bin From giannozz at nest.sns.it Sun Jan 15 22:11:05 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Sun, 15 Jan 2006 22:11:05 +0100 Subject: [Pw_forum] which file is a must for continueing ph.x run if time_max is reached? In-Reply-To: <20060113173209.18834.qmail@web52002.mail.yahoo.com> References: <20060113173209.18834.qmail@web52002.mail.yahoo.com> Message-ID: <200601152211.05589.giannozz@nest.sns.it> On Friday 13 January 2006 18:32, Konstantin Kudin wrote: > Actually, suppose the job is restarted on the same nodes as before, > but the process ordering got screwed up. Would it be possible to do > something like this: > > -upon a restart probe for the existence of the restartable files (the > names are generally known!) on each node, and make a list of what is > available > > -figure out if each process can see some unique file, and create a > 1-to-1 mapping from process numbers to file numbers > > -then upon read/write simply remap the sequential file numbers into > the other ordering you may need not only to remap files, but also to have the same distribution of grid points in R-space and vectors in G-space across processors than in the previous run. In the specific case of phonon calculation it might not be needed; I have to check this. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From yuss at jlu.edu.cn Mon Jan 16 10:28:15 2006 From: yuss at jlu.edu.cn (yuss) Date: Mon, 16 Jan 2006 17:28:15 +0800 Subject: [Pw_forum] For INPUT of WanT Message-ID: <003d01c61a7f$2e0e5da0$5e223c0a@yuss> Dear all: Who could offer the example of transport for CNT ( INPUT of PWSCF and WanT)? Thanks S.S.YU -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060116/7f093daf/attachment.htm From sclauzer at sissa.it Mon Jan 16 11:14:26 2006 From: sclauzer at sissa.it (Gabriele Sclauzero) Date: Mon, 16 Jan 2006 11:14:26 +0100 Subject: [Pw_forum] PWcond: parallel exec. failure? Message-ID: <43CB7202.8070503@sissa.it> Dear PW Users, I was testing the 3.0 espresso distribution on a parallel machine where I compiled the codes with mpich. I tried to run the example 22 which comes with this distribution, but the pwcond.x program seems to have some problem. This is the last line obtained from the output file pt.cond.out: ngper, shell number = 69 13 then the job gets stuck. Could anyone report the same problem? Gabriele From g.ballabio at cineca.it Mon Jan 16 11:12:20 2006 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Mon, 16 Jan 2006 11:12:20 +0100 (MET) Subject: [Pw_forum] which file is a must for continueing ph.x run if time_max is reached? In-Reply-To: <200601152211.05589.giannozz@nest.sns.it> (from giannozz@nest.sns.it on Sun Jan 15 22:11:05 2006) References: <20060113173209.18834.qmail@web52002.mail.yahoo.com> <200601152211.05589.giannozz@nest.sns.it> Message-ID: <1137406339l.4238l.1l@nb-ballabio.cineca.it> On 01/15/2006 10:11:05 PM, Paolo Giannozzi wrote: > you may need not only to remap files, but also to have the same > distribution of grid points in R-space and vectors in G-space > across processors than in the previous run. Wouldn't it be better to swap processor ranks? Gerardo From giannozz at nest.sns.it Mon Jan 16 17:36:39 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 16 Jan 2006 17:36:39 +0100 Subject: [Pw_forum] PWcond: parallel exec. failure? In-Reply-To: <43CB7202.8070503@sissa.it> References: <43CB7202.8070503@sissa.it> Message-ID: <200601161736.39676.giannozz@nest.sns.it> On Monday 16 January 2006 11:14, Gabriele Sclauzero wrote: > I was testing the 3.0 espresso distribution on a parallel machine > where I compiled the codes with mpich. I tried to run the example 22 > which comes with this distribution, but the pwcond.x program seems to > have some problem. This is the last line obtained from the output file > pt.cond.out: > > ngper, shell number = 69 13 > > then the job gets stuck. on parallel machines the last line written to file may not be the last. Write to standard output, not to file; then let all processes, and not only one of them, print the output (see file PW/startup.f90). The pwcond.x code performs a diagonalization of a non-symmetric matrix that sometimes crashes for no apparent good reason. P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From ferretti.andrea at unimore.it Mon Jan 16 19:35:50 2006 From: ferretti.andrea at unimore.it (Andrea Ferretti) Date: Mon, 16 Jan 2006 19:35:50 +0100 (CET) Subject: [Pw_forum] For INPUT of WanT In-Reply-To: <003d01c61a7f$2e0e5da0$5e223c0a@yuss> References: <003d01c61a7f$2e0e5da0$5e223c0a@yuss> Message-ID: On Mon, 16 Jan 2006, yuss wrote: > Dear all: > Who could offer the example of transport for CNT ( INPUT of PWSCF and WanT)? > Thanks > S.S.YU Hi, I have no pre-defined input files for transport in C nanotubes (CNT, isn't?), but I think you can try to set up the whole transport calculation following some of the tests (test06 to test11) provided with WanT. the needed calculations are: * pw.x: scf (as usual) and nscf (in order to compute eigenvalues on a regular grid spanning the whole BZ)... at the end run pw_export.x to export espresso data (if you are using espresso 3.0 it is already there. otherwise read Sec. 3.1 of WanT manual which explains how to get the pw_export utility) * you are now in the position to run want. Some examples of 1D transport calculation are in the tests (particularly test10 and test11) and you can first take a look there to understand which calculations you need (the conductor cell only, the leads separately etc etc)... the part of the want input which is really very system-specific is the choice of the "starting wannier centers" giving the initial guess for the wannier localization. Some criteria to choose these centers are exaplined in Sec. 5.2 (troubleshoting, pag 37): usually they are set on the covalent bonds and on the atoms... test03 provides an example on how this works for benzene... the case of nanotubes should not be that different. Andrea PS: sorry to those espresso users not directly interested... :-) From yonasb at yahoo.com Tue Jan 17 15:57:29 2006 From: yonasb at yahoo.com (Yonas Abraham) Date: Tue, 17 Jan 2006 06:57:29 -0800 (PST) Subject: [Pw_forum] CVS and PAW Message-ID: <20060117145729.74643.qmail@web32005.mail.mud.yahoo.com> Hi, In my CVS ChangeLog generated by cvs2cl.pl shows some PAW references like 2005-12-21 12:26 fratesi * PW/: electrons.f90, grid_paw_variables.f90: wrong ranges in deband_paw, descf_paw. Set really_do_paw=.T. (GF) My question is that I can't seem to find the listed file in my directories. For example the above note implies (I guess) the is a file called PW/grid_paw_variables.f90 which is affected by that commit. But I don't have that file. I have done "cvs update -d" I am interested on PAW and want to know the how it is progressing, which note it is based on etc and to see if I can help in testing. /yonas From akohlmey at vitae.cmm.upenn.edu Tue Jan 17 16:26:23 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Tue, 17 Jan 2006 10:26:23 -0500 (EST) Subject: [Pw_forum] CVS and PAW In-Reply-To: <20060117145729.74643.qmail@web32005.mail.mud.yahoo.com> Message-ID: On Tue, 17 Jan 2006, Yonas Abraham wrote: yonas, please note, that cvs2cl.pl by default creates a changelog for _all_ branches. the change you are referring to is on the develop_PAW branch. just do a 'cvs status -v PW/electrons.f90' to see all branches. usually it is recommended to run ./cvs2cl.pl -b see the cvs documentation on how to update your checkout to a different branch and how to go back. since this is most likely even more experimental than the regular q-espresso cvs, i would, however, _strongly_ recommend, you first get into contact with the PAW developer(s) before you even try it out. i know nothing about this specific branch, but usually developers create these kind of branches, when they they have to change some internal structures that affect many parts of the code, so that there are high chances, that for a while _nothing_ might work... regards, axel. YA> Hi, YA> YA> In my CVS ChangeLog generated by cvs2cl.pl shows some YA> PAW references like YA> YA> 2005-12-21 12:26 fratesi YA> YA> YA> YA> * PW/: electrons.f90, grid_paw_variables.f90: YA> YA> YA> YA> wrong ranges in deband_paw, YA> descf_paw. Set really_do_paw=.T. (GF) YA> YA> YA> My question is that I can't seem to find the listed YA> file in my directories. For example the above note YA> implies (I guess) the is a file called YA> PW/grid_paw_variables.f90 which is affected by that YA> commit. But I don't have that file. I have done "cvs YA> update -d" YA> YA> I am interested on PAW and want to know the how it is YA> progressing, which note it is based on etc and to see YA> if I can help in testing. YA> YA> /yonas YA> _______________________________________________ YA> Pw_forum mailing list YA> Pw_forum at pwscf.org YA> http://www.democritos.it/mailman/listinfo/pw_forum YA> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From yonasb at yahoo.com Tue Jan 17 17:23:02 2006 From: yonasb at yahoo.com (Yonas Abraham) Date: Tue, 17 Jan 2006 08:23:02 -0800 (PST) Subject: [Pw_forum] CVS and PAW In-Reply-To: Message-ID: <20060117162302.20658.qmail@web32004.mail.mud.yahoo.com> Thanks, I didn't know that cvs2cl.pl was generating from other branches. cvs co -jdevelop_PAW espresso did the job. I put it in a separate directory just to test it. It is really exciting that Q-espresso is adding PAW. /yonas --- Axel Kohlmeyer wrote: > On Tue, 17 Jan 2006, Yonas Abraham wrote: > > > yonas, > > please note, that cvs2cl.pl by default creates > a changelog for _all_ branches. the change you > are referring to is on the develop_PAW branch. > just do a 'cvs status -v PW/electrons.f90' > to see all branches. usually it is recommended > to run ./cvs2cl.pl -b > > see the cvs documentation on how to update your > checkout to a different branch and how to go back. > > since this is most likely even more experimental > than the regular q-espresso cvs, i would, however, > _strongly_ recommend, you first get into contact > with the PAW developer(s) before you even try it > out. > i know nothing about this specific branch, but > usually > developers create these kind of branches, when they > they > have to change some internal structures that affect > many > parts of the code, so that there are high chances, > that > for a while _nothing_ might work... > > regards, > axel. > > YA> Hi, > YA> > YA> In my CVS ChangeLog generated by cvs2cl.pl shows > some > YA> PAW references like > YA> > YA> 2005-12-21 12:26 fratesi > YA> > > YA> > > YA> > YA> * PW/: electrons.f90, > grid_paw_variables.f90: > YA> > > YA> > > YA> > YA> wrong ranges in > deband_paw, > YA> descf_paw. Set really_do_paw=.T. (GF) > YA> > YA> > YA> My question is that I can't seem to find the > listed > YA> file in my directories. For example the above > note > YA> implies (I guess) the is a file called > YA> PW/grid_paw_variables.f90 which is affected by > that > YA> commit. But I don't have that file. I have done > "cvs > YA> update -d" > YA> > YA> I am interested on PAW and want to know the how > it is > YA> progressing, which note it is based on etc and > to see > YA> if I can help in testing. > YA> > YA> /yonas > YA> _______________________________________________ > YA> Pw_forum mailing list > YA> Pw_forum at pwscf.org > YA> > http://www.democritos.it/mailman/listinfo/pw_forum > YA> > > -- > ======================================================================= > Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu > http://www.cmm.upenn.edu > Center for Molecular Modeling -- University > of Pennsylvania > Department of Chemistry, 231 S.34th Street, > Philadelphia, PA 19104-6323 > tel: 1-215-898-1582, fax: 1-215-573-6233, > office-tel: 1-215-898-5425 > ======================================================================= > If you make something idiot-proof, the universe > creates a better idiot. > > From akohlmey at vitae.cmm.upenn.edu Tue Jan 17 17:40:19 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Tue, 17 Jan 2006 11:40:19 -0500 (EST) Subject: [Pw_forum] CVS and PAW In-Reply-To: <20060117162302.20658.qmail@web32004.mail.mud.yahoo.com> Message-ID: On Tue, 17 Jan 2006, Yonas Abraham wrote: YA> YA> Thanks, YA> YA> I didn't know that cvs2cl.pl was generating from other YA> branches. YA> YA> cvs co -jdevelop_PAW espresso YA> YA> did the job. I put it in a separate directory just to YA> test it. please have a closer look at the documentation. with -j cvs should check out main trunk and merge in the branch. if you want to follow the branch, you have to check out with '-rdevelop_PAW' so it becomes a 'sticky' tag and future updates with 'cvs update' with stay in that branch. axel. YA> YA> It is really exciting that Q-espresso is adding PAW. YA> /yonas YA> YA> YA> --- Axel Kohlmeyer YA> wrote: YA> YA> > On Tue, 17 Jan 2006, Yonas Abraham wrote: YA> > YA> > YA> > yonas, YA> > YA> > please note, that cvs2cl.pl by default creates YA> > a changelog for _all_ branches. the change you YA> > are referring to is on the develop_PAW branch. YA> > just do a 'cvs status -v PW/electrons.f90' YA> > to see all branches. usually it is recommended YA> > to run ./cvs2cl.pl -b YA> > YA> > see the cvs documentation on how to update your YA> > checkout to a different branch and how to go back. YA> > YA> > since this is most likely even more experimental YA> > than the regular q-espresso cvs, i would, however, YA> > _strongly_ recommend, you first get into contact YA> > with the PAW developer(s) before you even try it YA> > out. YA> > i know nothing about this specific branch, but YA> > usually YA> > developers create these kind of branches, when they YA> > they YA> > have to change some internal structures that affect YA> > many YA> > parts of the code, so that there are high chances, YA> > that YA> > for a while _nothing_ might work... YA> > YA> > regards, YA> > axel. YA> > YA> > YA> Hi, YA> > YA> YA> > YA> In my CVS ChangeLog generated by cvs2cl.pl shows YA> > some YA> > YA> PAW references like YA> > YA> YA> > YA> 2005-12-21 12:26 fratesi YA> > YA> YA> > YA> > YA> YA> > YA> > YA> YA> > YA> * PW/: electrons.f90, YA> > grid_paw_variables.f90: YA> > YA> YA> > YA> > YA> YA> > YA> > YA> YA> > YA> wrong ranges in YA> > deband_paw, YA> > YA> descf_paw. Set really_do_paw=.T. (GF) YA> > YA> YA> > YA> YA> > YA> My question is that I can't seem to find the YA> > listed YA> > YA> file in my directories. For example the above YA> > note YA> > YA> implies (I guess) the is a file called YA> > YA> PW/grid_paw_variables.f90 which is affected by YA> > that YA> > YA> commit. But I don't have that file. I have done YA> > "cvs YA> > YA> update -d" YA> > YA> YA> > YA> I am interested on PAW and want to know the how YA> > it is YA> > YA> progressing, which note it is based on etc and YA> > to see YA> > YA> if I can help in testing. YA> > YA> YA> > YA> /yonas YA> > YA> _______________________________________________ YA> > YA> Pw_forum mailing list YA> > YA> Pw_forum at pwscf.org YA> > YA> YA> > http://www.democritos.it/mailman/listinfo/pw_forum YA> > YA> YA> > YA> > -- YA> > YA> ======================================================================= YA> > Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu YA> > http://www.cmm.upenn.edu YA> > Center for Molecular Modeling -- University YA> > of Pennsylvania YA> > Department of Chemistry, 231 S.34th Street, YA> > Philadelphia, PA 19104-6323 YA> > tel: 1-215-898-1582, fax: 1-215-573-6233, YA> > office-tel: 1-215-898-5425 YA> > YA> ======================================================================= YA> > If you make something idiot-proof, the universe YA> > creates a better idiot. YA> > YA> > YA> YA> _______________________________________________ YA> Pw_forum mailing list YA> Pw_forum at pwscf.org YA> http://www.democritos.it/mailman/listinfo/pw_forum YA> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From naromero at gmail.com Tue Jan 17 17:51:34 2006 From: naromero at gmail.com (Nichols A. Romero) Date: Tue, 17 Jan 2006 11:51:34 -0500 Subject: [Pw_forum] speeding up vc-relax Message-ID: <6ac064b60601170851u67868fd8h220be7f34d0b8bd8@mail.gmail.com> Hi, I was doing vc-relax on a vdW bonded system. An inherently "floppy" system that has a very shallow energy minimum. It took about 1000 relaxation steps to find the energy minimum. I set dt = 10.0 which is probably too low, but I had problems at dt = 100.0 mostly because my starting equilibrium structure was off (The input parameters where from experiment and the starting pressure calculated by PWSCF was 10 GPa). It doesn't look like the BFGS works with the vc-relax algorithm. Does anyone have any suggestions for speeding up vc-relax? Thanks, -- Dr. Nichols A. Romero, PhD. 1613 Denise Dr. Apt. D Forest Hill, MD 21050 443-567-8328 (C) 410-306-0709 (O) From giannozz at nest.sns.it Tue Jan 17 17:56:32 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 17 Jan 2006 17:56:32 +0100 Subject: [Pw_forum] speeding up vc-relax In-Reply-To: <6ac064b60601170851u67868fd8h220be7f34d0b8bd8@mail.gmail.com> References: <6ac064b60601170851u67868fd8h220be7f34d0b8bd8@mail.gmail.com> Message-ID: <200601171756.32182.giannozz@nest.sns.it> On Tuesday 17 January 2006 17:51, Nichols A. Romero wrote: > I was doing vc-relax on a vdW bonded system you shouldn't. Van der Waals bonded systems are not well described by DFT. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From naromero at gmail.com Tue Jan 17 18:00:43 2006 From: naromero at gmail.com (Nichols A. Romero) Date: Tue, 17 Jan 2006 12:00:43 -0500 Subject: [Pw_forum] speeding up vc-relax In-Reply-To: <200601171756.32182.giannozz@nest.sns.it> References: <6ac064b60601170851u67868fd8h220be7f34d0b8bd8@mail.gmail.com> <200601171756.32182.giannozz@nest.sns.it> Message-ID: <6ac064b60601170900i26f490b0t34810a996e4b1c70@mail.gmail.com> Paolo, I absolutely agree. This is more for testing purposes. To show that different codes give the same "bad" DFT answers. On 1/17/06, Paolo Giannozzi wrote: > On Tuesday 17 January 2006 17:51, Nichols A. Romero wrote: > > > I was doing vc-relax on a vdW bonded system > > you shouldn't. Van der Waals bonded systems are not well > described by DFT. > > Paolo > > -- > Paolo Giannozzi e-mail: giannozz at nest.sns.it > Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 > Piazza dei Cavalieri 7 I-56126 Pisa, Italy > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > -- Dr. Nichols A. Romero, PhD. 1613 Denise Dr. Apt. D Forest Hill, MD 21050 443-567-8328 (C) 410-306-0709 (O) From marzari at MIT.EDU Tue Jan 17 18:08:48 2006 From: marzari at MIT.EDU (Nicola Marzari) Date: Tue, 17 Jan 2006 12:08:48 -0500 Subject: [Pw_forum] speeding up vc-relax In-Reply-To: <200601171756.32182.giannozz@nest.sns.it> References: <6ac064b60601170851u67868fd8h220be7f34d0b8bd8@mail.gmail.com> <200601171756.32182.giannozz@nest.sns.it> Message-ID: <43CD24A0.80209@mit.edu> Well, since a system can be floppy for non van der waals reasons, what is the best strategy to combat floppyness ? Floppyness is akin to say that the ionic potential energy surface has a very wide spread in eigenvalues - and the strategy that would improve BFGS or ionic conjugate gradients minimization is preconditioning. There was a talk by Dominic King-Smith at ES2001, in Princeton, on optimal choices of internal coordinates. I think he published the work (around ~2001), or it might be on the Accelrys website. nicola Paolo Giannozzi wrote: > On Tuesday 17 January 2006 17:51, Nichols A. Romero wrote: > >> I was doing vc-relax on a vdW bonded system > > you shouldn't. Van der Waals bonded systems are not well > described by DFT. > > Paolo > From yuss at jlu.edu.cn Thu Jan 19 05:42:30 2006 From: yuss at jlu.edu.cn (yuss at jlu.edu.cn) Date: Thu, 19 Jan 2006 12:42:30 +0800 Subject: [Pw_forum] Why is different bewteen example12 of PWSCF and test08 of WanT? Message-ID: <1137645750.43cf18b68b39a@mail.ctosoft.com> Dear all: The example12 of PWSCF and test08 of WanT all study the transport of Al chain. Why are results ( trans.alwire and cond.dat) different? Thanks! From merlin.meheut at lmcp.jussieu.fr Thu Jan 19 11:55:02 2006 From: merlin.meheut at lmcp.jussieu.fr (merlin.meheut at lmcp.jussieu.fr) Date: Thu, 19 Jan 2006 11:55:02 +0100 Subject: [Pw_forum] Pressure calculations with 2 different versions Message-ID: <1137668102.43cf700677b2f@www.impmc.jussieu.fr> Hello, I am experiencing quite a strange thing with pwscf: with the version 1.3.0 and 2.1.4, with an (almost) identical input file, I find 2 very different calculated pressures (even if almost everything else is the same). Is that me or there is a difference between the two versions? Below I report my two input files: for pw.1.3.0 and for 2.1.4 quantum expresso. This is a calculation on the water molecule, so I take a big unit cell for the molecules not to interact. I took the same initial structure for the two calculations, except: the mixing_mode: it is potential for 1.3.0 (which is considered as obsolete in the doc, but it converged anyway, so I don't see the trouble), and plain for 2.1.4 conv_thr : it is 10-18 in 1.3.0 and 10-9 in 2.1.4 , but as I understood it is a formal question. Moreover, on the same structure, if I make a structural relaxation (calculation = RELAX), with pw.1.3.0 I find a final pressure of 0.1 kbars , whereas with the 2.1.4 I find almost the same relaxed structure, but with a pressure of -20 kbars ! input for pw.1.3.0 &control calculation = 'scf', restart_mode = 'from_scratch' , prefix = 'VAP', disk_io = 'default' , pseudo_dir = './', outdir = './', tprnfor = .true., tstress = .true., /&end &system ibrav = 0, celldm(1)=30, nat = 3, ntyp = 2, ecutwfc = 80.0, ecutrho = 480.0, /&end &electrons electron_maxstep = 30, conv_thr = 1.d-18, mixing_mode = 'potential', startingwfc = 'atomic', mixing_beta = 0.5, diagonalization = 'david_overlap', /&end &ions ion_dynamics = 'bfgs', potential_extrapolation = 'atomic', /&end ATOMIC_SPECIES O 15.9949 O.pbe H 1.0078 H.pbe2 ATOMIC_POSITIONS {angstrom} O -.010283269 .000000000 .000000000 H .590805635 .770226149 .000000000 H .590805635 -.770226149 .000000000 K_POINTS { gamma } CELL_PARAMETERS { cubic } 1.000000000 0.000000000 0.00000000 0.000000000 1.000000000 0.00000000 0.000000000 0.000000000 1.00000000 input for quantum expresso 2.1.4 &control calculation = 'scf', restart_mode = 'from_scratch' , prefix = 'VAP', disk_io = 'default' , pseudo_dir = './', outdir = './scr/', tprnfor = .true., tstress = .true., /&end &system ibrav =0, celldm(1)=30, nat = 3, ntyp = 2, ecutwfc =80.0, ecutrho=480.0 /&end &electrons electron_maxstep = 30, conv_thr = 1.d-9, mixing_mode = 'plain', startingwfc = 'atomic', mixing_beta = 0.5, diagonalization = 'david_overlap', /&end ATOMIC_SPECIES O 15.99491 O.pbe H 1.00783 H.pbe2 ATOMIC_POSITIONS {angstrom} O -.010283269 .000000000 .000000000 H .590805635 .770226149 .000000000 H .590805635 -.770226149 .000000000 K_POINTS {gamma} CELL_PARAMETERS {CUBIC} 1.000000000 0.000000000 0.00000000 0.000000000 1.000000000 0.00000000 0.000000000 0.000000000 1.00000000 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From proffess at yandex.ru Thu Jan 19 20:38:29 2006 From: proffess at yandex.ru (Sergey Lisenkov) Date: Thu, 19 Jan 2006 22:38:29 +0300 (MSK) Subject: [Pw_forum] compiling e-3.0 on HP Message-ID: <43CFEAB5.000002.26984@webmail10.yandex.ru> Dear PWscf authors, I have some problems to compiler espresso-3.0 (in particullarly, iotk directory) on HP machine with HP compiler: ... mpif90 +O2 -w +cpp=yes +Odataprefetch +Onolimit +U77 +DA2.0 +DS2.0 -D__HP -D__FFTW -D__USE_INTERNAL_FFTW -D__MPI -D__PARA -I../include -I/nethome/proffess/hpux/lib/fftw-215_cc-32/include/ -I. -I../Modules -I../PW -I../PH -I../iotk/src -I../CPV -c iotk_attr+COMPLEX1_0.f90 /var/tmp//fciBAAa27725.f90 external subroutine IOTK_PRIVATE_PACK_COMPLEX1 external subroutine IOTK_WRITE_COMPLEX1 external subroutine IOTK_READ_COMPLEX1 tmpcomplex = cmplx(tmpreal,aimag((val((index+1)/2))),kind=selected_real_kind(6,30)) ^ Error 1003 at (207:iotk_attr.spp) : Argument KIND must be a constant tmpcomplex = cmplx(real(val((index+1)/2)),tmpreal,kind=selected_real_kind(6,30)) ^ Error 1003 at (209:iotk_attr.spp) : Argument KIND must be a constant external subroutine IOTK_WRITE_ATTR_COMPLEX1_0 external subroutine IOTK_SCAN_ATTR_COMPLEX1_0 external subroutine IOTK_ATTR_DUMMY_COMPLEX1_0 external subroutine IOTK_WRITE_ATTR_COMPLEX1_1 external subroutine IOTK_SCAN_ATTR_COMPLEX1_1 external subroutine IOTK_ATTR_DUMMY_COMPLEX1_1 external subroutine IOTK_WRITE_ATTR_COMPLEX1_2 external subroutine IOTK_SCAN_ATTR_COMPLEX1_2 external subroutine IOTK_ATTR_DUMMY_COMPLEX1_2 2 Errors f90: error 213: Errors detected. *** Error exit code 1 Stop. *** Error exit code 1 Stop. *** Error exit code 1 Stop. Any hints? Thanks, Sergey From giannozz at nest.sns.it Thu Jan 19 21:40:38 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 19 Jan 2006 21:40:38 +0100 Subject: [Pw_forum] compiling e-3.0 on HP In-Reply-To: <43CFEAB5.000002.26984@webmail10.yandex.ru> References: <43CFEAB5.000002.26984@webmail10.yandex.ru> Message-ID: <200601192140.39202.giannozz@nest.sns.it> On Thursday 19 January 2006 20:38, Sergey Lisenkov wrote: > tmpcomplex = > cmplx(tmpreal,aimag((val((index+1)/2))),kind=selected_real_kind(6,30)) ^ > Error 1003 at (207:iotk_attr.spp) : Argument KIND must be a constant some compilers don't like this construct (another one is intel 7.x). I am told that it is standard f90, but go explain it to the compiler. In iotk/include/iotk_config.h replace #define __IOTK_REAL1 selected_real_kind(6,30) #define __IOTK_REAL2 selected_real_kind(14,200) with whatever is appropriate in your case, presumably #define __IOTK_REAL1 4 #define __IOTK_REAL2 8 By the way: did you manage to have the code working on Altix, on Cray X-1, on the 25 other different machines you occasionally ask about?!? P -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Thu Jan 19 21:46:21 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 19 Jan 2006 21:46:21 +0100 Subject: [Pw_forum] Pressure calculations with 2 different versions In-Reply-To: <1137668102.43cf700677b2f@www.impmc.jussieu.fr> References: <1137668102.43cf700677b2f@www.impmc.jussieu.fr> Message-ID: <200601192146.21909.giannozz@nest.sns.it> On Thursday 19 January 2006 11:55, merlin.meheut at lmcp.jussieu.fr wrote: > with the version 1.3.0 and 2.1.4, with an (almost) identical input file, > I find 2 very different calculated pressures you should verify what you get with later versions, and if you get the same results on different machines. Pressure is quite sensitive to the quality of convergence and to numerical noise. In a supercell containing a molecule, it is a rather meaningless quantity anyway. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From proffess at yandex.ru Thu Jan 19 22:04:05 2006 From: proffess at yandex.ru (Sergey Lisenkov) Date: Fri, 20 Jan 2006 00:04:05 +0300 (MSK) Subject: [Pw_forum] compiling e-3.0 on HP In-Reply-To: <200601192140.39202.giannozz@nest.sns.it> References: <43CFEAB5.000002.26984@webmail10.yandex.ru> <200601192140.39202.giannozz@nest.sns.it> Message-ID: <43CFFEC5.000002.03228@colgate.yandex.ru> Dear Paolo! Thanks for the help. It works. S. From proffess at yandex.ru Fri Jan 20 17:34:12 2006 From: proffess at yandex.ru (Sergey Lisenkov) Date: Fri, 20 Jan 2006 19:34:12 +0300 (MSK) Subject: [Pw_forum] compiling e-3.0 on HP In-Reply-To: <200601192140.39202.giannozz@nest.sns.it> References: <43CFEAB5.000002.26984@webmail10.yandex.ru> <200601192140.39202.giannozz@nest.sns.it> Message-ID: <43D11104.000001.27061@ariel.yandex.ru> Dear Paolo, The pwscf code is compiled, but execution was failed at the end: .... Writing output data file pwscf.save %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from seqopn : error # 4 error opening pwscf.bfgs %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... STOP 2 It was example3 (bfgs relaxation of Al) from espresso execution. I see that this file is exist and contains some data. Version 2.1.5 works perfectly in this case. Thanks, Sergey >By the way: did you manage to have the code working on Altix, >on Cray X-1, on the 25 other different machines you occasionally >ask about?!? Not on all of them, but I am trying to do my best :) From ferretti.andrea at unimore.it Sat Jan 21 20:50:43 2006 From: ferretti.andrea at unimore.it (Andrea Ferretti) Date: Sat, 21 Jan 2006 20:50:43 +0100 (CET) Subject: [Pw_forum] Why is different bewteen example12 of PWSCF and test08 of WanT? In-Reply-To: <1137645750.43cf18b68b39a@mail.ctosoft.com> References: <1137645750.43cf18b68b39a@mail.ctosoft.com> Message-ID: On Thu, 19 Jan 2006 yuss at jlu.edu.cn wrote: > Dear all: > The example12 of PWSCF and test08 of WanT all study the transport of Al chain. > Why are results ( trans.alwire and cond.dat) different? > Thanks! Hi, concerning the ideal aluminum chain, example12 in espresso and test08 in WanT do not have the same geometry (mainly, different bond length)... according to me, there is also a factor 2 (due to a different convention in the choice of the transmitance units): espresso results must be divided by 2 to be in the same units of WanT once these problems are overcome, a discrepancy is still around. this is due to a more physical reason: when computing the transmittance across the scattering (conductor) region, the matrix green function technique implemented in WanT treats the leads as a chain of principal layers with nearest neighbour interactions. these layers can be made larger and larger in order to control the convergence of the calculation, but in the present case the aluminum chain in WanT was simulated with one atom per unit cell (= the principal layer, here), making the difference wrt example12 in espresso... Since it is quite nice to have such a direct comparison with different methods, I update test08 in WanT in order to be the most similar to example12 as possible... You can find this updated version at http://nanofs.unimo.it/~ferretti/test08.tar.gz the calculation now includes: * Al chain with one atom per cell (as before) * Al chain with 5 atoms per cell (now directly comp with example12) * Al chain with H impurity (also comparable with example12) results from the two methods are now in a pretty good agreement the README file in the test dir gives more details about the comparison thanks for the tip Andrea From yuwen_66 at yahoo.com Sun Jan 22 02:52:27 2006 From: yuwen_66 at yahoo.com (W. YU) Date: Sat, 21 Jan 2006 17:52:27 -0800 (PST) Subject: [Pw_forum] problems with phonon dispersion Message-ID: <20060122015227.52299.qmail@web51013.mail.yahoo.com> Dear all, I met some problems with phonon calculations and I hope someone could give me some help. I did some calculations on a system with NaCl structure. I used three types of pseudopotentials: norm-conserving LDA, ultrasoft LDA, ultrasoft GGA. The lattice constants are all in good or reasonable agreement with experiments or other full potential calculations. When it comes to phonon dispersion curves, the NC LDA pseudopotentials gave smooth curves and the agreement with experiment is relatively good. For the US LDA calculation, the dispersion curves are smooth and the agreement with experiment is acceptable, but the smallest achievable values of the accoustic branches at Gamma point are about 40 wavenumber. With the increase of the ecut and ecutrho, these values became as large as 70 wavenumber. Now my question is: aren't they supposed to go to zero with the increase of ecut and ecutrho? If the answer is yes, does this mean the pseudopotential has some flaw or it is completely untrustable? As for the US GGA, I found negtive frequencies around gamma point with the same ecut and ecutrho as the LDA case. So I used larger ecut and ecutrho, the negtive frequencies became positive, but there are some kohn-like anomalies in the accoustic branches and the agreement with experiment became very poor for the accoustic branches. I though this might be caused by long range interactions. So I took a 888 q point grid instead of the original 444 one. This time, besides negtive frequencies around the gamma point and the anomalies, the accoustic branches even became zigzaged! I really couldn't figure it out. Does anybody has similar experience? Could anyone tell me what could be the most possible cause for this? PS: accoustic sum rule has been imposed throughout these calculations. ONLY the accoustic branches have these problems. The optical branches seem to be insensitive to the changes of the q point grid and cutoffs. Thanks a lot, W. YU __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From eyvaz_isaev at yahoo.com Sun Jan 22 17:04:13 2006 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Sun, 22 Jan 2006 08:04:13 -0800 (PST) Subject: [Pw_forum] problems with phonon dispersion In-Reply-To: <20060122015227.52299.qmail@web51013.mail.yahoo.com> Message-ID: <20060122160413.24646.qmail@web60317.mail.yahoo.com> Hi, Did you to calculate phonons for Na using these pseudopotentials? Bests, Eyvaz. --- "W. YU" wrote: > Dear all, > > I met some problems with phonon calculations and I > hope someone could give me some help. > > I did some calculations on a system with NaCl > structure. I used three types of pseudopotentials: > norm-conserving LDA, ultrasoft LDA, ultrasoft GGA. > The > lattice constants are all in good or reasonable > agreement with experiments or other full potential > calculations. When it comes to phonon dispersion > curves, the NC LDA pseudopotentials gave smooth > curves > and the agreement with experiment is relatively > good. > > For the US LDA calculation, the dispersion curves > are > smooth and the agreement with experiment is > acceptable, but the smallest achievable values of > the > accoustic branches at Gamma point are about 40 > wavenumber. With the increase of the ecut and > ecutrho, > these values became as large as 70 wavenumber. Now > my > question is: aren't they supposed to go to zero with > the increase of ecut and ecutrho? If the answer is > yes, does this mean the pseudopotential has some > flaw > or it is completely untrustable? > > As for the US GGA, I found negtive frequencies > around > gamma point with the same ecut and ecutrho as the > LDA > case. So I used larger ecut and ecutrho, the negtive > frequencies became positive, but there are some > kohn-like anomalies in the accoustic branches and > the > agreement with experiment became very poor for the > accoustic branches. I though this might be caused by > long range interactions. So I took a 888 q point > grid > instead of the original 444 one. This time, besides > negtive frequencies around the gamma point and the > anomalies, the accoustic branches even became > zigzaged! I really couldn't figure it out. Does > anybody has similar experience? Could anyone tell me > what could be the most possible cause for this? > > PS: accoustic sum rule has been imposed throughout > these calculations. ONLY the accoustic branches have > these problems. The optical branches seem to be > insensitive to the changes of the q point grid and > cutoffs. > > Thanks a lot, > > W. YU > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From yuwen_66 at yahoo.com Mon Jan 23 01:27:49 2006 From: yuwen_66 at yahoo.com (W. YU) Date: Sun, 22 Jan 2006 16:27:49 -0800 (PST) Subject: [Pw_forum] problems with phonon dispersion In-Reply-To: <20060122063517.17288.77421.Mailman@democritos.sissa.it> Message-ID: <20060123002749.2244.qmail@web51009.mail.yahoo.com> Dear Eyvaz, Acturally I did calculation with these pseudopotentials for LiH and probably for NaH later. The pseudopotentials of Li include 1s electrons as valance electrons. Wen >Hi, > >Did you to calculate phonons for Na using these >pseudopotentials? >Bests, >Eyvaz. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From giannozz at nest.sns.it Mon Jan 23 12:08:16 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 23 Jan 2006 12:08:16 +0100 Subject: [Pw_forum] compiling e-3.0 on HP In-Reply-To: <43D11104.000001.27061@ariel.yandex.ru> References: <43CFEAB5.000002.26984@webmail10.yandex.ru> <200601192140.39202.giannozz@nest.sns.it> <43D11104.000001.27061@ariel.yandex.ru> Message-ID: <200601231208.16519.giannozz@nest.sns.it> On Friday 20 January 2006 17:34, Sergey Lisenkov wrote: > The pwscf code is compiled, but execution was failed at the end: > from seqopn : error # 4 > error opening pwscf.bfgs unless you bring evidence of the contrary, I'll assume it is a compiler bug P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From cbarreteau at cea.fr Thu Jan 26 14:07:42 2006 From: cbarreteau at cea.fr (Cyrille Barreteau) Date: Thu, 26 Jan 2006 14:07:42 +0100 (CET) Subject: [Pw_forum] espresso3.0 different results in serial and paralelle mode... Message-ID: <52426.132.166.17.128.1138280862.squirrel@dsm-mail> Dear PWscf fans, I am facing a strange problem with pwscf (pw.x) of the espresso3.0 version. I have performed two identical calculations: one on my local linux machine and the same job on a linux cluster. The compiler is the same (ifort version 9) and the machines are rather similar (64bytes processors). However the results are not exactly the same (see below the result of calculations on Fe bcc and Fe wire from serial and parallel executions..) Any comment is very welcome cyrille ================================================================== Fe bulk bcc: serial the Fermi energy is 12.4997 ev ! total energy = -61.13842278 ryd estimated scf accuracy < 8.9E-10 ryd band energy sum = 6.08329685 ryd one-electron contribution = 3.42413935 ryd hartree contribution = 8.76962528 ryd xc contribution = -30.38754311 ryd ewald contribution = -42.94464676 ryd correction for metals = 0.00000247 ryd convergence has been achieved cluster the Fermi energy is 12.4997 ev ! total energy = -61.13842278 ryd estimated scf accuracy < 8.9E-10 ryd band energy sum = 6.08329678 ryd one-electron contribution = 3.42413925 ryd hartree contribution = 8.76962544 ryd xc contribution = -30.38754318 ryd ewald contribution = -42.94464676 ryd correction for metals = 0.00000247 ryd convergence has been achieved ================================================================== Fe wire serial the Fermi energy is -3.7064 ev ! total energy = -60.94621023 ryd estimated scf accuracy < 9.9E-09 ryd band energy sum = -3.47102873 ryd one-electron contribution = -103.24843460 ryd hartree contribution = 57.38042984 ryd xc contribution = -30.44155502 ryd ewald contribution = 15.36351010 ryd correction for metals = -0.00016054 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell convergence has been achieved cluster the Fermi energy is -3.7058 ev ! total energy = -60.94621063 ryd estimated scf accuracy < 3.3E-09 ryd band energy sum = -3.47080039 ryd one-electron contribution = -103.24792049 ryd hartree contribution = 57.37977246 ryd xc contribution = -30.44141187 ryd ewald contribution = 15.36351010 ryd correction for metals = -0.00016084 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell convergence has been achieved -- ================================================================== Cyrille Barreteau | phone : +33 (0)1 69 08 29 51 CEA Saclay | fax : +33 (0)1 69 08 84 46 DSM/DRECAM/SPCSI | email : cyrille.barreteau at cea.fr Batiment 462 | 91191 Gif sur Yvette Cedex FRANCE ~~~~~~~~~~~~~~~~~~~~~~~~ http://www-drecam.cea.fr/spcsi/index.php http://www-drecam.cea.fr/Images/Pisp/cbarreteau/cbarreteau_fr.html http://www-drecam.cea.fr/Phocea/Membres/Cours/index.php ================================================================== From g.ballabio at cineca.it Thu Jan 26 14:42:29 2006 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Thu, 26 Jan 2006 14:42:29 +0100 (MET) Subject: [Pw_forum] espresso3.0 different results in serial and paralelle mode... In-Reply-To: <52426.132.166.17.128.1138280862.squirrel@dsm-mail> (from cbarreteau@cea.fr on Thu Jan 26 14:07:42 2006) References: <52426.132.166.17.128.1138280862.squirrel@dsm-mail> Message-ID: <1138282948l.23211l.0l@nb-ballabio.cineca.it> On 01/26/2006 02:07:42 PM, Cyrille Barreteau wrote: > serial > the Fermi energy is 12.4997 ev > > ! total energy = -61.13842278 ryd > band energy sum = 6.08329685 ryd > cluster > the Fermi energy is 12.4997 ev > > ! total energy = -61.13842278 ryd > band energy sum = 6.08329678 ryd I would not mind. It is quite normal for iterative methods to reach convergence through different paths as soon as anything changes. Between serial and parallel execution there are probably some operations that aren't performed in the same order, and as the numerical accuracy of computer numbers is finite, this can give slightly different results. It is also normal that the total energy converges to a better accuracy than the parts it is composed of. Thus if the convergence threshold is 1e-8, you'll get 8-digit accuracy on the total energy, but one or two less on other terms. It isn't a problem, but if you mind, try changing the threshold to 1e-10 or 1e-12, I'm sure the differences will go away (but it'll probably take a few more iterations to converge). Gerardo From cbarreteau at cea.fr Thu Jan 26 15:30:23 2006 From: cbarreteau at cea.fr (Cyrille Barreteau) Date: Thu, 26 Jan 2006 15:30:23 +0100 (CET) Subject: [Pw_forum] espresso3.0 different results in serial andparalelle mode... In-Reply-To: <1138282948l.23211l.0l@nb-ballabio.cineca.it> References: <52426.132.166.17.128.1138280862.squirrel@dsm-mail> <1138282948l.23211l.0l@nb-ballabio.cineca.it> Message-ID: <52752.132.166.17.128.1138285823.squirrel@dsm-mail> Ok so there is nothing to worry about. I was just a bit puzzled also by the fact that it took 14 iterations to converge in serial and 24 in parallel (for the wire). But maybe it was just bad luck.. cyrille -- ================================================================== Cyrille Barreteau | phone : +33 (0)1 69 08 29 51 CEA Saclay | fax : +33 (0)1 69 08 84 46 DSM/DRECAM/SPCSI | email : cyrille.barreteau at cea.fr Batiment 462 | 91191 Gif sur Yvette Cedex FRANCE ~~~~~~~~~~~~~~~~~~~~~~~~ http://www-drecam.cea.fr/spcsi/index.php http://www-drecam.cea.fr/Images/Pisp/cbarreteau/cbarreteau_fr.html http://www-drecam.cea.fr/Phocea/Membres/Cours/index.php ================================================================== On Jeu 26 janvier 2006 14:42, Gerardo Ballabio a ?crit : > On 01/26/2006 02:07:42 PM, Cyrille Barreteau wrote: >> serial >> the Fermi energy is 12.4997 ev >> >> ! total energy = -61.13842278 ryd > >> band energy sum = 6.08329685 ryd > >> cluster >> the Fermi energy is 12.4997 ev >> >> ! total energy = -61.13842278 ryd > >> band energy sum = 6.08329678 ryd > > I would not mind. It is quite normal for iterative methods to reach > convergence through different paths as soon as anything changes. > Between serial and parallel execution there are probably some > operations that aren't performed in the same order, and as the > numerical accuracy of computer numbers is finite, this can give > slightly different results. > > It is also normal that the total energy converges to a better > accuracy than the parts it is composed of. Thus if the convergence > threshold is 1e-8, you'll get 8-digit accuracy on the total energy, > but one or two less on other terms. It isn't a problem, but if you > mind, try changing the threshold to 1e-10 or 1e-12, I'm sure the > differences will go away (but it'll probably take a few more > iterations to converge). > > Gerardo > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From konstantin_kudin at yahoo.com Thu Jan 26 16:49:54 2006 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Thu, 26 Jan 2006 07:49:54 -0800 (PST) Subject: [Pw_forum] espresso3.0 different results in serial and paralel mode... In-Reply-To: <52752.132.166.17.128.1138285823.squirrel@dsm-mail> Message-ID: <20060126154954.47178.qmail@web52013.mail.yahoo.com> Well, if the number of SCF iterations differ by so much, the possibility that it is some kind of a bug and not just pure bad luck is pretty high ... Could you post a) the progress of the total energies toward convergence for both runs and b) the actual input file ? Also, it'd be nice if you could test the CVS version and see if this behaviour is also there. Kosgtya --- Cyrille Barreteau wrote: > Ok so there is nothing to worry about. > I was just a bit puzzled also by the fact that > it took 14 iterations to converge in serial and > 24 in parallel (for the wire). > But maybe it was just bad luck.. > > cyrille > > > -- > ================================================================== > Cyrille Barreteau | phone : +33 (0)1 69 08 29 51 > CEA Saclay | fax : +33 (0)1 69 08 84 46 > DSM/DRECAM/SPCSI | email : cyrille.barreteau at cea.fr > Batiment 462 | > 91191 Gif sur Yvette Cedex FRANCE > ~~~~~~~~~~~~~~~~~~~~~~~~ > http://www-drecam.cea.fr/spcsi/index.php > http://www-drecam.cea.fr/Images/Pisp/cbarreteau/cbarreteau_fr.html > http://www-drecam.cea.fr/Phocea/Membres/Cours/index.php > ================================================================== > > On Jeu 26 janvier 2006 14:42, Gerardo Ballabio a ?crit : > > On 01/26/2006 02:07:42 PM, Cyrille Barreteau wrote: > >> serial > >> the Fermi energy is 12.4997 ev > >> > >> ! total energy = -61.13842278 ryd > > > >> band energy sum = 6.08329685 ryd > > > >> cluster > >> the Fermi energy is 12.4997 ev > >> > >> ! total energy = -61.13842278 ryd > > > >> band energy sum = 6.08329678 ryd > > > > I would not mind. It is quite normal for iterative methods to reach > > convergence through different paths as soon as anything changes. > > Between serial and parallel execution there are probably some > > operations that aren't performed in the same order, and as the > > numerical accuracy of computer numbers is finite, this can give > > slightly different results. > > > > It is also normal that the total energy converges to a better > > accuracy than the parts it is composed of. Thus if the convergence > > threshold is 1e-8, you'll get 8-digit accuracy on the total energy, > > but one or two less on other terms. It isn't a problem, but if you > > mind, try changing the threshold to 1e-10 or 1e-12, I'm sure the > > differences will go away (but it'll probably take a few more > > iterations to converge). > > > > Gerardo > > > > _______________________________________________ > > 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 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From cbarreteau at cea.fr Thu Jan 26 17:15:05 2006 From: cbarreteau at cea.fr (Cyrille Barreteau) Date: Thu, 26 Jan 2006 17:15:05 +0100 (CET) Subject: [Pw_forum] espresso3.0 different results in serial and paralel mode... In-Reply-To: <20060126154954.47178.qmail@web52013.mail.yahoo.com> References: <52752.132.166.17.128.1138285823.squirrel@dsm-mail> <20060126154954.47178.qmail@web52013.mail.yahoo.com> Message-ID: <53174.132.166.17.128.1138292105.squirrel@dsm-mail> You will find below: the input and the 2 outputs (serial+parallel) =============================================== input ================================================= &control calculation='scf' restart_mode='from_scratch', pseudo_dir = '/home/barreto/SOFTWARE/pseudo/', outdir='tmp' prefix='fe_wire' / &system ibrav = 6, celldm(1) =30.0, celldm(3) =0.14333333333333333333, nat= 1, ntyp= 1, nbnd=15, nspin = 2, starting_magnetization(1)=0.3, ecutwfc = 35.0, ecutrho=250., occupations='smearing', smearing='methfessel-paxton', degauss=0.005 / &electrons conv_thr = 1.0e-8 mixing_beta = 0.3 / ATOMIC_SPECIES Fe 55.847 Fe_us_gga_d2.1.8.pseudo.UPF ATOMIC_POSITIONS Fe 0.0 0.0 0.0 K_POINTS (automatic) 1 1 111 0 0 0 ============================================================== output Serial job: ================================================================= Program PWSCF v.3.0 starts ... Today is 23Jan2006 at 11:45: 4 Ultrasoft (Vanderbilt) Pseudopotentials Current dimensions of program pwscf are: ntypx = 10 npk = 40000 lmax = 3 nchix = 6 ndmx = 2000 nbrx = 14 nqfx = 8 bravais-lattice index = 6 lattice parameter (a_0) = 30.0000 a.u. unit-cell volume = 3870.0000 (a.u.)^3 number of atoms/cell = 1 number of atomic types = 1 kinetic-energy cutoff = 35.0000 Ry charge density cutoff = 250.0000 Ry convergence threshold = 1.0E-08 beta = 0.3000 number of iterations used = 8 plain mixing Exchange-correlation = SLA PW GGX GGC (1422) celldm(1)= 30.000000 celldm(2)= 0.000000 celldm(3)= 0.143333 celldm(4)= 0.000000 celldm(5)= 0.000000 celldm(6)= 0.000000 crystal axes: (cart. coord. in units of a_0) a(1) = ( 1.000000 0.000000 0.000000 ) a(2) = ( 0.000000 1.000000 0.000000 ) a(3) = ( 0.000000 0.000000 0.143333 ) reciprocal axes: (cart. coord. in units 2 pi/a_0) b(1) = ( 1.000000 0.000000 0.000000 ) b(2) = ( 0.000000 1.000000 0.000000 ) b(3) = ( 0.000000 0.000000 6.976744 ) PSEUDO 1 is Fe (US) zval = 8.0 lmax= 2 lloc= 0 Version 0 0 0 of US pseudo code Using log mesh of 935 points The pseudopotential has 3 beta functions with: l(1) = 1 l(2) = 2 l(3) = 2 Q(r) pseudized with 8 coefficients, rinner = 1.300 1.000 1.200 1.200 1.200 atomic species valence mass pseudopotential Fe 8.00 55.84700 Fe( 1.00) Starting magnetic structure atomic species magnetization Fe 0.300 16 Sym.Ops. (with inversion) Cartesian axes site n. atom positions (a_0 units) 1 Fe tau( 1) = ( 0.0000000 0.0000000 0.0000000 ) number of k points= 112 gaussian broad. (ryd)= 0.0050 ngauss = 1 cart. coord. in units 2pi/a_0 ..... G cutoff = 5699.3166 ( 258221 G-vectors) FFT grid: (160,160, 24) G cutoff = 3191.6173 ( 108117 G-vectors) smooth grid: (120,120, 18) nbndx = 60 nbnd = 15 natomwfc = 9 npwx = 13668 nelec = 8.00 nkb = 13 ngl = 12824 Check: negative/imaginary core charge= -0.000003 0.000000 Initial potential from superposition of free atoms Check: negative starting charge=(component1): -0.000502 Check: negative starting charge=(component2): -0.000270 starting charge 7.99062, renormalised to 8.00000 negative rho (up, down): 0.502E-03 0.270E-03 Starting wfc are atomic + 6 random wfc total cpu time spent up to now is 99.80 secs Self-consistent Calculation iteration # 1 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 1.00E-02, avg # of iterations = 7.0 negative rho (up, down): 0.545E-03 0.321E-03 total cpu time spent up to now is 609.24 secs total energy = -60.71926701 ryd estimated scf accuracy < 0.79937747 ryd total magnetization = 2.74 Bohr mag/cell absolute magnetization = 2.74 Bohr mag/cell iteration # 2 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 9.99E-03, avg # of iterations = 1.0 negative rho (up, down): 0.426E-03 0.309E-03 total cpu time spent up to now is 837.04 secs total energy = -60.87606685 ryd estimated scf accuracy < 0.44179732 ryd total magnetization = 3.34 Bohr mag/cell absolute magnetization = 3.34 Bohr mag/cell iteration # 3 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 5.52E-03, avg # of iterations = 1.0 negative rho (up, down): 0.499E-03 0.383E-03 total cpu time spent up to now is 1062.96 secs total energy = -60.93425941 ryd estimated scf accuracy < 0.06041955 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.33 Bohr mag/cell iteration # 4 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 7.55E-04, avg # of iterations = 5.3 negative rho (up, down): 0.539E-03 0.381E-03 total cpu time spent up to now is 1362.19 secs total energy = -60.94173473 ryd estimated scf accuracy < 0.00533639 ryd total magnetization = 3.32 Bohr mag/cell absolute magnetization = 3.32 Bohr mag/cell iteration # 5 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 6.67E-05, avg # of iterations = 6.5 negative rho (up, down): 0.720E-03 0.466E-03 total cpu time spent up to now is 1756.57 secs total energy = -60.94496133 ryd estimated scf accuracy < 0.00517422 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.34 Bohr mag/cell iteration # 6 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 6.47E-05, avg # of iterations = 3.3 negative rho (up, down): 0.722E-03 0.471E-03 total cpu time spent up to now is 2019.99 secs total energy = -60.94571298 ryd estimated scf accuracy < 0.00066608 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.34 Bohr mag/cell iteration # 7 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 8.33E-06, avg # of iterations = 6.4 negative rho (up, down): 0.833E-03 0.524E-03 total cpu time spent up to now is 2352.78 secs total energy = -60.94605170 ryd estimated scf accuracy < 0.00046101 ryd total magnetization = 3.34 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 8 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap WARNING: 1 eigenvalues not converged ethr = 5.76E-06, avg # of iterations = 3.5 negative rho (up, down): 0.777E-03 0.507E-03 total cpu time spent up to now is 2625.51 secs total energy = -60.94617143 ryd estimated scf accuracy < 0.00006035 ryd total magnetization = 3.34 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 9 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 7.54E-07, avg # of iterations = 2.4 negative rho (up, down): 0.798E-03 0.508E-03 total cpu time spent up to now is 2859.29 secs total energy = -60.94618108 ryd estimated scf accuracy < 0.00002585 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 10 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 3.23E-07, avg # of iterations = 1.0 negative rho (up, down): 0.788E-03 0.507E-03 total cpu time spent up to now is 3095.70 secs total energy = -60.94620173 ryd estimated scf accuracy < 0.00001416 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 11 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 1.77E-07, avg # of iterations = 1.0 negative rho (up, down): 0.778E-03 0.505E-03 total cpu time spent up to now is 3318.43 secs total energy = -60.94620857 ryd estimated scf accuracy < 0.00000196 ryd total magnetization = 3.34 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 12 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 2.45E-08, avg # of iterations = 1.0 negative rho (up, down): 0.768E-03 0.504E-03 total cpu time spent up to now is 3556.50 secs total energy = -60.94620933 ryd estimated scf accuracy < 0.00000032 ryd total magnetization = 3.34 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 13 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 4.01E-09, avg # of iterations = 1.0 negative rho (up, down): 0.768E-03 0.504E-03 total cpu time spent up to now is 3779.79 secs total energy = -60.94620993 ryd estimated scf accuracy < 0.00000076 ryd total magnetization = 3.34 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 14 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 4.01E-09, avg # of iterations = 1.0 negative rho (up, down): 0.771E-03 0.505E-03 total cpu time spent up to now is 3997.68 secs End of self-consistent calculation ================================================================= outuput parallel job: ================================================================= Program PWSCF v.3.0 starts ... Today is 23Jan2005 at 14:26: 8 Parallel version (MPI) Number of processors in use: 8 K-points division: npool = 8 Ultrasoft (Vanderbilt) Pseudopotentials Current dimensions of program pwscf are: ntypx = 10 npk = 40000 lmax = 3 nchix = 6 ndmx = 2000 nbrx = 14 nqfx = 8 Planes per process (thick) : nr3 = 24 npp = 24 ncplane =25600 Planes per process (smooth): nr3s= 18 npps= 18 ncplanes=14400 Proc/ planes cols G planes cols G columns G Pool (dense grid) (smooth grid) (wavefct grid) 1 24 17905 258221 18 10029 108117 3149 19261 0 24 17905 258221 18 10029 108117 3149 19261 bravais-lattice index = 6 lattice parameter (a_0) = 30.0000 a.u. unit-cell volume = 3870.0000 (a.u.)^3 number of atoms/cell = 1 number of atomic types = 1 kinetic-energy cutoff = 35.0000 Ry charge density cutoff = 250.0000 Ry convergence threshold = 1.0E-08 beta = 0.3000 number of iterations used = 8 plain mixing Exchange-correlation = SLA PW GGX GGC (1422) celldm(1)= 30.000000 celldm(2)= 0.000000 celldm(3)= 0.143333 celldm(4)= 0.000000 celldm(5)= 0.000000 celldm(6)= 0.000000 crystal axes: (cart. coord. in units of a_0) a(1) = ( 1.000000 0.000000 0.000000 ) a(2) = ( 0.000000 1.000000 0.000000 ) a(3) = ( 0.000000 0.000000 0.143333 ) reciprocal axes: (cart. coord. in units 2 pi/a_0) b(1) = ( 1.000000 0.000000 0.000000 ) b(2) = ( 0.000000 1.000000 0.000000 ) b(3) = ( 0.000000 0.000000 6.976744 ) PSEUDO 1 is Fe (US) zval = 8.0 lmax= 2 lloc= 0 Version 0 0 0 of US pseudo code Using log mesh of 935 points The pseudopotential has 3 beta functions with: l(1) = 1 l(2) = 2 l(3) = 2 Q(r) pseudized with 8 coefficients, rinner = 1.300 1.000 1.200 1.200 1.200 atomic species valence mass pseudopotential Fe 8.00 55.84700 Fe( 1.00) Starting magnetic structure atomic species magnetization Fe 0.300 16 Sym.Ops. (with inversion) Cartesian axes site n. atom positions (a_0 units) 1 Fe tau( 1) = ( 0.0000000 0.0000000 0.0000000 ) number of k points= 112 gaussian broad. (ryd)= 0.0050 ngauss = 1 cart. coord. in units 2pi/a_0....... G cutoff = 5699.3166 ( 258221 G-vectors) FFT grid: (160,160, 24) G cutoff = 3191.6173 ( 108117 G-vectors) smooth grid: (120,120, 18) nbndx = 60 nbnd = 15 natomwfc = 9 npwx = 13452 nelec = 8.00 nkb = 13 ngl = 12824 Check: negative/imaginary core charge= -0.000003 0.000000 Initial potential from superposition of free atoms Check: negative starting charge=(component1): -0.000502 Check: negative starting charge=(component2): -0.000270 starting charge 7.99062, renormalised to 8.00000 negative rho (up, down): 0.502E-03 0.270E-03 Starting wfc are atomic + 6 random wfc total cpu time spent up to now is 32.93 secs Self-consistent Calculation iteration # 1 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 1.00E-02, avg # of iterations = 7.0 negative rho (up, down): 0.545E-03 0.321E-03 total cpu time spent up to now is 153.32 secs total energy = -60.71941104 ryd estimated scf accuracy < 0.79904373 ryd total magnetization = 2.74 Bohr mag/cell absolute magnetization = 2.74 Bohr mag/cell iteration # 2 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 9.99E-03, avg # of iterations = 1.0 negative rho (up, down): 0.428E-03 0.309E-03 total cpu time spent up to now is 216.21 secs total energy = -60.87616961 ryd estimated scf accuracy < 0.44104929 ryd total magnetization = 3.34 Bohr mag/cell absolute magnetization = 3.34 Bohr mag/cell iteration # 3 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 5.51E-03, avg # of iterations = 1.0 negative rho (up, down): 0.502E-03 0.385E-03 total cpu time spent up to now is 279.35 secs total energy = -60.93436141 ryd estimated scf accuracy < 0.06034487 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.33 Bohr mag/cell iteration # 4 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 7.54E-04, avg # of iterations = 5.3 negative rho (up, down): 0.540E-03 0.382E-03 total cpu time spent up to now is 359.53 secs total energy = -60.94178319 ryd estimated scf accuracy < 0.00533628 ryd total magnetization = 3.32 Bohr mag/cell absolute magnetization = 3.33 Bohr mag/cell iteration # 5 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 6.67E-05, avg # of iterations = 6.7 negative rho (up, down): 0.719E-03 0.465E-03 total cpu time spent up to now is 461.07 secs total energy = -60.94499615 ryd estimated scf accuracy < 0.00512298 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.34 Bohr mag/cell iteration # 6 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 6.40E-05, avg # of iterations = 3.1 negative rho (up, down): 0.721E-03 0.471E-03 total cpu time spent up to now is 531.18 secs total energy = -60.94572162 ryd estimated scf accuracy < 0.00066383 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.34 Bohr mag/cell iteration # 7 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 8.30E-06, avg # of iterations = 6.3 negative rho (up, down): 0.849E-03 0.525E-03 total cpu time spent up to now is 616.10 secs total energy = -60.94603043 ryd estimated scf accuracy < 0.00045072 ryd total magnetization = 3.34 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 8 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 5.63E-06, avg # of iterations = 3.7 negative rho (up, down): 0.789E-03 0.508E-03 total cpu time spent up to now is 697.96 secs total energy = -60.94617844 ryd estimated scf accuracy < 0.00008931 ryd total magnetization = 3.34 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 9 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 1.12E-06, avg # of iterations = 2.3 negative rho (up, down): 0.788E-03 0.508E-03 total cpu time spent up to now is 765.87 secs total energy = -60.94620809 ryd estimated scf accuracy < 0.00000354 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 10 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 4.42E-08, avg # of iterations = 1.0 negative rho (up, down): 0.782E-03 0.505E-03 total cpu time spent up to now is 830.09 secs total energy = -60.94620408 ryd estimated scf accuracy < 0.00000595 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 11 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 4.42E-08, avg # of iterations = 1.0 negative rho (up, down): 0.783E-03 0.504E-03 total cpu time spent up to now is 894.86 secs total energy = -60.94620190 ryd estimated scf accuracy < 0.00001525 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 12 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 4.42E-08, avg # of iterations = 1.0 negative rho (up, down): 0.778E-03 0.504E-03 total cpu time spent up to now is 959.01 secs total energy = -60.94620338 ryd estimated scf accuracy < 0.00002750 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 13 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 4.42E-08, avg # of iterations = 1.0 negative rho (up, down): 0.779E-03 0.504E-03 total cpu time spent up to now is 1023.28 secs total energy = -60.94621029 ryd estimated scf accuracy < 0.00000800 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 14 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 4.42E-08, avg # of iterations = 1.0 negative rho (up, down): 0.772E-03 0.502E-03 total cpu time spent up to now is 1087.84 secs total energy = -60.94620677 ryd estimated scf accuracy < 0.00001090 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 15 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 4.42E-08, avg # of iterations = 1.0 negative rho (up, down): 0.772E-03 0.503E-03 total cpu time spent up to now is 1151.78 secs total energy = -60.94620707 ryd estimated scf accuracy < 0.00002032 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.34 Bohr mag/cell iteration # 16 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 4.42E-08, avg # of iterations = 1.0 negative rho (up, down): 0.773E-03 0.503E-03 total cpu time spent up to now is 1215.99 secs total energy = -60.94620774 ryd estimated scf accuracy < 0.00001375 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 17 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 4.42E-08, avg # of iterations = 1.0 negative rho (up, down): 0.773E-03 0.503E-03 total cpu time spent up to now is 1280.02 secs total energy = -60.94620773 ryd estimated scf accuracy < 0.00001041 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 18 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 4.42E-08, avg # of iterations = 1.0 negative rho (up, down): 0.773E-03 0.506E-03 total cpu time spent up to now is 1344.19 secs total energy = -60.94620618 ryd estimated scf accuracy < 0.00001043 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 19 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 4.42E-08, avg # of iterations = 1.0 negative rho (up, down): 0.770E-03 0.505E-03 total cpu time spent up to now is 1408.21 secs total energy = -60.94620822 ryd estimated scf accuracy < 0.00000015 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 20 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 1.86E-09, avg # of iterations = 1.0 negative rho (up, down): 0.769E-03 0.505E-03 total cpu time spent up to now is 1472.42 secs total energy = -60.94620901 ryd estimated scf accuracy < 0.00000009 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 21 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 1.08E-09, avg # of iterations = 1.0 negative rho (up, down): 0.770E-03 0.505E-03 total cpu time spent up to now is 1536.69 secs total energy = -60.94620985 ryd estimated scf accuracy < 0.00000003 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 22 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 3.81E-10, avg # of iterations = 1.0 negative rho (up, down): 0.771E-03 0.505E-03 total cpu time spent up to now is 1600.75 secs total energy = -60.94621110 ryd estimated scf accuracy < 0.00000001 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 23 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 1.42E-10, avg # of iterations = 1.0 negative rho (up, down): 0.771E-03 0.505E-03 total cpu time spent up to now is 1665.13 secs total energy = -60.94621099 ryd estimated scf accuracy < 0.00000002 ryd total magnetization = 3.33 Bohr mag/cell absolute magnetization = 3.35 Bohr mag/cell iteration # 24 ecut= 35.00 ryd beta=0.30 Davidson diagonalization with overlap ethr = 1.42E-10, avg # of iterations = 1.0 negative rho (up, down): 0.771E-03 0.505E-03 total cpu time spent up to now is 1727.68 secs End of self-consistent calculation -- ================================================================== Cyrille Barreteau | phone : +33 (0)1 69 08 29 51 CEA Saclay | fax : +33 (0)1 69 08 84 46 DSM/DRECAM/SPCSI | email : cyrille.barreteau at cea.fr Batiment 462 | 91191 Gif sur Yvette Cedex FRANCE ~~~~~~~~~~~~~~~~~~~~~~~~ http://www-drecam.cea.fr/spcsi/index.php http://www-drecam.cea.fr/Images/Pisp/cbarreteau/cbarreteau_fr.html http://www-drecam.cea.fr/Phocea/Membres/Cours/index.php ================================================================== On Jeu 26 janvier 2006 16:49, Konstantin Kudin a ?crit : > Well, if the number of SCF iterations differ by so much, the > possibility that it is some kind of a bug and not just pure bad luck is > pretty high ... > > Could you post a) the progress of the total energies toward > convergence for both runs and b) the actual input file ? > > Also, it'd be nice if you could test the CVS version and see if this > behaviour is also there. > > Kosgtya > > > --- Cyrille Barreteau wrote: > >> Ok so there is nothing to worry about. >> I was just a bit puzzled also by the fact that >> it took 14 iterations to converge in serial and >> 24 in parallel (for the wire). >> But maybe it was just bad luck.. >> >> cyrille >> >> >> -- >> ================================================================== >> Cyrille Barreteau | phone : +33 (0)1 69 08 29 51 >> CEA Saclay | fax : +33 (0)1 69 08 84 46 >> DSM/DRECAM/SPCSI | email : cyrille.barreteau at cea.fr >> Batiment 462 | >> 91191 Gif sur Yvette Cedex FRANCE >> ~~~~~~~~~~~~~~~~~~~~~~~~ >> http://www-drecam.cea.fr/spcsi/index.php >> http://www-drecam.cea.fr/Images/Pisp/cbarreteau/cbarreteau_fr.html >> http://www-drecam.cea.fr/Phocea/Membres/Cours/index.php >> ================================================================== >> >> On Jeu 26 janvier 2006 14:42, Gerardo Ballabio a ?crit : >> > On 01/26/2006 02:07:42 PM, Cyrille Barreteau wrote: >> >> serial >> >> the Fermi energy is 12.4997 ev >> >> >> >> ! total energy = -61.13842278 ryd >> > >> >> band energy sum = 6.08329685 ryd >> > >> >> cluster >> >> the Fermi energy is 12.4997 ev >> >> >> >> ! total energy = -61.13842278 ryd >> > >> >> band energy sum = 6.08329678 ryd >> > >> > I would not mind. It is quite normal for iterative methods to reach >> > convergence through different paths as soon as anything changes. >> > Between serial and parallel execution there are probably some >> > operations that aren't performed in the same order, and as the >> > numerical accuracy of computer numbers is finite, this can give >> > slightly different results. >> > >> > It is also normal that the total energy converges to a better >> > accuracy than the parts it is composed of. Thus if the convergence >> > threshold is 1e-8, you'll get 8-digit accuracy on the total energy, >> > but one or two less on other terms. It isn't a problem, but if you >> > mind, try changing the threshold to 1e-10 or 1e-12, I'm sure the >> > differences will go away (but it'll probably take a few more >> > iterations to converge). >> > >> > Gerardo >> > >> > _______________________________________________ >> > 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 >> > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From ylin at shell.cas.usf.edu Thu Jan 26 17:54:44 2006 From: ylin at shell.cas.usf.edu (You Lin) Date: Thu, 26 Jan 2006 11:54:44 -0500 (EST) Subject: [Pw_forum] convergence NOT achieved, stopping Message-ID: Dear pwscf developers or users: I tried pwscf on an interface between Nickle and Alumina. The self-consistent calculation cannot finish with the following error: convergence NOT achieved, stopping I found this in the manual: -- Self-consistency is slow or does not converge. [...] If the highest occupied and lowest unoccupied state(s) keep exchanging place during self-consistency, forget about reaching convergence. A typical sign of such behavior is that the self-consistency error goes down, down, down, than all of a sudden up again, and so on. Usually one can solve the problem by adding a few empty bands and a broadening. -- So I tried to manually assign more empty bands and degauss=0.0002. I still get oscillations in total energy. The last a few total energies are listed below: total energy = -2803.40138682 ryd total energy = -2830.79824814 ryd total energy = -2819.95336489 ryd total energy = -2846.17498280 ryd total energy = -2838.30750908 ryd total energy = -2816.89515320 ryd total energy = -2844.65794627 ryd total energy = -2851.17678186 ryd total energy = -2857.26598638 ryd total energy = -2851.22021650 ryd total energy = -2803.07516948 ryd total energy = -2831.39193734 ryd total energy = -2819.19178874 ryd total energy = -2846.04973420 ryd total energy = -2836.37911313 ryd total energy = -2817.70612317 ryd total energy = -2842.03435570 ryd total energy = -2850.49039020 ryd total energy = -2857.53771242 ryd total energy = -2851.23397342 ryd total energy = -2800.87394328 ryd total energy = -2831.32149373 ryd total energy = -2819.05136878 ryd Looks like the problem still exists. I didn't finish this calculation since it doesn't seem to converge anyway. Is there solution out of this problem? More info: I'm using espresso 3.0 running both in series and in parallel. My input file is: -- Start of input -- &control calculation='relax' restart_mode='from_scratch', pseudo_dir = '/homes/r40/ylin/Del/Run/pwscf/espresso-3.0/pseudo/', outdir='/scratch1/ylin/tmp/3.0/' prefix='al2o3' tprnfor = .true., nstep=20, dt=100. tstress = .true., verbosity='high' / &system ibrav=0, celldm(1) =9.4176391165, nat=46, ntyp=3, nbnd=230, ecutwfc = 26, ecutrho = 288.0, nspin = 2, starting_magnetization(1)=0.7, occupations='smearing', smearing='methfessel-paxton', degauss=0.0002 / &electrons diagonalization='david' conv_thr = 1.0e-2, electron_maxstep=200 mixing_beta = 0.7 / &ions upscale=10 / ATOMIC_SPECIES Ni 58.69 Ni.pbe-nd-rrkjus.UPF Al 26.98 Al.pbe-n-van_ak.UPF O 16.00 O.pbe-rrkjus.UPF ATOMIC_POSITIONS {crystal} Ni 0.000000000 0.000000000 0.000000000 Ni -0.000000000 -0.000000000 0.247992113 Ni -0.000000000 -0.000000000 0.495984226 Ni 0.000000000 0.500000000 0.000000000 .... O -0.000002801 -0.695543049 0.704618081 O -0.028885007 -0.333327809 0.617873620 O 0.362212748 -1.028876505 0.617873591 O 0.666663767 -0.637778737 0.617873627 Al 0.333330268 -0.666660823 0.737258713 Al 0.333330525 -0.666661167 0.845466117 CELL_PARAMETERS 1.0000000000 0.0000000000 0.0000000000 0.5000000000 0.8660254038 0.0000000000 0.0000000000 0.0000000000 4.9386941745 K_POINTS automatic 4 4 1 0 0000 0000 -- End of input -- Thanks in advance. ________________________________________ You Lin Department of Physics University of South Florida 4202 East Fowler Avenue Tampa, FL 33620 ________________________________________ Tel: (813)396-9220 [Office] Homepage: http://shell.cas.usf.edu/~ylin ________________________________________ From wmbmacam at lg.ehu.es Thu Jan 26 18:03:33 2006 From: wmbmacam at lg.ehu.es (=?UTF-8?B?TWlndWVsIE1hcnTDrW5leiBDYW5hbGVz?=) Date: Thu, 26 Jan 2006 18:03:33 +0100 Subject: [Pw_forum] vc-md question Message-ID: <43D900E5.4070907@lg.ehu.es> Hello everybody, I'm trying to relax a GeH4 structure at some 76GPa, for which I am doing a vc-md calculation. The problem is that the run always ends at 50 iterations. If I use the last structure in the input and re-run it, it still doesn't end after 50 iterations. And that has happened four times. This might point to a low dt. So, I have changed dt from 20 to 200 (50 iterations seemed too much, so I thought it was an order-of-magnitude question). But then, the structure went crazy... which I expected if dt was way too large. Just in case this is relevant, doing a scf run with the last structure will give me small forces and the stress tensor is nearly diag(a,a,a). The forces on the ions that should move more are relatively small, and a relax run would easily take care of them. 1) Is this normal? When I was using VASP, I could set a fixed volume and relax the structure, and it would converge pretty fast if the starting input wasn't too far off. In this case, the starting structure shouldn't be far off, as it has been modified from a VASP output at 72GPa (the change in volume from 72 to 76 GPa's is pretty small). 2) On another ground, why are the stresses shown in a scf run and in a vc-md run different? Aren't they calculated using the Feynman-Hellman theorem with the knwon wavefunctions? How are they calculated in each case? 3) Would a cp or fpmd run be better suited for my needs (good relax for a future phonon calculation)? 4) VASP featured fixing some atoms. As far as I know, espresso doesn't allow this (at least for pw.x runs). Am I totally wrong? Side note: I'm running ESPRESSO v3.0. Under espresso 2.1.5, the Wentzkovitz lagrangian seemed to not evolve, while the Parrinelo-Raman lagrangian would not run unless nosym=.true. was stated. The pw.x input is the following: cat > geh4.scf.in << EOF &control calculation='vc-md' title='Germane at 75GPa', restart_mode='from_scratch', tstress = .true. tprnfor = .true. prefix='h', dt = 2.0d1, etot_conv_thr = 1.0d-5 forc_conv_thr = 1.0d-4 pseudo_dir = '$PSEUDO_DIR/', outdir='$TMP_DIR/' / &system ibrav= 7, celldm(1) =6.162, celldm(3)=1.28604, nat= 5, ntyp= 2, ecutwfc =50.0, ecutrho=400.0, occupations='smearing', smearing='methfessel-paxton', degauss=0.02 / &electrons conv_thr = 1.0d-8 mixing_beta = 0.7 / &ions ion_dynamics='beeman' / &cell cell_dynamics='w' press =760.0D0 cell_factor =2.0 / ATOMIC_SPECIES Ge 72.612 Ge.pw91-n-van.UPF H 1.00797 H.pw91-van_ak.UPF ATOMIC_POSITIONS Ge 0.00 0.00 0.00 H 0.50 0.00 0.00 H 0.00 0.50 0.00 H 0.00 0.00 0.4691 H 0.00 0.00 -0.4691 K_POINTS {automatic} 10 10 10 1 1 1 EOF Thanks in advance, Miguel PS: I'm running this on an Itanium 2 cluster, having compiled espresso with Intel Fortran Compiler v8 and mkl v8, just in case it matters. -- ---------------------------------------- Miguel Mart?nez Canales Dto. F?sica de la Materia Condensada UPV/EHU Facultad de Ciencia y Tecnolog?a Apdo. 644 48080 Bilbao (Spain) Fax: +34 94 601 3500 Tlf: +34 94 601 5437 ---------------------------------------- "I don't think that Debian can really compete with Gentoo. Sure it might be okay, but when it comes to dependencies, you probably are still going to have to get them all on your own. Or is there something like portage in the Debian world as well?" Annonymous From stewart at cnf.cornell.edu Thu Jan 26 18:06:35 2006 From: stewart at cnf.cornell.edu (stewart at cnf.cornell.edu) Date: Thu, 26 Jan 2006 12:06:35 -0500 Subject: [Pw_forum] Re: convergence NOT achieved, stopping In-Reply-To: References: Message-ID: <20060126170635.11508.qmail@xuxa.iecc.com> Hi You Lin, I would suggest increasing degauss to at least 0.02. This could help with convergence. In addition, it may help to increase the number of k-points used in your calculation. However, interfaces between oxides and metals can be very tricky due to the formation of a Schottky barrier. Another approach to consider would be to make a superlattice of Nickle and Alumina. The convergence may improve in this case and it you have enough layers, it should provide some insight into interface properties. Best regards, Derek You Lin writes: > Dear pwscf developers or users: > > I tried pwscf on an interface between Nickle and Alumina. > The self-consistent calculation cannot finish with the following error: > > convergence NOT achieved, stopping > > I found this in the manual: > -- > Self-consistency is slow or does not converge. > > [...] If the highest occupied and lowest unoccupied state(s) keep > exchanging place during self-consistency, forget about reaching > convergence. A typical sign of such behavior is that the self-consistency > error goes down, down, down, than all of a sudden up again, and so on. > Usually one can solve the problem by adding a few empty bands and a > broadening. > -- > > So I tried to manually assign more empty bands and degauss=0.0002. > I still get oscillations in total energy. The last a few total energies > are listed below: > > total energy = -2803.40138682 ryd > total energy = -2830.79824814 ryd > total energy = -2819.95336489 ryd > total energy = -2846.17498280 ryd > total energy = -2838.30750908 ryd > total energy = -2816.89515320 ryd > total energy = -2844.65794627 ryd > total energy = -2851.17678186 ryd > total energy = -2857.26598638 ryd > total energy = -2851.22021650 ryd > total energy = -2803.07516948 ryd > total energy = -2831.39193734 ryd > total energy = -2819.19178874 ryd > total energy = -2846.04973420 ryd > total energy = -2836.37911313 ryd > total energy = -2817.70612317 ryd > total energy = -2842.03435570 ryd > total energy = -2850.49039020 ryd > total energy = -2857.53771242 ryd > total energy = -2851.23397342 ryd > total energy = -2800.87394328 ryd > total energy = -2831.32149373 ryd > total energy = -2819.05136878 ryd > > Looks like the problem still exists. I didn't finish this calculation > since it doesn't seem to converge anyway. > Is there solution out of this problem? > > More info: > I'm using espresso 3.0 running both in series and in parallel. > My input file is: > -- Start of input -- > &control > calculation='relax' > restart_mode='from_scratch', > pseudo_dir = '/homes/r40/ylin/Del/Run/pwscf/espresso-3.0/pseudo/', > outdir='/scratch1/ylin/tmp/3.0/' > prefix='al2o3' > tprnfor = .true., nstep=20, dt=100. > tstress = .true., verbosity='high' > / > &system > ibrav=0, celldm(1) =9.4176391165, nat=46, ntyp=3, nbnd=230, > ecutwfc = 26, ecutrho = 288.0, nspin = 2, > starting_magnetization(1)=0.7, > occupations='smearing', smearing='methfessel-paxton', degauss=0.0002 > / > &electrons > diagonalization='david' > conv_thr = 1.0e-2, electron_maxstep=200 > mixing_beta = 0.7 > / > &ions > upscale=10 > / > ATOMIC_SPECIES > Ni 58.69 Ni.pbe-nd-rrkjus.UPF > Al 26.98 Al.pbe-n-van_ak.UPF > O 16.00 O.pbe-rrkjus.UPF > ATOMIC_POSITIONS {crystal} > Ni 0.000000000 0.000000000 0.000000000 > Ni -0.000000000 -0.000000000 0.247992113 > Ni -0.000000000 -0.000000000 0.495984226 > Ni 0.000000000 0.500000000 0.000000000 > .... > O -0.000002801 -0.695543049 0.704618081 > O -0.028885007 -0.333327809 0.617873620 > O 0.362212748 -1.028876505 0.617873591 > O 0.666663767 -0.637778737 0.617873627 > Al 0.333330268 -0.666660823 0.737258713 > Al 0.333330525 -0.666661167 0.845466117 > CELL_PARAMETERS > 1.0000000000 0.0000000000 0.0000000000 > 0.5000000000 0.8660254038 0.0000000000 > 0.0000000000 0.0000000000 4.9386941745 > K_POINTS automatic > 4 4 1 0 0000 0000 > -- End of input -- > > Thanks in advance. > > ________________________________________ > > You Lin > > Department of Physics > University of South Florida > 4202 East Fowler Avenue > Tampa, FL 33620 > ________________________________________ > > Tel: (813)396-9220 [Office] > > Homepage: http://shell.cas.usf.edu/~ylin > ________________________________________ > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum ################################ Derek Stewart, Ph. D. Scientific Computation Associate 250 Duffield Hall Cornell Nanoscale Facility (CNF) Ithaca, NY 14853 stewart (at) cnf.cornell.edu (607) 255-2856 From eyvaz_isaev at yahoo.com Thu Jan 26 18:45:49 2006 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Thu, 26 Jan 2006 09:45:49 -0800 (PST) Subject: [Pw_forum] convergence NOT achieved, stopping In-Reply-To: Message-ID: <20060126174549.61210.qmail@web60320.mail.yahoo.com> Hi, --- You Lin wrote: > smearing='methfessel-paxton', degauss=0.0002 degauss - as already replied by Stewart. > conv_thr = 1.0e-2, This one looks not a good choice. Decrease at least down to 1e-6 (and test with lower threshold). > mixing_beta = 0.7 Try 0.1 and combine it with mixing_mode='local-TF' Hope they help. Bests, Eyvaz. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From giannozz at nest.sns.it Thu Jan 26 18:53:57 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 26 Jan 2006 18:53:57 +0100 Subject: [Pw_forum] espresso3.0 different results in serial and paralel mode... In-Reply-To: <53174.132.166.17.128.1138292105.squirrel@dsm-mail> References: <52752.132.166.17.128.1138285823.squirrel@dsm-mail> <20060126154954.47178.qmail@web52013.mail.yahoo.com> <53174.132.166.17.128.1138292105.squirrel@dsm-mail> Message-ID: <200601261853.57812.giannozz@nest.sns.it> I have occasionally seen small numerical differences to build up into rather different convergence pattern. There is nothing obviously wrong in your input and output data. P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From ylin at shell.cas.usf.edu Thu Jan 26 19:46:34 2006 From: ylin at shell.cas.usf.edu (You Lin) Date: Thu, 26 Jan 2006 13:46:34 -0500 (EST) Subject: [Pw_forum] Re: convergence NOT achieved, stopping Message-ID: Thanks Derek and Eyvaz for the reply. However, I've already tried some of the suggestions before. There may be only two more things I can try: One is mixing_mode='local-TF' with mixing_beta=0.1 The other is increase the thickness of metal layer though I already have 7 layers(10angstrom) in the system. I'll tell you my result. >Hi, > >--- You Lin wrote: > >> smearing='methfessel-paxton', degauss=0.0002 >degauss - as already replied by Stewart. I tried degauss=0.02 before. > >> conv_thr = 1.0e-2, >This one looks not a good choice. Decrease at least >down to 1e-6 (and test with lower threshold). I know this is not a good choice, I set it this just to see if it can actually converge at this threshold. > >> mixing_beta = 0.7 >Try 0.1 and combine it with >mixing_mode='local-TF' This is what I'm going to try. > >Hope they help. > >Bests, >Eyvaz. ________________________________________ You Lin Department of Physics University of South Florida 4202 East Fowler Avenue Tampa, FL 33620 ________________________________________ Tel: (813)396-9220 [Office] Homepage: http://shell.cas.usf.edu/~ylin ________________________________________ From konstantin_kudin at yahoo.com Thu Jan 26 20:17:17 2006 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Thu, 26 Jan 2006 11:17:17 -0800 (PST) Subject: [Pw_forum] espresso3.0 different results in serial and paralel mode... In-Reply-To: <200601261853.57812.giannozz@nest.sns.it> Message-ID: <20060126191717.31967.qmail@web52007.mail.yahoo.com> --- Paolo Giannozzi wrote: > I have occasionally seen small numerical differences to build up > into rather different convergence pattern. There is nothing obviously > wrong in your input and output data. > > P. Is it because of the Davidson diagonalization that the energies start out being different already in the 4th decimal? Is there a way to make Davidson more consistent on the same architecture across different number of cpus ? Kostya 24 cycles 14 cycles -60.71941104 ryd -60.71926701 ryd -60.87616961 ryd -60.87606685 ryd -60.93436141 ryd -60.93425941 ryd -60.94178319 ryd -60.94173473 ryd -60.94499615 ryd -60.94496133 ryd -60.94572162 ryd -60.94571298 ryd -60.94603043 ryd -60.94605170 ryd -60.94617844 ryd -60.94617143 ryd -60.94620809 ryd -60.94618108 ryd -60.94620408 ryd -60.94620173 ryd -60.94620190 ryd -60.94620857 ryd -60.94620338 ryd -60.94620933 ryd -60.94621029 ryd -60.94620993 ryd -60.94620677 ryd -60.94620707 ryd -60.94620774 ryd -60.94620773 ryd -60.94620618 ryd -60.94620822 ryd -60.94620901 ryd -60.94620985 ryd -60.94621110 ryd -60.94621099 ryd __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From giannozz at nest.sns.it Fri Jan 27 09:54:46 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 27 Jan 2006 09:54:46 +0100 Subject: [Pw_forum] espresso3.0 different results in serial and paralel mode... In-Reply-To: <20060126191717.31967.qmail@web52007.mail.yahoo.com> References: <20060126191717.31967.qmail@web52007.mail.yahoo.com> Message-ID: <200601270954.46276.giannozz@nest.sns.it> On Thursday 26 January 2006 20:17, Konstantin Kudin wrote: > > I have occasionally seen small numerical differences to build up > > into rather different convergence pattern. There is nothing obviously > > wrong in your input and output data. > > > > P. > > Is it because of the Davidson diagonalization that the energies start > out being different already in the 4th decimal? Is there a way to make > Davidson more consistent on the same architecture across different > number of cpus ? maybe there is a way, but I don't know it. As far as I know there is nothing numerically inaccurate in either the diagonalization or the charge mixing. In this specific case, some starting wavefunctions that are initialized with random numbers. There is no warranty that they are the same for different machines/number of processors/phases of the moon. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From ylin at shell.cas.usf.edu Fri Jan 27 15:05:43 2006 From: ylin at shell.cas.usf.edu (You Lin) Date: Fri, 27 Jan 2006 09:05:43 -0500 (EST) Subject: [Pw_forum] Re: convergence NOT achieved, stopping In-Reply-To: References: Message-ID: > One is mixing_mode='local-TF' with mixing_beta=0.1 This option works smoothly. Sorry, I still don't know how to post a follow up and I cannot find a help anywhere. Anybody could tell me how to post a follow up? Thank you very much! On Thu, 26 Jan 2006, You Lin wrote: > Thanks Derek and Eyvaz for the reply. However, I've already tried some of > the suggestions before. > There may be only two more things I can try: > > One is mixing_mode='local-TF' with mixing_beta=0.1 > > The other is increase the thickness of metal layer though I already have 7 > layers(10angstrom) in the system. > > I'll tell you my result. > > >Hi, > > > >--- You Lin wrote: > > > >> smearing='methfessel-paxton', degauss=0.0002 > >degauss - as already replied by Stewart. > > I tried degauss=0.02 before. > > > > >> conv_thr = 1.0e-2, > >This one looks not a good choice. Decrease at least > >down to 1e-6 (and test with lower threshold). > > I know this is not a good choice, I set it this just to see if it can > actually converge at this threshold. > > > > >> mixing_beta = 0.7 > >Try 0.1 and combine it with > >mixing_mode='local-TF' > > This is what I'm going to try. > > > > >Hope they help. > > > >Bests, > >Eyvaz. > > > > ________________________________________ > > You Lin > > Department of Physics > University of South Florida > 4202 East Fowler Avenue > Tampa, FL 33620 > ________________________________________ > > Tel: (813)396-9220 [Office] > > Homepage: http://shell.cas.usf.edu/~ylin > ________________________________________ > > ________________________________________ You Lin Department of Physics University of South Florida 4202 East Fowler Avenue Tampa, FL 33620 ________________________________________ Tel: (813)396-9220 [Office] Homepage: http://shell.cas.usf.edu/~ylin ________________________________________ From giannozz at nest.sns.it Fri Jan 27 19:17:00 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 27 Jan 2006 19:17:00 +0100 Subject: [Pw_forum] Re: convergence NOT achieved, stopping In-Reply-To: References: Message-ID: <200601271917.00901.giannozz@nest.sns.it> On Friday 27 January 2006 15:05, You Lin wrote: > > One is mixing_mode='local-TF' with mixing_beta=0.1 > > This option works smoothly. > Sorry, I still don't know how to post a follow up and I cannot find a help > anywhere. Anybody could tell me how to post a follow up? isn't what you just posted a "follow-up" ? Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From ylin at shell.cas.usf.edu Fri Jan 27 19:52:07 2006 From: ylin at shell.cas.usf.edu (You Lin) Date: Fri, 27 Jan 2006 13:52:07 -0500 (EST) Subject: [Pw_forum] Re: convergence NOT achieved, stopping In-Reply-To: References: Message-ID: On Fri, 27 Jan 2006, You Lin wrote: > > One is mixing_mode='local-TF' with mixing_beta=0.1 > > This option works smoothly. > Sorry, I still don't know how to post a follow up and I cannot find a help > anywhere. Anybody could tell me how to post a follow up? > > Thank you very much! > >isn't what you just posted a "follow-up" ? > >Paolo Never mind. I didn't realize I did posted a "follow-up". Thanks anyway. ________________________________________ You Lin Department of Physics University of South Florida 4202 East Fowler Avenue Tampa, FL 33620 ________________________________________ Tel: (813)396-9220 [Office] Homepage: http://shell.cas.usf.edu/~ylin ________________________________________ From naromero at gmail.com Fri Jan 27 20:49:47 2006 From: naromero at gmail.com (Nichols A. Romero) Date: Fri, 27 Jan 2006 14:49:47 -0500 Subject: [Pw_forum] PWSCF 3.0 and XCrysDen 1.4.1 Message-ID: <6ac064b60601271149v4190186axfda12c8eabff8bab@mail.gmail.com> Hi, Has anyone observed incompatibility problems between PWSCF 3.0 and XCrysDen 1.4.1? For me, it works on some output files, but never consistently. The awk parser seems to either generate an error, or take forever to parse a modest size output file. I am using PWSCF 3.0 and XCrysDen 1.4.1 statically linked binary (linux) from the web site. I execute xcrysden --pw_out filename Does anyone have an alternative? Say some perl script that can convert PWSCF output into an XSF anim file? Thanks, -- Nichols A. Romero, Ph.D. 1613 Denise Dr. Apt. D Forest Hill, MD 21050 443-567-8328 (C) 410-306-0709 (O) From konstantin_kudin at yahoo.com Sun Jan 29 18:41:08 2006 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Sun, 29 Jan 2006 09:41:08 -0800 (PST) Subject: [Pw_forum] FFT & MPI - issues with latency In-Reply-To: <6ac064b60601271149v4190186axfda12c8eabff8bab@mail.gmail.com> Message-ID: <20060129174108.81898.qmail@web52010.mail.yahoo.com> Hi all, I am wondering if anybody has investigated systematically the performance of different MPI implementations with the QE package. Was anyone successful in using OPEN-MPI which is the project spawned off by the LAM-MPI people ? The issue seem to be that FFTs are very latency driven, and here are some tests from the past http://www.hpc.sfu.ca/bugaboo/fft-performance.html which seem to indicate that MPICH and LAM-MPI differ significantly with respect to their performance as it applies to the FFTW library. For the largest 2d transform (1600x1600) it appears that LAM-MPI is way better than MPICH on 8 cpus. These are pretty old versions, but anyway, it is some quantitative data which is interesting to look at. The experience we have here with QE on dual Opterons is that there is no gain in the cpu time at all if one goes above 2 nodes with 2 cpus using Gigabit. CPMD on this Opteron cluster behaved pretty much identically to CP, thus indicating that the problem transends slight differences in implementations. Nicola's bencharks with LAM-MPI [ http://nnn.mit.edu/ESPRESSO/CP90_tests/CP90.timings.large ] seemed to indicate that there was some improvement after 4 cpus. So now I am starting to think that MPICH may be responsible for no improvement at all above 4 cpus. Ideas ? Kostya __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From akohlmey at vitae.cmm.upenn.edu Sun Jan 29 21:02:50 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Sun, 29 Jan 2006 15:02:50 -0500 (EST) Subject: [Pw_forum] FFT & MPI - issues with latency In-Reply-To: <20060129174108.81898.qmail@web52010.mail.yahoo.com> Message-ID: On Sun, 29 Jan 2006, Konstantin Kudin wrote: KK> Hi all, hi kostya, KK> I am wondering if anybody has investigated systematically the KK> performance of different MPI implementations with the QE package. Was KK> anyone successful in using OPEN-MPI which is the project spawned off by KK> the LAM-MPI people ? you are opening a _big_ can of worms. not only the different implementations matter, there are also several tunable parameters for each of them, that may or may not help. KK> The issue seem to be that FFTs are very latency driven, and here are KK> some tests from the past KK> http://www.hpc.sfu.ca/bugaboo/fft-performance.html which seem to KK> indicate that MPICH and LAM-MPI differ significantly with respect to KK> their performance as it applies to the FFTW library. it is not the fft itself, but a _distributed_ fft, where the performance basically boils down to the performance of the MPI_AllToAll implementation. the observation in the URL is still consistent with my more recent experiments, IFF you are using ethernet communication. here the TCP/IP overhead is very high and LAM-MPI has the better collective communication algorithms. still the extremely large overhead of the TCP/IP limits the scaling significantly. the picture changes, however, in the case of myrinet interconnect, where the currently released LAM/MPI version is still not optimal and has higher latencies compared to MPICH-gm. KK> The experience we have here with QE on dual Opterons is that there is KK> no gain in the cpu time at all if one goes above 2 nodes with 2 cpus KK> using Gigabit. CPMD on this Opteron cluster behaved pretty much KK> identically to CP, thus indicating that the problem transends slight note that this is only true for the G/R-space decomposition. the scaling in that case is indeed very limited, but for large enough problems you may be able to go up to 6-8 nodes. in the case of CPMD there is an additional improvement, when you cache the G-space to R-space fourier transforms using REAL SPACE WFN KEEP and thus limit the dependency of all-to-all. KK> differences in implementations. Nicola's bencharks with LAM-MPI [ KK> http://nnn.mit.edu/ESPRESSO/CP90_tests/CP90.timings.large ] seemed to KK> indicate that there was some improvement after 4 cpus. KK> KK> So now I am starting to think that MPICH may be responsible for no KK> improvement at all above 4 cpus. to get a reasonable scaling you first have to get a low latency communication. this is most easily (but also at a high cost) achieved by buying hardware (myrinet, infiniband, dolphin-SCI, quadrics), but there are also some MPI implementations, that support communication, that bypasses the TCP layer, e.g. scali, and parastation. see. http://www.scali.com http://www.cluster-competence-center.com/ccc2.php?page=parastation&lang=en that latter is supposedly available at no cost for academic institutions now. BTW: both packages started as modified MPICH version. i have done a test with parastation when it was fully commercial and found some improvements, but not enough to warrant at that time the price compared to the gain from buying faster communication hardware. if you want to get to _extreme_ scaling, latency is all that matters. then even the operating system, that is running a lot of stuff in the background can become a problem. extremely scalable machines like BG/L or Cray XT3 eliminate this by running parallel jobs in a transputer style, i.e. by having a modified kernel on the compute nodes, that will run only one process: your computation. e.g., on a cray xt3 i was recently able to run a pw.x job across 768 processors (12 k-points, = 64 PEs per k-point), where the performance was only limited by the wavefunction i/o. if we would have an option diskio='none', that would probably give a much better performace and scale even better. on the same machine using CPMD with all available tricks enabled, one could scale a 100ry / 32 water system easily to 1024 processors, where the time spent on i/o would limit further scaling. KK> KK> Ideas ? my conclusion is: if you have the money, buy the hardware. in that case you should also have an eye on the topology. the more nodes you want to hook up, the larger the advantage of switchless, 2-d or 3-d torus communication (dolphin-sci, cray-xt3, BG/L) over switch based systems like myrinet and infiniband. for many nodes you have to build CLOS-networks and thus get additional latencies and suffer from backplane bandwidth limitations. if you don't have the money, support people working on TCP-bypass MPI implementations and hope for the best. for the (comparatively small) differences between current MPI implementations, i would prefer correctness and convenience over speed. if a package is difficult to use, people will waste more time on failed jobs, than you'd gain from the faster library. also improving the QE code itself to reduce or avoid those 'costly' operations, is probably more useful. best regards, axel. KK> KK> Kostya KK> KK> __________________________________________________ KK> Do You Yahoo!? KK> Tired of spam? Yahoo! Mail has the best spam protection around KK> http://mail.yahoo.com KK> _______________________________________________ KK> Pw_forum mailing list KK> Pw_forum at pwscf.org KK> http://www.democritos.it/mailman/listinfo/pw_forum KK> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From marzari at MIT.EDU Mon Jan 30 06:01:32 2006 From: marzari at MIT.EDU (Nicola Marzari) Date: Mon, 30 Jan 2006 00:01:32 -0500 Subject: [Pw_forum] FFT & MPI - issues with latency In-Reply-To: References: Message-ID: <43DD9DAC.60501@mit.edu> Dear Kostya, Alex, this is our datapoint on reasonably good scaling for small clusters (i.e. assuming that one should leave hardware for massive parallelism to the experts): http://nnn.mit.edu/ESPRESSO/CP90_tests/CP_2_1_3_half.pdf We have a cluster of 32 Dell 1425 3.2 GHz dual-xeons, grouped in 4 nodes of 8 dual-xeons. Each node has its own private gigabit ethernet network, so we can run on up to 16 cpus on each node (each dual-xeon in one node is connected locally to the other dual-xeons on the same node with a dedicated 8-port gigabit switch; all dual-xeon are also connected, with their second gigabit port, to the master via a global master switch, that has no MPI traffic on it.) The results for a medium sized job ("half", 243 bands of AgI in a 30^ a.u. cell) are in the page above - more details on the job are in http://nnn.mit.edu/ESPRESSO/CP90_tests/, in the timings file (it's the "half" job, i.e. half the electrons of large.j). As you can see, scaling up to 8 blades works unexpectedly well (another slightly older cluster of ours saturated at around 6 blades). Also, the second CPU on a dual-xeon adds very little, due to the limited memory bandwidth (Opterons would do much better in scaling from 1 to 2 CPUs on the same motherboard, but do not do as well in single-CPU performance). So, if I were to purchase now, I would go with PIVs with the fastest front side bus and ram (1066 MHz and 667-5300, resepctively), grouped in small nodes of ~6 CPUs. nicola Axel Kohlmeyer wrote: > On Sun, 29 Jan 2006, Konstantin Kudin wrote: > > KK> Hi all, > > hi kostya, > --------------------------------------------------------------------- Prof Nicola Marzari Department of Materials Science and Engineering 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu From giannozz at nest.sns.it Mon Jan 30 10:10:21 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 30 Jan 2006 10:10:21 +0100 Subject: [Pw_forum] vc-md question In-Reply-To: <43D900E5.4070907@lg.ehu.es> References: <43D900E5.4070907@lg.ehu.es> Message-ID: <200601301010.21511.giannozz@nest.sns.it> On Thursday 26 January 2006 18:03, Miguel Mart?nez Canales wrote: > 2) On another ground, why are the stresses shown in a scf run and > in a vc-md run different? they shouldn't be (and I am quite sure they aren't). Are you by any chance using the modified kinetic energy functional in vc-md runs? > 3) Would a cp or fpmd run be better suited for my needs (good > relax for a future phonon calculation)? I don't think so: you can find the optimized structure with a series of calculations at fixed volumes and c/a, if this is all you need. > 4) VASP featured fixing some atoms. As far as I know, espresso > doesn't allow this (at least for pw.x runs). Am I totally wrong? don't be so pessimistic: you are wrong on this specific point only :-) See the definition of ATOMIC_POSITIONS , variables if_pos. > Side note: I'm running ESPRESSO v3.0. Under espresso 2.1.5, > the Wentzkovitz lagrangian seemed to not evolve there were some problems in previous versions with variable-cell dynamics, but they should have been fixed in 2.1.5, AFAIK. Unfortunately nobody seems to be interested in maintaining the variable-cell stuff. I am seriously considering removing it altogether from future releases. > while the Parrinelo-Raman lagrangian would not run unless > nosym=.true. was stated. this is correct: since the Parrinello-Rahman may break the symmetry, you cannot rely on symmetry to reduce the number of k-points Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From roma at srmp19.saclay.cea.fr Mon Jan 30 10:22:22 2006 From: roma at srmp19.saclay.cea.fr (Guido Roma) Date: Mon, 30 Jan 2006 10:22:22 +0100 Subject: [Pw_forum] vc-md question In-Reply-To: <200601301010.21511.giannozz@nest.sns.it> References: <43D900E5.4070907@lg.ehu.es> <200601301010.21511.giannozz@nest.sns.it> Message-ID: <1138612942.28983.9.camel@srmp19.saclay.cea.fr> On Mon, 2006-01-30 at 10:10, Paolo Giannozzi wrote: > there were some problems in previous versions with variable-cell > dynamics, but they should have been fixed in 2.1.5, AFAIK. > Unfortunately nobody seems to be interested in maintaining > the variable-cell stuff. I am seriously considering removing it > altogether from future releases. > Hi all, I think it is useful in some cases, I used it for calculating formation volume of defects. It is true that for this kind of duty one could simply have a conjugate gradient (or BFGS) minimization of position together with cell parameters. Guido > > while the Parrinelo-Raman lagrangian would not run unless > > nosym=.true. was stated. > > this is correct: since the Parrinello-Rahman may break the symmetry, > you cannot rely on symmetry to reduce the number of k-points > > Paolo From roma at srmp19.saclay.cea.fr Mon Jan 30 10:23:48 2006 From: roma at srmp19.saclay.cea.fr (Guido Roma) Date: Mon, 30 Jan 2006 10:23:48 +0100 Subject: [Pw_forum] vc-md question P.S.: In-Reply-To: <200601301010.21511.giannozz@nest.sns.it> References: <43D900E5.4070907@lg.ehu.es> <200601301010.21511.giannozz@nest.sns.it> Message-ID: <1138613028.28926.11.camel@srmp19.saclay.cea.fr> > there were some problems in previous versions with variable-cell > dynamics, but they should have been fixed in 2.1.5, AFAIK. > Unfortunately nobody seems to be interested in maintaining > the variable-cell stuff. I am seriously considering removing it > altogether from future releases. P.S.: of course I was thinking of vc-relax (damped dynamics) in my previous message. Guido -- Guido Roma -- CEA-Saclay - DEN/DMN/SRMP Bat.520/130 Phone: [+33]-1-69085738 -- Fax: ...6867 -- Mobile: [+33]-6-20069085 From giannozz at nest.sns.it Mon Jan 30 10:43:34 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 30 Jan 2006 10:43:34 +0100 Subject: [Pw_forum] PWSCF 3.0 and XCrysDen 1.4.1 In-Reply-To: <6ac064b60601271149v4190186axfda12c8eabff8bab@mail.gmail.com> References: <6ac064b60601271149v4190186axfda12c8eabff8bab@mail.gmail.com> Message-ID: <200601301043.34499.giannozz@nest.sns.it> On Friday 27 January 2006 20:49, Nichols A. Romero wrote: > Has anyone observed incompatibility problems between PWSCF 3.0 and > XCrysDen 1.4.1? For me, it works on some output files, but never > consistently. The awk parser seems to either generate an error, or > take forever to parse a modest size output file. please post (modest-size) cases in which the parser doesn't work. P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From tone.kokalj at ijs.si Mon Jan 30 11:04:03 2006 From: tone.kokalj at ijs.si (Tone Kokalj) Date: Mon, 30 Jan 2006 11:04:03 +0100 Subject: [Pw_forum] PWSCF 3.0 and XCrysDen 1.4.1 In-Reply-To: <200601301043.34499.giannozz@nest.sns.it> References: <6ac064b60601271149v4190186axfda12c8eabff8bab@mail.gmail.com> <200601301043.34499.giannozz@nest.sns.it> Message-ID: <43DDE493.6040908@ijs.si> Paolo Giannozzi wrote: >On Friday 27 January 2006 20:49, Nichols A. Romero wrote: > > > >>Has anyone observed incompatibility problems between PWSCF 3.0 and >>XCrysDen 1.4.1? For me, it works on some output files, but never >>consistently. The awk parser seems to either generate an error, or >>take forever to parse a modest size output file. >> >> > >please post (modest-size) cases in which the parser doesn't work. > >P. > > Indeed so! Without the "problematic" output files it is difficult to say anything, (the parser works well for my cases) Tone From merlin.meheut at lmcp.jussieu.fr Fri Jan 27 16:42:24 2006 From: merlin.meheut at lmcp.jussieu.fr (merlin.meheut at lmcp.jussieu.fr) Date: Fri, 27 Jan 2006 16:42:24 +0100 Subject: [Pw_forum] Pressure calculations at gamma (version espresso 2.1.4) Message-ID: <1138376544.43da3f600db98@www.impmc.jussieu.fr> Dear pwscf authors, I wanted to signal a strange feature of pressure calculations when you put the option K_points {gamma} with scf calculations. My system is a water molecule inside a supercell of 30 Bohr radius. I recognize that pressure has no real physical sense in this system. Nevertheless, I am surprized that the pressure calculated with k = 0, with the espresso 2.1.4 version (-20 kbars), is such different from the pressure calculated: - at k=0, with the version pw.1.3.0 - at k different from zero (I tried k=0.5 0.5 0.5 , and k=0.0, 0.0, 0.5), with the espresso 2.1.4. In the two last situations, the found pressure is of -0.1 kbars (let's say 0.0). I can also mention that this pressure of -20 kbars is quite stable with convergency criteria and cutoff frequencies (from ecutwfc=60 to 130Ry and from conv_thr= 10-7 to 10-9). I think that we can conclude to an effect due to gamma-point specific algorithms. I don't know if it can create troubles in other circumstances, actually for other reasons I will not continue to investigate this trouble ( I am calculating phonon frequencies, and ph.x refuses to work with pw.x data files calculated at gamma: from phq_readin : error # 1 cannot start from pw.x data file using Gamma-point tricks ) My input files are partially contained in a precedent post. Greetings, Merlin ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From eyvaz_isaev at yahoo.com Mon Jan 30 13:30:13 2006 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Mon, 30 Jan 2006 04:30:13 -0800 (PST) Subject: [Pw_forum] Pressure calculations at gamma (version espresso 2.1.4) In-Reply-To: <1138376544.43da3f600db98@www.impmc.jussieu.fr> Message-ID: <20060130123013.55190.qmail@web60314.mail.yahoo.com> Hi Merlin, > calculating phonon frequencies, and ph.x refuses to > work with pw.x data files > calculated at gamma: > from phq_readin : error # 1 > cannot start from pw.x data file using > Gamma-point tricks ) > This is a famous message, and not an error. In order to calculate phonons you should not use the gamma-point based algorithm (please read carefully the message you have got). Instead you have to use a standard pw.x and specify K_POINTS {automatic} 1 1 1 0 0 0 Bests, Eyvaz > My input files are partially contained in a > precedent post. > > Greetings, > > Merlin > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet > Messaging Program. > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From konstantin_kudin at yahoo.com Mon Jan 30 13:35:31 2006 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Mon, 30 Jan 2006 04:35:31 -0800 (PST) Subject: [Pw_forum] FFT & MPI - issues with latency In-Reply-To: <43DD9DAC.60501@mit.edu> Message-ID: <20060130123531.16265.qmail@web52011.mail.yahoo.com> Axel, Nicola, thanks for sharing the experiences! I am actually wondering now if the benchmarks that Nicola posted did not have the 2nd Xeon cpu running threads with the GOTO or MKL libraries (launched on their own). If such threads were running, then that would make the 1 cpu per node times artifically low, making it look like the 2nd cpu adds very little. As far as Axel's comments go, the idea of caching the G-space to R-space fourier transforms sound intriguing. Perhaps going to 8 or even 16 cpus is nothing to high rollers like Axel :-) , however, for mere mortals using the regular Gigabit and cheap clusters that would be a step forward ! Also, this parastation for Gigabit-not-really-Gigabit sounded like it could reduce the latency with no new hardware. Was it implied that such a solution was somewhat unstable? How easy is it to get it running, and to use it afterwards? Kostya __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From akohlmey at vitae.cmm.upenn.edu Mon Jan 30 14:24:16 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Mon, 30 Jan 2006 08:24:16 -0500 (EST) Subject: [Pw_forum] FFT & MPI - issues with latency In-Reply-To: <20060130123531.16265.qmail@web52011.mail.yahoo.com> Message-ID: On Mon, 30 Jan 2006, Konstantin Kudin wrote: KK> Axel, Nicola, thanks for sharing the experiences! dear kostya, KK> I am actually wondering now if the benchmarks that Nicola posted did KK> not have the 2nd Xeon cpu running threads with the GOTO or MKL KK> libraries (launched on their own). If such threads were running, then KK> that would make the 1 cpu per node times artifically low, making it KK> look like the 2nd cpu adds very little. in my experience, this is less likely. some friend of mine made tests, and even if forcing MKL to using only one thread by setting the environment variable OMP_NUM_THREADS to 1, the pentium IV processors beat the opteron hands down. MKL does a fantastic job on those cpus. the only PC machines, where i found a _significant_ gain in using a multithreaded BLAS/LAPACK, were dual athlon MP 1600+/1800+ machines using an AMD MPX chipset, but on those using MPI over shared memory was even more efficient. as nicola pointed out, memory bandwith is a key issue (btw. this is true for both opteron and xeon) and dual processor on x86/em64t/amd64 for most scientific applications currently only makes sense with opteron. KK> As far as Axel's comments go, the idea of caching the G-space to KK> R-space fourier transforms sound intriguing. Perhaps going to 8 or even KK> 16 cpus is nothing to high rollers like Axel :-) , however, for mere KK> mortals using the regular Gigabit and cheap clusters that would be a KK> step forward ! i'm all for it. hell, i've done a lot of that kind of machine myself. my point was only, that i found, one has to consider the value of the time (and money) invested versus the gain. you cannot expect to get much further than the cluster of 8 nodes subclusters setup, that nicola was describing (which i think is a commendable idea for setting up a cost-efficient cluster solution for those plane wave codes, we all love/hate/use so much) KK> Also, this parastation for Gigabit-not-really-Gigabit sounded like it KK> could reduce the latency with no new hardware. Was it implied that such KK> a solution was somewhat unstable? How easy is it to get it running, and KK> to use it afterwards? it is definitely worth a try. when i tried it about two years ago, it was comparatively easy to setup. to me the most annoying part was having to run a separate license manager and being locked into their 'middleware' solution. stability was good. i would recommend, you try it, especially if you qualify for the acedemic (i.e. no-cost) licensing. axel KK> KK> Kostya KK> KK> __________________________________________________ KK> Do You Yahoo!? KK> Tired of spam? Yahoo! Mail has the best spam protection around KK> http://mail.yahoo.com KK> _______________________________________________ KK> Pw_forum mailing list KK> Pw_forum at pwscf.org KK> http://www.democritos.it/mailman/listinfo/pw_forum KK> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From wmbmacam at lg.ehu.es Mon Jan 30 15:46:12 2006 From: wmbmacam at lg.ehu.es (=?UTF-8?B?TWlndWVsIE1hcnTDrW5leiBDYW5hbGVz?=) Date: Mon, 30 Jan 2006 15:46:12 +0100 Subject: [Pw_forum] vc-md question In-Reply-To: <200601301010.21511.giannozz@nest.sns.it> References: <43D900E5.4070907@lg.ehu.es> <200601301010.21511.giannozz@nest.sns.it> Message-ID: <43DE26B4.9020809@lg.ehu.es> Hi again, First, I'd like to thank you for your answers. Now, a couple of things Paolo Giannozzi wrote: >>2) On another ground, why are the stresses shown in a scf run and >>in a vc-md run different? > > they shouldn't be (and I am quite sure they aren't). Are you by any > chance using the modified kinetic energy functional in vc-md runs? No, I am not using it. You can see my input on my firt e-mail (I did a copy and paste). However, I was wrong on this one. If I use all the decimal places, I get stresses right: very similar when doing a vc-md after a scf, and differing by about 0.4% when using the last vc-md output figures on a scf run. >>4) VASP featured fixing some atoms. As far as I know, espresso >>doesn't allow this (at least for pw.x runs). Am I totally wrong? > > don't be so pessimistic: you are wrong on this specific point only :-) > See the definition of ATOMIC_POSITIONS , variables if_pos. Thank you very much, Paolo. I misunderstood that if_pos only applied to neb and smd runs. > I am seriously considering removing it altogether from future releases. From pw only or from all codes? Is there another simple way of performing structural relaxation of noncubic structures? Especially with non-orthogonal cells at high pressure. To Guido Roma: Yes, I know that the default limit is 50 iterations and that I am hitting this limit. What puzzles me is that, after using the last vc-md coordinates in a re-run, it still doesn't finish in 50 iterations. If I repeat the process it will happen again. For this simple tetragonal structure it would be more efficient for me to see the stress at different c/a ratios and interpolate to achieve the desired result (as Paolo suggested), but I won't be facing tetragonal (or even orthorrombic structures) always. Thanks again to everybody, Miguel -- ---------------------------------------- Miguel Mart?nez Canales Dto. F?sica de la Materia Condensada UPV/EHU Facultad de Ciencia y Tecnolog?a Apdo. 644 48080 Bilbao (Spain) Fax: +34 94 601 3500 Tlf: +34 94 601 5437 ---------------------------------------- "I don't think that Debian can really compete with Gentoo. Sure it might be okay, but when it comes to dependencies, you probably are still going to have to get them all on your own. Or is there something like portage in the Debian world as well?" Annonymous From giannozz at nest.sns.it Mon Jan 30 18:56:08 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 30 Jan 2006 18:56:08 +0100 Subject: [Pw_forum] vc-md question In-Reply-To: <43DE26B4.9020809@lg.ehu.es> References: <43D900E5.4070907@lg.ehu.es> <200601301010.21511.giannozz@nest.sns.it> <43DE26B4.9020809@lg.ehu.es> Message-ID: <200601301856.08284.giannozz@nest.sns.it> On Monday 30 January 2006 15:46, Miguel Mart?nez Canales wrote: > I misunderstood that if_pos only applied to neb and smd runs. it was the documentation that was actually misleading > What puzzles me is that, after using the last vc-md coordinates > in a re-run, it still doesn't finish in 50 iterations. If I repeat the > process it will happen again. I think that there is presently no check on convergence, so if you keep sending jobs, it will keep running. Does it converge or not? By the way, there is also a 'vc-relax' option that is supposed to perform structural optimization. I am not sure if vc-md can actually do damped dynamics Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From wmbmacam at lg.ehu.es Mon Jan 30 19:41:56 2006 From: wmbmacam at lg.ehu.es (=?UTF-8?B?TWlndWVsIE1hcnTDrW5leiBDYW5hbGVz?=) Date: Mon, 30 Jan 2006 19:41:56 +0100 Subject: [Pw_forum] vc-md question In-Reply-To: <200601301856.08284.giannozz@nest.sns.it> References: <43D900E5.4070907@lg.ehu.es> <200601301010.21511.giannozz@nest.sns.it> <43DE26B4.9020809@lg.ehu.es> <200601301856.08284.giannozz@nest.sns.it> Message-ID: <43DE5DF4.4070906@lg.ehu.es> Hi again, Paolo > I think that there is presently no check on convergence, so if you > keep sending jobs, it will keep running. Does it converge or not? Ok, so there is no check. I should have known better. Use the source, Luke. Regarding convergence, it starts closing (slowly if dt is not good, obviously) and then it oscillates. Or that is what it seems. Some output at the end of the e-mail. > By the way, there is also a 'vc-relax' option that is supposed to > perform structural optimization. I am not sure if vc-md can > actually do damped dynamics I understood that vc-relax fully relaxes the structure. I mean, the target pressure of the relaxation is p=0. That is why I used vc-md. How do you compute equations of state for noncubic cells? Because maybe I am working in a very ineffective way. Oh! and vc-md not being damped might explain the following output: Input is the same as in first e-mail, but dt=100 (note: dt=150 leads to structure deestabilisation) and the following &system flags and ATOMIC_POS: ##################### &system ibrav= 7, celldm(1) =6.163307, celldm(3)=1.2845405, nat= 5, ntyp= 2, ... &cell cell_dynamics='w' press=760.0 cell_factor=1.5 / ... H 0.00 0.00 0.474478194 H 0.00 0.00 -0.474478194 ##################### Output (long and boring): $ grep bohr** geh4.scf.out total stress (ryd/bohr**3) (kbar) P= 760.49 total stress (ryd/bohr**3) (kbar) P= 760.78 total stress (ryd/bohr**3) (kbar) P= 760.12 total stress (ryd/bohr**3) (kbar) P= 760.52 total stress (ryd/bohr**3) (kbar) P= 759.82 total stress (ryd/bohr**3) (kbar) P= 760.42 total stress (ryd/bohr**3) (kbar) P= 759.61 total stress (ryd/bohr**3) (kbar) P= 760.44 total stress (ryd/bohr**3) (kbar) P= 759.40 total stress (ryd/bohr**3) (kbar) P= 760.71 total stress (ryd/bohr**3) (kbar) P= 760.74 total stress (ryd/bohr**3) (kbar) P= 760.80 total stress (ryd/bohr**3) (kbar) P= 760.27 total stress (ryd/bohr**3) (kbar) P= 760.49 total stress (ryd/bohr**3) (kbar) P= 760.06 total stress (ryd/bohr**3) (kbar) P= 760.14 total stress (ryd/bohr**3) (kbar) P= 759.93 total stress (ryd/bohr**3) (kbar) P= 759.75 total stress (ryd/bohr**3) (kbar) P= 759.83 total stress (ryd/bohr**3) (kbar) P= 759.55 total stress (ryd/bohr**3) (kbar) P= 759.64 total stress (ryd/bohr**3) (kbar) P= 759.39 total stress (ryd/bohr**3) (kbar) P= 759.76 total stress (ryd/bohr**3) (kbar) P= 759.62 total stress (ryd/bohr**3) (kbar) P= 759.54 total stress (ryd/bohr**3) (kbar) P= 759.44 total stress (ryd/bohr**3) (kbar) P= 759.63 total stress (ryd/bohr**3) (kbar) P= 759.54 total stress (ryd/bohr**3) (kbar) P= 758.71 total stress (ryd/bohr**3) (kbar) P= 758.70 total stress (ryd/bohr**3) (kbar) P= 758.93 total stress (ryd/bohr**3) (kbar) P= 758.87 total stress (ryd/bohr**3) (kbar) P= 759.46 total stress (ryd/bohr**3) (kbar) P= 759.23 total stress (ryd/bohr**3) (kbar) P= 759.58 total stress (ryd/bohr**3) (kbar) P= 759.60 total stress (ryd/bohr**3) (kbar) P= 759.92 total stress (ryd/bohr**3) (kbar) P= 759.90 total stress (ryd/bohr**3) (kbar) P= 760.20 total stress (ryd/bohr**3) (kbar) P= 760.47 total stress (ryd/bohr**3) (kbar) P= 760.19 total stress (ryd/bohr**3) (kbar) P= 760.54 total stress (ryd/bohr**3) (kbar) P= 760.84 total stress (ryd/bohr**3) (kbar) P= 760.80 -- ---------------------------------------- Miguel Mart?nez Canales Dto. F?sica de la Materia Condensada UPV/EHU Facultad de Ciencia y Tecnolog?a Apdo. 644 48080 Bilbao (Spain) Fax: +34 94 601 3500 Tlf: +34 94 601 5437 ---------------------------------------- "I don't think that Debian can really compete with Gentoo. Sure it might be okay, but when it comes to dependencies, you probably are still going to have to get them all on your own. Or is there something like portage in the Debian world as well?" Annonymous From giannozz at nest.sns.it Mon Jan 30 21:10:40 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 30 Jan 2006 21:10:40 +0100 Subject: [Pw_forum] Pressure calculations at gamma (version espresso 2.1.4) In-Reply-To: <1138376544.43da3f600db98@www.impmc.jussieu.fr> References: <1138376544.43da3f600db98@www.impmc.jussieu.fr> Message-ID: <200601302110.40302.giannozz@nest.sns.it> On Friday 27 January 2006 16:42, merlin.meheut at lmcp.jussieu.fr wrote: > Nevertheless, I am surprized that the pressure calculated with k = 0, > with the espresso 2.1.4 version (-20 kbars), is such different from the > pressure calculated: [...] > - at k different from zero (I tried k=0.5 0.5 0.5 , and k=0.0, 0.0, 0.5), > with the espresso 2.1.4. the correct comparison is between the pressure calculated using K_POINTS (Gamma) (using gamma-specific algorithms) and K_POINTS 1 0.0 0.0 0.0 1.0 (not using them). There was in some version a potential problem (an unitialized variable) with stress calculation that should have been fixed by now. > My input files are partially contained in a precedent post. there is no indication of the pseudopotentials used, so your input is useless P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Mon Jan 30 21:27:42 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 30 Jan 2006 21:27:42 +0100 Subject: [Pw_forum] vc-md question In-Reply-To: <43DE5DF4.4070906@lg.ehu.es> References: <43D900E5.4070907@lg.ehu.es> <200601301856.08284.giannozz@nest.sns.it> <43DE5DF4.4070906@lg.ehu.es> Message-ID: <200601302127.42391.giannozz@nest.sns.it> On Monday 30 January 2006 19:41, Miguel Mart?nez Canales wrote: > I understood that vc-relax fully relaxes the structure. I mean, the target > pressure of the relaxation is p=0. did you try? I would be surprised if relaxation at finite pressure was not implemented: it is a trivial extension of the p=0 case. Note however that the convergence of equilibrium volume with cutoff is veeery slow. P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From baroni at sissa.it Mon Jan 30 22:04:16 2006 From: baroni at sissa.it (Stefano Baroni) Date: Mon, 30 Jan 2006 22:04:16 +0100 Subject: [Pw_forum] About neb and smd In-Reply-To: <005401c60dbe$8d1f1690$1d00a8c0@solarflare> References: <005401c60dbe$8d1f1690$1d00a8c0@solarflare> Message-ID: Dear Huiqun Zhou: sorry for the (very) late reply On Dec 31, 2005, at 4:59 AM, Huiqun Zhou wrote: > Dear list-users, > > Could anyone give me a pointer whether it's theoretically > reasonable to investigate solid state > transition induced by pressure using NEB or string method? In principle, it is. In practice, I would have strong reservations. The energy difference between two different phases is an extensive quantity, hence the jump from one structure right to another would require to overcome an infinite energy barrier in the thermodynamic limit. The way structural transitions occur in nature is through nucleation: an energy fluctuation of the order of (K_B T) determines the change of structure in a small portion of the crystal which then gradually increases its size until it "eats" the whole system. In order to accomodate two different structures to coexist, a lot of defects are produced at the interface and the disturbance may extend far from the nucleaton center due to the long-range nature of the resulting elastic interactions. The energy barrier results from a delicate balance between the energy gain due to the phase transformation and the energy loss due to the creation of defects. As, noticed, the size of the perturbed region may be large, so that a direct simulation would require large supercells. > Any references are appreciated. I am not directly aware of any, but I would not be surprised if a few existed. Nor would I be surprised if most of them were wrong, just because of the temptation of simulating a direct jump between two phases just ignoring the nucleation process. > Happy New Year! All the same to you Stefano --- Stefano Baroni - SISSA & DEMOCRITOS National Simulation Center - Trieste [+39] 040 3787 406 (tel) -528 (fax) / stefanobaroni (skype) Please, if possible, don't send me MS Word or PowerPoint attachments Why? See: http://www.gnu.org/philosophy/no-word-attachments.html -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060130/f57f99f2/attachment.htm From degironc at sissa.it Tue Jan 31 09:22:15 2006 From: degironc at sissa.it (Stefano de Gironcoli) Date: Tue, 31 Jan 2006 09:22:15 +0100 Subject: [Pw_forum] vc-md question References: <43D900E5.4070907@lg.ehu.es> <200601301010.21511.giannozz@nest.sns.it> <43DE26B4.9020809@lg.ehu.es> <200601301856.08284.giannozz@nest.sns.it> <43DE5DF4.4070906@lg.ehu.es> Message-ID: <43DF1E37.3000205@sissa.it> As Paolo say vc related things are far from optimal... however it is possible tu use it to perform structural relaxation at finite pressure using it. Check information about namelist &CELL in file Doc/INPUT_PW calc='vc-md' performs variable cell MD (no damping) at the pressure specified by the variable press (in Kbar) in namelist &CELL using either Parrinelllo-Raman or Wentzcovitch extended lagrangian ( specified as cell_dynamics='pr' or cell_dynamics='w' ). BEWARE default value of cell_dynamics is NONE even if calc='vc-md'. calc='vc-relax' performs relaxation by damped dynamics using either Parrinello-Raman or Wentzcovitch extended lagrangian (cell_dynamics='damp-pr' or 'damp-w' ... againg default is NONE) at the pressure specified by press. stefano Miguel Mart?nez Canales wrote: > Hi again, Paolo > >> I think that there is presently no check on convergence, so if you >> keep sending jobs, it will keep running. Does it converge or not? > > > Ok, so there is no check. I should have known better. Use the source, > Luke. > Regarding convergence, it starts closing (slowly if dt is not good, > obviously) and then it oscillates. Or that is what it seems. Some > output at > the end of the e-mail. > >> By the way, there is also a 'vc-relax' option that is supposed to >> perform structural optimization. I am not sure if vc-md can >> actually do damped dynamics > > I understood that vc-relax fully relaxes the structure. I mean, the > target > pressure of the relaxation is p=0. That is why I used vc-md. How do you > compute equations of state for noncubic cells? Because maybe I am working > in a very ineffective way. > > Oh! and vc-md not being damped might explain the following output: > > Input is the same as in first e-mail, but dt=100 (note: dt=150 leads to > structure deestabilisation) and the following &system flags and > ATOMIC_POS: > From wmbmacam at lg.ehu.es Tue Jan 31 10:49:54 2006 From: wmbmacam at lg.ehu.es (Miguel Martinez) Date: Tue, 31 Jan 2006 10:49:54 +0100 Subject: [Pw_forum] vc-md question In-Reply-To: <43DF1E37.3000205@sissa.it> References: <43D900E5.4070907@lg.ehu.es> <200601301010.21511.giannozz@nest.sns.it> <43DE26B4.9020809@lg.ehu.es> <200601301856.08284.giannozz@nest.sns.it> <43DE5DF4.4070906@lg.ehu.es> <43DF1E37.3000205@sissa.it> Message-ID: <43DF32C2.3060505@lg.ehu.es> Hi all, This is from Doc/INOUT_PW .... press REAL ( default = 0.D0 ) target pressure [KBar] in a variable-cell md simulation .... But, as Paolo suggested, vc-relax does work for finite pressures. Additionally, the system doesn't oscillate undamped. However, I found INPUT_PW a bit misleading. If this part of the code isn't removed, could the readme be changed to reflect that both vc-relax and vc-md support finite-pressure? Thanks again for your help, Miguel -- ---------------------------------------- Miguel Mart?nez Canales Dto. F?sica de la Materia Condensada UPV/EHU Facultad de Ciencia y Tecnolog?a Apdo. 644 48080 Bilbao (Spain) Fax: +34 94 601 3500 Tlf: +34 94 601 5437 ---------------------------------------- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." Doug Gwyn From konstantin_kudin at yahoo.com Tue Jan 31 23:06:05 2006 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Tue, 31 Jan 2006 14:06:05 -0800 (PST) Subject: [Pw_forum] Espresso and OpenMPI In-Reply-To: <43DF32C2.3060505@lg.ehu.es> Message-ID: <20060131220605.76541.qmail@web52004.mail.yahoo.com> Has anyone tried QE-3.0 with OpenMPI ? Both QE-3.0 and the latest CVS compiled with either OpenMPI 1.0.1 or the latest CVS snapshot [1.0.2a4r8848] give the error below. Kostya forrtl: Input/output error forrtl: severe (39): error during read, unit 5, file /dev/ptmx Image PC Routine Line Source cp.x 000000000084931F Unknown Unknown Unknown cp.x 0000000000846EDE Unknown Unknown Unknown cp.x 000000000082BD52 Unknown Unknown Unknown cp.x 00000000007E89E5 Unknown Unknown Unknown cp.x 00000000007E863E Unknown Unknown Unknown cp.x 00000000008052C2 Unknown Unknown Unknown cp.x 00000000006F96EE Unknown Unknown Unknown cp.x 000000000070994D Unknown Unknown Unknown cp.x 00000000004F09D7 Unknown Unknown Unknown cp.x 000000000043BA2C Unknown Unknown Unknown cp.x 000000000043B976 Unknown Unknown Unknown libc.so.6 0000002A9731A197 Unknown Unknown Unknown cp.x 000000000043B8AA Unknown Unknown Unknown --- Miguel Martinez wrote: > Hi all, > > This is from Doc/INOUT_PW > .... > press REAL ( default = 0.D0 ) > target pressure [KBar] in a variable-cell md > simulation > .... > > But, as Paolo suggested, vc-relax does work for finite pressures. > Additionally, the system doesn't oscillate undamped. However, I found > > INPUT_PW a bit misleading. If this part of the code isn't removed, > could > the readme be changed to reflect that both vc-relax and vc-md support > > finite-pressure? > > Thanks again for your help, > > Miguel > > -- > ---------------------------------------- > Miguel Mart?nez Canales > Dto. F?sica de la Materia Condensada > UPV/EHU > Facultad de Ciencia y Tecnolog?a > Apdo. 644 > 48080 Bilbao (Spain) > Fax: +34 94 601 3500 > Tlf: +34 94 601 5437 > ---------------------------------------- > > "UNIX was not designed to stop its users from doing > stupid things, as that would also stop them from > doing clever things." > > Doug Gwyn > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com