From pushpa at jncasr.ac.in Mon Jan 5 08:04:46 2004 From: pushpa at jncasr.ac.in (Raghani Pushpa) Date: Mon, 5 Jan 2004 12:34:46 +0530 (IST) Subject: [Pw_forum] 'davcio' error Message-ID: Dear users, I was doing the phonon calculations and the job got killed somehow. But when i resubmit the job it gives the following error IOS = -1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from davcio : error # 21 i/o error in davcio %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... I have all the necessary files in the tmp directory. I don't understand why this ios is becoming -1. Could somebody tell me what is the problem? Thanx, Pushpa -- From giannozz at nest.sns.it Wed Jan 7 09:38:24 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 7 Jan 2004 09:38:24 +0100 Subject: [Pw_forum] 'davcio' error In-Reply-To: References: Message-ID: <200401070938.24829.giannozz@nest.sns.it> On Monday 05 January 2004 08:04, Raghani Pushpa wrote: > I was doing the phonon calculations and the job got killed somehow. > But when i resubmit the job it gives the following error > [...] from davcio : error # 21 > i/o error in davcio one or more files are corrupted. It is something that can (and usually does) happen when a job is killed. 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 *** please note my new phone and fax numbers *** From cvasse at fy.chalmers.se Wed Jan 7 12:01:05 2004 From: cvasse at fy.chalmers.se (Vasile Chis) Date: Wed, 07 Jan 2004 12:01:05 +0100 Subject: [Pw_forum] slab with fixed bulk atoms?? Message-ID: <3FFBE6F1.5000904@fy.chalmers.se> Dear users. I have a question about relaxation of a metal-slab! Is it possible to set up a slab of a number of atomic layers and keep the bulk-like atoms fixed? e.g. from example 3 Al(001) slab: &end 0.5000000 0.5000000 -2.121320 1 0.0000000 0.0000000 -1.414213 1 0.5000000 0.5000000 -0.707107 1 0.0000000 0.0000000 0.000000 1 0.5000000 0.5000000 0.707107 1 0.0000000 0.0000000 1.414213 1 0.5000000 0.5000000 2.121320 1 'Al' 1 1 1.0 Is it possible to keep layer 3, 4 and 5 fixed? Thanx in advance!! -- """""""""""""""""""""""""""""""""""" Vasile Chis Interface Modelling Group Solid State Physics Department of Experimental Physics G?teborgs Universitet/Chalmers Fysikg?rden 6B s-412 96 G?teborg, SWEDEN tel. : +46 (0) 31 7723338 mobile : +46 (0) 70 8348867 fax. : +46 (0) 31 7723367 email : cvasse at fy.chalmers.se """""""""""""""""""""""""""""""""""" From roma at cea.fr Wed Jan 7 11:58:19 2004 From: roma at cea.fr (Guido Roma) Date: Wed, 07 Jan 2004 11:58:19 +0100 Subject: [Pw_forum] slab with fixed bulk atoms?? References: <3FFBE6F1.5000904@fy.chalmers.se> Message-ID: <3FFBE64B.C6DD751E@cea.fr> Hello, yes you can, you only have to put the three layers you want to keep fixed at the end and specify iforce(i=1=3)=0 (see INPUT_PW for details). Guido > > e.g. from example 3 Al(001) slab: > &end > 0.5000000 0.5000000 -2.121320 1 > 0.0000000 0.0000000 -1.414213 1 > 0.5000000 0.5000000 -0.707107 1 > 0.0000000 0.0000000 0.000000 1 > 0.5000000 0.5000000 0.707107 1 > 0.0000000 0.0000000 1.414213 1 > 0.5000000 0.5000000 2.121320 1 > 'Al' 1 1 1.0 > > Is it possible to keep layer 3, 4 and 5 fixed? > -- Guido Roma -- CEA-Saclay - DEN/DMN/SRMP Bat.520/130 Phone: [+33]-1-69085738 -- Fax: ...6867 -- Mobile: [+33]-6-20069085 From weihe at mail.ustc.edu.cn Wed Jan 7 12:54:33 2004 From: weihe at mail.ustc.edu.cn (=?gb2312?B?utjOsA==?=) Date: Wed, 7 Jan 2004 19:54:33 +0800 Subject: [Pw_forum] problem of the second derivative of energy of DFPT Message-ID: <200401071152.TAA10885@mx1.ustc.edu.cn> Dear PWSCF user I want to get the second derivatives of Born-Oppenheimer energy surface, but I found that dinsity functional perturbation mothod gave different result than the stupid finite difference method. My testing system is the AlAs bulk. In finite difference method, I first did a scf calculation with the relaxed geometry. Then I moved Al atom 1/1000 of celldm(1) along x and -x directions, and did scf calculations again. The resulting three energies gave a FD second derivative of energy as 0.571 Ryd/Bohr^2. But DFTP gave the second derivative as 0.203 Ryd/Bohr^2 (the first element of the dynamic matrix). Can anybody give me some suggestion? Thanks! I have attach the input files with this email. Best Wishes Wei He -------------- next part -------------- A non-text attachment was scrubbed... Name: alas.scf.in Type: application/octet-stream Size: 493 bytes Desc: not available Url : /pipermail/attachments/20040107/0946e9fd/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: alas.dx.scf.in Type: application/octet-stream Size: 502 bytes Desc: not available Url : /pipermail/attachments/20040107/0946e9fd/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: alas.phG.in Type: application/octet-stream Size: 186 bytes Desc: not available Url : /pipermail/attachments/20040107/0946e9fd/attachment-0002.obj From francesco.antoniella at aquila.infn.it Wed Jan 7 13:19:11 2004 From: francesco.antoniella at aquila.infn.it (Francesco Antoniella) Date: 07 Jan 2004 13:19:11 +0100 Subject: [Pw_forum] problem of the second derivative of energy of DFPT In-Reply-To: <200401071152.TAA10885@mx1.ustc.edu.cn> References: <200401071152.TAA10885@mx1.ustc.edu.cn> Message-ID: <1073477954.1954.13.camel@altair> Il mer, 2004-01-07 alle 12:54, ?? ha scritto: > Dear PWSCF user > > I want to get the second derivatives of Born-Oppenheimer energy surface, > but I found that dinsity functional perturbation mothod gave different result > than the stupid finite difference method. > > My testing system is the AlAs bulk. In finite difference method, I first > did a scf calculation with the relaxed geometry. Then I moved Al atom 1/1000 > of celldm(1) along x and -x directions, and did scf calculations again. The > resulting three energies gave a FD second derivative of energy as 0.571 Ryd/Bohr^2. > But DFTP gave the second derivative as 0.203 Ryd/Bohr^2 (the first element of > the dynamic matrix). > > Can anybody give me some suggestion? Thanks! I have attach the input files > with this email. Try to take a bigger dx and more points in your FD to improve the accuracy of the derivative. F. > > Best Wishes > Wei He From degironc at sissa.it Wed Jan 7 14:08:04 2004 From: degironc at sissa.it (Stefano de Gironcoli) Date: Wed, 07 Jan 2004 14:08:04 +0100 Subject: [Pw_forum] problem of the second derivative of energy of DFPT References: <200401071152.TAA10885@mx1.ustc.edu.cn> Message-ID: <3FFC04B4.90105@sissa.it> using your input I get: 0.190 Ryd/bohr2 from energy vs displacement of frozen phonon 0.193 Ryd/bohr2 from force vs displacement of frozen phonon 0.191 Ryd/bohr2 from diagonal element of dynamical matrix computed by phonon code. pay attention that in your input alas.dx.scf.in the atom is displaced by 0.001 in the 111 direction so the lenght of your displacement is 10.60 * 0.001 * sqrt(3) bohr. I guess you overlooked that (0.571/3=0.190). I don't know why you get 0.203 from the phonon calculation. Stefano de Gironcoli ?? wrote: >Dear PWSCF user > > I want to get the second derivatives of Born-Oppenheimer energy surface, >but I found that dinsity functional perturbation mothod gave different result >than the stupid finite difference method. > > My testing system is the AlAs bulk. In finite difference method, I first >did a scf calculation with the relaxed geometry. Then I moved Al atom 1/1000 >of celldm(1) along x and -x directions, and did scf calculations again. The >resulting three energies gave a FD second derivative of energy as 0.571 Ryd/Bohr^2. >But DFTP gave the second derivative as 0.203 Ryd/Bohr^2 (the first element of >the dynamic matrix). > > Can anybody give me some suggestion? Thanks! I have attach the input files >with this email. > >Best Wishes >Wei He > From weihe at mail.ustc.edu.cn Wed Jan 7 14:27:17 2004 From: weihe at mail.ustc.edu.cn (Wei He) Date: Wed, 7 Jan 2004 21:27:17 +0800 Subject: [Pw_forum] problem of the second derivative of energy of DFPT Message-ID: <200401071325.VAA28663@mx1.ustc.edu.cn> Dear Francesco Antoniella Thank you very much for your suggestion. But increasing dx to 2/1000 or 1/100 or using 4-order FD do not improve the result or even give a worse result. Another thing puzzling me is that the energies are not strictly equal for movements along x and -x direction. Sincerely, Wei He ======= 2004-01-07 20:19:11 ======= >Il mer, 2004-01-07 alle 12:54, ?? ha scritto: >> Dear PWSCF user >> >> I want to get the second derivatives of Born-Oppenheimer energy surface, >> but I found that dinsity functional perturbation mothod gave different result >> than the stupid finite difference method. >> >> My testing system is the AlAs bulk. In finite difference method, I first >> did a scf calculation with the relaxed geometry. Then I moved Al atom 1/1000 >> of celldm(1) along x and -x directions, and did scf calculations again. The >> resulting three energies gave a FD second derivative of energy as 0.571 Ryd/Bohr^2. >> But DFTP gave the second derivative as 0.203 Ryd/Bohr^2 (the first element of >> the dynamic matrix). >> >> Can anybody give me some suggestion? Thanks! I have attach the input files >> with this email. >Try to take a bigger dx and more points in your FD to improve the >accuracy of the derivative. >F. >> >> Best Wishes >> Wei He > > > >_______________________________________________ >Pw_forum mailing list >Pw_forum at pwscf.org >http://www.democritos.it/mailman/listinfo/pw_forum = = = = = = = = = = = = = = = = = = = = ????????? ?? ????????Wei He ????????weihe at mail.ustc.edu.cn ??????????2004-01-07 From weihe at mail.ustc.edu.cn Wed Jan 7 14:36:44 2004 From: weihe at mail.ustc.edu.cn (Wei He) Date: Wed, 7 Jan 2004 21:36:44 +0800 Subject: [Pw_forum] problem of the second derivative of energy of DFPT Message-ID: <200401071334.VAA30624@mx1.ustc.edu.cn> Dear Stefano You are right, thank you. I have missed {crystal} in the input file, which makes me confused on the direction of displacement. Best Wishes Wei He ======= 2004-01-07 21:08:04 ======= >using your input I get: > >0.190 Ryd/bohr2 from energy vs displacement of frozen phonon >0.193 Ryd/bohr2 from force vs displacement of frozen phonon >0.191 Ryd/bohr2 from diagonal element of dynamical matrix computed by >phonon code. > >pay attention that in your input alas.dx.scf.in the atom is displaced by >0.001 in the 111 direction so the lenght of your displacement is 10.60 * >0.001 * sqrt(3) bohr. I guess you overlooked that (0.571/3=0.190). >I don't know why you get 0.203 from the phonon calculation. > >Stefano de Gironcoli > > >?? wrote: > >>Dear PWSCF user >> >> I want to get the second derivatives of Born-Oppenheimer energy surface, >>but I found that dinsity functional perturbation mothod gave different result >>than the stupid finite difference method. >> >> My testing system is the AlAs bulk. In finite difference method, I first >>did a scf calculation with the relaxed geometry. Then I moved Al atom 1/1000 >>of celldm(1) along x and -x directions, and did scf calculations again. The >>resulting three energies gave a FD second derivative of energy as 0.571 Ryd/Bohr^2. >>But DFTP gave the second derivative as 0.203 Ryd/Bohr^2 (the first element of >>the dynamic matrix). >> >> Can anybody give me some suggestion? Thanks! I have attach the input files >>with this email. >> >>Best Wishes >>Wei He >> > > > >_______________________________________________ >Pw_forum mailing list >Pw_forum at pwscf.org >http://www.democritos.it/mailman/listinfo/pw_forum > = = = = = = = = = = = = = = = = = = = = ????????? ?? ????????Wei He ????????weihe at mail.ustc.edu.cn ??????????2004-01-07 From goranka.bilalbegovic at zg.htnet.hr Wed Jan 7 19:09:51 2004 From: goranka.bilalbegovic at zg.htnet.hr (Goranka Bilalbegovic) Date: Wed, 7 Jan 2004 19:09:51 +0100 Subject: [Pw_forum] XCrySDen, gOpenMol: translational asymmetric unit cell Message-ID: <004a01c3d549$a598f6a0$07311dc3@gost> Hello, (1) I found an example (cluster) where in the XCrySDen, the translational asymmetric unit cell follows the symmetry of the problem. This is not true for "nicely cut unit cell = unit cell". The *.xsf file (prepared by PWscf 1.3.0, pp/chdens) opens with "unit cell". However, when I change this option (display menu/unit of repetition) to the "Translational asymmetric unit", only the balls/stick image changes, whereas charge densities are still distributed according to the "unit cell". Is there a way to plot charge densities for the translational asymmetric unit cell ? (2) In gOpenMol, I was not able to find something similar to the translational asymmetric unit cell of XCrySDen. Is this possible in gOpenMol ? Thanks for help. Best regards, Goranka -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20040107/3d1f2462/attachment.htm From giannozz at nest.sns.it Fri Jan 9 17:01:36 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 9 Jan 2004 17:01:36 +0100 Subject: [Pw_forum] problem of calculation of phonon In-Reply-To: <200312171259.UAA15481@mx1.ustc.edu.cn> References: <200312171259.UAA15481@mx1.ustc.edu.cn> Message-ID: <200401091701.36321.giannozz@nest.sns.it> On Wednesday 17 December 2003 14:00, Zhenyu Li wrote: > I always get error in the following q points: > 0.0000000,0.0000000,-.1313474 > 0.1250000,0.3608439,0.0000000 > 0.1250000,0.3608439,-.1313474 these q-points may have 4-dimensional irreps. In previous versions of the code, this wasn't allowed: a special flag (the infamous "iswitch=-3, needed in some cases") removed q => -q+G symmetry (or something like this) thus reducing the maximum dimension of irreps to 3. The special flag is no longer there and the code should deal with 4-dim irrep. Unfortunately it doesn't because a few arrays were not properly dimensioned. The I/O errors you got were a consequence of out-of-bound errors. This will be fixed very soon. Meanwhile, you may try the following: In PH/addusddens.f90, replace 72c72 < allocate (aux( ngm , nspin , 3)) --- > allocate (aux( ngm , nspin , npertx)) 94c94 < call setv (6 * ngm * nspin, 0.d0, aux, 1) --- > aux(:,:,:) = (0.d0, 0.d0) In PH/drho.f90, replace 141c141 < allocate (drhoust( nrxx , nspin , 3)) --- > allocate (drhoust( nrxx , nspin , npertx)) In PH/phqscf.f90, replace 67c66 < WRITE( stdout, '(//,5x,"Representation #", i3," modes # ",3i3)')& --- > WRITE( stdout, '(//,5x,"Representation #", i3," modes # ",4i3)')& 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 *** please note my new phone and fax numbers *** From zyli at sina.com Sun Jan 11 04:05:53 2004 From: zyli at sina.com (Zhenyu Li) Date: Sun, 11 Jan 2004 11:05:53 +0800 Subject: [Pw_forum] problem of calculation of phonon Message-ID: <200401110308.LAA15296@mx1.ustc.edu.cn> Dear Paolo Thank you very much for providing a solution. But it does not work well in parallel version, which end with the following debug information: --------------------------------------------------------------- #23 0x12019ff08 in reduce() "reduce.f90":76 #24 0x12005fbc0 in drhodvnl() "drhodvnl.f90":142 #25 0x12005cba4 in drhodv() "drhodv.f90":100 #26 0x12009bc80 in phqscf() "phqscf.f90":78 #27 0x1200971a0 in phonon() "phonon.f90":78 ----------------------------------------------------------------- Best Wishes Zhenyu ======= 2004-01-10 00:01:36 ======= >On Wednesday 17 December 2003 14:00, Zhenyu Li wrote: > >> I always get error in the following q points: >> 0.0000000,0.0000000,-.1313474 >> 0.1250000,0.3608439,0.0000000 >> 0.1250000,0.3608439,-.1313474 > >these q-points may have 4-dimensional irreps. In previous >versions of the code, this wasn't allowed: a special flag >(the infamous "iswitch=-3, needed in some cases") removed >q => -q+G symmetry (or something like this) thus reducing >the maximum dimension of irreps to 3. The special flag is >no longer there and the code should deal with 4-dim irrep. >Unfortunately it doesn't because a few arrays were not >properly dimensioned. The I/O errors you got were a >consequence of out-of-bound errors. This will be fixed >very soon. Meanwhile, you may try the following: > >In PH/addusddens.f90, replace >72c72 >< allocate (aux( ngm , nspin , 3)) >--- >> allocate (aux( ngm , nspin , npertx)) >94c94 >< call setv (6 * ngm * nspin, 0.d0, aux, 1) >--- >> aux(:,:,:) = (0.d0, 0.d0) > >In PH/drho.f90, replace >141c141 >< allocate (drhoust( nrxx , nspin , 3)) >--- >> allocate (drhoust( nrxx , nspin , npertx)) > >In PH/phqscf.f90, replace >67c66 >< WRITE( stdout, '(//,5x,"Representation #", i3," modes # ",3i3)')& >--- >> WRITE( stdout, '(//,5x,"Representation #", i3," modes # ",4i3)')& > >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 >*** please note my new phone and fax numbers *** > >_______________________________________________ >Pw_forum mailing list >Pw_forum at pwscf.org >http://www.democritos.it/mailman/listinfo/pw_forum > > = = = = = = = = = = = = = = = = = = = = ????????? ?? ????????Zhenyu Li ????????zyli at sina.com ??????????2004-01-11 ================================================= Zhenyu LI Ph.D. Candidate Open Laboratory of Bond Selective Chemistry, University of Science and Technology of China, Hefei, Anhui, 230026, People's Republic of China Tel.: 86-551-3606428 Fax.: 86-551-3602969 http://www.bsc.ustc.edu.cn/~zyli/whoami/ ===================================================?????????????? From pushpa at jncasr.ac.in Mon Jan 12 05:40:35 2004 From: pushpa at jncasr.ac.in (Raghani Pushpa) Date: Mon, 12 Jan 2004 10:10:35 +0530 (IST) Subject: [Pw_forum] (no subject) Message-ID: Dear all, In the phonon calculations if we kill the process in between and if the files in the scratch directory get corrupted that we cannot restart the job. In that case, can we get the frequencies and eigenvectors of the representations which it has already achieved the self consistency for? Then start the program again and achieve the selfconsistency for the representations which it didn't do previously. This can be done only if the irreps are decoupled at a particular q point and I am not sure if it's so. In general, is there any solution to this kind of a problem than just restarting the calculation from scratch? Pushpa From himanshu at apsara.barc.ernet.in Mon Jan 12 19:16:59 2004 From: himanshu at apsara.barc.ernet.in (himanshu at apsara.barc.ernet.in) Date: Mon, 12 Jan 2004 23:46:59 +0530 (IST) Subject: [Pw_forum] atomic positions Message-ID: <1073931419.4002e49bce729@bts.barc.ernet.in> dear users I could not understand how one can set atomic positions in any calculations. In perticular if I know the space group C222_1 and frictional coordinate of sample and my unit cell contains four formula units e.g. (four ABO4 molecule ).And also whether it is possible to use only premittive for phonon calculation. Is anybody aware of how coordinates in premittive cell can be generated for perticular space group and frictional coordinates .thanks in anticipations. with best regards ------------------------------------------------- From giannozz at nest.sns.it Mon Jan 12 22:34:11 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 12 Jan 2004 22:34:11 +0100 Subject: [Pw_forum] problem of calculation of phonon In-Reply-To: <200401110308.LAA15296@mx1.ustc.edu.cn> References: <200401110308.LAA15296@mx1.ustc.edu.cn> Message-ID: <200401122234.11475.giannozz@nest.sns.it> On Sunday 11 January 2004 04:05, Zhenyu Li wrote: > Thank you very much for providing a solution. But it does > not work well in parallel version, which end with the following > debug information: > --------------------------------------------------------------- > #23 0x12019ff08 in reduce() "reduce.f90":76 > #24 0x12005fbc0 in drhodvnl() "drhodvnl.f90":142 > #25 0x12005cba4 in drhodv() "drhodv.f90":100 > #26 0x12009bc80 in phqscf() "phqscf.f90":78 > #27 0x1200971a0 in phonon() "phonon.f90":78 > ----------------------------------------------------------------- I don't have that error (with the parallel version). May you try the latest (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 zyli at sina.com Tue Jan 13 15:52:48 2004 From: zyli at sina.com (Zhenyu Li) Date: Tue, 13 Jan 2004 22:52:48 +0800 Subject: [Pw_forum] problem of calculation of phonon Message-ID: <200401131455.WAA11670@mx1.ustc.edu.cn> Dear Paolo I am afraid that the developing version from CVS server is too unstable. In fact, the version I got this morning is failed to be compiled. By fixing some type errors in a source file and PH/Makefile, I compiled the pw.x and ph.x successfully. But the ph.x report the following error in q point 0.0000000,0.0000000,-.1313474 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from phq_readin : error # 1 Wrong iswitch %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... Zhenyu ======= 2004-01-13 05:34:11 ======= >On Sunday 11 January 2004 04:05, Zhenyu Li wrote: > >> Thank you very much for providing a solution. But it does >> not work well in parallel version, which end with the following >> debug information: >> --------------------------------------------------------------- >> #23 0x12019ff08 in reduce() "reduce.f90":76 >> #24 0x12005fbc0 in drhodvnl() "drhodvnl.f90":142 >> #25 0x12005cba4 in drhodv() "drhodv.f90":100 >> #26 0x12009bc80 in phqscf() "phqscf.f90":78 >> #27 0x1200971a0 in phonon() "phonon.f90":78 >> ----------------------------------------------------------------- > >I don't have that error (with the parallel version). May you try >the latest (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 > > >_______________________________________________ >Pw_forum mailing list >Pw_forum at pwscf.org >http://www.democritos.it/mailman/listinfo/pw_forum > > = = = = = = = = = = = = = = = = = = = = ????????? ?? ????????Zhenyu Li ????????zyli at sina.com ??????????2004-01-13 ================================================= Zhenyu LI Ph.D. Candidate Open Laboratory of Bond Selective Chemistry, University of Science and Technology of China, Hefei, Anhui, 230026, People's Republic of China Tel.: 86-551-3606428 Fax.: 86-551-3602969 http://www.bsc.ustc.edu.cn/~zyli/whoami/ ===================================================?????????????? From giannozz at nest.sns.it Wed Jan 14 09:57:56 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 14 Jan 2004 09:57:56 +0100 Subject: [Pw_forum] problem of calculation of phonon In-Reply-To: <200401131455.WAA11670@mx1.ustc.edu.cn> References: <200401131455.WAA11670@mx1.ustc.edu.cn> Message-ID: <200401140957.56315.giannozz@nest.sns.it> On Tuesday 13 January 2004 15:52, Zhenyu Li wrote: > I am afraid that the developing version from CVS server is > too unstable. In fact, the version I got this morning is failed > to be compiled. By fixing some type errors in a source file and > PH/Makefile you need to "make clean" and to re-run "configure" ("or "configure.new") after an update > I compiled the pw.x and ph.x successfully. But the > ph.x report the following error in q point 0.0000000,0.0000000,-.1313474 > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > from phq_readin : error # 1 > Wrong iswitch > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% I am using the last (CVS) version of the code, and it works for me 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 phyche1 at bo.imm.cnr.it Wed Jan 14 10:06:40 2004 From: phyche1 at bo.imm.cnr.it (Eros Albertazzi) Date: Wed, 14 Jan 2004 10:06:40 +0100 Subject: [Pw_forum] pw on Opteron Message-ID: <400506A0.8020706@bo.imm.cnr.it> I would like to run pw on an Opteron pc (Suse 9 AMD64 + PGI 5.1-3) in 64bit mode Has anyone succeded in porting a version of the code that can be released? Regards -- Eros Albertazzi CNR-IMM, Sez. Bologna Via P.Gobetti 101 I-40129 Bologna, Italy Tel:(+39)-051-639 9179 Fax:(+39)-051-639 9216 From breezejd at lsbu.ac.uk Wed Jan 14 13:19:34 2004 From: breezejd at lsbu.ac.uk (Jonathan Breeze) Date: Wed, 14 Jan 2004 12:19:34 +0000 Subject: [Pw_forum] CVS information Message-ID: <400533D6.1030800@lsbu.ac.uk> Dear PWSCF developers, I keep hearing about CVS and the possibility of keeping up to date with most recent versions of the code. What do I need to do in order to take advantage of CVS ??? -- Jonathan Breeze Research Fellow Centre for Physical Electronics and Materials London South Bank University 103 Borough Road London SE1 0AA Tel: +44(0)20 7815 7582 Fax: +44(0)20 7815 7599 From giannozz at nest.sns.it Wed Jan 14 17:19:50 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 14 Jan 2004 17:19:50 +0100 Subject: [Pw_forum] CVS information In-Reply-To: <400533D6.1030800@lsbu.ac.uk> References: <400533D6.1030800@lsbu.ac.uk> Message-ID: <200401141719.50796.giannozz@nest.sns.it> On Wednesday 14 January 2004 13:19, Jonathan Breeze wrote: > I keep hearing about CVS and the possibility of keeping up to date with > most recent versions of the code. > What do I need to do in order to take advantage of CVS ??? see the file README.cvs (attached) that comes with the PWscf distribution. CVS tutorial: http://www.loria.fr/~molli/cvs/cvs-tut/ . A few notes on what can happen when you update: --------- Update to the latest release: "cvs update" You should get lines looking like > cvs server: Updating Modules > P Modules/Makefile > U Modules/control_flags.f90 where P means "patched", U means "Updated" (a new file is added); or > M PW/Makefile where M means locally modified wrt the CVS repository version; or > ? CPV/intel.pcl meaning that cvs knows nothing about such file; or > cvs server: FPMD/control_flags.f90 is no longer in the repository meaning that these files are no longer in the repository; but no lines like > C Somedir/SomeFile > cvs server: conflict while updating Somedir/SomeFile This means that somebody else has modified the same parts of the code that you have locally modified; conflicting files will contain lines like > >>>>>>>>>>>>> > something > ============ > something else > <<<<<<<<<<<<< --------- 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 -------------- The current (development) version is available using anonymous CVS. Define environmental variables: setenv CVS_RSH ssh setenv CVSROOT :pserver:cvsanon at democritos.sissa.it:/home/cvs (tcsh/csh) or export CVS_RSH=ssh export CVSROOT=:pserver:cvsanon at democritos.sissa.it:/home/cvs (sh/bash). Then: cvs login (password: cvsanon). For the first code download: cvs co O-sesame for the entire repository (the code appears in directory O-sesame/). Alternatively, "cvs co pwscf", or "cp", or "fpmd" will download only PWscf, CP, FPMD, respectively, in directories with the same name. For updating the code to the current version: cvs update -d in the directory containing the distribution. PLEASE NOTE: re-run "./configure" if files have been moved/added/removed since the last checkout, otherwise "make" may not work properly due to obsolete or missing dependencies. Do not blindly re-use a "make.sys" file from a preceding version: it may no longer work. PLEASE ALSO NOTE: the development version may not work properly, and sometimes not even compile properly. Use at your own risk. From breezejd at lsbu.ac.uk Wed Jan 14 17:27:57 2004 From: breezejd at lsbu.ac.uk (Jonathan Breeze) Date: Wed, 14 Jan 2004 16:27:57 +0000 Subject: [Pw_forum] CVS information References: <400533D6.1030800@lsbu.ac.uk> <200401141719.50796.giannozz@nest.sns.it> Message-ID: <40056E0D.1010602@lsbu.ac.uk> Thank you very much for your help Paolo, I'll give it a whirl. Paolo Giannozzi wrote: >On Wednesday 14 January 2004 13:19, Jonathan Breeze wrote: > > > >>I keep hearing about CVS and the possibility of keeping up to date with >>most recent versions of the code. >>What do I need to do in order to take advantage of CVS ??? >> >> > >see the file README.cvs (attached) that comes with the PWscf distribution. >CVS tutorial: http://www.loria.fr/~molli/cvs/cvs-tut/ . A few notes on what >can happen when you update: > >--------- >Update to the latest release: "cvs update" >You should get lines looking like > > > >>cvs server: Updating Modules >>P Modules/Makefile >>U Modules/control_flags.f90 >> >> > >where P means "patched", U means "Updated" (a new file is added); or > > > >>M PW/Makefile >> >> > >where M means locally modified wrt the CVS repository version; or > > > >>? CPV/intel.pcl >> >> > >meaning that cvs knows nothing about such file; or > > > >>cvs server: FPMD/control_flags.f90 is no longer in the repository >> >> > >meaning that these files are no longer in the repository; but no lines like > > > >>C Somedir/SomeFile >>cvs server: conflict while updating Somedir/SomeFile >> >> > >This means that somebody else has modified the same parts of the code >that you have locally modified; conflicting files will contain lines like > > > >> something >>============ >> something else >><<<<<<<<<<<<< >> >> >--------- > >Paolo > > >------------------------------------------------------------------------ > > >The current (development) version is available using anonymous CVS. >Define environmental variables: > setenv CVS_RSH ssh > setenv CVSROOT :pserver:cvsanon at democritos.sissa.it:/home/cvs >(tcsh/csh) or > export CVS_RSH=ssh > export CVSROOT=:pserver:cvsanon at democritos.sissa.it:/home/cvs >(sh/bash). Then: > cvs login >(password: cvsanon). For the first code download: > cvs co O-sesame >for the entire repository (the code appears in directory O-sesame/). >Alternatively, "cvs co pwscf", or "cp", or "fpmd" will download only >PWscf, CP, FPMD, respectively, in directories with the same name. >For updating the code to the current version: > cvs update -d >in the directory containing the distribution. > >PLEASE NOTE: re-run "./configure" if files have been moved/added/removed >since the last checkout, otherwise "make" may not work properly due to >obsolete or missing dependencies. Do not blindly re-use a "make.sys" file >from a preceding version: it may no longer work. > >PLEASE ALSO NOTE: the development version may not work properly, and >sometimes not even compile properly. Use at your own risk. > > > -- Jonathan Breeze Research Fellow Centre for Physical Electronics and Materials London South Bank University 103 Borough Road London SE1 0AA Tel: +44(0)20 7815 7582 Fax: +44(0)20 7815 7599 From cvasse at fy.chalmers.se Fri Jan 16 10:36:02 2004 From: cvasse at fy.chalmers.se (Vasile Chis) Date: Fri, 16 Jan 2004 10:36:02 +0100 Subject: [Pw_forum] Bandstructure of a metal slab Message-ID: <4007B082.2060907@fy.chalmers.se> Dear Users. I have some questions. When calculating bandstructure of a metal slab, what type of smearing is to be preferred? Fermi-Dirac smearing or Gaussian spreading? And, why? Thanks in advance! -- """""""""""""""""""""""""""""""""""" Vasile Chis Interface Modelling Group Solid State Physics Department of Experimental Physics G?teborgs Universitet/Chalmers Fysikg?rden 6B s-412 96 G?teborg, SWEDEN tel. : +46 (0) 31 7723338 mobile : +46 (0) 70 8348867 fax. : +46 (0) 31 7723367 email : cvasse at fy.chalmers.se """""""""""""""""""""""""""""""""""" From marzari at MIT.EDU Fri Jan 16 17:18:31 2004 From: marzari at MIT.EDU (Nicola Marzari) Date: Fri, 16 Jan 2004 11:18:31 -0500 Subject: [Pw_forum] Bandstructure of a metal slab In-Reply-To: <4007B082.2060907@fy.chalmers.se> References: <4007B082.2060907@fy.chalmers.se> Message-ID: <40080ED7.6090301@mit.edu> Dear Vasile, Fermi-Dirac is used only when trying to mimic a true physical electronic temperature - in all other cases it is less convenient to use, since it is comparatively "long-tailed" with respect to a Gaussian smearing. This means you need to introduce more bands above the Fermi energy in order to capture all the states with non-zero occupancy than you would otherwise do with a different smearing. (It's not a completely fair comparison, since for the same temperature Gaussian and F-D have different slopes at the Fermi energy, so in practice one should have a "renormalizing" factor between the temperatures to compare their efficacy in improving sampling accuracy). In general, Gaussian-like smearings are preferable. If you are interested only in the total energies, you can just use a Gaussian smearing - but you need to be aware of Gillan (JPhysCondMatt 1989) and De Vita work on how to extract a meanigful corrected energy taking the semisum of the energy and the free energy. Methfessel-Paxton and Marzari-Vanderbilt do this automatically for you, and also provide forces, stresses, and whatever else corrected for the leading term in the temperature. I personally like the M-V cold smearing best :-), since it does not resort to introducing negative occupancies. Negative occupancies could e.g. give rise to regions of negative charge density in a slab, where some of the states above the Fermi energy extend in the vacuum. A detailed description of all these techniques is in chapter 4 of my thesis, found at http://nnn.mit.edu/phd/ . Note that recently Verstaete and Gonze have also shown that you can do a cold-smearing of a Fermi-Dirac (i.e. the smearing is used not to recover the 0 temperature result with fewer k-point, but to recover a finite-temperature Fermi-Dirac distribution. It's in PRB, and mentioned in the ABINIT bibliography). If you are dealing with atoms and molecules with fractional occupancies, I would use plain Gaussian smearing, being careful in taking the limit to T-->0 (the free energy E-TS has a S different from 0 for an atom with fractional occupancies, so you want the limit for zero T). I seem to remember that what PWSCF calls energy is actually the free energy E-TS, when temperature broadening is switched on, and -TS is what is called "correction for metals". Please correct me if not the case. Best luck, nicola marzari PWSCF_PS: is the mailing list archived ? It could build up into a worthwhile repository. Vasile Chis wrote: > Dear Users. > > I have some questions. > When calculating bandstructure of a metal slab, what type of smearing is > to be preferred? > Fermi-Dirac smearing or Gaussian spreading? And, why? > Thanks in advance! > -- --------------------------------------------------------------------- Prof Nicola Marzari Department of Materials Science and Engineering 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA tel 617.4522758 fax 617.2586534 marzari at mit.edu http://nnn.mit.edu From verissim at df.ufscar.br Fri Jan 16 21:15:36 2004 From: verissim at df.ufscar.br (Marcos Verissimo Alves) Date: 16 Jan 2004 18:15:36 -0200 Subject: [Pw_forum] Bandstructure of a metal slab In-Reply-To: <40080ED7.6090301@mit.edu> References: <4007B082.2060907@fy.chalmers.se> <40080ED7.6090301@mit.edu> Message-ID: <1074284136.8969.100.camel@rocknroll> Hi all, This e-mail has nothing to do with pwscf specifically, but it is something I am having trouble with. Right now I want to calculate the phonon spectrum of PbO at the Gamma point, and study its behavior with pressure. I don't want the frequencies, only; I want the eigenmodes as well, to see which of them (obtained by DFT) are Raman active (through group theory analysis), and which are not. I performed calculations with a large supercell (180 atoms) using finite displacements of the atoms in the primitive cell to generate the force constants matrix and then diagonalized it, and got a set of phonon frequencies and a set of phonon eigenmodes. Then, I performed a phonon calculation with a single unit cell instead of a supercell. The eigenfrequencies thus obtained are practically identical to the ones from the supercell calculation, but the eigenmodes are not. My questions are: why do the eigenmodes differ? My guess is that the forces on the other atoms have not decayed, in the calculation using a single unit cell. However, why are the frequencies at Gamma identical for the two calculations? Second, can I trust the eigenmodes obtained from a single-cell calculation? Is there any way to relate them to the ones obtained from the supercell calculation? Third, is there some method I can use to use a single unit cell for a phonon calculation and still obtain good eigenmodes? Or is it inevitable to use a supercell, when using finite displacements to calculate the force constant matrix? I would greatly appreciate any help you can give me, including basic literature on the subject, as well as papers you might know that you find relevant to clear this subject... Thanks, Marcos From konstantin_kudin at yahoo.com Sun Jan 18 01:31:59 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Sat, 17 Jan 2004 16:31:59 -0800 (PST) Subject: [Pw_forum] AMD Core Math Library & PWSCF Message-ID: <20040118003159.91431.qmail@web21206.mail.yahoo.com> Hi there, I thought I'd share how to link PWSCF with the AMD Core Math Library (ACML). It is free and supposed to be well optimized. (http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_2282,00.html) For ifc 8.0 replace MKL libraries with: /usr/acml1.5/gnu32_nosse2/lib/libacml.so /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/libg2c.so (or use .a instead of .so) Libg2c is needed to make libacml happy. In pgf 5.1 this library is included with the compiler. To use that, add options: -lacml -lpgmp -lpgthread If you want to use the one from the AMD website, use: /usr/acml1.5/pgi32_nosse2/lib/libacml.so Good luck. Kostya __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From giannozz at nest.sns.it Mon Jan 19 09:31:58 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 19 Jan 2004 09:31:58 +0100 Subject: [Pw_forum] Bandstructure of a metal slab In-Reply-To: <1074284136.8969.100.camel@rocknroll> References: <4007B082.2060907@fy.chalmers.se> <40080ED7.6090301@mit.edu> <1074284136.8969.100.camel@rocknroll> Message-ID: <200401190931.58478.giannozz@nest.sns.it> On Friday 16 January 2004 21:15, Marcos Verissimo Alves wrote: > I want to calculate the phonon spectrum of PbO at the Gamma point if you are interested to q=0 phonons only, you do not need supercells, either using frozen phonon or using linear response (the phonon code). If you are interested to interatomic force constants in real space, then you need a suitable supercell (using frozen phonon) or a suitable grid of q-points in the unit cell (using linear response). See for instance: Rev. Mod. Phys. 73, 515 (2001) (pdf file at: http://www.nest.sns.it/~giannozz/Papers/RMP_52.pdf) Phys. Rev. B 43, 7231 (1991) (pdf file at: http://www.nest.sns.it/~giannozz/Papers/PRB_19.pdf) Phys. Rep. 309, 209 (1999) Phys. Rev. A 52, 1086 (1995) and 1096 Phys. Rev. B 35, 10337(1997) and 10555 > My questions are: why do the eigenmodes differ? they don't, if both calculations are performed in the proper way. Beware normalizations, atomic masses, units, degenerate eigenvalues, and so on 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 Mon Jan 19 09:40:39 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 19 Jan 2004 09:40:39 +0100 Subject: [Pw_forum] AMD Core Math Library & PWSCF In-Reply-To: <20040118003159.91431.qmail@web21206.mail.yahoo.com> References: <20040118003159.91431.qmail@web21206.mail.yahoo.com> Message-ID: <200401190940.39240.giannozz@nest.sns.it> On Sunday 18 January 2004 01:31, Konstantin Kudin wrote: > I thought I'd share how to link PWSCF with the AMD > Core Math Library (ACML). thank you! > For ifc 8.0 8.0 ? I tried it and got a bunch of "Compiler Internal Error" ! 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 konstantin_kudin at yahoo.com Mon Jan 19 19:27:50 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Mon, 19 Jan 2004 10:27:50 -0800 (PST) Subject: [Pw_forum] AMD Core Math Library & PWSCF In-Reply-To: <200401190940.39240.giannozz@nest.sns.it> Message-ID: <20040119182750.3169.qmail@web21205.mail.yahoo.com> --- Paolo Giannozzi wrote: > On Sunday 18 January 2004 01:31, Konstantin Kudin > wrote: > > > I thought I'd share how to link PWSCF with the > AMD > > Core Math Library (ACML). > > thank you! Actually, I found out that ACML is kind of slow. It is much better to use ATLAS, and then ACML for the missing routines. Here is the linking order (it is important!!!): AMDLIB1= /home/software/common/acml1.5/gnu32_nosse2/lib/libacml.a AMDLIB = /home/software/32bit/atlas/libf77blas.a /home/software/32bit/atlas/liblapack.a /home/software/32bit/atlas/libcblas.a /home/software/32bit/atlas/libatlas.a $(AMDLIB1) LIBS= $(FFTW_LIB) $(AMDLIB) /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/libg2c.a So, 1st it uses blas and lapack from ATLAS, and if something is not found, it gets pulled from ACML. The code works, I checked. Usually, ATLAS provides the first 4 libraries in the above list. Also, gnu32/lib/libacml.so crashes on my Opteron, so I am using gnu32_nosse2. > > For ifc 8.0 > > 8.0 ? I tried it and got a bunch of "Compiler > Internal Error" ! Perhaps you're using flags which are too fancy. A recent CVS pull gave a bunch of errors for things like .times. So something is not compatible there code-wise. PWSCF 1.3.0, on the other hand, compiles fine with the flags: -Vaxlib -O2 -tpp6 -Zp8 -axK -xK -ftz -ipo -ipo_obj Also, -tpp7 and -xW (and -O3) can work but is slower on Opteron. Regards, Kostya __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From konstantin_kudin at yahoo.com Mon Jan 19 19:36:14 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Mon, 19 Jan 2004 10:36:14 -0800 (PST) Subject: [Pw_forum] 2Gb file limit in PWSCF In-Reply-To: <20040119182750.3169.qmail@web21205.mail.yahoo.com> Message-ID: <20040119183614.44962.qmail@web21202.mail.yahoo.com> Hello, I tried to run a job on a 32-bit Linux, and once the *.wfc file became larger than 2Gb, the job crashed due to the file size restrictions. Not good :-) How doable would it be to have each k point written out in a seperate *.wfc file? The parallel code does exactly that when it splits things across nodes, so possibly most things are in place. Kostya __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From giannozz at nest.sns.it Mon Jan 19 22:15:43 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 19 Jan 2004 22:15:43 +0100 Subject: [Pw_forum] AMD Core Math Library & PWSCF In-Reply-To: <20040119182750.3169.qmail@web21205.mail.yahoo.com> References: <20040119182750.3169.qmail@web21205.mail.yahoo.com> Message-ID: <200401192215.43139.giannozz@nest.sns.it> On Monday 19 January 2004 19:27, Konstantin Kudin wrote: > Actually, I found out that ACML is kind of slow. It is much > better to use ATLAS, and then ACML for the missing routines. > Here is the linking order (it is important!!!): [...] thank you again! > > 8.0 ? I tried it and got a bunch of "Compiler > > Internal Error" ! > > Perhaps you're using flags which are too fancy. A recent > CVS pull gave a bunch of errors for things like .times. this might be a problem of the code, but even if I manage to go past that section, I get "Compiler Internal Error", and these are for sure a compiler problem. I haven't tried with the stable version, though. > PWSCF 1.3.0, on the other hand, compiles fine with the > flags: > -Vaxlib -O2 -tpp6 -Zp8 -axK -xK -ftz -ipo -ipo_obj I used -Vaxlib -O2 -tpp6 . So, who is the one using fancier flags :-) ? 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 francesco.antoniella at aquila.infn.it Mon Jan 19 23:43:25 2004 From: francesco.antoniella at aquila.infn.it (Francesco Antoniella) Date: 19 Jan 2004 23:43:25 +0100 Subject: [Pw_forum] 2Gb file limit in PWSCF In-Reply-To: <20040119183614.44962.qmail@web21202.mail.yahoo.com> References: <20040119183614.44962.qmail@web21202.mail.yahoo.com> Message-ID: <1074552208.1606.14.camel@altair> Il lun, 2004-01-19 alle 19:36, Konstantin Kudin ha scritto: > Hello, > > I tried to run a job on a 32-bit Linux, and once the > *.wfc file became larger than 2Gb, the job crashed due > to the file size restrictions. Not good :-) > > How doable would it be to have each k point written > out in a seperate *.wfc file? The parallel code does > exactly that when it splits things across nodes, so > possibly most things are in place. I think that you can foul the system by using anyway mpi on a single processor. If you have a "standard" red hat distro with LAM-MPI installed you can lamboot the mpi daemon with a lamnodes like this me.localhost me.localhost me.localhost me.localhost so the LAM daemon will start 4 processes on the same node, but beware the memory: if you want to scale the files you must use -pools so you will multiplicate the raw memory occupation. Best Whishes Francesco P.S.:Wath are you doing with this huge wfc file? A thousand k points on a supercell?? > > Kostya > > __________________________________ > Do you Yahoo!? > Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes > http://hotjobs.sweepstakes.yahoo.com/signingbonus > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From konstantin_kudin at yahoo.com Tue Jan 20 00:10:51 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Mon, 19 Jan 2004 15:10:51 -0800 (PST) Subject: [Pw_forum] 2Gb file limit in PWSCF In-Reply-To: <1074552208.1606.14.camel@altair> Message-ID: <20040119231051.72709.qmail@web21201.mail.yahoo.com> --- Francesco Antoniella wrote: > so the LAM daemon will start 4 processes on the same > node, but beware > the memory: if you want to scale the files you must > use -pools so you > will multiplicate the raw memory occupation. OK. So it will use more memory. What about speed? Are these these gonna start in parallel, or will they be serialized? > P.S.:Wath are you doing with this huge wfc file? A > thousand k points on > a supercell?? It is just a 3x3x3 supercell for Mg with 1 atom taken out (53 atoms total). The cutoff is 28. Ry, nbndx=477, nbnd=64,natomsfc=477,npwx=20727,nelec=106.0,nkb=212,ngl=6878 The k point grid is {4 4 4 1 1 1}, so the total number of k points after the symmetry is 52. Perhaps I am missing some obvious parameter that can reduce that file size? I was gonna let this thing run for a few days on a local machine. Now it is probably better to go to a bigger system, and run true multiprocessor. Kostya __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From francesco.antoniella at aquila.infn.it Tue Jan 20 00:32:16 2004 From: francesco.antoniella at aquila.infn.it (Francesco Antoniella) Date: 20 Jan 2004 00:32:16 +0100 Subject: [Pw_forum] 2Gb file limit in PWSCF In-Reply-To: <20040119231051.72709.qmail@web21201.mail.yahoo.com> References: <20040119231051.72709.qmail@web21201.mail.yahoo.com> Message-ID: <1074555139.1447.21.camel@altair> Il mar, 2004-01-20 alle 00:10, Konstantin Kudin ha scritto: > > --- Francesco Antoniella > wrote: > > > so the LAM daemon will start 4 processes on the same > > node, but beware > > the memory: if you want to scale the files you must > > use -pools so you > > will multiplicate the raw memory occupation. > > OK. So it will use more memory. What about speed? Are > these these gonna start in parallel, or will they be > serialized? They will undergo an effective serialization, or it will use the processor in a time-share or round-fashion. In fact you will get little worsening in performance unless you have a multiprocessor or hyperthreading node(like PIV 3.0GHz), of course. In this case you will find this procedure useful to make two processes instead only one, and doing so, to use the second processor. > > > P.S.:Wath are you doing with this huge wfc file? A > > thousand k points on > > a supercell?? > > It is just a 3x3x3 supercell for Mg with 1 atom taken > out (53 atoms total). The cutoff is 28. Ry, nbndx=477, > nbnd=64,natomsfc=477,npwx=20727,nelec=106.0,nkb=212,ngl=6878 > > The k point grid is {4 4 4 1 1 1}, so the total > number of k points after the symmetry is 52. > > Perhaps I am missing some obvious parameter that can > reduce that file size? I don't think so, only: it is not worth to try before with gamma only (and possibily with the Gamma code, halwing the memory) to tackle the biggest components of the relaxation? > > I was gonna let this thing run for a few days on a > local machine. Now it is probably better to go to a > bigger system, and run true multiprocessor. > > Kostya > > __________________________________ > Do you Yahoo!? > Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes > http://hotjobs.sweepstakes.yahoo.com/signingbonus > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From konstantin_kudin at yahoo.com Tue Jan 20 00:42:27 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Mon, 19 Jan 2004 15:42:27 -0800 (PST) Subject: [Pw_forum] 2Gb file limit in PWSCF In-Reply-To: <1074555139.1447.21.camel@altair> Message-ID: <20040119234227.18096.qmail@web21208.mail.yahoo.com> --- Francesco Antoniella > I don't think so, only: it is not worth to try > before with gamma only > (and possibily with the Gamma code, halwing the > memory) to tackle the > biggest components of the relaxation? This is a good point! Thanks for the tip! I need to switch myself to the mode "N k points - N times longer calculation". Kostya __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From konstantin_kudin at yahoo.com Tue Jan 20 00:47:24 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Mon, 19 Jan 2004 15:47:24 -0800 (PST) Subject: [Pw_forum] AMD Core Math Library & PWSCF In-Reply-To: <200401192215.43139.giannozz@nest.sns.it> Message-ID: <20040119234724.83063.qmail@web21204.mail.yahoo.com> --- Paolo Giannozzi wrote: > I used -Vaxlib -O2 -tpp6 . So, who is the one using > fancier flags :-) ? You're right :-)! Even if you take ALL the optimization flags out, it still gives an "Internal compiler error" for neb_routines.f90 This is really bad ... The stock version 1.3.0 compiles fine though. Of course, one can always move *.o files around from a different version of the compiler, but this is getting way too complicated. Kostya __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From ponniah.ravindran at kjemi.uio.no Tue Jan 20 16:32:58 2004 From: ponniah.ravindran at kjemi.uio.no (Ponniah Ravindran) Date: Tue, 20 Jan 2004 16:32:58 +0100 (MET) Subject: [Pw_forum] PhD Position at the University of Oslo In-Reply-To: References: Message-ID: Please forward the following message to pwscf forum -------------------------------------------------------------------------- PhD Position at the University of Oslo A doctoral scholarship available to model complex hydrides using density functional calculations in Centre for Materials Science and Nanotechnology at the University of Oslo. Official Details can be found at http://folk.uio.no/ravi/activity/utlysn_hydrogen.rtf We seek candidate for the following activity http://folk.uio.no/ravi/position.htm For Unofficial Details, please contact Helmer Fjellvag (helmerf at kjemi.uio.no) or P. Ravindran (ponniah.ravindran at kjemi.uio.no) and see our activities at group's website (http://folk.uio.no/ravi/activities.htm) The closing date for applications is 1st February 2004. -------------------------------------------------------------------------- ***************************************************************** Dr.P.Ravindran, Associate Professor | Department of Chemistry |Tel work: +47 22 85 56 06 University of Oslo, PO Box 1033 | mob: +47 45 27 07 37 Blindern, N-0315 OSLO, NORWAY |Fax: +47 22 85 54 41/55 65 Email: ponniah.ravindran at kjemi.uio.no | URL : http://folk.uio.no/~ravi/ | ***************************************************************** From speyer at asu.edu Thu Jan 22 19:23:25 2004 From: speyer at asu.edu (Gil Speyer) Date: Thu, 22 Jan 2004 11:23:25 -0700 Subject: [Pw_forum] Compiling PWscf Message-ID: <01c601c3e114$d3de90c0$6b29a995@enpc3521> Hello, I am trying to install PWscf software for our molecular electronics group at Arizona State University. First off, the installation procedure seems to work almost perfectly for us. The intel fortran compiler (ifc) seems to compile most things alright, just 3 routines seem to have a problem: read_cards.f90 and vcsmd.f90: If I change a broken line in each of these (linked to the next line with "&", read_cards.f90:444 and vcsmd.f90:177) to one continuous line, it compiles. bfgs_module.f90: In the subroutine "update_inverse_hessian" the last line will not compile. More specifically, the last "chunk" of the last line won't compile, even if I separate it into its own line. The subroutine "lbfgs_update" will not compile unless I change the line: alpha(i) = ( s(:,i) .dot. bfgs_step(:) ) / sdoty(i) to: alpha(i) = ( s(:,i) .dot. bfgs_step ) / sdoty(i) The only routine of concern is the update_inverse_hessian routine which I cannot get to compile properly. If I comment out the last section of the problematic line, everything compiles and runs. Have there been similar problems with these routines? Any assistance here would be appreciated. Thanks, Gil Speyer Graduate Student Electrical Engineering Arizona State University From giannozz at nest.sns.it Thu Jan 22 21:26:34 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 22 Jan 2004 21:26:34 +0100 Subject: [Pw_forum] Compiling PWscf In-Reply-To: <01c601c3e114$d3de90c0$6b29a995@enpc3521> References: <01c601c3e114$d3de90c0$6b29a995@enpc3521> Message-ID: <200401222126.34881.giannozz@nest.sns.it> On Thursday 22 January 2004 19:23, Gil Speyer wrote: > I am trying to install PWscf software good idea. Is it the development (CVS) version that you are trying to install? > The intel fortran compiler (ifc) which version exactly? ifc 7.1 (latest releases) and 6.0 compile fine. eifc 8 does not compile the CVS version, for no apparent reason. If you have any workaround to suggest, it will be greatly appreciated 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 konstantin_kudin at yahoo.com Thu Jan 22 21:34:45 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Thu, 22 Jan 2004 12:34:45 -0800 (PST) Subject: [Pw_forum] Symmetry in PWSCF 1.3.0 - were there any bugs? In-Reply-To: <200401222126.34881.giannozz@nest.sns.it> Message-ID: <20040122203445.62092.qmail@web21204.mail.yahoo.com> --- Paolo Giannozzi wrote: > On Thursday 22 January 2004 19:23, Gil Speyer wrote: > > > I am trying to install PWscf software > > good idea. Is it the development (CVS) version that > you are trying > to install? > > > The intel fortran compiler (ifc) > > which version exactly? ifc 7.1 (latest releases) and > 6.0 compile > fine. eifc 8 does not compile the CVS version, for > no apparent > reason. If you have any workaround to suggest, it > will be greatly > appreciated > > 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 __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From konstantin_kudin at yahoo.com Thu Jan 22 21:41:07 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Thu, 22 Jan 2004 12:41:07 -0800 (PST) Subject: [Pw_forum] Symmetry in PWSCF 1.3.0 - were there any bugs? In-Reply-To: <200401222126.34881.giannozz@nest.sns.it> Message-ID: <20040122204107.64590.qmail@web21204.mail.yahoo.com> Hi guys, Sorry for the empty message - I hit "send" accidently :-) I am trying to run Y2O3 with 1.3.0, and the same input (coordinates and lattice vectors) produced 24 sym operations with 1.2.0, but only 6 sym operations with 1.3.0. The unit cell has 80 atoms (Ia3 symmetry). I seem to recall some discussion on the list about some symmetry issues, but the archive does not seem to be searchable, so I can't find that message. Thanks! Kostya __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From sbraccia at sissa.it Fri Jan 23 09:29:11 2004 From: sbraccia at sissa.it (sbraccia carlo) Date: Fri, 23 Jan 2004 09:29:11 +0100 Subject: [Pw_forum] Compiling PWscf In-Reply-To: <01c601c3e114$d3de90c0$6b29a995@enpc3521> References: <01c601c3e114$d3de90c0$6b29a995@enpc3521> Message-ID: <200401230929.11687.sbraccia@sissa.it> Dear Gil Speyer, > The intel fortran compiler (ifc) seems to compile most things alright, > just 3 routines seem to have a problem: > > read_cards.f90 and vcsmd.f90: > If I change a broken line in each of these (linked to the next line with > "&", read_cards.f90:444 and vcsmd.f90:177) to one continuous line, it > compiles. > > bfgs_module.f90: > In the subroutine "update_inverse_hessian" the last line will not > compile. More specifically, the last "chunk" of the last line won't > compile, even if I separate it into its own line. > The subroutine "lbfgs_update" will not compile unless I change the line: > > alpha(i) = ( s(:,i) .dot. bfgs_step(:) ) / sdoty(i) > > to: > alpha(i) = ( s(:,i) .dot. bfgs_step ) / sdoty(i) > > The only routine of concern is the update_inverse_hessian routine which > I cannot get to compile properly. If I comment out the last section of > the problematic line, everything compiles and runs. > Have there been similar problems with these routines? Any assistance > here would be appreciated. I've successefully compiled that module with ifc (6.0, 7.0, 7.1), lf95, xlf95, compaq f95, ... Anyway, can you try to compile pwscf with this modified version of the bfgs_module (see attached file). carlo sbraccia -------------- next part -------------- ! ! Copyright (C) 2003-2004 PWSCF group ! This file is distributed under the terms of the ! GNU General Public License. See the file `License' ! in the root directory of the present distribution, ! or http://www.gnu.org/copyleft/gpl.txt . ! !---------------------------------------------------------------------------- MODULE bfgs_module !---------------------------------------------------------------------------- ! ! ... ionic relaxation through Broyden-Fletcher-Goldfarb-Shanno ! ... minimization and a "trust radius" line search based on ! ... Wolfe conditions ( bfgs() subroutine ) ! ... A linear scaling BFGS is also implemented ( lin_bfgs() subroutine ) ! ... Both subroutines are called with the same list of arguments ! ! ... Written by Carlo Sbraccia ( 5/12/2003 ) ! ! ... references : ! ! ... 1) Roger Fletcher, Practical Methods of Optimization, John Wiley and ! ... Sons, Chichester, 2nd edn, 1987. ! ... 2) Salomon R. Billeter, Alexander J. Turner, Walter Thiel, ! ... Phys. Chem. Chem. Phys. 2, 2177 (2000). ! ... 3) Salomon R. Billeter, Alessandro Curioni, Wanda Andreoni, ! ... Comput. Mat. Science 27, 437, (2003). ! ... 4) Ren Weiqing, PhD Thesis: Numerical Methods for the Study of Energy ! ... Landscapes and Rare Events. ! ! USE parameters, ONLY : DP USE io_files, ONLY : iunbfgs ! USE basic_algebra_routines ! IMPLICIT NONE ! PRIVATE ! ! ... public methods ! PUBLIC :: bfgs, & lin_bfgs ! ! ... public variables ! PUBLIC :: lbfgs_ndim, & trust_radius_max, & trust_radius_min, & trust_radius_ini, & trust_radius_end, & w_1, & w_2 ! ! ... global variables ! REAL(KIND=DP), ALLOCATABLE :: & pos_old(:,:), &! list of m old positions ( m = 1 for ! standard BFGS algorithm ) inverse_hessian(:,:), &! inverse of the hessian matrix (updated via ! BFGS formula) bfgs_step(:), &! bfgs direction bfgs_step_old(:), &! old bfgs direction gradient_old(:,:) ! list of m old gradients ( m = 1 for ! standard BFGS algorithm ) INTEGER :: & lbfgs_ndim = 4 ! dimension of the subspace for L-BFGS ! fixed to 1 for standard BFGS algorithm REAL(KIND=DP) :: & trust_radius, &! displacement along the bfgs direction trust_radius_old, &! old displacement along the bfgs direction energy_old ! old energy INTEGER :: & scf_iter, &! number of scf iterations bfgs_iter, &! number of bfgs iterations lin_iter ! number of line search iterations REAL(KIND=DP) :: & trust_radius_max = 0.5D0, &! maximum allowed displacement trust_radius_min = 1.D-5, &! minimum allowed displacement trust_radius_ini = 0.5D0, &! initial displacement trust_radius_end = 1.D-7 ! bfgs stops when trust_radius is less than ! this value REAL(KIND=DP) :: & w_1 = 0.5D-1, &! parameters for Wolfe conditions w_2 = 0.5D0 ! parameters for Wolfe conditions ! ! ... Note that m, trust_radius_max, trust_radius_min, trust_radius_ini, ! ... trust_radius_end, w_1, w_2 have a default value, but can also be ! ... assigned in input ! ! CONTAINS ! ! ! ... public methods : ! !----------------------------------------------------------------------- SUBROUTINE bfgs( pos, energy, gradient, scratch, stdout, energy_thr, & gradient_thr, energy_error, gradient_error, & step_accepted, conv_bfgs ) !----------------------------------------------------------------------- ! ! ... list of input/output arguments : ! ! pos : vector containing 3N coordinates of the system ( x ) ! energy : energy of the system ( V(x) ) ! gradient : vector containing 3N components of ( grad( V(x) ) ) ! scratch : scratch diercotry ! stdout : unit for standard output ! energy_thr : treshold on energy difference for BFGS convergence ! gradient_thr : treshold on gradient difference for BFGS convergence ! the largest component of grad( V(x) ) is considered ! energy_error : energy difference | V(x_i) - V(x_i-1) | ! gradient_error : the largest component of ! | grad(V(x_i)) - grad(V(x_i-1)) | ! step_accepted : .TRUE. if a new BFGS step is done ! conv_bfgs : .TRUE. if BFGS convergence has been achieved ! USE constants, ONLY : eps16 ! IMPLICIT NONE ! ! ... input/output arguments ! REAL(KIND=DP), INTENT(INOUT) :: pos(:) REAL(KIND=DP), INTENT(INOUT) :: energy REAL(KIND=DP), INTENT(INOUT) :: gradient(:) CHARACTER (LEN=*), INTENT(IN) :: scratch INTEGER, INTENT(IN) :: stdout REAL(KIND=DP), INTENT(IN) :: energy_thr, gradient_thr REAL(KIND=DP), INTENT(OUT) :: energy_error, gradient_error LOGICAL, INTENT(OUT) :: step_accepted, conv_bfgs ! ! ... local variables ! INTEGER :: dim, i LOGICAL :: lwolfe ! ! dim = SIZE( pos ) ! ! ... lbfgs_ndim is forced to be equal to 1 ( the complete inverse ! ... hessian matrix is stored ) ! lbfgs_ndim = 1 ! ALLOCATE( pos_old( dim, lbfgs_ndim ) ) ALLOCATE( inverse_hessian( dim, dim ) ) ALLOCATE( bfgs_step( dim ) ) ALLOCATE( bfgs_step_old( dim ) ) ALLOCATE( gradient_old( dim, lbfgs_ndim ) ) ! CALL read_bfgs_file( pos, energy, gradient, scratch, dim ) ! scf_iter = scf_iter + 1 ! conv_bfgs = ( ( energy_old - energy ) < energy_thr ) ! energy_error = ABS( energy_old - energy ) gradient_error = 0.D0 ! DO i = 1, dim ! conv_bfgs = ( conv_bfgs .AND. ( ABS( gradient(i) ) < gradient_thr ) ) ! gradient_error = MAX( gradient_error, ABS( gradient(i) ) ) ! END DO ! ! ... as long as the first two scf iterations have been performed the ! ... error on the energy is redefined as a "large" number. ! IF ( scf_iter < 2 ) energy_error = 1000.D0 ! IF ( conv_bfgs ) THEN ! CALL terminate_bfgs( energy, stdout, scratch ) ! RETURN ! END IF ! WRITE( UNIT = stdout, & & FMT = '(/,5X,"number of ionic steps",T30,"= ",I3)' ) scf_iter WRITE( UNIT = stdout, & & FMT = '( 5X,"number of bfgs steps",T30,"= ",I3,/)' ) bfgs_iter IF ( scf_iter > 1 ) & WRITE( UNIT = stdout, & & FMT = '(5X,"energy old",T30,"= ",F18.10," ryd")' ) energy_old WRITE( UNIT = stdout, & & FMT = '(5X,"energy new",T30,"= ",F18.10," ryd",/)' ) energy ! IF ( energy > energy_old ) THEN ! ! ... the previous step is rejected, line search goes on ! step_accepted = .FALSE. ! lin_iter = lin_iter + 1 ! WRITE( UNIT = stdout, & & FMT = '(5X,"CASE: energy_new > energy_old",/)' ) ! ! ... the old trust radius is reduced by a factor 2 ! trust_radius = 0.5D0 * trust_radius_old ! WRITE( UNIT = stdout, & & FMT = '(5X,"new trust radius",T30,"= ",F18.10," bohr",/)' ) & trust_radius ! IF ( trust_radius < trust_radius_min ) THEN ! ! ... the history is reset ! WRITE( UNIT = stdout, FMT = '(/,5X,"resetting bfgs history",/)' ) ! inverse_hessian = identity(dim) ! bfgs_step = - ( inverse_hessian .times. gradient ) ! trust_radius = trust_radius_min ! ELSE ! ! ... values of the last succeseful bfgs step are restored ! pos = pos_old(:,1) energy = energy_old gradient = gradient_old(:,1) ! ! ... old bfgs direction ( normalized ) is recovered ! bfgs_step = bfgs_step_old / trust_radius_old ! END IF ! ELSE ! ! ... a new bfgs step is done ! step_accepted = .TRUE. ! lin_iter = 1 bfgs_iter = bfgs_iter + 1 ! IF ( bfgs_iter > 1 ) THEN ! WRITE( UNIT = stdout, & & FMT = '(5X,"CASE: energy_new < energy_old",/)' ) ! CALL check_wolfe_conditions( lwolfe, energy, gradient ) ! IF ( lwolfe ) THEN ! WRITE( UNIT = stdout, & & FMT = '(5X,"Wolfe conditions satisfied",/)' ) ! ELSE ! WRITE( UNIT = stdout, & & FMT = '(5X,"Wolfe conditions not satisfied",/)' ) ! END IF ! CALL update_inverse_hessian( gradient, dim, stdout ) ! END IF ! ! ... bfgs direction ( not normalized ) ! bfgs_step = - ( inverse_hessian .times. gradient ) ! IF ( ( gradient .dot. bfgs_step ) > 0.D0 ) THEN ! ! ... bfgs direction is reversed if not downhill ! bfgs_step = - bfgs_step ! WRITE( UNIT = stdout, FMT = '(5X,"search direction reversed",/)' ) ! ! ... the history is reset ! WRITE( UNIT = stdout, FMT = '(5X,"resetting bfgs history",/)' ) ! inverse_hessian = identity(dim) ! END IF ! ! ... the new trust radius is computed ! IF ( bfgs_iter == 1 ) THEN ! trust_radius = trust_radius_ini ! ELSE ! CALL compute_trust_radius( lwolfe, energy, gradient, dim, & stdout, conv_bfgs ) ! END IF ! ! ... if trust_radius < trust_radius_end convergence is achieved ! IF ( conv_bfgs ) THEN ! CALL terminate_bfgs( energy, stdout, scratch ) ! RETURN ! END IF ! WRITE( UNIT = stdout, & & FMT = '(5X,"new trust radius",T30,"= ",F18.10," bohr",/)' ) & trust_radius ! END IF ! ! ... step along the bfgs direction ! IF ( norm( bfgs_step ) < eps16 ) THEN ! WRITE( UNIT = stdout, & & FMT = '(5X,"WARNING : norm( bfgs_step )",T30,"= ",F18.10)' ) & norm( bfgs_step ) ! bfgs_step = - gradient ! ELSE ! bfgs_step = trust_radius * bfgs_step / norm( bfgs_step ) ! END IF ! ! ... informations needed for the next iteration are saved ! ... this must be done before positions update ! CALL write_bfgs_file( pos, energy, gradient, scratch ) ! ! ... positions are updated ! pos = pos + bfgs_step ! DEALLOCATE( pos_old ) DEALLOCATE( inverse_hessian ) DEALLOCATE( bfgs_step ) DEALLOCATE( bfgs_step_old ) DEALLOCATE( gradient_old ) ! END SUBROUTINE bfgs ! ! !----------------------------------------------------------------------- SUBROUTINE lin_bfgs( pos, energy, gradient, scratch, stdout, energy_thr, & gradient_thr, energy_error, gradient_error, & step_accepted, conv_bfgs ) !----------------------------------------------------------------------- ! ! ... list of input/output arguments : ! ! pos : vector containing 3N coordinates of the system ( x ) ! energy : energy of the system ( V(x) ) ! gradient : vector containing 3N components of ( grad( V(x) ) ) ! scratch : scratch diercotry ! stdout : unit for standard output ! energy_thr : treshold on energy difference for BFGS convergence ! gradient_thr : treshold on gradient difference for BFGS convergence ! the largest component of grad( V(x) ) is considered ! energy_error : energy difference | V(x_i) - V(x_i-1) | ! gradient_error : the largest component of ! | grad(V(x_i)) - grad(V(x_i-1)) | ! step_accepted : .TRUE. if a new BFGS step is done ! conv_bfgs : .TRUE. if BFGS convergence has been achieved ! USE constants, ONLY : eps16 ! IMPLICIT NONE ! ! ! ... input/output arguments ! REAL(KIND=DP), INTENT(INOUT) :: pos(:) REAL(KIND=DP), INTENT(INOUT) :: energy REAL(KIND=DP), INTENT(INOUT) :: gradient(:) CHARACTER (LEN=*), INTENT(IN) :: scratch INTEGER, INTENT(IN) :: stdout REAL(KIND=DP), INTENT(IN) :: energy_thr, gradient_thr REAL(KIND=DP), INTENT(OUT) :: energy_error, gradient_error LOGICAL, INTENT(OUT) :: step_accepted, conv_bfgs ! ! ... local variables ! INTEGER :: dim, i LOGICAL :: lwolfe ! ! dim = SIZE( pos ) ! ALLOCATE( pos_old( dim, lbfgs_ndim ) ) ALLOCATE( gradient_old( dim, lbfgs_ndim ) ) ALLOCATE( bfgs_step( dim ) ) ALLOCATE( bfgs_step_old( dim ) ) ! CALL read_lbfgs_file( pos, energy, gradient, scratch, dim ) ! scf_iter = scf_iter + 1 ! ! ... convergence is checked ! conv_bfgs = ( ( energy_old - energy ) < energy_thr ) ! energy_error = ABS( energy_old - energy ) gradient_error = 0.D0 ! DO i = 1, dim ! conv_bfgs = ( conv_bfgs .AND. ( ABS( gradient(i) ) < gradient_thr ) ) ! gradient_error = MAX( gradient_error, ABS( gradient(i) ) ) ! END DO ! ! ... as long as the first two scf iterations have been performed the ! ... error on the energy is redefined as a "large" number. ! IF ( scf_iter < 2 ) energy_error = 1000.D0 ! IF ( conv_bfgs ) THEN ! ! ... convergence has been achieved ! CALL terminate_bfgs( energy, stdout, scratch ) ! RETURN ! END IF ! WRITE( UNIT = stdout, & & FMT = '(/,5X,"number of ionic steps",T30,"= ",I3)' ) scf_iter WRITE( UNIT = stdout, & & FMT = '( 5X,"number of bfgs steps",T30,"= ",I3,/)' ) bfgs_iter IF ( scf_iter > 1 ) & WRITE( UNIT = stdout, & & FMT = '(5X,"energy old",T30,"= ",F18.10," ryd")' ) energy_old WRITE( UNIT = stdout, & & FMT = '(5X,"energy new",T30,"= ",F18.10," ryd",/)' ) energy ! IF ( energy > energy_old ) THEN ! ! ... the previous step is rejected, line search goes on ! step_accepted = .FALSE. ! lin_iter = lin_iter + 1 ! WRITE( UNIT = stdout, & & FMT = '(5X,"CASE: energy_new > energy_old",/)' ) ! ! ... the old trust radius is reduced by a factor 2 ! trust_radius = 0.5D0 * trust_radius_old ! WRITE( UNIT = stdout, & & FMT = '(5X,"new trust radius",T30,"= ",F18.10," bohr",/)' ) & trust_radius ! IF ( trust_radius < trust_radius_min ) THEN ! ! ... the history is reset ! WRITE( UNIT = stdout, FMT = '(5X,"resetting bfgs history",/)' ) ! pos_old = 0.D0 gradient_old = 0.D0 ! bfgs_step = - gradient ! trust_radius = trust_radius_min ! ELSE ! ! ... values of the last succeseful bfgs step are restored ! pos = pos_old(:,lbfgs_ndim) energy = energy_old gradient = gradient_old(:,lbfgs_ndim) ! ! ... old bfgs direction ( normalized ) is recovered ! bfgs_step = bfgs_step_old / trust_radius_old ! END IF ! ELSE ! ! ... a new bfgs step is done ! step_accepted = .TRUE. ! lin_iter = 1 bfgs_iter = bfgs_iter + 1 ! WRITE( UNIT = stdout, & & FMT = '(5X,"CASE: energy_new < energy_old",/)' ) ! ! ... Wolfe conditions and hessian update are needed after ! ... the first bfgs iteration ! IF ( bfgs_iter == 1 ) THEN ! bfgs_step = - gradient ! ELSE ! CALL check_wolfe_conditions( lwolfe, energy, gradient ) ! IF ( lwolfe ) THEN ! WRITE( UNIT = stdout, & & FMT = '(5X,"Wolfe conditions satisfied",/)' ) ! ELSE ! WRITE( UNIT = stdout, & & FMT = '(5X,"Wolfe conditions not satisfied",/)' ) ! END IF ! CALL lbfgs_update( pos, gradient, dim ) ! END IF ! IF ( ( gradient .dot. bfgs_step ) > 0.D0 ) THEN ! ! ... bfgs direction is reversed if not downhill ! bfgs_step = - bfgs_step ! WRITE( UNIT = stdout, FMT = '(5X,"search direction reversed")' ) ! ! ... the history is reset ! WRITE( UNIT = stdout, FMT = '(5X,"resetting bfgs history",/)' ) ! pos_old = 0.D0 gradient_old = 0.D0 ! END IF ! ! ... the new trust radius is computed ! IF ( bfgs_iter == 1 ) THEN ! trust_radius = trust_radius_ini ! ELSE ! CALL compute_trust_radius( lwolfe, energy, gradient, dim, & stdout, conv_bfgs ) ! END IF ! ! ... if trust_radius < trust_radius_end convergence is achieved ! ... this should be a "rare event" ! IF ( conv_bfgs ) THEN ! CALL terminate_bfgs( energy, stdout, scratch ) ! RETURN ! END IF ! WRITE( UNIT = stdout, & & FMT = '(5X,"new trust radius",T30,"= ",F18.10," bohr",/)' ) & trust_radius ! END IF ! ! ... step along the bfgs direction ! IF ( norm( bfgs_step ) < eps16 ) THEN ! WRITE( UNIT = stdout, & & FMT = '(5X,"WARNING : norm( bfgs_step )",T30,"= ",F18.10)' ) & norm( bfgs_step ) ! bfgs_step = - gradient ! ELSE ! bfgs_step = trust_radius * bfgs_step / norm( bfgs_step ) ! END IF ! ! ... informations needed for the next iteration are saved ! ... this must be done before positions update ! CALL write_lbfgs_file( pos, energy, gradient, scratch ) ! ! ... positions are updated for a new scf calculation ! pos = pos + bfgs_step ! DEALLOCATE( pos_old ) DEALLOCATE( gradient_old ) DEALLOCATE( bfgs_step ) DEALLOCATE( bfgs_step_old ) ! END SUBROUTINE lin_bfgs ! ! ! ... private methods : ! !----------------------------------------------------------------------- SUBROUTINE read_bfgs_file( pos, energy, gradient, scratch, dim ) !----------------------------------------------------------------------- ! USE io_files, ONLY : prefix ! IMPLICIT NONE ! REAL(KIND=DP), INTENT(INOUT) :: pos(:) REAL(KIND=DP), INTENT(INOUT) :: energy REAL(KIND=DP), INTENT(INOUT) :: gradient(:) CHARACTER (LEN=*), INTENT(IN) :: scratch INTEGER, INTENT(IN) :: dim ! ! ... local variables ! CHARACTER (LEN=256) :: bfgs_file LOGICAL :: file_exists ! ! bfgs_file = TRIM( scratch ) // TRIM( prefix ) //'.bfgs' ! INQUIRE( FILE = TRIM( bfgs_file ) , EXIST = file_exists ) ! IF ( file_exists ) THEN ! ! ... bfgs is restarted from file ! OPEN( UNIT = iunbfgs, FILE = TRIM( bfgs_file ), & STATUS = 'UNKNOWN', ACTION = 'READ' ) ! READ( iunbfgs, * ) scf_iter READ( iunbfgs, * ) bfgs_iter READ( iunbfgs, * ) lin_iter READ( iunbfgs, * ) pos_old READ( iunbfgs, * ) energy_old READ( iunbfgs, * ) gradient_old READ( iunbfgs, * ) bfgs_step_old READ( iunbfgs, * ) trust_radius_old READ( iunbfgs, * ) inverse_hessian ! CLOSE( UNIT = iunbfgs ) ! ELSE ! ! ... bfgs initialization ! scf_iter = 0 bfgs_iter = 0 lin_iter = 0 pos_old(:,lbfgs_ndim) = pos energy_old = energy gradient_old(:,lbfgs_ndim) = gradient bfgs_step_old = 0.D0 trust_radius_old = trust_radius_ini inverse_hessian = identity(dim) ! END IF ! END SUBROUTINE read_bfgs_file ! ! !----------------------------------------------------------------------- SUBROUTINE read_lbfgs_file( pos, energy, gradient, scratch, dim ) !----------------------------------------------------------------------- ! USE io_files, ONLY : prefix ! IMPLICIT NONE ! REAL(KIND=DP), INTENT(INOUT) :: pos(:) REAL(KIND=DP), INTENT(INOUT) :: energy REAL(KIND=DP), INTENT(INOUT) :: gradient(:) CHARACTER (LEN=*), INTENT(IN) :: scratch INTEGER, INTENT(IN) :: dim ! ! ... local variables ! CHARACTER (LEN=256) :: bfgs_file LOGICAL :: file_exists ! ! bfgs_file = TRIM( scratch ) // TRIM( prefix ) //'.bfgs' ! INQUIRE( FILE = TRIM( bfgs_file ) , EXIST = file_exists ) ! IF ( file_exists ) THEN ! ! ... bfgs is restarted from file ! OPEN( UNIT = iunbfgs, FILE = TRIM( bfgs_file ), & STATUS = 'UNKNOWN', ACTION = 'READ' ) ! READ( iunbfgs, * ) scf_iter READ( iunbfgs, * ) bfgs_iter READ( iunbfgs, * ) lin_iter READ( iunbfgs, * ) pos_old(:,1:lbfgs_ndim) READ( iunbfgs, * ) energy_old READ( iunbfgs, * ) gradient_old(:,1:lbfgs_ndim) READ( iunbfgs, * ) bfgs_step_old READ( iunbfgs, * ) trust_radius_old ! CLOSE( UNIT = iunbfgs ) ! ELSE ! ! ... bfgs initialization ! scf_iter = 0 bfgs_iter = 0 lin_iter = 0 pos_old = 0.D0 energy_old = energy gradient_old = 0.D0 trust_radius_old = trust_radius_ini bfgs_step_old = 0.D0 ! END IF ! END SUBROUTINE read_lbfgs_file ! ! !----------------------------------------------------------------------- SUBROUTINE write_bfgs_file( pos, energy, gradient, scratch ) !----------------------------------------------------------------------- ! USE io_files, ONLY : prefix ! IMPLICIT NONE ! REAL(KIND=DP), INTENT(IN) :: pos(:) REAL(KIND=DP), INTENT(IN) :: energy REAL(KIND=DP), INTENT(IN) :: gradient(:) CHARACTER (LEN=*), INTENT(IN) :: scratch ! ! OPEN( UNIT = iunbfgs, FILE = TRIM( scratch )//TRIM( prefix )//'.bfgs', & STATUS = 'UNKNOWN', ACTION = 'WRITE' ) ! WRITE( iunbfgs, * ) scf_iter WRITE( iunbfgs, * ) bfgs_iter WRITE( iunbfgs, * ) lin_iter WRITE( iunbfgs, * ) pos WRITE( iunbfgs, * ) energy WRITE( iunbfgs, * ) gradient WRITE( iunbfgs, * ) bfgs_step WRITE( iunbfgs, * ) trust_radius WRITE( iunbfgs, * ) inverse_hessian ! CLOSE( UNIT = iunbfgs ) ! END SUBROUTINE write_bfgs_file ! ! !----------------------------------------------------------------------- SUBROUTINE write_lbfgs_file( pos, energy, gradient, scratch ) !----------------------------------------------------------------------- ! USE io_files, ONLY : prefix ! IMPLICIT NONE ! REAL(KIND=DP), INTENT(IN) :: pos(:) REAL(KIND=DP), INTENT(IN) :: energy REAL(KIND=DP), INTENT(IN) :: gradient(:) CHARACTER (LEN=*), INTENT(IN) :: scratch ! ! OPEN( UNIT = iunbfgs, FILE = TRIM( scratch )//TRIM( prefix )//'.bfgs', & STATUS = 'UNKNOWN', ACTION = 'WRITE' ) ! WRITE( iunbfgs, * ) scf_iter WRITE( iunbfgs, * ) bfgs_iter WRITE( iunbfgs, * ) lin_iter WRITE( iunbfgs, * ) pos_old(:,2:lbfgs_ndim), pos WRITE( iunbfgs, * ) energy WRITE( iunbfgs, * ) gradient_old(:,2:lbfgs_ndim), gradient WRITE( iunbfgs, * ) bfgs_step WRITE( iunbfgs, * ) trust_radius ! CLOSE( UNIT = iunbfgs ) ! END SUBROUTINE write_lbfgs_file ! ! !----------------------------------------------------------------------- SUBROUTINE update_inverse_hessian( gradient, dim, stdout ) !----------------------------------------------------------------------- ! USE constants, ONLY : eps16 ! IMPLICIT NONE ! REAL(KIND=DP), INTENT(IN) :: gradient(:) INTEGER, INTENT(IN) :: dim INTEGER, INTENT(IN) :: stdout ! ! ... local variables ! REAL(KIND=DP) :: y(dim) REAL(KIND=DP) :: sdoty ! ! y = gradient - gradient_old(:,lbfgs_ndim) ! sdoty = ( bfgs_step_old .dot. y ) ! IF ( ABS( sdoty ) < eps16 ) THEN ! ! ... the history is reset ! WRITE( stdout, '(/,5X,"WARINIG: unexpected behaviour in ", & & "update_inverse_hessian")' ) WRITE( stdout, '(5X," resetting bfgs history",/)' ) ! inverse_hessian = identity(dim) ! RETURN ! END IF ! inverse_hessian = inverse_hessian + & ( 1.D0 + ( y .dot. ( inverse_hessian .times. y ) ) / sdoty ) * & matrix( bfgs_step_old, bfgs_step_old ) / sdoty - & ( matrix( bfgs_step_old, ( y .times. inverse_hessian ) ) + & matrix( ( inverse_hessian .times. y ), bfgs_step_old ) ) / sdoty ! END SUBROUTINE update_inverse_hessian ! ! !----------------------------------------------------------------------- SUBROUTINE lbfgs_update( pos, gradient, dim ) !----------------------------------------------------------------------- ! USE constants, ONLY : eps16 ! IMPLICIT NONE ! REAL(KIND=DP), INTENT(IN) :: pos(:) REAL(KIND=DP), INTENT(IN) :: gradient(:) INTEGER, INTENT(IN) :: dim ! ! ... local variables ! INTEGER :: i REAL(KIND=DP) :: s(dim,lbfgs_ndim), y(dim,lbfgs_ndim) REAL(KIND=DP) :: alpha(lbfgs_ndim), sdoty(lbfgs_ndim) REAL(KIND=DP) :: preconditioning ! ! bfgs_step = gradient ! s(:,lbfgs_ndim) = pos - pos_old(:,lbfgs_ndim) y(:,lbfgs_ndim) = gradient - gradient_old(:,lbfgs_ndim) ! DO i = ( lbfgs_ndim - 1 ), 1, -1 ! s(:,i) = pos_old(:,i+1) - pos_old(:,i) y(:,i) = gradient_old(:,i+1) - gradient_old(:,i) ! END DO ! DO i = lbfgs_ndim, 1, -1 ! sdoty(i) = ( s(:,i) .dot. y(:,i) ) ! IF ( sdoty(i) > eps16 ) THEN ! alpha(i) = ( s(:,i) .dot. bfgs_step ) / sdoty(i) ! ELSE ! alpha(i) = 0.D0 ! END IF ! bfgs_step = bfgs_step - alpha(i) * y(:,i) ! END DO ! preconditioning = ( y(:,lbfgs_ndim) .dot. y(:,lbfgs_ndim) ) ! IF ( preconditioning > eps16 ) THEN ! bfgs_step = sdoty(lbfgs_ndim) / preconditioning * bfgs_step ! END IF ! DO i = 1, lbfgs_ndim ! IF ( sdoty(i) > eps16 ) THEN ! bfgs_step = bfgs_step + s(:,i) * ( alpha(i) - & ( y(:,lbfgs_ndim) .dot. bfgs_step ) / sdoty(i) ) ! END IF ! END DO ! bfgs_step = - bfgs_step ! END SUBROUTINE lbfgs_update ! ! !----------------------------------------------------------------------- SUBROUTINE check_wolfe_conditions( lwolfe, energy, gradient ) !----------------------------------------------------------------------- ! IMPLICIT NONE ! REAL(KIND=DP), INTENT(IN) :: energy REAL(KIND=DP), INTENT(IN) :: gradient(:) LOGICAL, INTENT(OUT) :: lwolfe ! ! lwolfe = ( energy - energy_old ) < & w_1 * ( gradient_old(:,lbfgs_ndim) .dot. bfgs_step_old ) ! lwolfe = lwolfe .AND. & ( ABS( gradient .dot. bfgs_step_old ) > & - w_2 * ( gradient_old(:,lbfgs_ndim) .dot. bfgs_step_old ) ) ! END SUBROUTINE check_wolfe_conditions ! ! !----------------------------------------------------------------------- SUBROUTINE compute_trust_radius( lwolfe, energy, gradient, dim, & stdout, conv_bfgs ) !----------------------------------------------------------------------- ! IMPLICIT NONE ! LOGICAL, INTENT(IN) :: lwolfe REAL(KIND=DP), INTENT(IN) :: energy REAL(KIND=DP), INTENT(IN) :: gradient(:) INTEGER, INTENT(IN) :: dim INTEGER, INTENT(IN) :: stdout LOGICAL, INTENT(OUT) :: conv_bfgs ! ! ... local variables ! REAL(KIND=DP) :: a LOGICAL :: ltest ! ! ltest = ( energy - energy_old ) < & w_1 * ( gradient_old(:,lbfgs_ndim) .dot. bfgs_step_old ) ! ltest = ltest .AND. ( norm( bfgs_step ) > trust_radius_old ) ! IF ( ltest ) THEN ! a = 1.25D0 ! ELSE ! a = 1.D0 ! END IF ! IF ( lwolfe ) THEN ! trust_radius = MIN( trust_radius_max, 2.D0 * a * trust_radius_old ) ! ELSE ! trust_radius = MIN( trust_radius_max, a * trust_radius_old, & norm( bfgs_step ) ) ! END IF ! IF ( trust_radius < trust_radius_end ) THEN ! conv_bfgs = .TRUE. ! ELSE IF ( trust_radius < trust_radius_min ) THEN ! ! ... the history is reset ! WRITE( UNIT = stdout, FMT = '(5X,"resetting bfgs history",/)' ) ! IF ( ALLOCATED( inverse_hessian ) ) THEN ! inverse_hessian = identity(dim) ! bfgs_step = - ( inverse_hessian .times. gradient ) ! trust_radius = trust_radius_min ! ELSE ! pos_old = 0.D0 gradient_old = 0.D0 ! bfgs_step = - gradient ! trust_radius = trust_radius_min ! END IF ! END IF ! END SUBROUTINE compute_trust_radius ! ! !----------------------------------------------------------------------- SUBROUTINE terminate_bfgs( energy, stdout, scratch ) !----------------------------------------------------------------------- ! USE io_files, ONLY : prefix ! IMPLICIT NONE ! REAL(KIND=DP), INTENT(IN) :: energy INTEGER, INTENT(IN) :: stdout CHARACTER (LEN=*), INTENT(IN) :: scratch ! ! WRITE( UNIT = stdout, & & FMT = '(/,5X,"bfgs converged in ",I3," ionic steps and ", & & I3," bfgs steps",/)' ) scf_iter, bfgs_iter WRITE( UNIT = stdout, & & FMT = '(5X,"Final energy",T30,"= ",F18.10," ryd")' ) energy ! IF ( ALLOCATED( inverse_hessian ) ) THEN ! WRITE( UNIT = stdout, & & FMT = '(/,5X,"Saving the approssimate hessian",/)' ) ! OPEN( UNIT = iunbfgs, FILE = TRIM( scratch ) // TRIM( prefix ) // & & '.hess', STATUS = 'UNKNOWN', ACTION = 'WRITE' ) ! WRITE( iunbfgs, * ) SHAPE( inverse_hessian ) WRITE( iunbfgs, * ) inverse_hessian ! CLOSE( UNIT = iunbfgs ) ! DEALLOCATE( pos_old ) DEALLOCATE( inverse_hessian ) DEALLOCATE( bfgs_step ) DEALLOCATE( bfgs_step_old ) DEALLOCATE( gradient_old ) ! ELSE ! DEALLOCATE( pos_old ) DEALLOCATE( gradient_old ) DEALLOCATE( bfgs_step ) DEALLOCATE( bfgs_step_old ) ! END IF ! OPEN( UNIT = iunbfgs, & FILE = TRIM( scratch )//TRIM( prefix )//'.bfgs' ) CLOSE( UNIT = iunbfgs, STATUS = 'DELETE' ) ! END SUBROUTINE terminate_bfgs ! END MODULE bfgs_module From degironc at sissa.it Fri Jan 23 08:44:25 2004 From: degironc at sissa.it (Stefano de Gironcoli) Date: Fri, 23 Jan 2004 08:44:25 +0100 Subject: [Pw_forum] Symmetry in PWSCF 1.3.0 - were there any bugs? References: <20040122204107.64590.qmail@web21204.mail.yahoo.com> Message-ID: <4010D0D9.8000800@sissa.it> Konstantin Kudin wrote: > I am trying to run Y2O3 with 1.3.0, and the same >input (coordinates and lattice vectors) produced 24 >sym operations with 1.2.0, but only 6 sym operations >with 1.3.0. The unit cell has 80 atoms (Ia3 symmetry). > > Does the code say something like "fractionary translation not allowed" at the beginning in the 1.3.0 version ? Do the fft dimensions (nr1,nr2,nr3 etc.) differ from 1.2.0 to 1.3.0 ? They should not but if they do this may cause some symmetry operations (involving fractionary translation) to be rejected in one case and accepted in the other one. Stefano de Gironcoli From giannozz at nest.sns.it Fri Jan 23 10:27:33 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 23 Jan 2004 10:27:33 +0100 Subject: [Pw_forum] Symmetry in PWSCF 1.3.0 - were there any bugs? In-Reply-To: <20040122204107.64590.qmail@web21204.mail.yahoo.com> References: <20040122204107.64590.qmail@web21204.mail.yahoo.com> Message-ID: <200401231027.33769.giannozz@nest.sns.it> On Thursday 22 January 2004 21:41, Konstantin Kudin wrote: > I seem to recall some discussion on the list about > some symmetry issues there is a rather lengthy discussion about symmetry issues in the manual. I am quite confident that there is nothing wrong with the symmetry-searching algorithm. If nothing of the following explains your problem, please post your data. Paolo --- \item {\em pw.x does not find all the symmetries you expected.} {\tt pw.x} determines first the symmetry operations (rotations) of the Bravais lattice; then checks which of these are symmetry operations of the system (including if needed fractional translations). This is done by rotating (and translating if needed) the atoms in the unit cell and verifying if the rotated unit cell coincides with the original one. You may miss symmetry operations because: \begin{enumerate} \item The number of significant figures in the atomic positions is not big enough. In {\tt PW/eqvect.f90}, the variable {\tt accep} is used to decide whether a rotation is a symmetry operation. Its current value ($10^{-5}$) is quite strict: a rotated atom must coincide with another atom to 5 significant digits. You may change the value of {\tt accep} and recompile. \item They are not acceptable symmetry operations of the Bravais lattice. This is the case for C$_{60}$, for instance: the $I_h$ icosahedral group of C$_{60}$ contains 5-fold rotations that are incompatible with translation symmetry \item The system is rotated with respect to symmetry axis. For instance: a C$_{60}$ molecule in the fcc lattice will have 24 symmetry operations ($T_h$ group) only if the double bond is aligned along one of the crystal axis; if C$_{60}$ is rotated in some arbitrary way, pw.x may not find any symmetry, apart from inversion. \item They contain a fractional translation that is incompatible with the FFT grid. Typical fractional translations are 1/2 or 1/3 of a lattice vector. If the FFT grid is not divisible respectively by 2 or by 3, the symmetry operation will not transform the FFT grid into itself. Such symmetry operations are disabled to prevent problems with symmetrization. Note that if you change cutoff or unit cell volume, the automatically computed FFT grid changes. and this may explain changes in symmetry (and number of k-points as a consequence) for no apparent good reason (only if you have fractional translations in the system, though). \item A fractional translation, without rotation, is a symmetry operation of the system (meaning that the cell is actually a supercell). In this case, all symmetry operations containing fractional translations are disabled. The reason is that in this rather exotic case there is no (simple) way to select those symmetry operations forming a group (in the strict mathematical sense). -- 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 23 19:58:27 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Fri, 23 Jan 2004 10:58:27 -0800 (PST) Subject: [Pw_forum] Symmetry in PWSCF 1.3.0 - were there any bugs? In-Reply-To: <200401231027.33769.giannozz@nest.sns.it> Message-ID: <20040123185827.76156.qmail@web21203.mail.yahoo.com> Hello, I found the origin of the issue. It appears that the results I tried to match were obtained with a modified code. I attached the relevant piece of explanation below. Perhaps there could be an input parameter that would let people use this ignored symmetry with a large warning printed? Something like "use at your own risk" ... Or do such cases fail in 100% of situations? Kostya Young-Gui Yoon writes: ********************************************** For nonsymmorphic groups, the code do not search thoroughly fractional translations. Therefore, I modified the code to search fractional translations. Then, Paolo let me know why he disabled the search. I am quoting his reply. I removed the modification again (I don't remember where it was, but it is simple.) YG ====================================================================== Hi > 2. In PWSCF, nonsymmorphic space group search has a bug. I don't think so: there is a tricky problem with fractionary translations. What happens is that a symmetry operation with a fractionary translation is not accepted if identity has also a fractionary translation (which means that the cell is a supercell). When this happens, fractionary translations are disabled, because even if good sym.ops. with fractionary translations are generated, there is no guarantee that they form a group. I encountered this problem years ago and found no solution other than disabling fractionary translations altogether in that case. There might be a solution, but the one you propose may not work in some cases. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050509412 Piazza dei Cavalieri 7 Fax: +39/050509417, 050563513 I-56126 Pisa, Italy Office: Lab. NEST, Via della Faggiola 19 ====================================================================== __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From speyer at asu.edu Fri Jan 23 20:50:58 2004 From: speyer at asu.edu (Gil Speyer) Date: Fri, 23 Jan 2004 12:50:58 -0700 Subject: [Pw_forum] Compiling PWscf Message-ID: <021301c3e1ea$385dbcd0$6b29a995@enpc3521> Sbraccia Carlo: the new version of bfgs_module.f90 compiles perfectly, and we're running! Paolo Giannozzi: Our ifc version is 7.1, and this is the development version (CVS) of pwscf. Please note the other codes I had to change slightly in order to compile (mentioned in my previous post). Thanks for your help! Gil Speyer Graduate Student Electrical Engineering Arizona State University From giannozz at nest.sns.it Sat Jan 24 22:17:44 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Sat, 24 Jan 2004 22:17:44 +0100 Subject: [Pw_forum] Compiling PWscf In-Reply-To: <021301c3e1ea$385dbcd0$6b29a995@enpc3521> References: <021301c3e1ea$385dbcd0$6b29a995@enpc3521> Message-ID: <200401242217.44305.giannozz@nest.sns.it> On Friday 23 January 2004 20:50, Gil Speyer wrote: > Please note the other codes I had to change slightly in order to > compile (mentioned in my previous post). My version of ifc 7.1 - the latest available - doesn't complain. There is nothing wrong in the lines you mentioned, as far as I can see. I suspect that the following citation applies to f90 compilers as well: "If builders constructed buildings the way programmers write software, the first woodpecker to come along would cause the collapse of civilization." 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 Sat Jan 24 22:29:17 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Sat, 24 Jan 2004 22:29:17 +0100 Subject: [Pw_forum] Symmetry in PWSCF 1.3.0 - were there any bugs? In-Reply-To: <20040123185827.76156.qmail@web21203.mail.yahoo.com> References: <20040123185827.76156.qmail@web21203.mail.yahoo.com> Message-ID: <200401242229.17808.giannozz@nest.sns.it> On Friday 23 January 2004 19:58, Konstantin Kudin wrote: > Perhaps there could be an input parameter that would > let people use this ignored symmetry with a large > warning printed? Something like "use at your own risk" there are already so many input parameters...it's a one-line change (in PW/sgam_at.f90, comment the line where fractional_translations is set to .false.) > ... Or do such cases fail in 100% of situations? no, they fail depending on the phase of the moon. Maybe somebody will come out with a better solution. The problem is rather trivial: if there are symmetries with "true" fractional translations, in addition to "fake" fractional transations due to the supercell geometry, choose those translations in such a way that the symmetry operations form a group. 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 subhra at physics.rutgers.edu Mon Jan 26 16:26:36 2004 From: subhra at physics.rutgers.edu (Subhradip Ghosh) Date: Mon, 26 Jan 2004 10:26:36 -0500 (EST) Subject: [Pw_forum] compilation error Message-ID: Hi, I am trying to install pwscf1.3.0 on a linux PC with intel fortran compiler and getting the following error after 'make pw': *********************************************************************** ld: Warning: size of symbol `MODULE.reciprocal_vectors_1' changed from 212 to 556 in ../Modules/recvec.o ld: cannot open /home/subhra/pw.1.3.0/clib/clib.a: No such file or directory make[1]: *** [memory] Error 1 make[1]: Leaving directory `/home/subhra/pw.1.3.0/PW' make: *** [pw] Error 2 *********************************************************************** Is it a problem in linking libraries? Subhradip From eyvaz_isaev at yahoo.com Mon Jan 26 16:41:35 2004 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Mon, 26 Jan 2004 07:41:35 -0800 (PST) Subject: [Pw_forum] compilation error In-Reply-To: Message-ID: <20040126154135.90608.qmail@web60307.mail.yahoo.com> Hi, Perhaps, it is due to the compiler error. I had the same error using IFC 7.0 on a parallel computer with Intel CPU's. But on other computers I am using everything was fine. More likely, the error means that sources in the /clib directory are not compiled. Regards, Eyvaz. --- Subhradip Ghosh wrote: > Hi, > I am trying to install pwscf1.3.0 on a linux PC with > intel fortran > compiler and getting the following error after 'make > pw': > *********************************************************************** > ld: Warning: size of symbol > `MODULE.reciprocal_vectors_1' changed from 212 > to 556 in ../Modules/recvec.o > ld: cannot open /home/subhra/pw.1.3.0/clib/clib.a: > No such file or > directory > make[1]: *** [memory] Error 1 > make[1]: Leaving directory > `/home/subhra/pw.1.3.0/PW' > make: *** [pw] Error 2 > *********************************************************************** > Is it a problem in linking libraries? > > Subhradip > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From subhra at ux1.cso.uiuc.edu Mon Jan 26 16:52:30 2004 From: subhra at ux1.cso.uiuc.edu (Subhradip Ghosh) Date: Mon, 26 Jan 2004 09:52:30 -0600 (CST) Subject: [Pw_forum] compilation error In-Reply-To: <20040126154135.90608.qmail@web60307.mail.yahoo.com> Message-ID: On Mon, 26 Jan 2004, Eyvaz Isaev wrote: Thanks. Looks like a compiler error indeed, because /clib doesn't have a file clib.a. Is there a way out anyway? Subhradip > Hi, > > Perhaps, it is due to the compiler error. I had the > same error using IFC 7.0 on a parallel computer with > Intel CPU's. But on other computers I am using > everything was fine. > > More likely, the error means that sources in the /clib > directory are not compiled. > > Regards, > Eyvaz. > > --- Subhradip Ghosh > wrote: > > Hi, > > I am trying to install pwscf1.3.0 on a linux PC with > > intel fortran > > compiler and getting the following error after 'make > > pw': > > > *********************************************************************** > > ld: Warning: size of symbol > > `MODULE.reciprocal_vectors_1' changed from 212 > > to 556 in ../Modules/recvec.o > > ld: cannot open /home/subhra/pw.1.3.0/clib/clib.a: > > No such file or > > directory > > make[1]: *** [memory] Error 1 > > make[1]: Leaving directory > > `/home/subhra/pw.1.3.0/PW' > > make: *** [pw] Error 2 > > > *********************************************************************** > > Is it a problem in linking libraries? > > > > Subhradip > > > > _______________________________________________ > > Pw_forum mailing list > > Pw_forum at pwscf.org > > http://www.democritos.it/mailman/listinfo/pw_forum > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free web site building tool. Try it! > http://webhosting.yahoo.com/ps/sb/ > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > ******************************************************************* Subhradip Ghosh Post doctoral Fellow Department of Materials Science & Engineering University of Illinois at Urbana-Champaign ******************************************************************** Office Home ********************************************************************** MSEB 312C * 2001 South Orchard Street Apt D 1304 W Green street * Urbana, IL-61801 Urbana, IL-61801 * Phone # 2173841824 Phone # 2173336584 * E-mail: subhradip at yahoo.com E-mail: subhra at uiuc.edu * ************************************************************************ From speyer at asu.edu Mon Jan 26 17:28:03 2004 From: speyer at asu.edu (Gil Speyer) Date: Mon, 26 Jan 2004 09:28:03 -0700 Subject: [Pw_forum] compilation error In-Reply-To: Message-ID: <002701c3e429$5ed6bfb0$6b29a995@enpc3521> How about going into clib and typing "make"... -----Original Message----- From: pw_forum-admin at pwscf.org [mailto:pw_forum-admin at pwscf.org] On Behalf Of Subhradip Ghosh Sent: Monday, January 26, 2004 8:53 AM To: pw_forum at pwscf.org Subject: Re: [Pw_forum] compilation error On Mon, 26 Jan 2004, Eyvaz Isaev wrote: Thanks. Looks like a compiler error indeed, because /clib doesn't have a file clib.a. Is there a way out anyway? Subhradip > Hi, > > Perhaps, it is due to the compiler error. I had the > same error using IFC 7.0 on a parallel computer with > Intel CPU's. But on other computers I am using > everything was fine. > > More likely, the error means that sources in the /clib > directory are not compiled. > > Regards, > Eyvaz. > > --- Subhradip Ghosh > wrote: > > Hi, > > I am trying to install pwscf1.3.0 on a linux PC with > > intel fortran > > compiler and getting the following error after 'make > > pw': > > > *********************************************************************** > > ld: Warning: size of symbol > > `MODULE.reciprocal_vectors_1' changed from 212 > > to 556 in ../Modules/recvec.o > > ld: cannot open /home/subhra/pw.1.3.0/clib/clib.a: > > No such file or > > directory > > make[1]: *** [memory] Error 1 > > make[1]: Leaving directory > > `/home/subhra/pw.1.3.0/PW' > > make: *** [pw] Error 2 > > > *********************************************************************** > > Is it a problem in linking libraries? > > > > Subhradip > > > > _______________________________________________ > > Pw_forum mailing list > > Pw_forum at pwscf.org > > http://www.democritos.it/mailman/listinfo/pw_forum > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free web site building tool. Try it! > http://webhosting.yahoo.com/ps/sb/ > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > ******************************************************************* Subhradip Ghosh Post doctoral Fellow Department of Materials Science & Engineering University of Illinois at Urbana-Champaign ******************************************************************** Office Home ********************************************************************** MSEB 312C * 2001 South Orchard Street Apt D 1304 W Green street * Urbana, IL-61801 Urbana, IL-61801 * Phone # 2173841824 Phone # 2173336584 * E-mail: subhradip at yahoo.com E-mail: subhra at uiuc.edu * ************************************************************************ _______________________________________________ Pw_forum mailing list Pw_forum at pwscf.org http://www.democritos.it/mailman/listinfo/pw_forum From subhra at ux1.cso.uiuc.edu Mon Jan 26 17:39:26 2004 From: subhra at ux1.cso.uiuc.edu (Subhradip Ghosh) Date: Mon, 26 Jan 2004 10:39:26 -0600 (CST) Subject: [Pw_forum] compilation error In-Reply-To: <002701c3e429$5ed6bfb0$6b29a995@enpc3521> Message-ID: On Mon, 26 Jan 2004, Gil Speyer wrote: didn't work. The list of error is long and something like the following: **************************************************************fft_stick.c:17:20: fftw.h: No such file or directory fft_stick.c:21: error: parse error before '*' token fft_stick.c: In function `create_plan_1d_': fft_stick.c:23: error: `fftw_direction' undeclared (first use in this function) fft_stick.c:23: error: (Each undeclared identifier is reported only once fft_stick.c:23: error: for each function it appears in.) fft_stick.c:23: error: parse error before "dir" fft_stick.c:24: error: `p' undeclared (first use in this function) fft_stick.c:24: error: `n' undeclared (first use in this function) fft_stick.c:24: error: `dir' undeclared (first use in this function) fft_stick.c:24: error: `FFTW_ESTIMATE' undeclared (first use in this function) fft_stick.c:24: error: `FFTW_IN_PLACE' undeclared (first use in this function) fft_stick.c:25: error: `NULL' undeclared (first use in this function) fft_stick.c:25: error: `stderr' undeclared (first use in this function) fft_stick.c: At top level: fft_stick.c:30: error: parse error before '*' token fft_stick.c: In function `destroy_plan_1d_': fft_stick.c:32: error: `p' undeclared (first use in this function) fft_stick.c:32: error: `NULL' undeclared (first use in this function) ***************************************************************** Misses the fft_stick.c file somehow. Subhradip > How about going into clib and typing "make"... > > -----Original Message----- > From: pw_forum-admin at pwscf.org [mailto:pw_forum-admin at pwscf.org] On > Behalf Of Subhradip Ghosh > Sent: Monday, January 26, 2004 8:53 AM > To: pw_forum at pwscf.org > Subject: Re: [Pw_forum] compilation error > > > On Mon, 26 Jan 2004, Eyvaz Isaev wrote: > > Thanks. Looks like a compiler error indeed, because /clib doesn't have a > file clib.a. > > Is there a way out anyway? > > Subhradip > > > Hi, > > > > Perhaps, it is due to the compiler error. I had the > > same error using IFC 7.0 on a parallel computer with > > Intel CPU's. But on other computers I am using > > everything was fine. > > > > More likely, the error means that sources in the /clib > > directory are not compiled. > > > > Regards, > > Eyvaz. > > > > --- Subhradip Ghosh > > wrote: > > > Hi, > > > I am trying to install pwscf1.3.0 on a linux PC with > > > intel fortran > > > compiler and getting the following error after 'make > > > pw': > > > > > > *********************************************************************** > > > ld: Warning: size of symbol > > > `MODULE.reciprocal_vectors_1' changed from 212 > > > to 556 in ../Modules/recvec.o > > > ld: cannot open /home/subhra/pw.1.3.0/clib/clib.a: > > > No such file or > > > directory > > > make[1]: *** [memory] Error 1 > > > make[1]: Leaving directory > > > `/home/subhra/pw.1.3.0/PW' > > > make: *** [pw] Error 2 > > > > > > *********************************************************************** > > > Is it a problem in linking libraries? > > > > > > Subhradip > > > > > > _______________________________________________ > > > Pw_forum mailing list > > > Pw_forum at pwscf.org > > > http://www.democritos.it/mailman/listinfo/pw_forum > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! SiteBuilder - Free web site building tool. Try it! > > http://webhosting.yahoo.com/ps/sb/ > > _______________________________________________ > > Pw_forum mailing list > > Pw_forum at pwscf.org > > http://www.democritos.it/mailman/listinfo/pw_forum > > > > ******************************************************************* > Subhradip Ghosh > Post doctoral Fellow > Department of Materials Science & Engineering > University of Illinois at Urbana-Champaign > ******************************************************************** > Office Home > ********************************************************************** > MSEB 312C * 2001 South Orchard Street Apt D > 1304 W Green street * Urbana, IL-61801 > Urbana, IL-61801 * Phone # 2173841824 > Phone # 2173336584 * E-mail: subhradip at yahoo.com > E-mail: subhra at uiuc.edu * > ************************************************************************ > > _______________________________________________ > 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 > ******************************************************************* Subhradip Ghosh Post doctoral Fellow Department of Materials Science & Engineering University of Illinois at Urbana-Champaign ******************************************************************** Office Home ********************************************************************** MSEB 312C * 2001 South Orchard Street Apt D 1304 W Green street * Urbana, IL-61801 Urbana, IL-61801 * Phone # 2173841824 Phone # 2173336584 * E-mail: subhradip at yahoo.com E-mail: subhra at uiuc.edu * ************************************************************************ From yanming_ma at hotmail.com Mon Jan 26 17:41:50 2004 From: yanming_ma at hotmail.com (ma Yanming) Date: Tue, 27 Jan 2004 00:41:50 +0800 Subject: [Pw_forum] Asking help for the frozen phonon calculation Message-ID: Dear Users, I have a case to consider the anharmonic effect in the phonon frequency. we can include the anharmonic effect in the Frozen phonon calculation. I do not have any experience on the Frozen phonon calculation. Does anyone use successfuly the PWSCF to do the Frozen phonon calcualtion? I will appreciate you help? Best Regards Yanming Ma PhD Steacie Institute for Molecular Sciences, National Research Councils of Canada. 100 Sussex K1A 0R6 _________________________________________________________________ ??????????????? MSN Hotmail? http://www.hotmail.com From subhra at ux1.cso.uiuc.edu Mon Jan 26 18:08:06 2004 From: subhra at ux1.cso.uiuc.edu (Subhradip Ghosh) Date: Mon, 26 Jan 2004 11:08:06 -0600 (CST) Subject: [Pw_forum] Error in matdyn Message-ID: Hi, I am trying to compile pw.1.3.0 in IBM. Everything compiled fine except few routines in pwtools. It could only compile band_plot amd q2r successfully. The error message I am getting is the following: ********************************************************************* mpxlf -o matdyn.x matdyn.o rigid.o ../PW/error.o ../PW/cryst_to_car.o ../PW/cubicsym.o ../PW/hexsym.o ../PW/kpoint_grid.o ../PW/sgama.o ../PW/sgam_at.o ../PW/sgam_ph.o ../PW/coset.o ../PW/multable.o ../PW/smallg_q.o ../PW/dsum.o ../PW/trnvecc.o ../PW/invmat.o ../PW/checksym.o ../PW/eqvect.o ../PW/setv.o ../PW/irrek.o ../PW/mode_group.o ../PW/cft_3.o ../PW/error_handler.o ../Modules/parameters.o ../Modules/kind.o ../Modules/fft_scalar.o /home/subhra/pwscf/flib/ptools.a /home/subhra/pwscf/flib/flib.a /home/subhra/pwscf/clib/clib.a -lessl -L/usr/local/lib -llapack_rs64c -s -bmaxdata:512000000 ld: 0711-317 ERROR: Undefined symbol: .__constants_MOD__&&_constants ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make: *** [matdyn.x] Error 8 ******************************************************************** Any idea why this is happening? Subhradip ******************************************************************* Subhradip Ghosh Post doctoral Fellow Department of Materials Science & Engineering University of Illinois at Urbana-Champaign ******************************************************************** Office Home ********************************************************************** MSEB 312C * 2001 South Orchard Street Apt D 1304 W Green street * Urbana, IL-61801 Urbana, IL-61801 * Phone # 2173841824 Phone # 2173336584 * E-mail: subhradip at yahoo.com E-mail: subhra at uiuc.edu * ************************************************************************ From konstantin_kudin at yahoo.com Mon Jan 26 18:23:01 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Mon, 26 Jan 2004 09:23:01 -0800 (PST) Subject: [Pw_forum] compilation error In-Reply-To: Message-ID: <20040126172301.75265.qmail@web21201.mail.yahoo.com> It might be easier to go to the root directory of 1.3.0 and type (under csh or tcsh): make clean make all > & make.log & The idea is to have a clean start, and that all the messages go to make.log and not to the terminal, so once it fails at the linking stage, on can track down earlier errors. Often things fail visibly later than when the actual error occured, so having a complete log for forensic purposes is convenient. Then one can do {grep -i error make.log}. Kostya --- Subhradip Ghosh wrote: > On Mon, 26 Jan 2004, Gil Speyer wrote: > > didn't work. The list of error is long and something > like the following: > **************************************************************fft_stick.c:17:20: > fftw.h: No such file or directory > fft_stick.c:21: error: parse error before '*' token > fft_stick.c: In function `create_plan_1d_': > fft_stick.c:23: error: `fftw_direction' undeclared > (first use in this > function) > fft_stick.c:23: error: (Each undeclared identifier > is reported only once > fft_stick.c:23: error: for each function it appears > in.) > fft_stick.c:23: error: parse error before "dir" > fft_stick.c:24: error: `p' undeclared (first use in > this function) > fft_stick.c:24: error: `n' undeclared (first use in > this function) > fft_stick.c:24: error: `dir' undeclared (first use > in this function) > fft_stick.c:24: error: `FFTW_ESTIMATE' undeclared > (first use in this > function) > fft_stick.c:24: error: `FFTW_IN_PLACE' undeclared > (first use in this > function) > fft_stick.c:25: error: `NULL' undeclared (first use > in this function) > fft_stick.c:25: error: `stderr' undeclared (first > use in this function) > fft_stick.c: At top level: > fft_stick.c:30: error: parse error before '*' token > fft_stick.c: In function `destroy_plan_1d_': > fft_stick.c:32: error: `p' undeclared (first use in > this function) > fft_stick.c:32: error: `NULL' undeclared (first use > in this function) > ***************************************************************** > Misses the fft_stick.c file somehow. > > Subhradip __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From giannozz at nest.sns.it Mon Jan 26 21:26:04 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 26 Jan 2004 21:26:04 +0100 Subject: [Pw_forum] compilation error In-Reply-To: References: Message-ID: <200401262126.04274.giannozz@nest.sns.it> On Monday 26 January 2004 17:39, Subhradip Ghosh wrote: > didn't work. The list of error is long no, it's very short, actually: >7:20: fftw.h: No such file or directory all other errors you get are a consequence of this one. If you are using a precompiled copy of fftw (version 2, NOT 3), you need to point to the file fftw.h of the same version of fftw. Otherwise, define in make.sys __USE_INTERNAL_FFTW . > `MODULE.reciprocal_vectors_1' changed from 212 to > 556 in ../Modules/recvec.o this is irrelevant 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 Tue Jan 27 10:17:08 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 27 Jan 2004 10:17:08 +0100 Subject: [Pw_forum] Error in matdyn In-Reply-To: References: Message-ID: <200401271017.08323.giannozz@nest.sns.it> On Monday 26 January 2004 18:08, Subhradip Ghosh wrote: > I am trying to compile pw.1.3.0 in IBM. Everything compiled fine except > few routines in pwtools [....] Any idea why this is happening? in pwtools/Makefile, add ../Modules/constants.o to MODULES = ... 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 subhra at ux1.cso.uiuc.edu Tue Jan 27 13:46:06 2004 From: subhra at ux1.cso.uiuc.edu (Subhradip Ghosh) Date: Tue, 27 Jan 2004 06:46:06 -0600 (CST) Subject: [Pw_forum] Error in matdyn In-Reply-To: <200401271017.08323.giannozz@nest.sns.it> Message-ID: On Tue, 27 Jan 2004, Paolo Giannozzi wrote: Yes. It works now. Thank you very much. Subhradip > On Monday 26 January 2004 18:08, Subhradip Ghosh wrote: > > > I am trying to compile pw.1.3.0 in IBM. Everything compiled fine except > > few routines in pwtools [....] Any idea why this is happening? > > in pwtools/Makefile, add ../Modules/constants.o to MODULES = ... > > 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 > ******************************************************************* Subhradip Ghosh Post doctoral Fellow Department of Materials Science & Engineering University of Illinois at Urbana-Champaign ******************************************************************** Office Home ********************************************************************** MSEB 312C * 2001 South Orchard Street Apt D 1304 W Green street * Urbana, IL-61801 Urbana, IL-61801 * Phone # 2173841824 Phone # 2173336584 * E-mail: subhradip at yahoo.com E-mail: subhra at uiuc.edu * ************************************************************************ From breezejd at lsbu.ac.uk Tue Jan 27 15:07:24 2004 From: breezejd at lsbu.ac.uk (Jonathan Breeze) Date: Tue, 27 Jan 2004 14:07:24 +0000 Subject: [Pw_forum] is D3 working now? Message-ID: <4016709C.6070908@lsbu.ac.uk> Dear Paolo, I recall that there was maybe a problem with D3.x in the pw.1.2.0 version, hence I have been using pw.1.1.2. Do you know if D3.x is working with pw.1.3.0 or CVS versions ? -- Jonathan Breeze Research Fellow Centre for Physical Electronics and Materials London South Bank University 103 Borough Road London SE1 0AA Tel: +44(0)20 7815 7582 Fax: +44(0)20 7815 7599 From breezejd at lsbu.ac.uk Wed Jan 28 16:33:00 2004 From: breezejd at lsbu.ac.uk (Jonathan Breeze) Date: Wed, 28 Jan 2004 15:33:00 +0000 Subject: [Pw_forum] cpmd2upf conversion Message-ID: <4017D62C.6010901@lsbu.ac.uk> In the upftool 'cpmd2upf', after reading the &POTENTIAL tag, the program executes read (iunps,*) mesh_, amesh Unfortunately, the CPMD pseudopotential file only has a single entrey after &POTENTIAL (that is, no amesh value). The program reads the amesh value from the next line which contains pseudopotential data, hence it ultimately fails when it doesn't find mesh_ data entries. My question is, what is 'amesh', and if it is missing from a psp file, can it be inferred ? Many thanks -- Jonathan Breeze Research Fellow Centre for Physical Electronics and Materials London South Bank University 103 Borough Road London SE1 0AA Tel: +44(0)20 7815 7582 Fax: +44(0)20 7815 7599 From konstantin_kudin at yahoo.com Thu Jan 29 00:01:54 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Wed, 28 Jan 2004 15:01:54 -0800 (PST) Subject: [Pw_forum] Error encountered while attempting to allocate a data object. In-Reply-To: <4017D62C.6010901@lsbu.ac.uk> Message-ID: <20040128230154.75035.qmail@web21204.mail.yahoo.com> Hi there I am trying to run a job with 128 Mg atoms and no symmetry. I request that the gamma point is used for the K space grid. When I run memory.x, I get the following estimates: Number of processors/pools: 1 1 Estimated Max memory (Gamma-only code): 941.62Mb nonscalable memory = 30.51Mb scalable memory = 768.65Mb nonscalable wspace = 70.90Mb scalable wspace = 71.55Mb (diag: -663.26Mb, mix: 71.55Mb) It looks like the amount of memory for "diag:" got wrapped around the 32-bit limit and became negative. At least, I get numbers without "-" for really small jobs. The other numbers look reasonable. Then when I actually run pw.x, I get the error: 1525-108 Error encountered while attempting to allocate a data object. The program will stop. I tried to run the code both under 32-bit linux on a computer with 2Gb of RAM, and also on an IBM with 2Gb of RAM. The same problem happens on both machines. I lowered the PW cutoff from 28.0 to 15.0, and also used "diago_david_ndim=2", and then I got from memory.x: Estimated Max memory (Gamma-only code): 1739.87Mb nonscalable memory = 28.41Mb scalable memory = 300.81Mb nonscalable wspace = 64.66Mb scalable wspace = 1345.99Mb (diag: 1345.99Mb, mix: 28.10Mb) Well, pw.x still gives the same error. Can anyone shed some light on what is going on here and what is a possible workaround? Thanks! Kostya __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From konstantin_kudin at yahoo.com Thu Jan 29 02:50:06 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Wed, 28 Jan 2004 17:50:06 -0800 (PST) Subject: [Pw_forum] Error encountered while attempting to allocate a data object. In-Reply-To: Message-ID: <20040129015006.87608.qmail@web21205.mail.yahoo.com> Dear Serguei Thanks for the tips! I seem to recall now that under IBM AIX in 32-bits -bmaxdata can request RAM up to 2Gb. I had it at 512Mb, now I recompiled with -bmaxdata:0x7FFFFFFF {2Gb-1byte} and the scaled down version of the job proceeded. (Note to Paolo: should not this value be set as the default in the standard make file? As far as I know, it does not hurt anything ...) > 1. You'll need to compile a static binary. If you > use ifc, > use "-static" flag (or "-Wl,-non_shared" if you > like to be > fancy). You are also limited to MKL 5.1 or ATLAS > for BLAS > - later versions of MKL don't support static > linking. Regarding Intel compiler, what is the default size of the memory (i.e. without extra flags) there? Is it up to 1Gb, or something smaller? > 2. You may need to rebuild Linux kernel. Take a look > at > /proc/config.gz - you should be using > "CONFIG_1GB" kernel > (or preferably "CONFIG_05GB", if your > distribution supports > it). This job with definitly NOT run with > "CONFIG_2GB" or > "CONFIG_3GB" kernels. [*] I think I was able to run programs that used up to 1.6Gb under Linux, so the kernel seems to be fine. Is there a way to reduce the memory required for a given PWSCF job? Or should I just move to a 64-bit machine with enough physical RAM such as an SGI? Thanks! Kostya __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From ps at ned.sims.nrc.ca Thu Jan 29 00:36:58 2004 From: ps at ned.sims.nrc.ca (Serguei Patchkovskii) Date: Wed, 28 Jan 2004 18:36:58 -0500 (EST) Subject: [Pw_forum] Error encountered while attempting to allocate a data object. In-Reply-To: <20040128230154.75035.qmail@web21204.mail.yahoo.com> Message-ID: On Wed, 28 Jan 2004, Konstantin Kudin wrote: > Then when I actually run pw.x, I get the error: > 1525-108 Error encountered while attempting to > allocate a data object. The program will stop. IBM AIX? Make sure you use the "-bmaxdata" flag set to something high enough. As far as I recall, the absolute maximum you could use is 2560 megabytes. > memory.x: > Estimated Max memory (Gamma-only code): > 1739.87Mb > nonscalable memory = 28.41Mb > scalable memory = 300.81Mb > nonscalable wspace = 64.66Mb > scalable wspace = 1345.99Mb (diag: > 1345.99Mb, mix: 28.10Mb) You should still be able to do this on a Linux PC, BUT: 1. You'll need to compile a static binary. If you use ifc, use "-static" flag (or "-Wl,-non_shared" if you like to be fancy). You are also limited to MKL 5.1 or ATLAS for BLAS - later versions of MKL don't support static linking. 2. You may need to rebuild Linux kernel. Take a look at /proc/config.gz - you should be using "CONFIG_1GB" kernel (or preferably "CONFIG_05GB", if your distribution supports it). This job with definitly NOT run with "CONFIG_2GB" or "CONFIG_3GB" kernels. [*] #2 should not be necessary with a 64-bit kernel on Opteron - you autimatically get the largest possible address space, even for a 32-bit process. Serguei [*] Technical background: the amount of memory your job can allocate is close to the difference between PAGE_OFFSET_RAW and TASK_UNMAPPED_BASE kernel #define's. Linux kernel occupies address space above PAGE_OFFSET_RAW; Your program's stack is usually growing down from that address. Your program's code and static data are usually found at low addresses, while (large) dynamically allocated arrays grow up from about TASK_UNMAPPED_BASE. You can get a pretty good idea of what is going on by taking a look at the contents of "/proc/$$/maps" --- Dr. Serguei Patchkovskii Tel: +1-(613)-990-0945 Fax: +1-(613)-947-2838 E-mail: Serguei.Patchkovskii at nrc.ca Coordinator of Modelling Software Theory and Computation Group Steacie Institute for Molecular Sciences National Research Council Canada Room 2011, 100 Sussex Drive Ottawa, Ontario K1A 0R6 Canada From ps at ned.sims.nrc.ca Thu Jan 29 03:37:24 2004 From: ps at ned.sims.nrc.ca (Serguei Patchkovskii) Date: Wed, 28 Jan 2004 21:37:24 -0500 (EST) Subject: [Pw_forum] Error encountered while attempting to allocate a d ata object. In-Reply-To: <20040129015006.87608.qmail@web21205.mail.yahoo.com> Message-ID: On Wed, 28 Jan 2004, Konstantin Kudin wrote: > Regarding Intel compiler, what is the default size of > the memory (i.e. without extra flags) there? Is it up > to 1Gb, or something smaller? That depends on the compiler options, kernel, the C library, and any other libraries linked in. At least some 2.4-series kernels also contain a bug in memory management routines, which may make the maximum memory size decrease with time. I usually end up running a little test program (attached) every time I am not entirely sure. E.g.: Linux 2.4.10 (1GB); glibc 2.2.4; ifc -FR : BSS is around 807DDF8 ( 128.492 Mb) stack is around BFFFF620 ( -1024.002 Mb) Max array size = 2036.000 mbyte Last array was at 409A2040 ( 1033.633 Mb) Max second array size = 0.000 mbyte Last second array was at 409A2040 ( 1033.633 Mb) Linux 2.4.18 (0.5GB); glibc 2.2.5; ifc -FR : BSS is around 807DD9C ( 128.492 Mb) stack is around DFFFF410 ( -512.003 Mb) Max array size = 2044.000 mbyte Last array was at EAA8040 ( 234.656 Mb) Max second array size = 1304.000 mbyte Last second array was at ********** ( -1817.340 Mb) Linux(x86_64) 2.4.19; glibc 2.3.2; ifc -FR: BSS is around 807DDBC ( 128.492 Mb) stack is around FFFFD280 ( -0.011 Mb) Max array size = 2044.000 mbyte Last array was at 40AC7040 ( 1034.777 Mb) Max second array size = 1016.000 mbyte Last second array was at ********** ( -1017.219 Mb) Linux(x86_64) 2.4.19; glibc 2.3.2; pfg90 -Mfree (32-bit) : BSS is around 8067188 ( 0.000 Mb) stack is around 806EFC8 ( 0.000 Mb) Max array size = 3068.000 mbyte Last array was at 401A1010 ( 1025.629 Mb) Max second array size = 892.000 mbyte Last second array was at 8073950 ( 128.451 Mb) As you can see, the results can be quite variable :-0) Cheers, Serguei --- Dr. Serguei Patchkovskii Tel: +1-(613)-990-0945 Fax: +1-(613)-947-2838 E-mail: Serguei.Patchkovskii at nrc.ca Coordinator of Modelling Software Theory and Computation Group Steacie Institute for Molecular Sciences National Research Council Canada Room 2011, 100 Sussex Drive Ottawa, Ontario K1A 0R6 Canada -------------- next part -------------- program mem implicit none integer, parameter :: inc = 1024*1024 integer, allocatable :: ary(:), ary1(:), ary2(:) integer :: size, status integer*8 :: addr logical :: failed integer, save :: static = 1 write (6,"(' BSS is around ',z10,' (',f10.3,' Mb)')") & loc(static), loc(static)/(1024d0**2) write (6,"(' stack is around ',z10,' (',f10.3,' Mb)')") & loc(failed), loc(failed)/(1024d0**2) failed = .false. size = 0 do while (.not.failed) size = size + inc status = 0 allocate (ary(size),stat=status) if (status/=0) then failed = .true. else addr = loc(ary) deallocate (ary) end if end do write (6,"(' Max array size = ',f10.3,' mbyte')") & ((0d0+size-inc)*bit_size(ary))/8d0/(1024d0**2) write (6,"(' Last array was at ',z10,' (',f10.3,' Mb)')") & addr, addr/(1024d0**2) allocate (ary1(size-inc)) failed = .false. size = 0 do while (.not.failed) size = size + inc status = 0 allocate (ary(size),stat=status) if (status/=0) then failed = .true. else addr = loc(ary) deallocate (ary) end if end do write (6,"(' Max second array size = ',f10.3,' mbyte')") & ((0d0+size-inc)*bit_size(ary))/8d0/(1024d0**2) write (6,"(' Last second array was at ',z10,' (',f10.3,' Mb)')") & addr, addr/(1024d0**2) allocate (ary2(size-inc)) pause end program mem From giannozz at nest.sns.it Thu Jan 29 10:30:14 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 29 Jan 2004 10:30:14 +0100 Subject: [Pw_forum] cpmd2upf conversion In-Reply-To: <4017D62C.6010901@lsbu.ac.uk> References: <4017D62C.6010901@lsbu.ac.uk> Message-ID: <200401291030.14513.giannozz@nest.sns.it> On Wednesday 28 January 2004 16:33, Jonathan Breeze wrote: > In the upftool 'cpmd2upf', after reading the &POTENTIAL tag, the program > executes > > read (iunps,*) mesh_, amesh > > Unfortunately, the CPMD pseudopotential file only has a single entry > after &POTENTIAL (that is, no amesh value). there are several different formats of CPMD pseudopotentials, and no documentation. The converter works for one specific case, i.e., the only one I know. "amesh" is a parameter of the logarithmic grid and can be inferred from it: r(i) = r_0*exp(i*amesh) (grid not starting from 0) or r(i) = r_0*(exp(i*amesh) -1) (grid starting from 0). Maybe your CPMD potential does not use a logarithmic grid. About your second question: I have been told that somebody is working on D3 right now. If you have successfully used a previous version, you can easily verify if the new version is working: the input data of D3.x and of the phonon code is little changed from previous versions. 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 29 10:53:16 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 29 Jan 2004 10:53:16 +0100 Subject: [Pw_forum] Error encountered while attempting to allocate a data object. In-Reply-To: <20040128230154.75035.qmail@web21204.mail.yahoo.com> References: <20040128230154.75035.qmail@web21204.mail.yahoo.com> Message-ID: <200401291053.16935.giannozz@nest.sns.it> On Thursday 29 January 2004 00:01, Konstantin Kudin wrote: > It looks like the amount of memory for "diag:" got > wrapped around the 32-bit limit and became negative. that's strange: the amount of memory used is stored in real numbers, to avoid this kind of problem. Maybe your version was still using integer numbers. > Is there a way to reduce the memory required for a > given PWSCF job? from the manual: ----------------------------------------------------------- \item increase the amount of memory you are authorized to use, if possible (ask your system guru) \item reduce {\tt nbnd} to the strict minimum \item use conjugate-gradient or DIIS diagonalization ({\tt diagonalization='cg'} or {\tt 'diis'}): slower but requires less memory. \item in parallel execution, use more processors, or use the same number of processors with less pools. Remember that parallelization with respect to k-points (pools) does not distribute memory: parallelization with respect to {\bf R}-- and {\bf G}--space does. \item IBM only: if you need more than 256 Mb you must specify it at link time (option {\tt -bmaxdata}). ----------------------------------------------------------- The second and third items are relevant to your case > Or should I just move to a 64-bit machine with enough physical RAM > such as an SGI? or to a parallel machine 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 breezejd at lsbu.ac.uk Thu Jan 29 13:31:45 2004 From: breezejd at lsbu.ac.uk (Jonathan Breeze) Date: Thu, 29 Jan 2004 12:31:45 +0000 Subject: [Pw_forum] cpmd2upf conversion References: <4017D62C.6010901@lsbu.ac.uk> <200401291030.14513.giannozz@nest.sns.it> Message-ID: <4018FD31.8080209@lsbu.ac.uk> Thanks for the help Paolo, with regards to the CPMD potential. I'll have a look to see if it is a logarithmic mesh (if possible). On the matter of D3, I will do what you suggested and update soem input data I used with version 1.1.2 and see if they agree. Thanks Jonathan Paolo Giannozzi wrote: >On Wednesday 28 January 2004 16:33, Jonathan Breeze wrote: > > > >>In the upftool 'cpmd2upf', after reading the &POTENTIAL tag, the program >>executes >> >> read (iunps,*) mesh_, amesh >> >>Unfortunately, the CPMD pseudopotential file only has a single entry >>after &POTENTIAL (that is, no amesh value). >> >> > >there are several different formats of CPMD pseudopotentials, and no >documentation. The converter works for one specific case, i.e., the only >one I know. "amesh" is a parameter of the logarithmic grid and can be >inferred from it: r(i) = r_0*exp(i*amesh) (grid not starting from 0) or >r(i) = r_0*(exp(i*amesh) -1) (grid starting from 0). Maybe your CPMD >potential does not use a logarithmic grid. > >About your second question: I have been told that somebody is working >on D3 right now. If you have successfully used a previous version, you >can easily verify if the new version is working: the input data of D3.x and >of the phonon code is little changed from previous versions. > >Paolo > > > -- Jonathan Breeze Research Fellow Centre for Physical Electronics and Materials London South Bank University 103 Borough Road London SE1 0AA Tel: +44(0)20 7815 7582 Fax: +44(0)20 7815 7599 From breezejd at lsbu.ac.uk Thu Jan 29 13:45:04 2004 From: breezejd at lsbu.ac.uk (Jonathan Breeze) Date: Thu, 29 Jan 2004 12:45:04 +0000 Subject: [Pw_forum] cpmd2upf conversion References: <4017D62C.6010901@lsbu.ac.uk> <200401291030.14513.giannozz@nest.sns.it> Message-ID: <40190050.2030704@lsbu.ac.uk> Dear Paolo, I have just compiled and run D3 for the CVS version of PWscf and am pleased to say that it works. I got number that agreed fairly well with each other, considering that I used different pseudopotentials. I am very pleased now :) Kind regards, Jonathan Breeze Paolo Giannozzi wrote: >About your second question: I have been told that somebody is working >on D3 right now. If you have successfully used a previous version, you >can easily verify if the new version is working: the input data of D3.x and >of the phonon code is little changed from previous versions. > >Paolo > > > -- Jonathan Breeze Research Fellow Centre for Physical Electronics and Materials London South Bank University 103 Borough Road London SE1 0AA Tel: +44(0)20 7815 7582 Fax: +44(0)20 7815 7599 From mtoso at ts.infn.it Thu Jan 29 15:44:53 2004 From: mtoso at ts.infn.it (Michele Tosolini) Date: Thu, 29 Jan 2004 15:44:53 +0100 (MET) Subject: [Pw_forum] relax Message-ID: hello, i'm making simple tests with the new pw 1.3.0 version of the code. I use i.f.c-8.0 with mkl-6.1 on a linux pc. I have this stop problem, trying to relax with damped dynamics. forrtl: severe (59): list-directed I/O syntax error, unit 4, file /tmp//silicon.md I notice that some silicon coordinates are set to 'infinity' after few dynamical steps ?! I attach the input, output and silicon.md files . thanks. I -------------- next part -------------- 3.328225239784213E-005 -9.984675719352636E-005 3.328225239784213E-005 -0.240033282252398 0.720099846757194 -0.240033282252398 Infinity -Infinity Infinity 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 1.238657086937464E-007 -3.715971260812391E-007 1.238657086937464E-007 -1.238657086937464E-007 3.715971260812391E-007 -1.238657086937464E-007 1.238657086937464E-007 -3.715971260812391E-007 1.238657086937464E-007 -1.238657086937464E-007 3.715971260812391E-007 -1.238657086937464E-007 -3.328225239784213E-005 -3.328225239784212E-005 -3.328225239784212E-005 0.240033282252398 0.240033282252398 0.240033282252398 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.240000000000000 0.240000000000000 0.240000000000000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000 -5.10000000000000 0.000000000000000E+000 5.10000000000000 0.000000000000000E+000 5.10000000000000 5.10000000000000 -5.10000000000000 5.10000000000000 0.000000000000000E+000 -26.0100000000000 -26.0100000000000 26.0100000000000 26.0100000000000 26.0100000000000 26.0100000000000 -26.0100000000000 26.0100000000000 -26.0100000000000 265.302000000000 -15.8397787582009 -15.8398446760938 -6.591789294496664E-005 6.725708120410806E-005 -4.596742974034973E-005 -1.219525104497426E-002 -6.591789294496664E-005 6.725708120410806E-005 -4.596742974034973E-005 -1.219525104497426E-002 -26.0100000000000 -26.0100000000000 26.0100000000000 26.0100000000000 26.0100000000000 26.0100000000000 -26.0100000000000 26.0100000000000 -26.0100000000000 2 1 0 -------------- next part -------------- Program PWSCF v.1.3.0 starts ... Today is 29Jan2004 at 15:33: 5 Ultrasoft (Vanderbilt) Pseudopotentials Current dimensions of program pwscf are: ntypx =10 npk =40000 lmax = 3 nchix = 6 ndim = 2000 nbrx = 8 nqfm = 8 warning: symmetry operation # 6 not allowed. fractional translation: 0.2400000 0.2800000 0.2400000 in crystal coordinates warning: symmetry operation # 10 not allowed. fractional translation: 0.2400000 0.2800000 0.2400000 in crystal coordinates warning: symmetry operation # 14 not allowed. fractional translation: 0.2400000 0.2800000 0.2400000 in crystal coordinates warning: symmetry operation # 25 not allowed. fractional translation: 0.2400000 0.2800000 0.2400000 in crystal coordinates warning: symmetry operation # 41 not allowed. fractional translation: 0.2400000 0.2800000 0.2400000 in crystal coordinates warning: symmetry operation # 45 not allowed. fractional translation: 0.2400000 0.2800000 0.2400000 in crystal coordinates bravais-lattice index = 2 lattice parameter (a_0) = 10.2000 a.u. unit-cell volume = 265.3020 (a.u.)^3 number of atoms/cell = 2 number of atomic types = 1 kinetic-energy cutoff = 18.0000 Ry charge density cutoff = 72.0000 Ry convergence threshold = 1.0E-08 beta = 0.7000 number of iterations used = 8 plain mixing Exchange-correlation = SLA PZ NOGX NOGC (1100) iswitch = 3 nstep = 50 celldm(1)= 10.20000 celldm(2)= 0.00000 celldm(3)= 0.00000 celldm(4)= 0.00000 celldm(5)= 0.00000 celldm(6)= 0.00000 crystal axes: (cart. coord. in units of a_0) a(1) = ( -0.5000 0.0000 0.5000 ) a(2) = ( 0.0000 0.5000 0.5000 ) a(3) = ( -0.5000 0.5000 0.0000 ) reciprocal axes: (cart. coord. in units 2 pi/a_0) b(1) = ( -1.0000 -1.0000 1.0000 ) b(2) = ( 1.0000 1.0000 1.0000 ) b(3) = ( -1.0000 1.0000 -1.0000 ) PSEUDO 1 is Si zval = 4.0 lmax= 1 lloc= 0 (in numerical form: 431 grid points, xmin = 0.00, dx = 0.0000) atomic species valence mass pseudopotential Si 4.00 28.00000 Si( 1.00) 6 Sym.Ops. (no inversion) Cartesian axes site n. atom positions (a_0 units) 1 Si tau( 1) = ( 0.0000000 0.0000000 0.0000000 ) 2 Si tau( 2) = ( 0.2400000 0.2400000 0.2400000 ) number of k points= 30 cart. coord. in units 2pi/a_0 k( 1) = ( -0.1250000 0.1250000 0.1250000), wk = 0.0468750 k( 2) = ( -0.3750000 0.3750000 -0.1250000), wk = 0.0937500 k( 3) = ( 0.3750000 -0.3750000 0.6250000), wk = 0.0937500 k( 4) = ( 0.1250000 -0.1250000 0.3750000), wk = 0.0937500 k( 5) = ( -0.1250000 0.6250000 0.1250000), wk = 0.0937500 k( 6) = ( 0.6250000 -0.1250000 0.8750000), wk = 0.0937500 k( 7) = ( 0.3750000 0.1250000 0.6250000), wk = 0.0937500 k( 8) = ( -0.1250000 -0.8750000 0.1250000), wk = 0.0937500 k( 9) = ( -0.3750000 0.3750000 0.3750000), wk = 0.0468750 k( 10) = ( 0.3750000 -0.3750000 1.1250000), wk = 0.0937500 k( 11) = ( -0.1250000 -0.1250000 -0.1250000), wk = 0.0156250 k( 12) = ( 0.3750000 0.3750000 0.1250000), wk = 0.0468750 k( 13) = ( -0.3750000 -0.3750000 0.1250000), wk = 0.0468750 k( 14) = ( -0.3750000 -0.3750000 -0.6250000), wk = 0.0468750 k( 15) = ( 0.3750000 0.3750000 -0.6250000), wk = 0.0468750 k( 16) = ( -0.1250000 -0.1250000 -0.3750000), wk = 0.0468750 k( 17) = ( 0.1250000 0.1250000 -0.3750000), wk = 0.0468750 k( 18) = ( 0.1250000 -0.6250000 0.1250000), wk = 0.0468750 k( 19) = ( -0.1250000 -0.6250000 -0.1250000), wk = 0.0468750 k( 20) = ( -0.6250000 0.1250000 0.8750000), wk = 0.0937500 k( 21) = ( -0.6250000 -0.1250000 -0.8750000), wk = 0.0937500 k( 22) = ( 0.6250000 0.1250000 -0.8750000), wk = 0.0937500 k( 23) = ( -0.3750000 -0.1250000 0.6250000), wk = 0.0937500 k( 24) = ( -0.3750000 0.1250000 -0.6250000), wk = 0.0937500 k( 25) = ( 0.3750000 -0.1250000 -0.6250000), wk = 0.0937500 k( 26) = ( 0.1250000 0.8750000 0.1250000), wk = 0.0468750 k( 27) = ( -0.1250000 0.8750000 -0.1250000), wk = 0.0468750 k( 28) = ( -0.3750000 -0.3750000 -0.3750000), wk = 0.0156250 k( 29) = ( -0.3750000 -0.3750000 -1.1250000), wk = 0.0468750 k( 30) = ( 0.3750000 0.3750000 -1.1250000), wk = 0.0468750 G cutoff = 189.7462 ( 2733 G-vectors) FFT grid: ( 20, 20, 20) nbndx = 8 nbnd = 4 natomwfc = 8 npwx = 350 nelec = 8.00 nkb = 8 ngl = 65 Initial potential from superposition of free atoms starting charge = 7.99901 Starting wfc are atomic total cpu time spent up to now is 0.70 secs iteration # 1 ecut= 18.00 ryd beta=0.70 Conjugate-gradient style diagonalization ethr = 1.00E-02, avg # of iterations = 3.0 total energy = -15.83287841 ryd estimated scf accuracy < 0.06251677 ryd total cpu time spent up to now is 1.29 secs iteration # 2 ecut= 18.00 ryd beta=0.70 Conjugate-gradient style diagonalization ethr = 7.81E-04, avg # of iterations = 3.1 total energy = -15.83949108 ryd estimated scf accuracy < 0.00197738 ryd total cpu time spent up to now is 1.90 secs iteration # 3 ecut= 18.00 ryd beta=0.70 Conjugate-gradient style diagonalization ethr = 2.47E-05, avg # of iterations = 3.4 total energy = -15.83976509 ryd estimated scf accuracy < 0.00004128 ryd total cpu time spent up to now is 2.56 secs iteration # 4 ecut= 18.00 ryd beta=0.70 Conjugate-gradient style diagonalization ethr = 5.16E-07, avg # of iterations = 4.0 total energy = -15.83977856 ryd estimated scf accuracy < 0.00000038 ryd total cpu time spent up to now is 3.33 secs iteration # 5 ecut= 18.00 ryd beta=0.70 Conjugate-gradient style diagonalization ethr = 4.78E-09, avg # of iterations = 4.2 total energy = -15.83977875 ryd estimated scf accuracy < 0.00000001 ryd total cpu time spent up to now is 4.11 secs iteration # 6 ecut= 18.00 ryd beta=0.70 Conjugate-gradient style diagonalization ethr = 1.66E-10, avg # of iterations = 3.7 ! total energy = -15.83977876 ryd estimated scf accuracy < 0.00000000 ryd convergence has been achieved Forces acting on atoms (Ry/au): atom 1 type 1 force = -0.03248595 -0.03248595 -0.03248595 atom 2 type 1 force = 0.03248595 0.03248595 0.03248595 Total force = 0.194916 Total SCF correction = 0.000015 entering subroutine stress ... total stress (a.u.) (kbar) P= -6.73 -0.00004578 0.00016359 0.00016359 -6.73 24.06 24.06 0.00016359 -0.00004578 0.00016359 24.06 -6.73 24.06 0.00016359 0.00016359 -0.00004578 24.06 24.06 -6.73 Damped Dynamics Minimization convergence thresholds: EPSE = 0.10E-03 EPSF = 0.10E-02 Entering Dynamics; it = 1 time = 0.00000 pico-seconds WARNING: e file was present; old file deleted WARNING: eal file was present; old file deleted WARNING: ave file was present; old file deleted WARNING: p file was present; old file deleted WARNING: avec file was present; old file deleted WARNING: tv file was present; old file deleted new positions in cryst coord Si 0.000033282 -0.000099847 0.000033282 Si -0.240033282 0.720099847 -0.240033282 new positions in cart coord (alat unit) Si -0.000033282 -0.000033282 -0.000033282 Si 0.240033282 0.240033282 0.240033282 Ekin = 0.00000000 Ryd T = 0.0 K Etot = -15.83977876 NEW-OLD atomic charge density approx. for the potential total cpu time spent up to now is 6.35 secs iteration # 1 ecut= 18.00 ryd beta=0.70 Conjugate-gradient style diagonalization ethr = 1.66E-10, avg # of iterations = 6.0 total energy = -15.83984467 ryd estimated scf accuracy < 0.00000002 ryd total cpu time spent up to now is 7.44 secs iteration # 2 ecut= 18.00 ryd beta=0.70 Conjugate-gradient style diagonalization ethr = 2.03E-10, avg # of iterations = 3.4 ! total energy = -15.83984468 ryd estimated scf accuracy < 0.00000000 ryd convergence has been achieved Forces acting on atoms (Ry/au): atom 1 type 1 force = -0.03224057 -0.03224057 -0.03224057 atom 2 type 1 force = 0.03224057 0.03224057 0.03224057 Total force = 0.193443 Total SCF correction = 0.000017 entering subroutine stress ... total stress (a.u.) (kbar) P= -6.79 -0.00004614 0.00016232 0.00016232 -6.79 23.88 23.88 0.00016232 -0.00004614 0.00016232 23.88 -6.79 23.88 0.00016232 0.00016232 -0.00004614 23.88 23.88 -6.79 Entering Dynamics; it = 2 time = 0.00097 pico-seconds new positions in cryst coord Si Infinity -Infinity Infinity Si -0.240057993 0.720173978 -0.240057993 new positions in cart coord (alat unit) Si NaN NaN NaN Si 0.240057993 0.240057993 0.240057993 Ekin = 0.00006726 Ryd T = 7.1 K Etot = -15.83977742 NEW-OLD atomic charge density approx. for the potential Warning: negative or imaginary starting charge NaN NaN 1 total cpu time spent up to now is 10.20 secs iteration # 1 ecut= 18.00 ryd beta=0.70 Conjugate-gradient style diagonalization ethr = 2.03E-10, avg # of iterations = 3.0 ! total energy = NaN ryd estimated scf accuracy < NaN ryd convergence has been achieved Forces acting on atoms (Ry/au): atom 1 type 1 force = NaN NaN NaN atom 2 type 1 force = NaN NaN NaN Total force = NaN Total SCF correction = NaN entering subroutine stress ... total stress (a.u.) (kbar) P= NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN -------------- next part -------------- &control calculation = 'relax' restart_mode='from_scratch', prefix='silicon', tstress = .true. tprnfor = .true. pseudo_dir = '/home/mtoso/pseudo//', outdir='/tmp//' dt=20, / &system ibrav= 2, celldm(1) =10.20, nat= 2, ntyp= 1, ecutwfc =18.0, / &electrons diagonalization='cg' mixing_mode = 'plain' mixing_beta = 0.7 conv_thr = 1.0d-8 / &ions ion_dynamics='damp', / ATOMIC_SPECIES Si 28 Si.pz-vbc.UPF ATOMIC_POSITIONS Si 0.00 0.00 0.00 Si 0.24 0.24 0.24 K_POINTS {automatic} 4 4 4 1 1 1 From giannozz at nest.sns.it Thu Jan 29 16:18:48 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 29 Jan 2004 16:18:48 +0100 Subject: [Pw_forum] relax In-Reply-To: References: Message-ID: <200401291618.48501.giannozz@nest.sns.it> On Thursday 29 January 2004 15:44, Michele Tosolini wrote: > I use i.f.c-8.0 with mkl-6.1 on a linux pc. I have this stop problem [...] please download the latest CVS version and verify if the problem is still there. Please also try to verify if the problem is present with other compilers. The most recent versions of the intel compiler are, well, a little bit bizarre, to say the least. 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 breezejd at lsbu.ac.uk Thu Jan 29 17:13:10 2004 From: breezejd at lsbu.ac.uk (Jonathan Breeze) Date: Thu, 29 Jan 2004 16:13:10 +0000 Subject: [Pw_forum] AMD64 and IFC Message-ID: <40193116.7040006@lsbu.ac.uk> Dear PWSCF'ers, I am soon to be the lucky recipient of an AMD64 computer. I haven't been able to follow the previous postings. So ... I intend to install either Mandrake or Suse 64-bit onto it. When I come to compiling PWSCF, I'll need to know : 1) Can one compile 64-bit code for AMD using the Intel Fortran Compiler ? If not, is there a compiler that can ? 2) How to get the best performance, i.e. not having to compile 32-bit libraries etc. 3) Any other things I should know :) I would be interested to hear from people 's experiences on this. Many thanks. -- Jonathan Breeze Research Fellow Centre for Physical Electronics and Materials London South Bank University 103 Borough Road London SE1 0AA Tel: +44(0)20 7815 7582 Fax: +44(0)20 7815 7599 From proffess at yandex.ru Fri Jan 30 08:11:58 2004 From: proffess at yandex.ru (Sergei Lisenkov) Date: Fri, 30 Jan 2004 10:11:58 +0300 (MSK) Subject: [Pw_forum] Error in "from c_bands :" In-Reply-To: References: Message-ID: <401A03BE.000003.10163@soapbox.yandex.ru> Dear PWscf authors, After a few succesfull iterations I got the next error: .... Ekin = 0.00004025 Ryd T = 0.0 K Etot = -870.64988066 NEW-OLD atomic charge density approx. for the potential total cpu time spent up to now is 96835.10 secs iteration # 1 ecut= 30.00 ryd beta=0.10 Conjugate-gradient style diagonalization warning : 63 eigenvectors not converged after 1 attemps %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from c_bands : error # 1 too many bands are not converged %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... I am using a CVS version. How to solve this problem? Thanks, Sergey From giannozz at nest.sns.it Fri Jan 30 09:53:37 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 30 Jan 2004 09:53:37 +0100 Subject: [Pw_forum] Error in "from c_bands :" In-Reply-To: <401A03BE.000003.10163@soapbox.yandex.ru> References: <401A03BE.000003.10163@soapbox.yandex.ru> Message-ID: <200401300953.37732.giannozz@nest.sns.it> On Friday 30 January 2004 08:11, Sergei Lisenkov wrote: > After a few succesfull iterations I got the next error [...] > > from c_bands : error # 1 > too many bands are not converged > > [...] I am using a CVS version. How to solve this problem? could you please post the complete output (compressed if large)? 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 Fri Jan 30 10:22:22 2004 From: proffess at yandex.ru (Sergei Lisenkov) Date: Fri, 30 Jan 2004 12:22:22 +0300 (MSK) Subject: [Pw_forum] Error in "from c_bands :" In-Reply-To: <200401300953.37732.giannozz@nest.sns.it> References: <401A03BE.000003.10163@soapbox.yandex.ru> <200401300953.37732.giannozz@nest.sns.it> Message-ID: <401A224E.000008.04341@pantene.yandex.ru> Dear Paolo, I send you two output files that contains this error. Sergey -------------- next part -------------- A non-text attachment was scrubbed... Name: ful90.out Type: application/octet-stream Size: 56508 bytes Desc: not available Url : /pipermail/attachments/20040130/65767ada/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: output.tar.gz Type: application/octet-stream Size: 51200 bytes Desc: not available Url : /pipermail/attachments/20040130/65767ada/attachment-0001.obj From giannozz at nest.sns.it Fri Jan 30 19:17:00 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 30 Jan 2004 19:17:00 +0100 Subject: [Pw_forum] AMD64 and IFC In-Reply-To: <40193116.7040006@lsbu.ac.uk> References: <40193116.7040006@lsbu.ac.uk> Message-ID: <200401301917.00051.giannozz@nest.sns.it> On Thursday 29 January 2004 17:13, Jonathan Breeze wrote: > I am soon to be the lucky recipient of an AMD64 computer [....] > When I come to compiling PWSCF, I'll need to know : > 1) Can one compile 64-bit code for AMD using the Intel Fortran > Compiler? If not, is there a compiler that can ? I have heard that you can compile 32-bit executables with Intel compilers, but it is not very fast, and that the only compiler that compiles 64-bit code on AMD is PGI. The CVS version has been reported to work (a few days ago) with PGI and 64-bit executables: you need to define -D__LINUX64 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 breezejd at lsbu.ac.uk Fri Jan 30 19:22:05 2004 From: breezejd at lsbu.ac.uk (Jonathan Breeze) Date: Fri, 30 Jan 2004 18:22:05 +0000 Subject: [Pw_forum] AMD64 and IFC References: <40193116.7040006@lsbu.ac.uk> <200401301917.00051.giannozz@nest.sns.it> Message-ID: <401AA0CD.3090806@lsbu.ac.uk> Dear Paolo, You are right. PGI is the only 64-bit compiler for AMD. I had better get my order in quick !!! Paolo Giannozzi wrote: >On Thursday 29 January 2004 17:13, Jonathan Breeze wrote: > > > >>I am soon to be the lucky recipient of an AMD64 computer [....] >>When I come to compiling PWSCF, I'll need to know : >>1) Can one compile 64-bit code for AMD using the Intel Fortran >> Compiler? If not, is there a compiler that can ? >> >> > >I have heard that you can compile 32-bit executables with Intel >compilers, but it is not very fast, and that the only compiler that >compiles 64-bit code on AMD is PGI. The CVS version has been >reported to work (a few days ago) with PGI and 64-bit executables: >you need to define -D__LINUX64 > >Paolo > > > -- Jonathan Breeze Research Fellow Centre for Physical Electronics and Materials London South Bank University 103 Borough Road London SE1 0AA Tel: +44(0)20 7815 7582 Fax: +44(0)20 7815 7599 From sbraccia at sissa.it Fri Jan 30 22:29:41 2004 From: sbraccia at sissa.it (Carlo Sbraccia) Date: Fri, 30 Jan 2004 22:29:41 +0100 (CET) Subject: [Pw_forum] Error in "from c_bands :" In-Reply-To: <401A03BE.000003.10163@soapbox.yandex.ru> Message-ID: Dear Sergei, this error is produced by an experimental check performed on the iterative diagonalization at the first scf iteration: it seems not to be yet well tuned! I hope the code attached to this mail could solve the problem (copy this file in the PW directory). carlo sbraccia -------------- next part -------------- ! ! Copyright (C) 2001-2004 PWSCF group ! This file is distributed under the terms of the ! GNU General Public License. See the file `License' ! in the root directory of the present distribution, ! or http://www.gnu.org/copyleft/gpl.txt . ! #include "machine.h" ! !---------------------------------------------------------------------------- SUBROUTINE c_bands( iter, ik_, dr2 ) !---------------------------------------------------------------------------- ! ! ... this is a wrapper to specific calls ! USE kinds, ONLY : DP USE io_global, ONLY : stdout USE wvfct, ONLY : gamma_only USE io_files, ONLY : iunigk, nwordatwfc, iunat, iunwfc, nwordwfc USE brilz, ONLY : tpiba2 USE klist, ONLY : nkstot, nks, xk USE us, ONLY : okvan, vkb, nkb USE gvect, ONLY : g, gstart, ecfixed, qcutz, q2sigma, nrxx, & nr1, nr2, nr3 USE wvfct, ONLY : g2kin, wg, nbndx, et, nbnd, npwx, igk, & npw USE control_flags, ONLY : diis_ndim, istep, ethr, lscf, max_cg_iter, & diis_ethr_cg, isolve, reduce_io USE ldaU, ONLY : lda_plus_u, swfcatom USE scf, ONLY : vltot USE lsda_mod, ONLY : current_spin, lsda, isk USE wavefunctions_module, ONLY : evc USE g_psi_mod ! IMPLICIT NONE ! ! ... First the I/O variables ! INTEGER :: ik_, iter ! k-point already done ! current iterations REAL(KIND=DP) :: dr2 ! current accuracy of self-consistency ! ! CALL start_clock( 'c_bands' ) ! IF ( gamma_only ) THEN ! CALL c_bands_gamma() ! ELSE ! CALL c_bands_k() ! END IF ! CALL stop_clock( 'c_bands' ) ! RETURN ! CONTAINS ! !----------------------------------------------------------------------- SUBROUTINE c_bands_gamma() !----------------------------------------------------------------------- ! ! ... This routine is a driver for the diagonalization routines of the ! ... total Hamiltonian at Gammma point only ! ... It reads the Hamiltonian and an initial guess of the wavefunctions ! ... from a file and computes initialization quantities for Davidson ! ... iterative diagonalization. ! USE rbecmod, ONLY: becp, becp_ ! IMPLICIT NONE ! ! ... here the local variables ! REAL(KIND=DP) :: avg_iter, v_of_0, DSUM, ERF ! average number of iterations ! the average of the potential ! summation function ! error function INTEGER :: ik, ig, ibnd, ntrt, ntry, notconv ! counter on k points ! counter on G vectors ! counter on bands ! number of iterations in Davidson ! number of repeated call to REGTERG ! number of notconverged elements LOGICAL :: ltest ! .TRUE. if there are too many not converged bands ! ! IF ( ik_ == nks ) THEN ! ik_ = 0 ! RETURN ! END IF ! ! ... allocate arrays ! ALLOCATE( h_diag( npwx ) ) ALLOCATE( s_diag( npwx ) ) ! ! ... becp, becp_ contain - used in h_psi and s_psi ! ... they are allocate once here in order to reduce overhead ! ALLOCATE( becp( nkb, nbnd ), becp_( nkb, nbnd ) ) ! IF ( isolve == 0 ) THEN WRITE( stdout, '(" Davidson diagonalization with overlap")' ) ELSE CALL errore( 'c_bands', & & 'CG and DIIS diagonalization not implemented', 1 ) END IF ! avg_iter = 0.D0 ! ! ... v_of_0 is (Vloc)(G=0) ! v_of_0 = DSUM( nrxx, vltot, 1 ) / REAL( nr1 * nr2 * nr3 ) ! #if defined (__PARA) CALL reduce( 1, v_of_0 ) #endif ! IF ( nks > 1 ) REWIND( iunigk ) ! ! ... For each k point diagonalizes the hamiltonian ! k_loop: DO ik = 1, nks ! IF ( lsda ) current_spin = isk(ik) ! ! ... Reads the Hamiltonian and the list k+G <-> G of this k point ! IF ( nks > 1 ) READ( iunigk ) npw, igk ! ! ... do not recalculate k-points if restored from a previous run ! IF ( ik <= ik_ ) THEN ! CALL save_in_cbands( iter, ik, dr2 ) ! CYCLE k_loop ! END IF ! ! ... various initializations ! IF ( nkb > 0 ) & CALL init_us_2( npw, igk, xk(1,ik), vkb ) ! ! ... read in wavefunctions from the previous iteration ! IF ( nks > 1 .OR. .NOT. reduce_io ) & call davcio( evc, nwordwfc, iunwfc, ik, -1 ) ! ! ... Needed for LDA+U ! IF ( lda_plus_u ) CALL davcio( swfcatom, nwordatwfc, iunat, ik, -1 ) ! ! ... sets the kinetic energy ! g2kin(1:npw) = ( ( xk(1,ik) + g(1,igk(1:npw)) )**2 + & ( xk(2,ik) + g(2,igk(1:npw)) )**2 + & ( xk(3,ik) + g(3,igk(1:npw)) )**2 ) * tpiba2 ! IF ( qcutz > 0.D0 ) THEN ! DO ig = 1, npw g2kin(ig) = g2kin(ig) + qcutz * & ( 1.D0 + ERF( (g2kin(ig) - ecfixed ) / q2sigma ) ) END DO ! END IF ! ! ... h_diag are the diagonal matrix elements of the ! ... hamiltonian used in g_psi to evaluate the correction ! ... to the trial eigenvectors ! h_diag(1:npw) = g2kin(1:npw) + v_of_0 ! CALL usnldiag( h_diag, s_diag ) ! ntry = 0 ! david_loop: DO ! CALL regterg( npw, npwx, nbnd, nbndx, evc, ethr, okvan, gstart, & et(1,ik), notconv, ntrt ) ! avg_iter = avg_iter + ntrt ! ! ... save wave-functions to be used as input for the ! ... iterative diagonalization of the next scf iteration ! ... and for rho calculation ! IF ( nks > 1 .OR. .NOT. reduce_io ) & CALL davcio( evc, nwordwfc, iunwfc, ik, 1 ) ! ntry = ntry + 1 ! ! ! ... exit condition ! ltest = .NOT. ( ( ntry <= 5 ) .AND. & ( ( .NOT. lscf .AND. ( notconv > 0 ) ) .OR. & ( lscf .AND. ( notconv > 5 ) ) ) ) ! IF ( ltest ) EXIT david_loop ! END DO david_loop ! IF ( notconv /= 0 ) & WRITE( stdout, '(" warning : ",I3," eigenvectors not",& &" converged after ",I3," attemps")') notconv, ntry ! IF ( notconv > MAX( 5, nbnd / 4 ) ) THEN ! CALL errore( 'c_bands', & & 'too many bands are not converged', 1 ) ! END IF ! ! ... save restart information ! CALL save_in_cbands( iter, ik, dr2 ) ! END DO k_loop ! ik_ = 0 ! #if defined (__PARA) CALL poolreduce( 1, avg_iter ) #endif ! avg_iter = avg_iter / nkstot ! WRITE( stdout, & '( 5X,"ethr = ",1PE9.2,", avg # of iterations =",0PF5.1 )' ) & ethr, avg_iter ! ! ... deallocate work space ! DEALLOCATE( becp, becp_ ) DEALLOCATE( s_diag ) DEALLOCATE( h_diag ) ! RETURN ! END SUBROUTINE c_bands_gamma ! ! !----------------------------------------------------------------------- SUBROUTINE c_bands_k() !----------------------------------------------------------------------- ! ! ... This routine is a driver for the diagonalization routines of the ! ... total Hamiltonian at each k-point. ! ... It reads the Hamiltonian and an initial guess of the wavefunctions ! ... from a file and computes initialization quantities for the ! ... diagonalization routines. ! ... There are three types of iterative diagonalization: ! ... a) Davidson algorithm (all-band) ! ... b) Conjugate Gradient (band-by-band) ! ... c) DIIS algorithm ! IMPLICIT NONE ! ! ... here the local variables ! REAL(KIND=DP) :: avg_iter, cg_iter, diis_iter, v_of_0, DSUM, ERF ! average number of iterations ! number of iteration in CG ! number of iteration in DIIS ! the average of the potential ! summation function ! error function INTEGER :: ik, ig, ibnd, dav_iter, ntry, notconv ! counter on k points ! counter on G vectors ! counter on bands ! number of iterations in Davidson ! number or repeated call to diagonalization in case of non convergence ! number of notconverged elements INTEGER, ALLOCATABLE :: btype(:) ! type of band: conduction (1) or valence (0) LOGICAL :: ltest ! .TRUE. if there are too many not converged bands ! ! IF ( ik_ == nks ) THEN ! ik_ = 0 ! RETURN ! END IF ! ! ... allocate arrays ! ALLOCATE( btype( nbnd ) ) ALLOCATE( h_diag( npwx ) ) ALLOCATE( s_diag( npwx ) ) ! IF ( isolve == 0 ) THEN ! WRITE( stdout, '(" Davidson diagonalization (with overlap)")') ! ELSE IF ( isolve == 1 ) THEN ! WRITE( stdout, '(" Conjugate-gradient style diagonalization")') ! ELSE IF ( isolve == 2 ) THEN ! WRITE( stdout, '(" DIIS style diagonalization")') IF ( ethr > diis_ethr_cg ) & WRITE( stdout, '(6X,"use conjugate-gradient method ", & & "until ethr <",1PE9.2)' ) diis_ethr_cg ELSE ! CALL errore( 'c_bands', 'isolve not implemented', 1 ) ! END IF ! avg_iter = 0.D0 ! ! ... v_of_0 is (Vloc)(G=0) ! v_of_0 = DSUM( nrxx, vltot, 1 ) / REAL( nr1 * nr2 * nr3 ) ! #if defined (__PARA) CALL reduce( 1, v_of_0 ) #endif ! if ( nks > 1 ) REWIND( iunigk ) ! ! ... For each k point diagonalizes the hamiltonian ! k_loop: DO ik = 1, nks ! IF ( lsda ) current_spin = isk(ik) ! ! ... Reads the Hamiltonian and the list k+G <-> G of this k point ! IF ( nks > 1 ) READ( iunigk ) npw, igk ! ! ... do not recalculate k-points if restored from a previous run ! IF ( ik <= ik_ ) THEN ! CALL save_in_cbands( iter, ik, dr2 ) ! CYCLE k_loop ! END IF ! ! ... various initializations ! IF ( nkb > 0 ) & CALL init_us_2( npw, igk, xk(1,ik), vkb ) ! ! ... read in wavefunctions from the previous iteration ! IF ( nks > 1 .OR. .NOT. reduce_io ) & CALL davcio( evc, nwordwfc, iunwfc, ik, -1 ) ! ! ... Needed for LDA+U ! IF ( lda_plus_u ) CALL davcio( swfcatom, nwordatwfc, iunat, ik, -1 ) ! ! ... sets the kinetic energy ! g2kin(1:npw) = ( ( xk(1,ik) + g(1,igk(1:npw)) )**2 + & ( xk(2,ik) + g(2,igk(1:npw)) )**2 + & ( xk(3,ik) + g(3,igk(1:npw)) )**2 ) * tpiba2 ! ! IF ( qcutz > 0.D0 ) THEN DO ig = 1, npw g2kin (ig) = g2kin(ig) + qcutz * & ( 1.D0 + ERF( ( g2kin(ig) - ecfixed ) / q2sigma ) ) END DO END IF ! IF ( ( isolve == 1 ) .OR. & ( isolve == 2 .AND. ethr > diis_ethr_cg ) ) THEN ! ! ... Conjugate-Gradient diagonalization ! ... and first steps of RMM-DIIS diagonalization ! ! ... h_diag is the precondition matrix ! h_diag(1:npw) = MAX( 1.D0, g2kin(1:npw) ) ! ntry = 0 ! CG_loop : DO ! IF ( iter /= 1 .OR. istep /= 1 .OR. ntry > 0 ) THEN ! CALL cinitcgg( npwx, npw, nbnd, nbnd, evc, evc, et(1,ik) ) ! avg_iter = avg_iter + 1.D0 ! END IF ! CALL ccgdiagg( npwx, npw, nbnd, evc, et(1,ik), h_diag, ethr, & max_cg_iter, .not.lscf, notconv, cg_iter ) ! avg_iter = avg_iter + cg_iter ! ! ... save wave-functions to be used as input for the ! ... iterative diagonalization of the next scf iteration ! ... and for rho calculation ! IF ( nks > 1 .OR. .NOT. reduce_io ) & CALL davcio( evc, nwordwfc, iunwfc, ik, 1 ) ! ntry = ntry + 1 ! ! ... exit condition ! ltest = .NOT. ( ( ntry <= 5 ) .AND. & ( ( .NOT. lscf .AND. ( notconv > 0 ) ) .OR. & ( lscf .AND. ( notconv > 5 ) ) ) ) ! IF ( ltest ) EXIT CG_loop ! END DO CG_loop ! ELSE IF ( isolve == 2 ) THEN ! ! ... when ethr <= diis_ethr_cg start the RMM-DIIS method ! h_diag(1:npw) = g2kin(1:npw) + v_of_0 ! CALL usnldiag( h_diag, s_diag ) ! ntry = 0 diis_iter = 0.D0 ! btype(:) = 0 ! IF ( iter > 1 ) & WHERE( wg(:,ik) < 1.0D-4 ) btype(:) = 1 ! RMMDIIS_loop: DO ! CALL cdiisg( npw, npwx, nbnd, diis_ndim, evc, et(1,ik), ethr, & btype, notconv, diis_iter, iter ) ! avg_iter = avg_iter + diis_iter ! ! ... save wave-functions to be used as input for the ! ... iterative diagonalization of the next scf iteration ! ... and for rho calculation ! IF ( nks > 1 .OR. .NOT. reduce_io ) & CALL davcio( evc, nwordwfc, iunwfc, ik, 1 ) ! ntry = ntry + 1 ! ! ... exit condition ! ltest = .NOT. ( ( ntry <= 5 ) .AND. & ( ( .NOT. lscf .AND. ( notconv > 0 ) ) .OR. & ( lscf .AND. ( notconv > 5 ) ) ) ) ! IF ( ltest ) EXIT RMMDIIS_loop ! END DO RMMDIIS_loop ! ELSE ! ! ... Davidson diagonalization ! ! ... h_diag are the diagonal matrix elements of the ! ... hamiltonian used in g_psi to evaluate the correction ! ... to the trial eigenvectors ! h_diag(1:npw) = g2kin(1:npw) + v_of_0 ! CALL usnldiag( h_diag, s_diag ) ! ntry = 0 ! david_loop: DO ! CALL cegterg( npw, npwx, nbnd, nbndx, evc, ethr, okvan, & et(1,ik), notconv, dav_iter ) ! avg_iter = avg_iter + dav_iter ! ! ... save wave-functions to be used as input for the ! ... iterative diagonalization of the next scf iteration ! ... and for rho calculation ! IF ( nks > 1 .OR. .NOT. reduce_io ) & CALL davcio( evc, nwordwfc, iunwfc, ik, 1 ) ! ntry = ntry + 1 ! ! ... exit condition ! ltest = .NOT. ( ( ntry <= 5 ) .AND. & ( ( .NOT. lscf .AND. ( notconv > 0 ) ) .OR. & ( lscf .AND. ( notconv > 5 ) ) ) ) ! IF ( ltest ) EXIT david_loop ! END DO david_loop ! END IF ! IF ( notconv /= 0 ) & WRITE( stdout, '(" warning : ",i3," eigenvectors not",& &" converged after ",i3," attemps")') notconv, ntry ! IF ( notconv > MAX( 5, nbnd / 4 ) ) THEN ! CALL errore( 'c_bands', & & 'too many bands are not converged', 1 ) ! END IF ! ! ... save restart information ! CALL save_in_cbands( iter, ik, dr2 ) ! END DO k_loop ! ik_ = 0 ! #if defined (__PARA) CALL poolreduce( 1, avg_iter ) #endif ! avg_iter = avg_iter / nkstot ! WRITE( stdout, & '( 5X,"ethr = ",1PE9.2,", avg # of iterations =",0PF5.1 )' ) & ethr, avg_iter ! ! ... deallocate work space ! DEALLOCATE( s_diag ) DEALLOCATE( h_diag ) DEALLOCATE( btype ) ! RETURN ! END SUBROUTINE c_bands_k ! END SUBROUTINE c_bands From ps at ned.sims.nrc.ca Fri Jan 30 20:08:13 2004 From: ps at ned.sims.nrc.ca (Serguei Patchkovskii) Date: Fri, 30 Jan 2004 14:08:13 -0500 (EST) Subject: [Pw_forum] AMD64 and IFC In-Reply-To: <200401301917.00051.giannozz@nest.sns.it> Message-ID: On Fri, 30 Jan 2004, Paolo Giannozzi wrote: > I have heard that you can compile 32-bit executables with Intel > compilers, but it is not very fast, Take a look at AMD SPECfp2000 submissions for opterons - ifc and pgf submissions for the same system are within a few percent of each other - sometimes ifc wins; sometimes pgf wins. This is despite the fact that ifc does not know about AMD64 as such, and can use only half of the FP registers available to pgf. If you look at the individual tests for Opteron 148, for example, you'll see that ifc generates faster code for 6 of those (swim, art, equake, ammp, lucas, apsi), while pgf is faster for 8 (wupwise, mgrid, applu, mesa, galgel, facerec, fma3d, sixtrack) - but none of the wins are particularly dramatic. This also tallies pretty well with my experience - ifc 7.1 and pgf90 5.0-2 are about neck-to-neck on opterons. > and that the only compiler that compiles 64-bit code on AMD > is PGI. There is also Pathscale (http://www.pathscale.com/) - if you are one of the few lucky people on their beta-testing program. Serguei --- Dr. Serguei Patchkovskii Tel: +1-(613)-990-0945 Fax: +1-(613)-947-2838 E-mail: Serguei.Patchkovskii at nrc.ca Coordinator of Modelling Software Theory and Computation Group Steacie Institute for Molecular Sciences National Research Council Canada Room 2011, 100 Sussex Drive Ottawa, Ontario K1A 0R6 Canada From giannozz at nest.sns.it Sat Jan 31 17:57:13 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Sat, 31 Jan 2004 17:57:13 +0100 Subject: [Pw_forum] Error in "from c_bands :" In-Reply-To: <401A224E.000008.04341@pantene.yandex.ru> References: <200401300953.37732.giannozz@nest.sns.it> <401A224E.000008.04341@pantene.yandex.ru> Message-ID: <200401311757.13057.giannozz@nest.sns.it> On Friday 30 January 2004 10:22, Sergei Lisenkov wrote: > I send you two output files that contains this error. Both calculations have been performed with a convergence threshold that is way too large. The bad convergence of both calculations might be a consequence of the metallic character of the systems. Add a few bands and a broadening. 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 Sat Jan 31 17:57:28 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Sat, 31 Jan 2004 17:57:28 +0100 Subject: [Pw_forum] Error in "from c_bands :" In-Reply-To: References: Message-ID: <200401311757.28892.giannozz@nest.sns.it> On Friday 30 January 2004 22:29, Carlo Sbraccia wrote: > this error is produced by an experimental check performed on the > iterative diagonalization at the first scf iteration: it seems not to be > yet well tuned! I don't think this is the problem: if half or one/third of the eigenvalues are not converged after the first diagonalization, as in those examples, something very wrong is going on and the program should stop. 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 konstantin_kudin at yahoo.com Sat Jan 31 20:28:13 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Sat, 31 Jan 2004 11:28:13 -0800 (PST) Subject: [Pw_forum] Error encountered while attempting to allocate a data object. In-Reply-To: <200401291053.16935.giannozz@nest.sns.it> Message-ID: <20040131192813.40518.qmail@web21204.mail.yahoo.com> --- Paolo Giannozzi wrote: > On Thursday 29 January 2004 00:01, Konstantin Kudin > wrote: > > > It looks like the amount of memory for "diag:" > got > > wrapped around the 32-bit limit and became > negative. > > that's strange: the amount of memory used is stored > in real > numbers, to avoid this kind of problem. Maybe your > version > was still using integer numbers. Actually, the problem with the wrapped around integers persists even in a recent CVS build. I've taken a look at memory.f90 and noticed that even though some of the expressions are assigned to a floating point number, they contain all integer arguments and thus are probably evaluated as integers until the very last assignment. A fix that requires not too much typing is to replace in memory.f90: > integer, parameter :: real_size = 8, int_size = 4 > integer, parameter :: comp_size = 2*real_size By the following: integer, parameter :: real_size_i = 8, int_size_i = 4 integer, parameter :: comp_size_i = 2*real_size_i real(kind=DP) :: real_size,int_size,comp_size ... (and then a bit later) ... real_size = float(real_size_i) int_size = float(int_size_i) comp_size = float(comp_size_i) This forces floating point numbers for intermediate values, and the estimates come out correctly. Kostya __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ From ps at ned.sims.nrc.ca Sat Jan 31 21:37:02 2004 From: ps at ned.sims.nrc.ca (Serguei Patchkovskii) Date: Sat, 31 Jan 2004 15:37:02 -0500 (EST) Subject: [Pw_forum] Error encountered while attempting to allocate a d ata object. In-Reply-To: <20040131192813.40518.qmail@web21204.mail.yahoo.com> Message-ID: On Sat, 31 Jan 2004, Konstantin Kudin wrote: > in memory.f90: > > > integer, parameter :: real_size = 8, int_size = 4 > > integer, parameter :: comp_size = 2*real_size > > By the following: > integer, parameter :: real_size_i = 8, int_size_i = 4 > integer, parameter :: comp_size_i = 2*real_size_i Actually, this is a very bad practice from the point of view of portability. The kind numbers are not guaranteed to have specific values. Fortunately, Fortran-90 provides a portable way of specifying non-default kinds (through the SELECTED_REAL_KIND and SELECTED_INTEGER_KIND intrinsics). Why not use those, and make the code portable? Serguei --- Dr. Serguei Patchkovskii Tel: +1-(613)-990-0945 Fax: +1-(613)-947-2838 E-mail: Serguei.Patchkovskii at nrc.ca Coordinator of Modelling Software Theory and Computation Group Steacie Institute for Molecular Sciences National Research Council Canada Room 2011, 100 Sussex Drive Ottawa, Ontario K1A 0R6 Canada