From sclauzer at sissa.it Thu Mar 2 11:23:04 2006 From: sclauzer at sissa.it (Gabriele Sclauzero) Date: Thu, 02 Mar 2006 11:23:04 +0100 Subject: [Pw_forum] Problems using 'relax' with bfgs Message-ID: <4406C788.2030605@sissa.it> Dear PW-users, while using calculation= 'relax' together with the 'bfgs' algorithm I encountered the following problem: the relaxation seems to proceed correctly up to a certain point and the reached configuration seems to be near the desired minimum position, but in the next bfgs steps the systems flips between two configurations and the energy oscillates up and down (around the supposed minimum position). At this point the algorithm seems not to be able to recognize that we are going back and forth and it does not find a configuration that matches the threshold I require (i.e. 1.0d-3, that is the default) on the forces. Shoudn't the algorithm be aware of this situation and do something smarter than oscillating back and forth? Or maybe should I adjust any parameters with values different from the default ones? In the attachment is the graph with the energy flips: someone might say that the difference is not so much, but the forces on the two atoms I let move are still higher than the threshold. Who might desire the output file (is 400KB large) should ask me, I will send it. Here is the input: ------- &control calculation='relax', restart_mode='from_scratch', forc_conv_thr= 1.0d-3, tprnfor= .TRUE., pseudo_dir = '/u/cm/sclauzer/Pseudo_/', outdir='/local_scratch/sclauzer/tmp/', prefix='COat6Ptwire', / &system ibrav = 6, celldm(1) = 18, celldm(3) = 1.47398638, nat= 8, ntyp= 3, ecutwfc = 29, ecutrho = 300, occupations= 'smearing', smearing='methfessel-paxton', degauss=0.01 / &electrons conv_thr = 1.0e-8 mixing_beta = 0.6 / &ions ion_dynamics= 'bfgs', upscale= 10.d0, / ATOMIC_SPECIES Pt 195.078 Ptsrnlcc.RRKJ3.UPF C 12.0107 C.pz-rrkjus.UPF O 15.9994 O.pz-rrkjus.UPF K_POINTS AUTOMATIC 1 1 13 0 0 1 ATOMIC_POSITIONS ANGSTROM C 2.2 0.0 0.0 1 0 0 O 3.343 0.0 0.0 1 0 0 Pt 0.0 0.0 -7.02 0 0 0 Pt 0.0 0.0 -4.68 0 0 0 Pt 0.0 0.0 -2.34 0 0 0 Pt 0.0 0.0 0 0 0 0 Pt 0.0 0.0 2.34 0 0 0 Pt 0.0 0.0 4.68 0 0 0 ------- Gabriele -------------- next part -------------- A non-text attachment was scrubbed... Name: Etot_cycle.ps Type: application/postscript Size: 16704 bytes Desc: not available Url : /pipermail/attachments/20060302/4ec61d0b/attachment.ps From glaweh at physik.fu-berlin.de Thu Mar 2 12:08:16 2006 From: glaweh at physik.fu-berlin.de (Henning Glawe) Date: Thu, 2 Mar 2006 12:08:16 +0100 Subject: [Pw_forum] Calculating Hubbard U Message-ID: <20060302110816.GA20079@physik.fu-berlin.de> Moin, I follow the Cococcioni/de Gironcoli procedure to estimate the Hubbard U for the Cu in bulk CaCuO_2; however, the first step, the self consistent calculation with Hubbard_U=Hubbard_alpha=0 fails with the error message: from setup : error # 1 lda_plus_u calculation but Hubbard_l not set I tracked this down to espresso-3.0/PW/setup.f90:854; for me, it looks like you can't do a LDA+U calculation when setting U or Alpha exactly to zero for all atoms. How much error would it introduce setting U for the Cu to say, 1d-10 and then varying alpha to determine the 'real' U? -- c u henning From giannozz at nest.sns.it Thu Mar 2 15:01:02 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 2 Mar 2006 15:01:02 +0100 Subject: [Pw_forum] Problems using 'relax' with bfgs In-Reply-To: <4406C788.2030605@sissa.it> References: <4406C788.2030605@sissa.it> Message-ID: <200603021501.02819.giannozz@nest.sns.it> On Thursday 02 March 2006 11:23, Gabriele Sclauzero wrote: > In the attachment is the graph with the energy flips: > someone might say that the difference is not so much 5 micro-eV is definitely "not so much", to say the least > but the forces on the two atoms I let move are still higher > than the threshold. if the atomic positions change very little from one iteration to another (and I would be surprised if they didn't) just raise the threshold on forces 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 Mar 2 15:01:10 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 2 Mar 2006 15:01:10 +0100 Subject: [Pw_forum] Calculating Hubbard U In-Reply-To: <20060302110816.GA20079@physik.fu-berlin.de> References: <20060302110816.GA20079@physik.fu-berlin.de> Message-ID: <200603021501.10691.giannozz@nest.sns.it> On Thursday 02 March 2006 12:08, Henning Glawe wrote: > from setup : error # 1 > lda_plus_u calculation but Hubbard_l not set > > [...] it looks like you can't do a LDA+U calculation > when setting U or Alpha exactly to zero for all atoms. ...when setting U *AND* Alpha exactly to zero for all atoms. Just set lda_plus_U=.false. 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 glaweh at physik.fu-berlin.de Thu Mar 2 15:12:44 2006 From: glaweh at physik.fu-berlin.de (Henning Glawe) Date: Thu, 2 Mar 2006 15:12:44 +0100 Subject: [Pw_forum] Calculating Hubbard U In-Reply-To: <200603021501.10691.giannozz@nest.sns.it> References: <20060302110816.GA20079@physik.fu-berlin.de> <200603021501.10691.giannozz@nest.sns.it> Message-ID: <20060302141244.GA27775@physik.fu-berlin.de> On Thu, Mar 02, 2006 at 03:01:10PM +0100, Paolo Giannozzi wrote: > > from setup : error # 1 > > lda_plus_u calculation but Hubbard_l not set > > > > [...] it looks like you can't do a LDA+U calculation > > when setting U or Alpha exactly to zero for all atoms. > > ...when setting U *AND* Alpha exactly to zero for all atoms. that's what I meant. sorry for mistyping ;) > Just set lda_plus_U=.false. but then I don't get the occupation matrices of the Cu d states for 'pushing' the system into the right direction, as it is suggested in the example25/README if one converges to the 'wrong', non-magnetic solution... -- c u henning From matteoc at MIT.EDU Thu Mar 2 15:28:44 2006 From: matteoc at MIT.EDU (Matteo Cococcioni) Date: Thu, 2 Mar 2006 09:28:44 -0500 (EST) Subject: [Pw_forum] Calculating Hubbard U In-Reply-To: <20060302110816.GA20079@physik.fu-berlin.de> References: <20060302110816.GA20079@physik.fu-berlin.de> Message-ID: Dear Henning, you are right: if you set Hubbard_U and Hubbard_alpha exactly to 0 the code won't print the occupations and if lda_plus_u = .true. it stops with the error message you report. Maybe this should be changed but the way around this is very easy and is exactly what you were suggesting. To obtain the occupations printed on your output file (and to compute the U) just set Hubbard_U to very small values (1.d-10 is on the very safe side but you could use even smaller values if you prefer: it only needs to be non zero). I hope this helps. Matteo On Thu, 2 Mar 2006, Henning Glawe wrote: > Moin, > I follow the Cococcioni/de Gironcoli procedure to estimate the Hubbard U for > the Cu in bulk CaCuO_2; however, the first step, the self consistent > calculation with Hubbard_U=Hubbard_alpha=0 fails with the error message: > > from setup : error # 1 > lda_plus_u calculation but Hubbard_l not set > > I tracked this down to espresso-3.0/PW/setup.f90:854; for me, it looks like > you can't do a LDA+U calculation when setting U or Alpha exactly to zero for > all atoms. > How much error would it introduce setting U for the Cu to say, 1d-10 and > then varying alpha to determine the 'real' U? > > -- > c u > henning > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From sbraccia at sissa.it Thu Mar 2 16:04:27 2006 From: sbraccia at sissa.it (carlo sbraccia) Date: Thu, 02 Mar 2006 10:04:27 -0500 Subject: [Pw_forum] Problems using 'relax' with bfgs In-Reply-To: <4406C788.2030605@sissa.it> References: <4406C788.2030605@sissa.it> Message-ID: <4407097B.6020908@sissa.it> Dear Gabriele, can you, please, send me the output (I can afford the 400KB) ? carlo Gabriele Sclauzero wrote: > Dear PW-users, > > while using calculation= 'relax' together with the 'bfgs' algorithm > I encountered the following problem: the relaxation seems to proceed > correctly up to a certain point and the reached configuration seems to > be near the desired minimum position, but in the next bfgs steps the > systems flips between two configurations and the energy oscillates up > and down (around the supposed minimum position). At this point the > algorithm seems not to be able to recognize that we are going back and > forth and it does not find a configuration that matches the threshold I > require (i.e. 1.0d-3, that is the default) on the forces. > > Shoudn't the algorithm be aware of this situation and do something > smarter than oscillating back and forth? Or maybe should I adjust any > parameters with values different from the default ones? > > In the attachment is the graph with the energy flips: someone might say > that the difference is not so much, but the forces on the two atoms I > let move are still higher than the threshold. > Who might desire the output file (is 400KB large) should ask me, I will > send it. > Here is the input: > ------- > &control > calculation='relax', > restart_mode='from_scratch', > forc_conv_thr= 1.0d-3, > tprnfor= .TRUE., > pseudo_dir = '/u/cm/sclauzer/Pseudo_/', > outdir='/local_scratch/sclauzer/tmp/', > prefix='COat6Ptwire', > / > &system > ibrav = 6, > celldm(1) = 18, > celldm(3) = 1.47398638, > nat= 8, > ntyp= 3, > ecutwfc = 29, > ecutrho = 300, > occupations= 'smearing', > smearing='methfessel-paxton', > degauss=0.01 > / > &electrons > conv_thr = 1.0e-8 > mixing_beta = 0.6 > / > &ions > ion_dynamics= 'bfgs', > upscale= 10.d0, > / > ATOMIC_SPECIES > Pt 195.078 Ptsrnlcc.RRKJ3.UPF > C 12.0107 C.pz-rrkjus.UPF > O 15.9994 O.pz-rrkjus.UPF > K_POINTS AUTOMATIC > 1 1 13 0 0 1 > ATOMIC_POSITIONS ANGSTROM > C 2.2 0.0 0.0 1 0 0 > O 3.343 0.0 0.0 1 0 0 > Pt 0.0 0.0 -7.02 0 0 0 > Pt 0.0 0.0 -4.68 0 0 0 > Pt 0.0 0.0 -2.34 0 0 0 > Pt 0.0 0.0 0 0 0 0 > Pt 0.0 0.0 2.34 0 0 0 > Pt 0.0 0.0 4.68 0 0 0 > ------- > > > Gabriele From twin at fromru.com Fri Mar 3 09:39:17 2006 From: twin at fromru.com (=?koi8-r?b?98nUwczJyg==?=) Date: Fri, 3 Mar 2006 11:39:17 +0300 (MSK) Subject: [Pw_forum] Using of pp.x for plotting Message-ID: <200603030839.k238dHnK045694@www8.pochta.ru> Dear members, please write me how I can use postprocessing code pp.x for plotting. When I run pp.x from terminal it start but it nothing do. Sincerely, mailto:twin at fromru.com From dkorotin at gmail.com Fri Mar 3 10:05:00 2006 From: dkorotin at gmail.com (Dmitry Korotin) Date: Fri, 3 Mar 2006 14:05:00 +0500 Subject: [Pw_forum] Re: Using of pp.x for plotting In-Reply-To: <200603030839.k238dHnK045694@www8.pochta.ru> References: <200603030839.k238dHnK045694@www8.pochta.ru> Message-ID: <2fd252650603030105qb8e85f0v1728581e7ff58053@mail.gmail.com> Please read file Doc/INPUT_PP 03.03.06, ??????? ???????(?): > Dear members, > please write me how I can use postprocessing code > pp.x for plotting. > When I run pp.x from terminal it start but it nothing do. > > Sincerely, > mailto:twin at fromru.com > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From prasenjit at jncasr.ac.in Fri Mar 3 11:14:28 2006 From: prasenjit at jncasr.ac.in (PRASENJIT GHOSH) Date: Fri, 3 Mar 2006 15:44:28 +0530 (IST) Subject: [Pw_forum] from davcio : error # 10 Message-ID: <56197.202.41.111.151.1141380868.squirrel@202.41.111.151> Hi everybody, I'm using 3.0 version (parallel) of PWscf to do neb calculations. When the neb calculations entered the 6th iterations, it stopped while relaxing the structure of the fourth image because the alooted computer time was over. When I restart the programme it starts from the sixth iteration but it stops exactly at the same point where it stopped while doing the fourth image, giving the following error: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% task # 5 from davcio : error # 10 i/o error in davcio %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% I checked the disk space & there is still 18% disk space left on the drive where the code is writing the wfc files. With regards, Prasenjit. PRASENJIT GHOSH, Ph. D STUDENT, THEORETICAL SCIENCES UNIT, JAWAHARLAL NEHRU CENTRE, JAKKUR P. O., BANGALORE - 560064, INDIA. PHONE:+91-80-22082835 (OFFICE) +91 9880519401 (MOBILE) From hqzhou at nju.edu.cn Fri Mar 3 12:19:29 2006 From: hqzhou at nju.edu.cn (Huiqun Zhou) Date: Fri, 3 Mar 2006 19:19:29 +0800 Subject: [Pw_forum] How to control temperature in vc-md or vc-relax runs? Message-ID: <000301c63eb4$59108c90$1d00a8c0@solarflare> list-users, I have tried several vc-md and vc-relax runs, but found that the temperature went very high even though I had set tempw to 300 and ion_temperature equal to 'rescaling'. Could anyone give me a pointer what other options I need to set for controlling temperature? Huiqun Zhou From hqzhou at nju.edu.cn Fri Mar 3 13:02:26 2006 From: hqzhou at nju.edu.cn (Huiqun Zhou) Date: Fri, 3 Mar 2006 20:02:26 +0800 Subject: [Pw_forum] Where can I find descriptions for the output files of vc-md run? Message-ID: <001801c63eba$625a44c0$1d00a8c0@solarflare> list-users, During run of a vc-md calculation, besides screen output several other files, e, p, eal, ave, avec and tv are generated, too. Although we can guess what some of them contain from their filenames, I need a clear description of these files for sure. Please help. Huiqun Zhou From Conor.Hogan at roma2.infn.it Fri Mar 3 16:01:28 2006 From: Conor.Hogan at roma2.infn.it (Conor Hogan) Date: Fri, 3 Mar 2006 16:01:28 +0100 (GMT+0100) Subject: [Pw_forum] Energy convergence in Cobalt Message-ID: Dear forum, I was trying to find the right kinetic energy cut-off using PWscf for a molecule which contains a cobalt atom. I already tested the convergence for the same molecule without cobalt, and everything seems fine. Now I am testing the kinetic energy cut-off with cobalt. The pseudo is : Co.pz-nd-rrkjus.UPF downloaded from the web For this reason I performed scf calculations, varying the cut-off both for an isolated Cobalt atom and also for the hexagonal bulk phase of Cobalt. In both cases I noted that the total energy does not decrease if the kinetic energy cut-off is increased, which is not what I expected (in fact it increases!) Here the results: Isolated atom: ecut=30 ry etot= -73.7557 ry ecut=40 ry etot= -73.7430 ry ecut=50 ry etot= -73.7367 ry Bulk of Co: ecut 30 -148.4497 ry ecut 40 -148.4448 ry ecut 50 -148.4440 ry I guess I am doing something stupid in the input - perhaps someone has an idea why? Am I missing convergence with respect to another parameter perhaps? The same problem happens with a PBE Co-pseudo downloaded from the web so I don't think it is a problem with the pseudopotential..! Cheers Conor Here are the two input files: Input for ISOLATED Co Atom: calculation = 'scf' restart_mode='from_scratch' verbosity= 'high', prefix='Co2', pseudo_dir = 'pseudo', max_seconds=1000, disk_io='minimal', etot_conv_thr=1.0e-5 outdir='./' / &system ibrav= 8, celldm(1)=20., celldm(2) =1, celldm(3) = 1. nat=1, ntyp=1, nbnd=30, nelec = 9.00, nosym=.true. nelup = 6 neldw = 3 nspin = 2, starting_magnetization = 1.0 , ecutwfc = 50.0 occupations='fixed' / &electrons diago_thr_init=1.0e-3 electron_maxstep = 200, conv_thr = 1.e-7, mixing_beta =0.6 / ATOMIC_SPECIES Co 58.00 Co.pz-nd-rrkjus.UPF ATOMIC_POSITIONS (angstrom) Co 5. 5. 5. K_POINTS (gamma) Input for Co-BULK: ----------------- &control calculation = 'scf' restart_mode='from_scratch' verbosity= 'high', prefix='Co-bulk', pseudo_dir = 'pseudo', max_seconds=1000, disk_io='minimal', etot_conv_thr=1.0e-5 outdir='./' / &system ibrav= 4, celldm(1)=4.74480009, celldm(2) =1, celldm(3) = 1.600000 nat=2, ntyp=1 nspin = 2, starting_magnetization(1) = 1.0 , ecutwfc = 40.0 occupations='smearing', smearing='gaussian' , degauss=0.001 / &electrons diago_thr_init=1.0e-3 electron_maxstep = 200, conv_thr = 1.e-7, mixing_beta =0.6 / ATOMIC_SPECIES Co 58.00 Co.pz-nd-rrkjus.UPF ATOMIC_POSITIONS (crystal) Co 0.0000000 0.0000000 0.00000000 Co 0.6666667 0.3333333 0.50000000 K_POINTS (automatic) 10 10 10 0 0 1 Maurizia Palummo Dipartimento di Fisica Universita' 'Tor Vergata' Via della Ricerca Scientifica I tel.++39-06-72594894 fax ++39-06-2023507 www.fisica.uniroma2.it/palummo From glaweh at physik.fu-berlin.de Fri Mar 3 18:42:32 2006 From: glaweh at physik.fu-berlin.de (Henning Glawe) Date: Fri, 3 Mar 2006 18:42:32 +0100 Subject: [Pw_forum] Calculating Hubbard U In-Reply-To: References: <20060302110816.GA20079@physik.fu-berlin.de> Message-ID: <20060303174232.GA16548@physik.fu-berlin.de> On Thu, Mar 02, 2006 at 09:28:44AM -0500, Matteo Cococcioni wrote: > you are right: if you set Hubbard_U and Hubbard_alpha exactly to 0 the > code won't print the occupations and if lda_plus_u = .true. it stops with > the error message you report. Maybe this should be changed but the way > around this is very easy and is exactly what you were suggesting. To > obtain the occupations printed on your output file (and to compute the > U) just set Hubbard_U to very small values (1.d-10 is on the very safe > side but you could use even smaller values if you prefer: it only needs to > be non zero). I hope this helps. it helped for the U=alpha=0 case, thanks. Now I tried to impose the perturbation by setting hubbard_alpha to various non-zero values, taking the data from the first calculation as a starting point (startingwfc=startingpot='file', diago_thr_init = 9.54E-10 from the last step of the U=1d-10 scf calculation). but re-running with a changed hubbard_alpha($atom) seems to have no effect, though setting hubbard_alpha(1)=0.1 in the input, pw.x keeps running with alpha=0 (at least this is what it writes on STDOUT). Does pw.x read this from the files in 'outdir' ? -- c u henning From matteoc at MIT.EDU Fri Mar 3 18:51:37 2006 From: matteoc at MIT.EDU (Matteo Cococcioni) Date: Fri, 3 Mar 2006 12:51:37 -0500 (EST) Subject: [Pw_forum] Calculating Hubbard U In-Reply-To: <20060303174232.GA16548@physik.fu-berlin.de> References: <20060302110816.GA20079@physik.fu-berlin.de> <20060303174232.GA16548@physik.fu-berlin.de> Message-ID: On Fri, 3 Mar 2006, Henning Glawe wrote: > On Thu, Mar 02, 2006 at 09:28:44AM -0500, Matteo Cococcioni wrote: >> you are right: if you set Hubbard_U and Hubbard_alpha exactly to 0 the >> code won't print the occupations and if lda_plus_u = .true. it stops with >> the error message you report. Maybe this should be changed but the way >> around this is very easy and is exactly what you were suggesting. To >> obtain the occupations printed on your output file (and to compute the >> U) just set Hubbard_U to very small values (1.d-10 is on the very safe >> side but you could use even smaller values if you prefer: it only needs to >> be non zero). I hope this helps. > > it helped for the U=alpha=0 case, thanks. > Now I tried to impose the perturbation by setting hubbard_alpha to various > non-zero values, taking the data from the first calculation as a starting > point (startingwfc=startingpot='file', diago_thr_init = 9.54E-10 from the > last step of the U=1d-10 scf calculation). > > but re-running with a changed hubbard_alpha($atom) seems to have no effect, > though setting hubbard_alpha(1)=0.1 in the input, pw.x keeps running with > alpha=0 (at least this is what it writes on STDOUT). Does pw.x read this from > the files in 'outdir' ? Dear Henning, make sure your restart_mode is set to "from_scratch" even when you restart with a finite value of Hubbard_alpha. Otherwise (I think) the code reads the restart file and doesn't realize that you have changed Hubbard_alpha. let us know how it goes. Matteo > > -- > c u > henning > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From glaweh at physik.fu-berlin.de Fri Mar 3 19:19:22 2006 From: glaweh at physik.fu-berlin.de (Henning Glawe) Date: Fri, 3 Mar 2006 19:19:22 +0100 Subject: [Pw_forum] Calculating Hubbard U In-Reply-To: References: <20060302110816.GA20079@physik.fu-berlin.de> <20060303174232.GA16548@physik.fu-berlin.de> Message-ID: <20060303181922.GA18121@physik.fu-berlin.de> On Fri, Mar 03, 2006 at 12:51:37PM -0500, Matteo Cococcioni wrote: > >but re-running with a changed hubbard_alpha($atom) seems to have no effect, > >though setting hubbard_alpha(1)=0.1 in the input, pw.x keeps running with > >alpha=0 (at least this is what it writes on STDOUT). Does pw.x read this > >from > >the files in 'outdir' ? > > Dear Henning, > > make sure your restart_mode is set to "from_scratch" even when you restart > with a finite value of Hubbard_alpha. Otherwise (I think) the code reads > the restart file and doesn't realize that you have changed Hubbard_alpha. > > let us know how it goes. restart_mode was set to 'from_scratch'; pw.x seems to get the hubbard_alpha(1)=0 anyways... -- c u henning From sbraccia at sissa.it Fri Mar 3 23:21:55 2006 From: sbraccia at sissa.it (carlo sbraccia) Date: Fri, 03 Mar 2006 17:21:55 -0500 Subject: [Pw_forum] from davcio : error # 10 In-Reply-To: <56197.202.41.111.151.1141380868.squirrel@202.41.111.151> References: <56197.202.41.111.151.1141380868.squirrel@202.41.111.151> Message-ID: <4408C183.1070408@sissa.it> When the job is killed by the scheduler because the time is over, the files on the scratch can result to be corrupted. Try to remove them by hand (I assume $outdir is the place where PW writes its files and $prefix is the prefix of the calculation): rm -rf $outdir/$prefix_* Notice that the restart file of your neb calculation is always saved in the working directory (it is called $prefix.path). carlo PRASENJIT GHOSH wrote: > Hi everybody, > I'm using 3.0 version (parallel) of PWscf to do neb calculations. > When the neb calculations entered the 6th iterations, it stopped while > relaxing the structure of the fourth image because the alooted computer > time was over. > When I restart the programme it starts from the sixth iteration but it > stops exactly at the same point where it stopped while doing the fourth > image, giving the following error: > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > task # 5 > from davcio : error # 10 > i/o error in davcio > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > I checked the disk space & there is still 18% disk space left on the drive > where the code is writing the wfc files. > > With regards, > Prasenjit. > PRASENJIT GHOSH, > Ph. D STUDENT, > THEORETICAL SCIENCES UNIT, > JAWAHARLAL NEHRU CENTRE, > JAKKUR P. O., > BANGALORE - 560064, > INDIA. > > PHONE:+91-80-22082835 (OFFICE) > +91 9880519401 (MOBILE) > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From proffess at yandex.ru Sat Mar 4 01:29:14 2006 From: proffess at yandex.ru (Sergey Lisenkov) Date: Sat, 4 Mar 2006 03:29:14 +0300 (MSK) Subject: [Pw_forum] execution error on Itanium2 Message-ID: <4408DF5A.000005.02512@tide.yandex.ru> Dear all, There is a problem with PWscf code running in parallel (serial version works fine) on Itanium2 cluster, compiled with Intel8.1 compilers, mpich-gm: 1 - MPI_ALLREDUCE : Datatype is MPI_TYPE_NULL 2 - MPI_ALLREDUCE : Datatype is MPI_TYPE_NULL 3 - MPI_ALLREDUCE : Datatype is MPI_TYPE_NULL 0 - MPI_ALLREDUCE : Datatype is MPI_TYPE_NULL [0] Aborting program ! [0] Aborting program! [1] Aborting program ! [1] Aborting program! [2] Aborting program ! [2] Aborting program! [3] Aborting program ! [3] Aborting program! It should be certanly a problem of MPICH, but system admins does not believe in that, because other MPI programs work fine. So, did anybody see the same problem or know how to fix it? Thanks in advance, Sergey From matteoc at MIT.EDU Sat Mar 4 22:17:59 2006 From: matteoc at MIT.EDU (Matteo Cococcioni) Date: Sat, 4 Mar 2006 16:17:59 -0500 (EST) Subject: [Pw_forum] Calculating Hubbard U In-Reply-To: <20060303181922.GA18121@physik.fu-berlin.de> References: <20060302110816.GA20079@physik.fu-berlin.de> <20060303174232.GA16548@physik.fu-berlin.de> <20060303181922.GA18121@physik.fu-berlin.de> Message-ID: Dear Henning could you please post your input files? Matteo On Fri, 3 Mar 2006, Henning Glawe wrote: > On Fri, Mar 03, 2006 at 12:51:37PM -0500, Matteo Cococcioni wrote: >>> but re-running with a changed hubbard_alpha($atom) seems to have no effect, >>> though setting hubbard_alpha(1)=0.1 in the input, pw.x keeps running with >>> alpha=0 (at least this is what it writes on STDOUT). Does pw.x read this >>> from >>> the files in 'outdir' ? >> >> Dear Henning, >> >> make sure your restart_mode is set to "from_scratch" even when you restart >> with a finite value of Hubbard_alpha. Otherwise (I think) the code reads >> the restart file and doesn't realize that you have changed Hubbard_alpha. >> >> let us know how it goes. > > restart_mode was set to 'from_scratch'; pw.x seems to get the > hubbard_alpha(1)=0 anyways... > > -- > c u > henning > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From marzari at MIT.EDU Sun Mar 5 00:15:47 2006 From: marzari at MIT.EDU (Nicola Marzari) Date: Sat, 04 Mar 2006 18:15:47 -0500 Subject: [Pw_forum] searching the archives In-Reply-To: References: Message-ID: <440A1FA3.5040005@mit.edu> Dear All, it looks like the two pw archives cannot be searched for anything more recent than June 16th 2005. nicola --------------------------------------------------------------------- Prof Nicola Marzari Department of Materials Science and Engineering 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu From konstantin_kudin at yahoo.com Sun Mar 5 01:36:17 2006 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Sat, 4 Mar 2006 16:36:17 -0800 (PST) Subject: [Pw_forum] searching the archives In-Reply-To: <440A1FA3.5040005@mit.edu> Message-ID: <20060305003617.97618.qmail@web52012.mail.yahoo.com> Dear Nicola, You can always go to www.google.com and search for "something site:democritos.it" Kostya --- Nicola Marzari wrote: > > > Dear All, > > it looks like the two pw archives cannot be searched for anything > more recent than June 16th 2005. > > nicola > > --------------------------------------------------------------------- > Prof Nicola Marzari Department of Materials Science and Engineering > 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA > tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From twin at fromru.com Sun Mar 5 08:59:25 2006 From: twin at fromru.com (=?windows-1251?Q?=C2=E8=F2=E0=EB=E8=E9?=) Date: Sun, 5 Mar 2006 12:59:25 +0500 Subject: [Pw_forum] Error while loading shared libraries In-Reply-To: <2fd252650603030105qb8e85f0v1728581e7ff58053@mail.gmail.com> References: <200603030839.k238dHnK045694@www8.pochta.ru> <2fd252650603030105qb8e85f0v1728581e7ff58053@mail.gmail.com> Message-ID: <1689204894.20060305125925@fromru.com> Dear Dmitry Korotin, ?fter installation of espresso-3.0 at start of calculations the following error stands out: > error while loading shared libraries:libimf.so:cannot open object file: No such file or directory Help to understand please. -- Zdravstvuite Dmitriya Korotin. Ya voobsche tol'ko nachal rabotat' s pwscf i poetomu u menya voznikayut trudnosti. Vot vydaet takuyu oshibku: > error while loading shared libraries:libimf.so:cannot open object file: No such file or directory Vidimo net biblioteki ili ne ukazan put' k nei. Podskazhite pozhaluista kak eto ispravit'. Spasibo! P.S.: otvet, zhelatel'no, prisylaite na russkom yazyke. -- ???????????? ??????? ???????. ? ?????? ?????? ????? ???????? ? pwscf, ? ??????? ? ???? ????????? ?????????. ??? ?????? ????? ??????: > error while loading shared libraries:libimf.so:cannot open object file: No such file or directory ?????? ??? ?????????? ??? ?? ?????? ???? ? ???. ?????????? ?????????? ??? ??? ?????????. ???????! P.S.: ?????, ??????????, ?????????? ?? ??????? ?????. -- ? ?????????, ??????? mailto: twin at fromru.com From akohlmey at vitae.cmm.upenn.edu Sun Mar 5 10:15:35 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Sun, 5 Mar 2006 04:15:35 -0500 (EST) Subject: [Pw_forum] Error while loading shared libraries In-Reply-To: <1689204894.20060305125925@fromru.com> Message-ID: On Sun, 5 Mar 2006, [windows-1251] ??????? wrote: DK> Dear Dmitry Korotin, DK> DK> ?fter installation of espresso-3.0 at start of calculations the DK> following error stands out: DK> > error while loading shared libraries:libimf.so:cannot open object file: No such file or directory DK> Help to understand please. dmitry, please have a closer look at the intel compiler documentation. you have to either replace 'ifort' in the make.sys file with 'ifort -i-static' so that the intel compiler runtime is linked statically, add an -Xlinker -rpath ... or set LD_LIBRARY_PATH, so that the compiled binary will find the shared compiler runtime libraries. regards, axel. DK> DK> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From giannozz at nest.sns.it Sun Mar 5 22:39:28 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Sun, 5 Mar 2006 22:39:28 +0100 Subject: [Pw_forum] execution error on Itanium2 In-Reply-To: <4408DF5A.000005.02512@tide.yandex.ru> References: <4408DF5A.000005.02512@tide.yandex.ru> Message-ID: <200603052239.28634.giannozz@nest.sns.it> On Saturday 04 March 2006 01:29, Sergey Lisenkov wrote: > There is a problem with PWscf code running in parallel > (serial version works fine) the stable version? > on Itanium2 cluster, compiled with Intel8.1 compilers, mpich-gm: > > 1 - MPI_ALLREDUCE : Datatype is MPI_TYPE_NULL if this is deterministic, it might be a problem with definitions like MPI_REAL8 and MPI_DOUBLE_PRECISION that are contained in mpif.h. You might be using an incompatible version of mpif.h, for instance. Try to locate where this happens. If this is erratic, it is a problem with either the compiler or the mpi libraries or both or the interactions between the two, whatever your system administrator says. 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 glaweh at physik.fu-berlin.de Mon Mar 6 09:34:45 2006 From: glaweh at physik.fu-berlin.de (Henning Glawe) Date: Mon, 6 Mar 2006 09:34:45 +0100 Subject: [Pw_forum] Calculating Hubbard U In-Reply-To: References: <20060302110816.GA20079@physik.fu-berlin.de> <20060303174232.GA16548@physik.fu-berlin.de> <20060303181922.GA18121@physik.fu-berlin.de> Message-ID: <20060306083445.GA7460@physik.fu-berlin.de> On Sat, Mar 04, 2006 at 04:17:59PM -0500, Matteo Cococcioni wrote: > could you please post your input files? they are attached to this mail. -- c u henning -------------- next part -------------- &control calculation = 'scf' restart_mode = 'from_scratch' prefix = 'CaCuO2' pseudo_dir = '/home/glaweh/CuO2/pseudo' wf_collect = .true. outdir = '/local_scratch/glaweh/CaCuO2-lgetU-2x2/' / &system ibrav = 6 celldm(1) = 14.74306 celldm(3) = 0.4101707165820785 nat = 16 ntyp = 6 ecutwfc = 60.0 ecutrho = 800.0 occupations = 'smearing' smearing = 'methfessel-paxton' degauss = 0.02 starting_magnetization(1) = 0.5 starting_magnetization(2) = -0.5 starting_magnetization(3) = -0.5 starting_magnetization(4) = 0.5 starting_magnetization(5) = 0 starting_magnetization(6) = 0 nspin=2 lda_plus_u =.true. Hubbard_U(1) = 1d-10 Hubbard_alpha(1) = 0.0 Hubbard_U(2) = 1d-10 Hubbard_alpha(2) = 0.0 Hubbard_U(3) = 1d-10 Hubbard_alpha(3) = 0.0 Hubbard_U(4) = 1d-10 Hubbard_alpha(4) = 0.0 / &electrons mixing_mode = 'plain' mixing_beta = 0.7 / ATOMIC_SPECIES Cu1 63.546 Cu.pz-d-rrkjus.UPF Cu2 63.546 Cu.pz-d-rrkjus.UPF Cu3 63.546 Cu.pz-d-rrkjus.UPF Cu4 63.546 Cu.pz-d-rrkjus.UPF O 15.9994 O.pz-rrkjus.UPF Ca 40.078 Ca.pz-n-vbc.UPF ATOMIC_POSITIONS crystal Cu1 0 0 0 O 0.25 0 0 O 0 0.25 0 Ca 0.25 0.25 0.5 Cu2 0 0.5 0 O 0.25 0.5 0 O 0 0.75 0 Ca 0.25 0.75 0.5 Cu3 0.5 0 0 O 0.75 0 0 O 0.5 0.25 0 Ca 0.75 0.25 0.5 Cu4 0.5 0.5 0 O 0.75 0.5 0 O 0.5 0.75 0 Ca 0.75 0.75 0.5 K_POINTS {automatic} 4 4 8 0 0 0 -------------- next part -------------- &control calculation = 'scf' restart_mode = 'from_scratch' prefix = 'CaCuO2' pseudo_dir = '/home/glaweh/CuO2/pseudo' wf_collect = .true. outdir = '/local_scratch/glaweh/CaCuO2-lalpha_0.05/' / &system ibrav = 6 celldm(1) = 14.74306 celldm(3) = 0.4101707165820785 nat = 16 ntyp = 6 ecutwfc = 60.0 ecutrho = 800.0 occupations = 'smearing' smearing = 'methfessel-paxton' degauss = 0.02 starting_magnetization(1) = 0.5 starting_magnetization(2) = -0.5 starting_magnetization(3) = -0.5 starting_magnetization(4) = 0.5 starting_magnetization(5) = 0 starting_magnetization(6) = 0 nspin=2 lda_plus_u =.true. Hubbard_U(1) = 1d-10 Hubbard_alpha(1) = 0.05 Hubbard_U(2) = 1d-10 Hubbard_alpha(2) = 0.0 Hubbard_U(3) = 1d-10 Hubbard_alpha(3) = 0.0 Hubbard_U(4) = 1d-10 Hubbard_alpha(4) = 0.0 / &electrons startingwfc = 'file' startingpot = 'file' diago_thr_init = 2.13E-09 mixing_mode = 'plain' mixing_beta = 0.7 / ATOMIC_SPECIES Cu1 63.546 Cu.pz-d-rrkjus.UPF Cu2 63.546 Cu.pz-d-rrkjus.UPF Cu3 63.546 Cu.pz-d-rrkjus.UPF Cu4 63.546 Cu.pz-d-rrkjus.UPF O 15.9994 O.pz-rrkjus.UPF Ca 40.078 Ca.pz-n-vbc.UPF ATOMIC_POSITIONS crystal Cu1 0 0 0 O 0.25 0 0 O 0 0.25 0 Ca 0.25 0.25 0.5 Cu2 0 0.5 0 O 0.25 0.5 0 O 0 0.75 0 Ca 0.25 0.75 0.5 Cu3 0.5 0 0 O 0.75 0 0 O 0.5 0.25 0 Ca 0.75 0.25 0.5 Cu4 0.5 0.5 0 O 0.75 0.5 0 O 0.5 0.75 0 Ca 0.75 0.75 0.5 K_POINTS {automatic} 4 4 8 0 0 0 From gmonaco at unisa.it Mon Mar 6 11:23:28 2006 From: gmonaco at unisa.it (gmonaco at unisa.it) Date: Mon, 6 Mar 2006 11:23:28 +0100 Subject: [Pw_forum] memory allocation failed Message-ID: <1141640608.440c0da091e72@webmail.unisa.it> Dear all, I have tried several times to make phonon calculations on a large cell. While the program terminated using some pseudopotentials, upon a change of basis a memory allocation error was obtained. Can anyine help me? Thanks Guglielmo The working pseudopotentials are: C 12.00 C.blyp-mt.UPF H 1.00 H.blyp-vbc.UPF The problematic pseudopotentials are: C 12.00 C.pz-rrkjus.UPF H 1.00 H.pz-rrkjus.UPF The last lines of the phonon calculation output are .. Representation 77 1 modes - To be done Representation 78 1 modes - To be done PHONON : 51.85s CPU time Electric Fields Calculation iter # 11 total cpu time : 1685.0 secs av.it.: 1.0 thresh= 0.937E-08 alpha_mix = 0.700 |ddv_scf|^2 = 0.877E-14 End of electric fields calculation Dielectric constant in cartesian axis ( 1.478968861 -0.002955477 -0.033795112 ) ( -0.002955437 1.296273216 -0.006722323 ) ( -0.033794945 -0.006722309 1.210278099 ) At line 172 of file add_for_charges.F90 Traceback: not available, compile with -ftrace=frame or -ftrace=full Operating system error: Cannot allocate memory Memory allocation failed ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From proffess at yandex.ru Mon Mar 6 17:35:26 2006 From: proffess at yandex.ru (Sergey Lisenkov) Date: Mon, 6 Mar 2006 19:35:26 +0300 (MSK) Subject: [Pw_forum] execution error on Itanium2 In-Reply-To: <200603052239.28634.giannozz@nest.sns.it> References: <4408DF5A.000005.02512@tide.yandex.ru> <200603052239.28634.giannozz@nest.sns.it> Message-ID: <440C64CE.000001.28513@webmail10.yandex.ru> Dear Paolo, Thanks a lot for the hints. >the stable version? Yes, it is 3.0 version. >if this is deterministic, it might be a problem with definitions like >MPI_REAL8 and MPI_DOUBLE_PRECISION that are contained in mpif.h. >You might be using an incompatible version of mpif.h, for instance. >Try to locate where this happens. I looked in mpif.h file, which is used by MPI and found very nice MPI definitions: .... PARAMETER (MPI_INTEGER1=0,MPI_INTEGER2=0) PARAMETER (MPI_INTEGER4=0) PARAMETER (MPI_INTEGER8=0) PARAMETER (MPI_INTEGER16=0) PARAMETER (MPI_REAL4=0) PARAMETER (MPI_REAL8=0) PARAMETER (MPI_REAL16=0) PARAMETER (MPI_COMPLEX8=0) PARAMETER (MPI_COMPLEX16=0) PARAMETER (MPI_COMPLEX32=0) Obviously, this is wrong, because on another Itanium2 cluster (with very good administration support...) I see: ... PARAMETER (MPI_INTEGER1=1,MPI_INTEGER2=4) PARAMETER (MPI_INTEGER4=6) PARAMETER (MPI_INTEGER8=8) PARAMETER (MPI_INTEGER16=0) PARAMETER (MPI_REAL4=10) PARAMETER (MPI_REAL8=11) PARAMETER (MPI_REAL16=12) PARAMETER (MPI_COMPLEX8=23) PARAMETER (MPI_COMPLEX16=24) PARAMETER (MPI_COMPLEX32=0) .... So, when I used this version of mpif.h instead previous one, the pwscf code works fine in parallel. Thanks a lot, Best wishes, Sergey From Sir_Puding at tut.by Tue Mar 7 15:28:36 2006 From: Sir_Puding at tut.by (Sir_Puding) Date: Tue, 7 Mar 2006 16:28:36 +0200 Subject: [Pw_forum] Charge error. Message-ID: <715654750.20060307162836@tut.by> Hello all, I use 3.0 version of the code and want to calculate relaxed ionic structure for Nitrogen substitute atom in Diamond. I use cubic cell of 64 atoms and get this error ------------------------------------------------------- Initial potential from superposition of free atoms starting charge 256.99668, renormalised to 257.00000 Starting wfc are atomic total cpu time spent up to now is 225.32 secs Self-consistent Calculation iteration # 1 ecut= 30.00 ryd beta=0.70 Davidson diagonalization with overlap ethr = 1.00E-02, avg # of iterations = 2.0 total cpu time spent up to now is 561.73 secs WARNING: integrated charge= 256.30000000, expected= 257.00000000 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from electrons : error # 1 charge is wrong %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... Input is ---------------------------- &CONTROL calculation = 'vc-relax' , restart_mode = 'from_scratch' , outdir = '/home/sergey/tmp/' , pseudo_dir = '/home/sergey/espresso/pseudo/' , prefix = 'silicon' , disk_io = 'high' , verbosity = 'high' , tstress = .true. , tprnfor = .true. , dt = 100.0 , / &SYSTEM ibrav = 1, celldm(1) = 13.4834, nat = 64, ntyp = 2, ecutwfc = 18 , nelec = 257, nspin = 1 , / &ELECTRONS conv_thr = 1.0d-8 , mixing_mode = 'plain' , mixing_beta = 0.7 , / &IONS ion_dynamics = 'damp' , / ATOMIC_SPECIES C 12.01078 C.pz-rrkjus.UPF N 14.00674 N.pz-rrkjus.UPF ATOMIC_POSITIONS alat C 0.000000000 0.000000000 0.000000000 C 0.000000000 0.000000000 0.500000000 C 0.000000000 0.250000000 0.250000000 C 0.000000000 0.250000000 0.750000000 C 0.000000000 0.500000000 0.000000000 C 0.000000000 0.500000000 0.500000000 C 0.000000000 0.750000000 0.250000000 C 0.000000000 0.750000000 0.750000000 C 0.125000000 0.125000000 0.125000000 C 0.125000000 0.125000000 0.625000000 C 0.125000000 0.375000000 0.375000000 C 0.125000000 0.375000000 0.875000000 C 0.125000000 0.625000000 0.125000000 C 0.125000000 0.625000000 0.625000000 C 0.125000000 0.875000000 0.375000000 C 0.125000000 0.875000000 0.875000000 C 0.250000000 0.000000000 0.250000000 C 0.250000000 0.000000000 0.750000000 C 0.250000000 0.250000000 0.000000000 C 0.250000000 0.250000000 0.500000000 C 0.250000000 0.500000000 0.250000000 C 0.250000000 0.500000000 0.750000000 C 0.250000000 0.750000000 0.000000000 C 0.250000000 0.750000000 0.500000000 C 0.375000000 0.125000000 0.375000000 C 0.375000000 0.125000000 0.875000000 C 0.375000000 0.375000000 0.125000000 C 0.375000000 0.375000000 0.625000000 C 0.375000000 0.625000000 0.375000000 C 0.375000000 0.625000000 0.875000000 C 0.375000000 0.875000000 0.125000000 C 0.375000000 0.875000000 0.625000000 C 0.500000000 0.000000000 0.000000000 C 0.500000000 0.000000000 0.500000000 C 0.500000000 0.250000000 0.250000000 C 0.500000000 0.250000000 0.750000000 C 0.500000000 0.500000000 0.000000000 N 0.500000000 0.500000000 0.500000000 C 0.500000000 0.750000000 0.250000000 C 0.500000000 0.750000000 0.750000000 C 0.625000000 0.125000000 0.125000000 C 0.625000000 0.125000000 0.625000000 C 0.625000000 0.375000000 0.375000000 C 0.625000000 0.375000000 0.875000000 C 0.625000000 0.625000000 0.125000000 C 0.625000000 0.625000000 0.625000000 C 0.625000000 0.875000000 0.375000000 C 0.625000000 0.875000000 0.875000000 C 0.750000000 0.000000000 0.250000000 C 0.750000000 0.000000000 0.750000000 C 0.750000000 0.250000000 0.000000000 C 0.750000000 0.250000000 0.500000000 C 0.750000000 0.500000000 0.250000000 C 0.750000000 0.500000000 0.750000000 C 0.750000000 0.750000000 0.000000000 C 0.750000000 0.750000000 0.500000000 C 0.875000000 0.125000000 0.375000000 C 0.875000000 0.125000000 0.875000000 C 0.875000000 0.375000000 0.125000000 C 0.875000000 0.375000000 0.625000000 C 0.875000000 0.625000000 0.375000000 C 0.875000000 0.625000000 0.875000000 C 0.875000000 0.875000000 0.125000000 C 0.875000000 0.875000000 0.625000000 K_POINTS automatic 4 4 4 1 1 1 ----- What is wrong???? Help please. -- Best regards, Sir_Puding mailto:Sir_Puding at tut.by From roma at srmp19.saclay.cea.fr Tue Mar 7 15:53:17 2006 From: roma at srmp19.saclay.cea.fr (Guido Roma) Date: Tue, 07 Mar 2006 15:53:17 +0100 Subject: [Pw_forum] Charge error. In-Reply-To: <715654750.20060307162836@tut.by> References: <715654750.20060307162836@tut.by> Message-ID: <1141743197.5282.30.camel@srmp19.saclay.cea.fr> Dear Sir_Puding, there is something strange in the input/output that you sent: in the input you have ecutwfc=18 and in the output it seems to be 30 ryd. In old versions of PWSCF you couldn't do systems with odd nelec without a broadening. I don't know for recent versions, perhaps by default you have fixed occupations, but, at least for the sake of convergence, it can be useful to put a broadening and more bands. Guido On Tue, 2006-03-07 at 15:28, Sir_Puding wrote: > Hello all, > > I use 3.0 version of the code and want to calculate relaxed ionic > structure for Nitrogen substitute atom in Diamond. > I use cubic cell of 64 atoms and get this error > > ------------------------------------------------------- > > Initial potential from superposition of free atoms > > starting charge 256.99668, renormalised to 257.00000 > Starting wfc are atomic > > total cpu time spent up to now is 225.32 secs > > Self-consistent Calculation > > iteration # 1 ecut= 30.00 ryd beta=0.70 > Davidson diagonalization with overlap > ethr = 1.00E-02, avg # of iterations = 2.0 > > total cpu time spent up to now is 561.73 secs > > WARNING: integrated charge= 256.30000000, expected= 257.00000000 > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > from electrons : error # 1 > charge is wrong > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > stopping ... > > Input is > ---------------------------- > &CONTROL > calculation = 'vc-relax' , > restart_mode = 'from_scratch' , > outdir = '/home/sergey/tmp/' , > pseudo_dir = '/home/sergey/espresso/pseudo/' , > prefix = 'silicon' , > disk_io = 'high' , > verbosity = 'high' , > tstress = .true. , > tprnfor = .true. , > dt = 100.0 , > / > &SYSTEM > ibrav = 1, > celldm(1) = 13.4834, > nat = 64, > ntyp = 2, > ecutwfc = 18 , > nelec = 257, > nspin = 1 , > / > &ELECTRONS > conv_thr = 1.0d-8 , > mixing_mode = 'plain' , > mixing_beta = 0.7 , > / > &IONS > ion_dynamics = 'damp' , > / > ATOMIC_SPECIES > C 12.01078 C.pz-rrkjus.UPF > N 14.00674 N.pz-rrkjus.UPF > ATOMIC_POSITIONS alat > C 0.000000000 0.000000000 0.000000000 > C 0.000000000 0.000000000 0.500000000 > C 0.000000000 0.250000000 0.250000000 > C 0.000000000 0.250000000 0.750000000 > C 0.000000000 0.500000000 0.000000000 > C 0.000000000 0.500000000 0.500000000 > C 0.000000000 0.750000000 0.250000000 > C 0.000000000 0.750000000 0.750000000 > C 0.125000000 0.125000000 0.125000000 > C 0.125000000 0.125000000 0.625000000 > C 0.125000000 0.375000000 0.375000000 > C 0.125000000 0.375000000 0.875000000 > C 0.125000000 0.625000000 0.125000000 > C 0.125000000 0.625000000 0.625000000 > C 0.125000000 0.875000000 0.375000000 > C 0.125000000 0.875000000 0.875000000 > C 0.250000000 0.000000000 0.250000000 > C 0.250000000 0.000000000 0.750000000 > C 0.250000000 0.250000000 0.000000000 > C 0.250000000 0.250000000 0.500000000 > C 0.250000000 0.500000000 0.250000000 > C 0.250000000 0.500000000 0.750000000 > C 0.250000000 0.750000000 0.000000000 > C 0.250000000 0.750000000 0.500000000 > C 0.375000000 0.125000000 0.375000000 > C 0.375000000 0.125000000 0.875000000 > C 0.375000000 0.375000000 0.125000000 > C 0.375000000 0.375000000 0.625000000 > C 0.375000000 0.625000000 0.375000000 > C 0.375000000 0.625000000 0.875000000 > C 0.375000000 0.875000000 0.125000000 > C 0.375000000 0.875000000 0.625000000 > C 0.500000000 0.000000000 0.000000000 > C 0.500000000 0.000000000 0.500000000 > C 0.500000000 0.250000000 0.250000000 > C 0.500000000 0.250000000 0.750000000 > C 0.500000000 0.500000000 0.000000000 > N 0.500000000 0.500000000 0.500000000 > C 0.500000000 0.750000000 0.250000000 > C 0.500000000 0.750000000 0.750000000 > C 0.625000000 0.125000000 0.125000000 > C 0.625000000 0.125000000 0.625000000 > C 0.625000000 0.375000000 0.375000000 > C 0.625000000 0.375000000 0.875000000 > C 0.625000000 0.625000000 0.125000000 > C 0.625000000 0.625000000 0.625000000 > C 0.625000000 0.875000000 0.375000000 > C 0.625000000 0.875000000 0.875000000 > C 0.750000000 0.000000000 0.250000000 > C 0.750000000 0.000000000 0.750000000 > C 0.750000000 0.250000000 0.000000000 > C 0.750000000 0.250000000 0.500000000 > C 0.750000000 0.500000000 0.250000000 > C 0.750000000 0.500000000 0.750000000 > C 0.750000000 0.750000000 0.000000000 > C 0.750000000 0.750000000 0.500000000 > C 0.875000000 0.125000000 0.375000000 > C 0.875000000 0.125000000 0.875000000 > C 0.875000000 0.375000000 0.125000000 > C 0.875000000 0.375000000 0.625000000 > C 0.875000000 0.625000000 0.375000000 > C 0.875000000 0.625000000 0.875000000 > C 0.875000000 0.875000000 0.125000000 > C 0.875000000 0.875000000 0.625000000 > K_POINTS automatic > 4 4 4 1 1 1 > > > > > > ----- > What is wrong???? Help please. > > > > > -- Guido Roma -- CEA-Saclay - DEN/DMN/SRMP Bat.520/130 Phone: [+33]-1-69085738 -- Fax: ...6867 -- Mobile: [+33]-6-20069085 From ejl7240 at chemail.tamu.edu Wed Mar 8 04:18:20 2006 From: ejl7240 at chemail.tamu.edu (Eduardo J. Lamas) Date: Tue, 7 Mar 2006 21:18:20 -0600 Subject: [Pw_forum] Problem calculating localized density of states in a slab Message-ID: <000501c6425e$f3528b70$0ee35ba5@ch0316> Hi, I want to calculate the localized density of states in a transition metal surface. My problem is that projwfc.x seems to fail no matter what I try. It gives nonsense charges and an spilling parameter of 0.91 or nan. It also fails for bigger unit cells (than the one I am posting bellow as an example), changing the kpoint sampling or the fft grid, the cut offs, number of bands, the pseudopotential and the smearing scheme or parameter doesn't helps. In the bulk solid case using the same PP as in the slab (with only one atom in the unit cell) it will work well and more or less independently of the above mentioned parameters. Even if the electronic structure in the bulk and slab cases are different. Can that account for the observed differences in the spilling parameter ? (from spilling 0.0022 in the solid case to 0.9 in the best case for the slab) Can somebody give me any advice about how to solve this? Thanks, Eduardo P.S.: I tried this on espresso 3.0 and 2.1.3 both compiled with portland fortran 5.1 on opteron quads I also tried it on an expresso compilled with intel compiler. The input file for pw.x is: &CONTROL title='Pt3 (111) surface', calculation='scf', restart_mode='from_scratch', dt=10., nstep=200000, tprnfor=.true., pseudo_dir='/home/lamas/espresso/pseudo/', outdir='./tmp/', max_seconds=90000, / &SYSTEM ibrav = 14, celldm(1)= 5.2950, celldm(2)= 1, celldm(3)= 5, celldm(4)= 0, celldm(5)= 0, celldm(6)= -0.5, nat = 3, ntyp = 1, ecutwfc =50.0, ecutrho =500, occupations='smearing', degauss=0.0025, smearing='mv', nspin=2, starting_magnetization=0.0 / &ELECTRONS mixing_beta = 0.1, conv_thr = 1.0d-8 / &IONS ion_dynamics='bfgs', / ATOMIC_SPECIES Pt 195.1 Pt_PBE_v1.vdb ATOMIC_POSITIONS {angstrom} Pt 0.000000000000 0.000000000000 0.000000000000 Pt 0.000000000000 1.617735454269 2.287833000000 Pt 1.401000000000 0.808867727135 4.575666000000 K_POINTS {automatic} 7 7 1 0 0 0 And the input for projwfc.x is : &inputpp outdir='./tmp/' prefix='pwscf' Emin=-5.0, Emax=10.0, DeltaE=0.01 ngauss=-1, degauss=0.0025 / From giannozz at nest.sns.it Wed Mar 8 11:36:00 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 8 Mar 2006 11:36:00 +0100 Subject: [Pw_forum] memory allocation failed In-Reply-To: <1141640608.440c0da091e72@webmail.unisa.it> References: <1141640608.440c0da091e72@webmail.unisa.it> Message-ID: <200603081136.00867.giannozz@nest.sns.it> On Monday 06 March 2006 11:23, gmonaco at unisa.it wrote: > I have tried several times to make phonon calculations on a large cell > While the program terminated using some pseudopotentials, upon a > change of basis a memory allocation error was obtained [..] > The working pseudopotentials are: > C 12.00 C.blyp-mt.UPF > H 1.00 H.blyp-vbc.UPF these are norm-conserving ... > The problematic pseudopotentials are: > C 12.00 C.pz-rrkjus.UPF > H 1.00 H.pz-rrkjus.UPF and these are ultrasoft PP's. In the latter case the phonon code requires more memory and it is not really optimized for large cells. In the case of C and H, you do not gain much anyway from USPP in a phonon calculation. You gain if you have transition metals, typically, but if you want to perform phonon calculations in large cells, you have to work on the code to make it less memory-hungry, I think. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Wed Mar 8 11:45:53 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 8 Mar 2006 11:45:53 +0100 Subject: [Pw_forum] memory allocation failed In-Reply-To: <1141640608.440c0da091e72@webmail.unisa.it> References: <1141640608.440c0da091e72@webmail.unisa.it> Message-ID: <200603081145.53830.giannozz@nest.sns.it> On Monday 06 March 2006 11:23, gmonaco at unisa.it wrote: > At line 172 of file add_for_charges.F90 [...] > Operating system error: Cannot allocate memory ...of course the presence in PH/add_for_charges.f90 of a line allocate (aux1( npwx, npwx)) instead of the correct one, that is: allocate (aux1( npwx, nbnd)) doesn't help: the number of plane waves (npwx) is much larger than the number of states (nbnd) ... P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Wed Mar 8 15:57:55 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 8 Mar 2006 15:57:55 +0100 Subject: [Pw_forum] Problem calculating localized density of states in a slab In-Reply-To: <000501c6425e$f3528b70$0ee35ba5@ch0316> References: <000501c6425e$f3528b70$0ee35ba5@ch0316> Message-ID: <200603081557.55142.giannozz@nest.sns.it> On Wednesday 08 March 2006 04:18, Eduardo J. Lamas wrote: > My problem is that projwfc.x seems to fail no matter what I try [...] > P.S.: I tried this on espresso 3.0 and 2.1.3 both compiled with > portland fortran 5.1 on opteron quads > I also tried it on an espresso compiled with intel compiler. portland is completely unreliable. I tried your data with a PP from www.pwscf.org on my PC (intel compiler) and the results look reasonable at a first glance. I used both versions 3.0 and the development version: http://web1.sns.it/~giannozz/public/projwfc.tar.gz Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Wed Mar 8 16:18:06 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 8 Mar 2006 16:18:06 +0100 Subject: [Pw_forum] Energy convergence in Cobalt In-Reply-To: References: Message-ID: <200603081618.06715.giannozz@nest.sns.it> On Friday 03 March 2006 16:01, Conor Hogan wrote: > I noted that the total energy does not decrease if the kinetic energy > cut-off is increased, which is not what I expected (in fact it increases!) I think this was already discussed in the forum, but I cannot find the reference. With ultrasoft PPs you are not guaranteed that the energy decreases with increasing cutoff, because the augmentation charge density is not exact but truncated (to cutoff "ecutrho") 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 sir_puding at tut.by Thu Mar 9 15:52:30 2006 From: sir_puding at tut.by (sir_puding at tut.by) Date: Thu, 9 Mar 2006 16:52:30 +0200 Subject: [Pw_forum] Crystallographic question. Message-ID: <241071702.20060309165230@tut.by> Hi, All Maybe my question is simple to answer, but I'm little confused with it. I want to calculate dispersion curves for an electron energy in diamond. So we have the FCC lattice with two atoms as the primitive basis. On the other hand this lattice is equivalent to the Simple Cubic lattice with 8 atoms as the primitive basis. (Let assume that we have a periodical defect such as very very tiny displacement of one of 8 atoms). The crystals are almost identical, but BZ are different. In the case of SP lattice BZ would be cubic with different volume than in the case of FCC. How one can transform one type of BZ to another when we place displaced atom at the right place in SC lattice. How do i need to sample this two BZs tio obtain equivalent dispersion curves? Thanx. Sergey/ -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From matteoc at MIT.EDU Thu Mar 9 22:00:26 2006 From: matteoc at MIT.EDU (Matteo Cococcioni) Date: Thu, 9 Mar 2006 16:00:26 -0500 (EST) Subject: [Pw_forum] Calculating Hubbard U In-Reply-To: <20060303181922.GA18121@physik.fu-berlin.de> References: <20060302110816.GA20079@physik.fu-berlin.de> <20060303174232.GA16548@physik.fu-berlin.de> <20060303181922.GA18121@physik.fu-berlin.de> Message-ID: Dear Henning I made some tests with your inputfiles and realized that the problem is due to the fact that a file.save (a restart file) is left in tmpdir by the scf run and is read by the code when you start your run with alpha =/= 0. Just try to remove it or rename it and you should get things working. It seems to me also that this problem has disappeared in most recent versions of the code (cvs) but I didn't do extensive tests on this. Hope this helps. Matteo On Fri, 3 Mar 2006, Henning Glawe wrote: > On Fri, Mar 03, 2006 at 12:51:37PM -0500, Matteo Cococcioni wrote: >>> but re-running with a changed hubbard_alpha($atom) seems to have no effect, >>> though setting hubbard_alpha(1)=0.1 in the input, pw.x keeps running with >>> alpha=0 (at least this is what it writes on STDOUT). Does pw.x read this >>> from >>> the files in 'outdir' ? >> >> Dear Henning, >> >> make sure your restart_mode is set to "from_scratch" even when you restart >> with a finite value of Hubbard_alpha. Otherwise (I think) the code reads >> the restart file and doesn't realize that you have changed Hubbard_alpha. >> >> let us know how it goes. > > restart_mode was set to 'from_scratch'; pw.x seems to get the > hubbard_alpha(1)=0 anyways... > > -- > c u > henning > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From emenendez at macul.ciencias.uchile.cl Fri Mar 10 13:29:38 2006 From: emenendez at macul.ciencias.uchile.cl (Eduardo Ariel Menendez P) Date: Fri, 10 Mar 2006 09:29:38 -0300 (CLST) Subject: [Pw_forum] Re: Crystallographic question. (sir_puding@tut.by) In-Reply-To: <20060310063705.12818.89246.Mailman@democritos.sissa.it> References: <20060310063705.12818.89246.Mailman@democritos.sissa.it> Message-ID: Hi, One way would be use the Brillouin zone of the 8-atoms cell for both cases. This is straightforward, but it may be not very pretty. The 8-atomos Brilloiun cell has the same information as the 2 atoms cell, it has 1/4 of the volume, and 4 times the number of bands. Other way would to represent the bands in the extended zone scheme (see Ashcroft and Mermin). This is straightforward in a 1-dimensional case (just adding 2N pi/a to the k-vector of the Nth-band). In the cubic cell, you can just plot the dispersion law for the x,y, or z direction, and to each Nth band add 2NPi/a to the wave vector, where a is the cubic lattice constant. Then you will have only one band that is discontinuous at the borders of the Brillouin zones. If the structure has additional peridiocity, such as the perfect lattice diamond, some discontinuities will vanish. I do not know hoy to do it in a general direction. I would be interested if you find an algorithm like that. Other straightforward possiblity is to forget the bands, and only compare the density of states. Eduardo > > Hi, All > > Maybe my question is simple to answer, but I'm little confused with it. > > I want to calculate dispersion curves for an electron energy in diamond. > > So we have the FCC lattice with two atoms as the primitive basis. On > the other hand this lattice is equivalent to the Simple Cubic lattice with 8 > atoms as the primitive basis. (Let assume that we have a periodical defect > such as very very tiny displacement of one of 8 atoms). > > The crystals are almost identical, but BZ are different. In the case > of SP lattice BZ would be cubic with different volume than in the case > of FCC. How one can transform one type of BZ to another when we place > displaced atom at the right place in SC lattice. How do i need to > sample this two BZs tio obtain equivalent dispersion curves? > > Thanx. > > Sergey/ > From sir_puding at tut.by Fri Mar 10 15:33:22 2006 From: sir_puding at tut.by (sir_puding at tut.by) Date: Fri, 10 Mar 2006 16:33:22 +0200 Subject: [Pw_forum] Crystallographic question. In-Reply-To: References: <20060310063705.12818.89246.Mailman@democritos.sissa.it> Message-ID: <135101813.20060310163322@tut.by> > Hi, > One way would be use the Brillouin zone of the 8-atoms cell for both > cases. This is straightforward, but it may be not very pretty. The > 8-atomos Brilloiun cell has the same information as the 2 atoms cell, it has 1/4 of > the volume, and 4 times the number of bands. Thanks, Eduardo. Your suggestions were very helpful. I think I've found the answer. I have plotted the BZs for SP and FCC real lattices with the same lattice constant and took the difference. If we "sum up" first and second BZs for FCC lattice we get the SC lattice BZ. So in the case of perfect Diamond, SC lattice with 8 atom basis contains twice more k-points than in FCC 2 atoms case. But the half of them are the same as for FCC lattice first BZ. THNX. Sergey. From glaweh at physik.fu-berlin.de Fri Mar 10 15:57:11 2006 From: glaweh at physik.fu-berlin.de (Henning Glawe) Date: Fri, 10 Mar 2006 15:57:11 +0100 Subject: [Pw_forum] Calculating Hubbard U In-Reply-To: References: <20060302110816.GA20079@physik.fu-berlin.de> <20060303174232.GA16548@physik.fu-berlin.de> <20060303181922.GA18121@physik.fu-berlin.de> Message-ID: <20060310145711.GB30546@physik.fu-berlin.de> On Thu, Mar 09, 2006 at 04:00:26PM -0500, Matteo Cococcioni wrote: > I made some tests with your inputfiles and realized that the problem is > due to the fact that a file.save (a restart file) is left in tmpdir by > the scf run and is read by the code when you start your run with alpha =/= > 0. Well, it seems like the starting wave functions are read from this file, so after removing file.save the code started from atomic wave functions _and_ potential (?). I thought the wave functions should be read from the file.wfc{1,2,3,4} (as I've been running the scf on one machine with 4 processors), and the potential from file.pot. I'm currently re-running the scf on 1 processor to see if this problem is related to the parallel run. > Just try to remove it or rename it and you should get things working. > It seems to me also that this problem has disappeared in most recent > versions of the code (cvs) but I didn't do extensive tests on this. > Hope this helps. so maybe I'll try the cvs version. -- c u henning From sir_puding at tut.by Fri Mar 10 16:06:52 2006 From: sir_puding at tut.by (sir_puding at tut.by) Date: Fri, 10 Mar 2006 17:06:52 +0200 Subject: [Pw_forum] Restart error. Message-ID: <93938399.20060310170652@tut.by> Hi all. Please help me to setup VC-minimization which can be restarted (Or tell me where can i read about it). When I try to restart my calculation the next error occurs: ----------- > Program PWSCF v.3.0 starts ... > Today is 10Mar2006 at 14:24:49 > > Ultrasoft (Vanderbilt) Pseudopotentials > > Current dimensions of program pwscf are: > > ntypx = 10 npk = 40000 lmax = 3 > nchix = 6 ndmx = 2000 nbrx = 14 nqfx = 8 > > Starting configuration read from file diaN8atom.save > > Reading file diaN8atom.save > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > from checkallsym : error # 1 > not orthogonal operation > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > stopping ... ---------- My first run input is : ---------- > &CONTROL > title = 'diamond and nitrogen' , > calculation = 'vc-relax' , > restart_mode = 'from_scratch' , > outdir = '/home/sergey/tmp/' , > wfcdir = '/home/sergey/tmp/cpu/' , > pseudo_dir = '/home/sergey/espresso/pseudo/' , > prefix = 'diaN8atom' , > disk_io = 'default' , > verbosity = 'high' , > etot_conv_thr = 1.D-4 , > forc_conv_thr = 1.D-3 , > nstep = 5 , > tstress = .true. , > tprnfor = .true. , > dt = 100 , > / > &SYSTEM > ibrav = 0, > celldm(1) = 6.74, > nat = 8, > ntyp = 2, > ecutwfc = 18 , > ecutrho = 80 , > nosym = .true. , > nbnd = 45, > nelec = 33, > occupations = 'tetrahedra' , > nspin = 1 , > lda_plus_u = .false. , > / > &ELECTRONS > conv_thr = 1.D-6 , > startingpot = 'atomic' , > startingwfc = 'atomic' , > diagonalization = 'david' , > / > &IONS > / > &CELL > cell_dynamics = 'damp-pr' , > / >CELL_PARAMETERS cubic > 1.000000000 0.000000000 0.000000000 > 0.000000000 1.000000000 0.000000000 > 0.000000000 0.000000000 1.000000000 >ATOMIC_SPECIES > C 12.01070 C.pbe-rrkjus.UPF > N 14.00674 N.pbe-rrkjus.UPF >ATOMIC_POSITIONS alat > C 0.000000000 0.000000000 0.000000000 > C 0.500000000 0.500000000 0.000000000 > C 0.500000000 0.000000000 0.500000000 > C 0.000000000 0.500000000 0.500000000 > N 0.250000000 0.250000000 0.250000000 > C 0.750000000 0.750000000 0.250000000 > C 0.750000000 0.250000000 0.750000000 > C 0.250000000 0.750000000 0.750000000 >K_POINTS automatic > 4 4 4 1 1 1 ---------- In the second run I've changed only this: ---------- &CONTROL restart_mode = 'restart' , nstep = 10 , / &ELECTRONS startingpot = 'file' , startingwfc = 'file' , / ---------- Thnx. Sergey. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From giannozz at nest.sns.it Fri Mar 10 16:27:21 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 10 Mar 2006 16:27:21 +0100 Subject: [Pw_forum] Restart error. In-Reply-To: <93938399.20060310170652@tut.by> References: <93938399.20060310170652@tut.by> Message-ID: <200603101627.21778.giannozz@nest.sns.it> On Friday 10 March 2006 16:06, sir_puding at tut.by wrote: > Please help me to setup VC-minimization which can be restarted > (Or tell me where can i read about it). > When I try to restart my calculation the next error occurs: > from checkallsym : error # 1 > not orthogonal operation it is a known bug. It is fixed in the CVS version, but only if the old file format is used (option -D __OLDPUNCH in preprocessing); with the new file format there is another problem that prevents restarting from a variable-cell calculation. 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 glaweh at physik.fu-berlin.de Fri Mar 10 16:49:15 2006 From: glaweh at physik.fu-berlin.de (Henning Glawe) Date: Fri, 10 Mar 2006 16:49:15 +0100 Subject: [Pw_forum] starting occupation for lda+u in case of a full d shell Message-ID: <20060310154915.GC30546@physik.fu-berlin.de> Moin, I'm currently trying to reproduce the antiferromagnetic insulating solution for CaCuO_2, using the lda+u method. Though I am still fighting with the determination of the U, I have spent some thoughts on the 'actual' LDA+U calculation, always having the example25 in mind. Imagine I converged to a nm metallic solution, how could I ever be able to change the starting occupations: Cu has got 3d^10 4s^1 valence, with the d state being the localized one treated in LDA+U. As the d state is full and non-magnetic in the starting, atomic configuration, how could one ever change its occupation for majority/minority spin component to start from another configuration? -- c u henning From mousumi at jncasr.ac.in Fri Mar 10 19:44:05 2006 From: mousumi at jncasr.ac.in (Mousumi Upadhyay Kahaly) Date: Sat, 11 Mar 2006 00:14:05 +0530 (IST) Subject: [Pw_forum] parallel scf run Message-ID: <39451.202.41.111.151.1142016245.squirrel@202.41.111.151> Dear All, I'm running some scf calculation using parallel version of PWSCF 2.0.5. I want to go for postprocessing after the scf calculation, using the wavefunction , rho etc files. But in parallel run, at each node separately some wavefunctions etc files are being created. How do I assemble the files (that are in one tmp directory in serial run) for postprocessing?? Please help. Thanks, mousumi. From glaweh at physik.fu-berlin.de Sat Mar 11 06:49:29 2006 From: glaweh at physik.fu-berlin.de (Henning Glawe) Date: Sat, 11 Mar 2006 06:49:29 +0100 Subject: [Pw_forum] parallel scf run In-Reply-To: <39451.202.41.111.151.1142016245.squirrel@202.41.111.151> References: <39451.202.41.111.151.1142016245.squirrel@202.41.111.151> Message-ID: <20060311054929.GA19075@ruprecht.simpsons.bogus> On Sat, Mar 11, 2006 at 12:14:05AM +0530, Mousumi Upadhyay Kahaly wrote: > I'm running some scf calculation using parallel version of PWSCF > 2.0.5. I want to go for postprocessing after the scf calculation, > using the wavefunction , rho etc files. But in parallel run, at > each node separately some wavefunctions etc files are being > created. How do I assemble the files (that are in one tmp directory > in serial run) for postprocessing?? try running the job with wf_collect in &control -- c u henning From ejl7240 at chemail.tamu.edu Mon Mar 13 16:00:25 2006 From: ejl7240 at chemail.tamu.edu (Eduardo J. Lamas) Date: Mon, 13 Mar 2006 09:00:25 -0600 Subject: [Pw_forum] Problem calculating localized density of states in a slab In-Reply-To: <200603081557.55142.giannozz@nest.sns.it> Message-ID: <000001c646ae$dc476c80$0ee35ba5@ch0316> Hi thanks for helping me. It worked only with the development version for me and only using the rrkj pseudos. I am wondering if there is any problem with vdb pseudos. With the PW vdb pseudo from Vanderbilt's library it will directly crash. (I tried other elements with vdb PP and it they will also crash projwfc.x) Input output and PP file can be obtained from: http://people.tamu.edu/~elamas/projProblem.htm Is there anyway to get projwfc.x working with vdb PP ? Thanks again, Eduardo PS. all new tests are with intel fortran 9.0 with mkl math libraries and I turned off all the optimization flags. Compiler flags: CC = icc MPICC = icc CFLAGS = -O0 $(DFLAGS) $(IFLAGS) CPP = icc -E CPPFLAGS = $(DFLAGS) $(IFLAGS) F90 = ifort MPIF90 = /usr/rels/mpich-1.2.5.intel/bin/mpif90 F90FLAGS = $(FFLAGS) -nomodule -fpp $(FDFLAGS) $(IFLAGS) $(MODFLAGS) F90FLAGS_NOOPT = $(FFLAGS_NOOPT) -nomodule -fpp $(FDFLAGS) $(IFLAGS) $(MODFLAGS) F77 = ifort MPIF77 = /usr/rels/mpich-1.2.5.intel/bin/mpif77 FFLAGS = -O0 -assume byterecl FFLAGS_NOOPT = -O0 -assume byterecl LD = /usr/rels/mpich-1.2.5.intel/bin/mpif90 LDFLAGS = AR = ar ARFLAGS = ruv RANLIB = echo BLAS_LIBS = -L/opt/intel/mkl/8.0.1/lib/em64t -lmkl_em64t -lguide -lpthread LAPACK_LIBS = -lmkl_lapack FFT_LIBS = MPI_LIBS = MASS_LIBS = # ----------------------------- # application-specific settings # See include/defs.h.README for a list of precompilation options # (possible arguments to -D or -U) and their meaning DFLAGS = -D__LINUX64 -D__INTEL -D__MPI -D__PARA -D__FFTW -D__USE_INTERNAL_FFTW -----Original Message----- From: pw_forum-admin at pwscf.org [mailto:pw_forum-admin at pwscf.org] On Behalf Of Paolo Giannozzi Sent: Wednesday, March 08, 2006 8:58 AM To: pw_forum at pwscf.org Subject: Re: [Pw_forum] Problem calculating localized density of states in a slab On Wednesday 08 March 2006 04:18, Eduardo J. Lamas wrote: > My problem is that projwfc.x seems to fail no matter what I try [...] > P.S.: I tried this on espresso 3.0 and 2.1.3 both compiled with > portland fortran 5.1 on opteron quads I also tried it on an espresso > compiled with intel compiler. portland is completely unreliable. I tried your data with a PP from www.pwscf.org on my PC (intel compiler) and the results look reasonable at a first glance. I used both versions 3.0 and the development version: http://web1.sns.it/~giannozz/public/projwfc.tar.gz 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 From mpayami at aeoi.org.ir Mon Mar 13 17:37:04 2006 From: mpayami at aeoi.org.ir (Mahmoud Payami) Date: Mon, 13 Mar 2006 21:07:04 +0430 Subject: [Pw_forum] Compiling errors Message-ID: <000d01c646bc$5c4f1380$6e6910ac@mahmoudctpm> Dear PW users, I have problem in compiling espresso-3.0. These errors were absent in old versions. Could anybody give some hints. Best regards, mahmoud ------------------------------------------------------------------------------------------------------------------------------------------------------- mpif90 -Vaxlib -O2 -tpp6 -nomodule -fpp -D__LINUX -D__INTEL -D__FFTW -D__USE_INTERNAL_FFTW -D__MPI -D__PARA -I../include -I. -I../Modules -I../PW -I../PH -I../iotk/src -c para.f90 module PARA_CONST module PFFT module PFFTS external subroutine REDUCE Error 355 : In program unit REDUCE variable MPI_REAL8 has not been given a type external subroutine IREDUCE external subroutine POOLREDUCE Error 355 : In program unit POOLREDUCE variable MPI_REAL8 has not been given a type external subroutine GATHER Error 355 : In program unit GATHER variable MPI_REAL8 has not been given a type external subroutine CGATHER_SYM Error 355 : In program unit CGATHER_SYM variable MPI_REAL8 has not been given a type external subroutine SCATTER Error 355 : In program unit SCATTER variable MPI_REAL8 has not been given a type external subroutine POOLSCATTER external subroutine FFT_SCATTER1 Error 355 : In program unit FFT_SCATTER1 variable MPI_REAL8 has not been given a type external subroutine POOLEXTREME Error 355 : In program unit POOLEXTREME variable MPI_REAL8 has not been given a type external subroutine POOLRECOVER Error 355 : In program unit POOLRECOVER variable MPI_REAL8 has not been given a type external subroutine IPOOLRECOVER external subroutine EXTREME Error 355 : In program unit EXTREME variable MPI_REAL8 has not been given a type 9 Errors compilation aborted for para.f90 (code 1) make[1]: *** [para.o] Error 1 make[1]: Leaving directory `/home/SHARED_FOLDER/espresso-3.0/PW' make: *** [pw] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060313/74c5e2e1/attachment.htm From glaweh at physik.fu-berlin.de Mon Mar 13 17:50:28 2006 From: glaweh at physik.fu-berlin.de (Henning Glawe) Date: Mon, 13 Mar 2006 17:50:28 +0100 Subject: [Pw_forum] Calculating Hubbard U In-Reply-To: <20060310145711.GB30546@physik.fu-berlin.de> References: <20060302110816.GA20079@physik.fu-berlin.de> <20060303174232.GA16548@physik.fu-berlin.de> <20060303181922.GA18121@physik.fu-berlin.de> <20060310145711.GB30546@physik.fu-berlin.de> Message-ID: <20060313165028.GA6987@physik.fu-berlin.de> On Fri, Mar 10, 2006 at 03:57:11PM +0100, Henning Glawe wrote: > On Thu, Mar 09, 2006 at 04:00:26PM -0500, Matteo Cococcioni wrote: > > I made some tests with your inputfiles and realized that the problem is > > due to the fact that a file.save (a restart file) is left in tmpdir by > > the scf run and is read by the code when you start your run with alpha =/= > > 0. > > Well, it seems like the starting wave functions are read from this file, so > after removing file.save the code started from atomic wave functions _and_ > potential (?). > I thought the wave functions should be read from the file.wfc{1,2,3,4} (as > I've been running the scf on one machine with 4 processors), and the potential > from file.pot. > I'm currently re-running the scf on 1 processor to see if this problem is > related to the parallel run. that didn't help. seems like the file.save is the one where the wf are stored... so I'll investigate the situation with the cvs version... -- c u henning From wmbmacam at lg.ehu.es Mon Mar 13 17:55:17 2006 From: wmbmacam at lg.ehu.es (=?ISO-8859-1?Q?Miguel_Mart=EDnez_Canales?=) Date: Mon, 13 Mar 2006 17:55:17 +0100 Subject: [Pw_forum] Compiling errors In-Reply-To: <000d01c646bc$5c4f1380$6e6910ac@mahmoudctpm> References: <000d01c646bc$5c4f1380$6e6910ac@mahmoudctpm> Message-ID: <4415A3F5.5070405@lg.ehu.es> Mahmoud Payami escribi?: > Dear PW users, > > I have problem in compiling espresso-3.0. These errors were absent in > old versions. Could anybody give some hints. > Best regards, > mahmoud > Just a quick note, mahmoud. If you are using Intel compiler version 9, it is known to fail. There is some info in the users' guide on some tricks that might help you (where might is the key word) -- ---------------------------------------- Miguel Mart?nez Canales Dto. F?sica de la Materia Condensada UPV/EHU Facultad de Ciencia y Tecnolog?a Apdo. 644 48080 Bilbao (Spain) Fax: +34 94 601 3500 Tlf: +34 94 601 5437 ---------------------------------------- "If you're a mad scientist, you can use GPLv2'd software for your evil plans to take over the world" Linus Torvalds From giannozz at nest.sns.it Mon Mar 13 18:00:04 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 13 Mar 2006 18:00:04 +0100 Subject: [Pw_forum] Calculating Hubbard U In-Reply-To: <20060313165028.GA6987@physik.fu-berlin.de> References: <20060302110816.GA20079@physik.fu-berlin.de> <20060310145711.GB30546@physik.fu-berlin.de> <20060313165028.GA6987@physik.fu-berlin.de> Message-ID: <200603131800.04408.giannozz@nest.sns.it> On Monday 13 March 2006 17:50, Henning Glawe wrote: > that didn't help. seems like the file.save is the one where the wf are > stored... > > so I'll investigate the situation with the cvs version... please wait a few more hours before investigating the cvs version... we are just fixing a few things related to how wavefunctions are read 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 glaweh at physik.fu-berlin.de Mon Mar 13 18:16:28 2006 From: glaweh at physik.fu-berlin.de (Henning Glawe) Date: Mon, 13 Mar 2006 18:16:28 +0100 Subject: [Pw_forum] Calculating Hubbard U In-Reply-To: <200603131800.04408.giannozz@nest.sns.it> References: <20060302110816.GA20079@physik.fu-berlin.de> <20060310145711.GB30546@physik.fu-berlin.de> <20060313165028.GA6987@physik.fu-berlin.de> <200603131800.04408.giannozz@nest.sns.it> Message-ID: <20060313171628.GB6987@physik.fu-berlin.de> On Mon, Mar 13, 2006 at 06:00:04PM +0100, Paolo Giannozzi wrote: > On Monday 13 March 2006 17:50, Henning Glawe wrote: > > > that didn't help. seems like the file.save is the one where the wf are > > stored... > > > > so I'll investigate the situation with the cvs version... > > please wait a few more hours before investigating the cvs version... > we are just fixing a few things related to how wavefunctions are read ok, thanks. -- c u henning From akohlmey at vitae.cmm.upenn.edu Tue Mar 14 01:30:51 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Mon, 13 Mar 2006 19:30:51 -0500 (EST) Subject: [Pw_forum] Compiling errors In-Reply-To: <000d01c646bc$5c4f1380$6e6910ac@mahmoudctpm> Message-ID: On Mon, 13 Mar 2006, Mahmoud Payami wrote: MP> Dear PW users, MP> MP> I have problem in compiling espresso-3.0. These errors were absent MP> in old versions. Could anybody give some hints. mahmoud, my guess is that you are compiling with LAM/MPI but did not set -D__LAM in the DFLAGS line in make.sys regards, axel. MP> Best regards, MP> mahmoud MP> MP> ------------------------------------------------------------------------------------------------------------------------------------------------------- MP> mpif90 -Vaxlib -O2 -tpp6 -nomodule -fpp -D__LINUX -D__INTEL -D__FFTW -D__USE_INTERNAL_FFTW -D__MPI -D__PARA -I../include -I. -I../Modules -I../PW -I../PH -I../iotk/src -c para.f90 MP> module PARA_CONST MP> module PFFT MP> module PFFTS MP> external subroutine REDUCE MP> Error 355 : In program unit REDUCE variable MPI_REAL8 has not been given a type MP> external subroutine IREDUCE MP> external subroutine POOLREDUCE MP> Error 355 : In program unit POOLREDUCE variable MPI_REAL8 has not been given a type MP> external subroutine GATHER MP> Error 355 : In program unit GATHER variable MPI_REAL8 has not been given a type MP> external subroutine CGATHER_SYM MP> Error 355 : In program unit CGATHER_SYM variable MPI_REAL8 has not been given a type MP> external subroutine SCATTER MP> Error 355 : In program unit SCATTER variable MPI_REAL8 has not been given a type MP> external subroutine POOLSCATTER MP> external subroutine FFT_SCATTER1 MP> Error 355 : In program unit FFT_SCATTER1 variable MPI_REAL8 has not been given a type MP> external subroutine POOLEXTREME MP> Error 355 : In program unit POOLEXTREME variable MPI_REAL8 has not been given a type MP> external subroutine POOLRECOVER MP> Error 355 : In program unit POOLRECOVER variable MPI_REAL8 has not been given a type MP> external subroutine IPOOLRECOVER MP> external subroutine EXTREME MP> Error 355 : In program unit EXTREME variable MPI_REAL8 has not been given a type MP> MP> 9 Errors MP> compilation aborted for para.f90 (code 1) MP> make[1]: *** [para.o] Error 1 MP> make[1]: Leaving directory `/home/SHARED_FOLDER/espresso-3.0/PW' MP> make: *** [pw] Error 2 MP> MP> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From giannozz at nest.sns.it Tue Mar 14 13:50:32 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 14 Mar 2006 13:50:32 +0100 Subject: [Pw_forum] Problem calculating localized density of states in a slab In-Reply-To: <000001c646ae$dc476c80$0ee35ba5@ch0316> References: <000001c646ae$dc476c80$0ee35ba5@ch0316> Message-ID: <200603141350.32607.giannozz@nest.sns.it> On Monday 13 March 2006 16:00, Eduardo J. Lamas wrote: > I am wondering if there is any problem with vdb pseudos. > With the PW vdb pseudo from Vanderbilt's library it will > directly crash. (I tried other elements with vdb PP and it > they will also crash projwfc.x) there was actually a problem in the development version with PPs in the Vanderbilt format (a variable was not correctly set when re-reading the files). Now it is fixed. Thank you for providing tests. I can run your test serially on a PC or on 1,2,4 processors of a sp5 machine and it works. Also the stable version (3.0) works for me on a PC, though. 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 ashelton at albany.edu Wed Mar 15 21:18:03 2006 From: ashelton at albany.edu (Anne P Shelton) Date: Wed, 15 Mar 2006 15:18:03 -0500 Subject: [Pw_forum] ld: cannot find -lfftw Message-ID: <9D95C2906FCCE04F836ECA17C4CE09210268C482@UAEXCH.univ.albany.edu> I am trying to install espresso-3.0 on an Intel server running Linux. It seems to configure fine and find the necessary library but then I get this error after I make all ld: skipping incompatible /usr/lib/libfftw.a when searching for -lfftw ld: cannot find -lfftw make[1]: *** [memory.x] Error 1 I have installed the fftw 2.1.5 package. Any ideas. Thanks From stewart at cnf.cornell.edu Wed Mar 15 21:22:59 2006 From: stewart at cnf.cornell.edu (stewart at cnf.cornell.edu) Date: Wed, 15 Mar 2006 15:22:59 -0500 Subject: [Pw_forum] Re: ld: cannot find -lfftw In-Reply-To: <9D95C2906FCCE04F836ECA17C4CE09210268C482@UAEXCH.univ.albany.edu> References: <9D95C2906FCCE04F836ECA17C4CE09210268C482@UAEXCH.univ.albany.edu> Message-ID: <20060315202259.17582.qmail@xuxa.iecc.com> Hi Anne, Which compiler are you using for the installation? If you are using the intel compilers then it usually complains when linking to libraries that are compiled with gnu compilers (gcc, g77). One option would be to recompile fftw with the intel compilers and link to that version of fftw. Hopefully, this will take care of your problem. Regards, Derek Anne P Shelton writes: > I am trying to install espresso-3.0 on an Intel server running Linux. > It seems to configure fine and find the necessary library but then I get > this error after I make all > > ld: skipping incompatible /usr/lib/libfftw.a when searching for -lfftw > ld: cannot find -lfftw > make[1]: *** [memory.x] Error 1 > > I have installed the fftw 2.1.5 package. > > Any ideas. > > Thanks > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum ################################ Derek Stewart, Ph. D. Scientific Computation Associate 250 Duffield Hall Cornell Nanoscale Facility (CNF) Ithaca, NY 14853 stewart (at) cnf.cornell.edu (607) 255-2856 From akohlmey at vitae.cmm.upenn.edu Wed Mar 15 21:56:12 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Wed, 15 Mar 2006 15:56:12 -0500 (EST) Subject: [Pw_forum] ld: cannot find -lfftw In-Reply-To: <9D95C2906FCCE04F836ECA17C4CE09210268C482@UAEXCH.univ.albany.edu> Message-ID: On Wed, 15 Mar 2006, Anne P Shelton wrote: AS> I am trying to install espresso-3.0 on an Intel server running Linux. AS> It seems to configure fine and find the necessary library but then I get AS> this error after I make all AS> AS> ld: skipping incompatible /usr/lib/libfftw.a when searching for -lfftw AS> ld: cannot find -lfftw AS> make[1]: *** [memory.x] Error 1 hi, this looks like you are running on an opteron or EM64t machine. check if you have a /usr/lib64/ directory. AS> I have installed the fftw 2.1.5 package. if my assumption is correct, you have to make sure, you have installed the 64-bit version. regards, axel. AS> AS> Any ideas. AS> AS> Thanks AS> _______________________________________________ AS> Pw_forum mailing list AS> Pw_forum at pwscf.org AS> http://www.democritos.it/mailman/listinfo/pw_forum AS> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From akohlmey at vitae.cmm.upenn.edu Wed Mar 15 21:57:49 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Wed, 15 Mar 2006 15:57:49 -0500 (EST) Subject: [Pw_forum] Re: ld: cannot find -lfftw In-Reply-To: <20060315202259.17582.qmail@xuxa.iecc.com> Message-ID: On Wed, 15 Mar 2006 stewart at cnf.cornell.edu wrote: DS> Hi Anne, DS> DS> Which compiler are you using for the installation? If you are using the DS> intel compilers then it usually complains when linking to libraries that are DS> compiled with gnu compilers (gcc, g77). One option would be to recompile DS> fftw with the intel compilers and link to that version of fftw. Hopefully, DS> this will take care of your problem. nope. that cannot be it, in that case you get tons of 'undefined reference to...' warnings before the linker gives up. regards, axel. DS> DS> Regards, DS> DS> Derek DS> DS> DS> Anne P Shelton writes: DS> DS> > I am trying to install espresso-3.0 on an Intel server running Linux. DS> > It seems to configure fine and find the necessary library but then I get DS> > this error after I make all DS> > DS> > ld: skipping incompatible /usr/lib/libfftw.a when searching for -lfftw DS> > ld: cannot find -lfftw DS> > make[1]: *** [memory.x] Error 1 DS> > DS> > I have installed the fftw 2.1.5 package. DS> > DS> > Any ideas. DS> > DS> > Thanks DS> > _______________________________________________ DS> > Pw_forum mailing list DS> > Pw_forum at pwscf.org DS> > http://www.democritos.it/mailman/listinfo/pw_forum DS> DS> DS> DS> ################################ DS> Derek Stewart, Ph. D. DS> Scientific Computation Associate DS> 250 Duffield Hall DS> Cornell Nanoscale Facility (CNF) DS> Ithaca, NY 14853 DS> stewart (at) cnf.cornell.edu DS> (607) 255-2856 DS> DS> _______________________________________________ DS> Pw_forum mailing list DS> Pw_forum at pwscf.org DS> http://www.democritos.it/mailman/listinfo/pw_forum DS> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From eyvaz_isaev at yahoo.com Wed Mar 15 23:16:43 2006 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Wed, 15 Mar 2006 14:16:43 -0800 (PST) Subject: [Pw_forum] ld: cannot find -lfftw In-Reply-To: <9D95C2906FCCE04F836ECA17C4CE09210268C482@UAEXCH.univ.albany.edu> Message-ID: <20060315221643.62806.qmail@web60321.mail.yahoo.com> Hi Anne, You can also use -D__FFTW -D__USE_INTERNAL_FFTW flags in CPPFLAGS. In this case -lfftw is not required. Bests, Eyvaz. --- Anne P Shelton wrote: > I am trying to install espresso-3.0 on an Intel > server running Linux. > It seems to configure fine and find the necessary > library but then I get > this error after I make all > > ld: skipping incompatible /usr/lib/libfftw.a when > searching for -lfftw > ld: cannot find -lfftw > make[1]: *** [memory.x] Error 1 > > I have installed the fftw 2.1.5 package. > > Any ideas. > > Thanks > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From yanmingma at sohu.com Thu Mar 16 12:21:17 2006 From: yanmingma at sohu.com (yanmingma at sohu.com) Date: Thu, 16 Mar 2006 19:21:17 +0800 (CST) Subject: [Pw_forum] I/O problem in phonon and electron-phonon coupling calculations Message-ID: <1258351.1142508077922.JavaMail.postfix@mx81.mail.sohu.com> Dear PWSCF Users,

Recently, we bought a very fast AMD cluster with big memory (say 4G/cpu memory).

However, in the phonon and electron-phonon coupling calculations, the calculation speed was slowed down dramatically due to the writing process of the temporary files in the hard disk, say writing wavefunctions. From my checks, the cpu running time is around 30%, while the writing file process in the hard disk takes up 70%. In this case, we could not take the advantage of our new fast computers.

So, my question is that could we use more memory instead of writing process in the hard disk? if so, how can we do this. Or, could we close out some unused writing files to save the CPU time in the phonon related calcualtions? if so,how can we do this?

I will highly appreciate your help.

Regards

Yanming -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060316/f3261a45/attachment.htm From wmbmacam at lg.ehu.es Thu Mar 16 12:33:54 2006 From: wmbmacam at lg.ehu.es (=?UTF-8?B?TWlndWVsIE1hcnTDrW5leiBDYW5hbGVz?=) Date: Thu, 16 Mar 2006 12:33:54 +0100 Subject: [Pw_forum] Re: I/O problem in phonon and electron-phonon coupling calculations Message-ID: <44194D22.7090901@lg.ehu.es> Hi Yanming, > Or, could we close out some unused writing files to save the CPU time in > the phonon related calcualtions? if so,how can we do this? You can set the flag reduce_io=.true. on the ph.x input file. I usually do, but I don't know if this will help much. Basically, because you still need the wavefunctions and fildvscf for el-ph calculations. -- ---------------------------------------- Miguel Mart?nez Canales Dto. F?sica de la Materia Condensada UPV/EHU Facultad de Ciencia y Tecnolog?a Apdo. 644 48080 Bilbao (Spain) Fax: +34 94 601 3500 Tlf: +34 94 601 5437 ---------------------------------------- "If you're a mad scientist, you can use GPLv2'd software for your evil plans to take over the world" Linus Torvalds From giannozz at nest.sns.it Thu Mar 16 19:17:18 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 16 Mar 2006 19:17:18 +0100 Subject: [Pw_forum] I/O problem in phonon and electron-phonon coupling calculations In-Reply-To: <1258351.1142508077922.JavaMail.postfix@mx81.mail.sohu.com> References: <1258351.1142508077922.JavaMail.postfix@mx81.mail.sohu.com> Message-ID: <200603161917.18146.giannozz@nest.sns.it> On Thursday 16 March 2006 12:21, yanmingma at sohu.com wrote: > [...] in the phonon and electron-phonon coupling calculations, the > calculation speed was slowed down dramatically due to the writing > process of the temporary files in the hard disk > [...] my question is that could we use more memory instead of writing > process in the hard disk? if so, how can we do this. it can be done but it is not straightforward, at least for the phonon calculation: one has to modify the code. It should be done and it will be done sooner or later, but in the meantime the only solution is to use the fastest disk you can. In particular, heavy I/O via the network to NFS-mounted disks must ABSOLUTELY be avoided. 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 sir_puding at tut.by Thu Mar 16 19:26:51 2006 From: sir_puding at tut.by (sir_puding at tut.by) Date: Thu, 16 Mar 2006 20:26:51 +0200 Subject: [Pw_forum] MPI detection by configure Message-ID: <1269071163.20060316202651@tut.by> Hi. Can anyone tell me how "parallel environment" is detected. And what one need to do in order to compile in parallel, if lam-mpi is not located in standard place. THNX. Sergey. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From eyvaz_isaev at yahoo.com Thu Mar 16 22:14:28 2006 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Thu, 16 Mar 2006 13:14:28 -0800 (PST) Subject: [Pw_forum] MPI detection by configure In-Reply-To: <1269071163.20060316202651@tut.by> Message-ID: <20060316211428.87645.qmail@web60313.mail.yahoo.com> Hi Sergei, If parallel environment is not detected by configure, it might be that you have some installation problem with LAM-MPI. Nevertheless, if you are sure that your LAM configuration is correct (say, mpif77 command works), then try ./configure.old beo-ifc and then add -D__LAM to CPPFLAGS (Thanks Nikola and Sahu). IFC v.8.1 and precompiled (and properly installed) LAM/MPI software are required. As concerns the second part of your question, try specify the full path for compilers. If you install precompiled LAM/MPI from RPM-file, there will be no problem with placing. Bests, Eyvaz. --- sir_puding at tut.by wrote: > Hi. > > Can anyone tell me how "parallel environment" is > detected. > And what one need to do in order to compile in > parallel, > if lam-mpi is not located in standard place. > > > THNX. > Sergey. > > -- > Please avoid sending me Word or PowerPoint > attachments. > See > http://www.gnu.org/philosophy/no-word-attachments.html > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From eyvaz_isaev at yahoo.com Fri Mar 17 00:06:45 2006 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Thu, 16 Mar 2006 15:06:45 -0800 (PST) Subject: [Pw_forum] CVS compiling In-Reply-To: <20060313171628.GB6987@physik.fu-berlin.de> Message-ID: <20060316230645.71585.qmail@web60315.mail.yahoo.com> Dear Paolo, I have just compiled successfully CVS version of QE. Everything went smoothly except the next error (quite easy to correct) in path_base.f90: mpif90 -O2 -tpp6 -assume byterecl -nomodule -fpp -D__LINUX -D__INTEL -D__FFTW -D__USE_INTERNAL_FFTW -D__MPI -D__PARA -I../include -I. -I../Modules -I../PW -I../PH -I../iotk/src -I../CPV -c path_base.f90 fortcom: Error: path_base.f90, line 280: Missing mandatory separating blank FMT = '(5X,"coarse-grained phase-space",T35, " = ",1X,L1))'& -------------------------^ fortcom: Error: path_base.f90, line 280: Missing mandatory separating blank FMT = '(5X,"coarse-grained phase-space",T35, " = ",1X,L1))'& -----------------------------------------------------------------------^ fortcom: Error: path_base.f90, line 281: Unbalanced parentheses & ) lcoarsegrained --^ Placing of quotas in the same line fixed the problem. I used IFC 8.1 on a parallel (Intel based) computer with MPI. Presumably, other compilers could result no error for this line (280th in path_base.f90). Bests, Eyvaz. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From giannozz at nest.sns.it Fri Mar 17 09:47:50 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 17 Mar 2006 09:47:50 +0100 Subject: [Pw_forum] MPI detection by configure In-Reply-To: <20060316211428.87645.qmail@web60313.mail.yahoo.com> References: <20060316211428.87645.qmail@web60313.mail.yahoo.com> Message-ID: <200603170947.50646.giannozz@nest.sns.it> On Thursday 16 March 2006 22:14, Eyvaz Isaev wrote: > If parallel environment is not detected by configure, > it might be that you have some installation problem > with LAM-MPI. Nevertheless, if you are sure that your > LAM configuration is correct (say, mpif77 command > works) say, "mpif90". All MPI installations should have a more or less working "mpif77" script, but the "mpif90" will work only if explicitly configured. No working mpif90, no parallel environment (working="found in the execution path, and able to compile a simple file"). 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 yanmingma at sohu.com Fri Mar 17 09:49:32 2006 From: yanmingma at sohu.com (yanmingma at sohu.com) Date: Fri, 17 Mar 2006 16:49:32 +0800 (CST) Subject: [Pw_forum] I/O problem in phonon and electron-phonon coupling calculations Message-ID: <12085211.1142585372970.JavaMail.postfix@mx81.mail.sohu.com> Dear Paolo and Miguel,

Thanks very much for your replies.

Definitely, the current I/O will reduce the performance of PWSCF in phonon and electron-phonon coupling.

We have to solve the current I/O problem, especially, when we are ready to recieve more and more fast computers.

Regards

Yanming

----- Original Message -----

From: Paolo Giannozzi

To: pw_forum at pwscf.org

Subject: Re: [Pw_forum] I/O problem in phonon and electron-phonon coupling calculations

Sent: Fri Mar 17 02:17:18 CST 2006

> On Thursday 16 March 2006 12:21, yanmingma at sohu.com wrote:

>

> > [...] in the phonon and electron-phonon coupling calculations, the

> > calculation speed was slowed down dramatically due to the writing

> > process of the temporary files in the hard disk

> > [...] my question is that could we use more memory instead of writing

> > process in the hard disk? if so, how can we do this.

>

> it can be done but it is not straightforward, at least for the phonon

> calculation: one has to modify the code. It should be done and it

> will be done sooner or later, but in the meantime the only solution

> is to use the fastest disk you can. In particular, heavy I/O via the

> network to NFS-mounted disks must ABSOLUTELY be avoided.

>

> 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

-------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060317/b4b15770/attachment.htm From giannozz at nest.sns.it Fri Mar 17 09:51:24 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 17 Mar 2006 09:51:24 +0100 Subject: [Pw_forum] MPI detection by configure In-Reply-To: <1269071163.20060316202651@tut.by> References: <1269071163.20060316202651@tut.by> Message-ID: <200603170951.24821.giannozz@nest.sns.it> On Thursday 16 March 2006 19:26, sir_puding at tut.by wrote: > And what one need to do in order to compile in parallel, > if lam-mpi is not located in standard place. configure LIBDIRS="/non/standard/place/" You may also need to specify where your mpif90 script is: configure MPIF90="/path/to/mpif90/script/mpif90" (see my previous message). See the users' guide for more info 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 dkorotin at gmail.com Fri Mar 17 09:59:31 2006 From: dkorotin at gmail.com (Dmitry Korotin) Date: Fri, 17 Mar 2006 13:59:31 +0500 Subject: [Pw_forum] dt parameter Message-ID: <2fd252650603170059x624e82d2h@mail.gmail.com> Dear ESPRESSO users, can anyone describe me the meaning of dt parameter (and give some advices in choosing it's value) in detail? (I'm going to do vc-relax calculation) Or, may be, there are some references... Thank you in advice, Dmitry Korotin. From giannozz at nest.sns.it Fri Mar 17 10:05:34 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 17 Mar 2006 10:05:34 +0100 Subject: [Pw_forum] CVS compiling In-Reply-To: <20060316230645.71585.qmail@web60315.mail.yahoo.com> References: <20060316230645.71585.qmail@web60315.mail.yahoo.com> Message-ID: <200603171005.34139.giannozz@nest.sns.it> On Friday 17 March 2006 00:06, Eyvaz Isaev wrote: > Dear Paolo, please don't address always to me: I am not the only one working on the code > I have just compiled successfully CVS version of QE. > Everything went smoothly except the next error [...] > fortcom: Error: path_base.f90, line 280: Missing > mandatory separating blank > FMT = '(5X,"coarse-grained > phase-space",T35, " = ",1X,L1))'& > -------------------------^ > I used IFC 8.1 on a parallel (Intel based) computer with MPI. My intel 8.1 (Build 20041118Z) yields no error...I think that the syntax is correct. If a character variable spans two lines there should be a & at the beginning of the second line, and there is one. 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 prasenjit at jncasr.ac.in Fri Mar 17 11:18:27 2006 From: prasenjit at jncasr.ac.in (PRASENJIT GHOSH) Date: Fri, 17 Mar 2006 15:48:27 +0530 (IST) Subject: [Pw_forum] CVS compiling In-Reply-To: <200603171005.34139.giannozz@nest.sns.it> References: <20060316230645.71585.qmail@web60315.mail.yahoo.com> <200603171005.34139.giannozz@nest.sns.it> Message-ID: <33106.202.41.111.151.1142590707.squirrel@202.41.111.151> Hi everybody, while trying to compile PWScf, CVS version using an ifort compiler (ver. 8.0) I got the following error: ../Modules/functionals.o(.text+0x125a): In function `funct_mp_xc_': : undefined reference to `vwn_' ../Modules/functionals.o(.text+0x1278): In function `funct_mp_xc_': : undefined reference to `gl_' ../Modules/functionals.o(.text+0x129b): In function `funct_mp_xc_': : undefined reference to `pw_' ../Modules/functionals.o(.text+0x12be): In function `funct_mp_xc_': : undefined reference to `pz_' ../Modules/functionals.o(.text+0x12dc): In function `funct_mp_xc_': : undefined reference to `hl_' ../Modules/functionals.o(.text+0x12fa): In function `funct_mp_xc_': : undefined reference to `wigner_' ../Modules/functionals.o(.text+0x131d): In function `funct_mp_xc_': : undefined reference to `pw_' ../Modules/functionals.o(.text+0x133b): In function `funct_mp_xc_': : undefined reference to `lyp_' ../Modules/functionals.o(.text+0x1359): In function `funct_mp_xc_': : undefined reference to `vwn_' ../Modules/functionals.o(.text+0x137c): In function `funct_mp_xc_': : undefined reference to `pz_' ../Modules/functionals.o(.text+0x1394): In function `funct_mp_xc_': : undefined reference to `slater_' ../Modules/functionals.o(.text+0x13c7): In function `funct_mp_xc_': : undefined reference to `slater_' ../Modules/functionals.o(.text+0x1412): In function `funct_mp_xc_': : undefined reference to `slater_' ../Modules/functionals.o(.text+0x1426): In function `funct_mp_xc_': : undefined reference to `slater_rxc_' ../Modules/functionals.o(.text+0x143a): In function `funct_mp_xc_': : undefined reference to `slater1_' ../Modules/functionals.o(.text+0x144e): In function `funct_mp_xc_': : undefined reference to `slater_' ../Modules/functionals.o(.text+0x17e4): In function `funct_mp_gcxc_': : undefined reference to `glyp_' ../Modules/functionals.o(.text+0x182f): In function `funct_mp_gcxc_': : undefined reference to `pbec_' ../Modules/functionals.o(.text+0x1850): In function `funct_mp_gcxc_': : undefined reference to `glyp_' ../Modules/functionals.o(.text+0x1871): In function `funct_mp_gcxc_': : undefined reference to `ggac_' ../Modules/functionals.o(.text+0x1892): In function `funct_mp_gcxc_': : undefined reference to `perdew86_' ../Modules/functionals.o(.text+0x18b1): In function `funct_mp_gcxc_': : undefined reference to `becke88_' ../Modules/functionals.o(.text+0x190b): In function `funct_mp_gcxc_': : undefined reference to `pbex_' ../Modules/functionals.o(.text+0x1960): In function `funct_mp_gcxc_': : undefined reference to `optx_' ../Modules/functionals.o(.text+0x1993): In function `funct_mp_gcxc_': : undefined reference to `hcth_' ../Modules/functionals.o(.text+0x19bc): In function `funct_mp_gcxc_': : undefined reference to `pbex_' ../Modules/functionals.o(.text+0x19e5): In function `funct_mp_gcxc_': : undefined reference to `pbex_' ../Modules/functionals.o(.text+0x1a09): In function `funct_mp_gcxc_': : undefined reference to `ggax_' ../Modules/functionals.o(.text+0x1a2d): In function `funct_mp_gcxc_': : undefined reference to `becke88_' ../Modules/functionals.o(.text+0x1c51): In function `funct_mp_gcx_spin_': : undefined reference to `pbex_' ../Modules/functionals.o(.text+0x1cc5): In function `funct_mp_gcx_spin_': : undefined reference to `pbex_' ../Modules/functionals.o(.text+0x1ddc): In function `funct_mp_gcx_spin_': : undefined reference to `ggax_' ../Modules/functionals.o(.text+0x1e4b): In function `funct_mp_gcx_spin_': : undefined reference to `ggax_' ../Modules/functionals.o(.text+0x2260): In function `funct_mp_dmxc_': : undefined reference to `slater_' ../Modules/functionals.o(.text+0x22a3): In function `funct_mp_dmxc_': : undefined reference to `dpz_' ../Modules/functionals.o(.text+0x262c): In function `funct_mp_dmxc_spin_': : undefined reference to `slater_' ../Modules/functionals.o(.text+0x2680): In function `funct_mp_dmxc_spin_': : undefined reference to `slater_' ../Modules/functionals.o(.text+0x26e8): In function `funct_mp_dmxc_spin_': : undefined reference to `dpz_' ../Modules/functionals.o(.text+0x2727): In function `funct_mp_dmxc_spin_': : undefined reference to `pz_' ../flib/flib.a(lsda_functionals.o)(.text+0xe6): In function `pz_spin_': : undefined reference to `pz_' Can someone please help me to sort this out. With regards, Prasenjit. PRASENJIT GHOSH, Ph. D STUDENT, THEORETICAL SCIENCES UNIT, JAWAHARLAL NEHRU CENTRE, JAKKUR P. O., BANGALORE - 560064, INDIA. PHONE:+91-80-22082835 (OFFICE) +91 9880519401 (MOBILE) From eyvaz_isaev at yahoo.com Fri Mar 17 12:09:50 2006 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Fri, 17 Mar 2006 03:09:50 -0800 (PST) Subject: [Pw_forum] Sorry In-Reply-To: <200603171005.34139.giannozz@nest.sns.it> Message-ID: <20060317110950.73355.qmail@web60313.mail.yahoo.com> Hi Paolo, My apologies troubling you. > My intel 8.1 (Build 20041118Z) yields no error... Unfortunately, I am not aware of the bulid number for IFC 8.1 I used. Bests, Eyvaz. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From giannozz at nest.sns.it Fri Mar 17 12:13:41 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 17 Mar 2006 12:13:41 +0100 Subject: [Pw_forum] Sorry In-Reply-To: <20060317110950.73355.qmail@web60313.mail.yahoo.com> References: <20060317110950.73355.qmail@web60313.mail.yahoo.com> Message-ID: <200603171213.41671.giannozz@nest.sns.it> On Friday 17 March 2006 12:09, Eyvaz Isaev wrote: > > My intel 8.1 (Build 20041118Z) yields no error... > > Unfortunately, I am not aware of the bulid number for > IFC 8.1 I used. nor am I, until I try "ifort -V" ! P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From eyvaz_isaev at yahoo.com Fri Mar 17 12:27:16 2006 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Fri, 17 Mar 2006 03:27:16 -0800 (PST) Subject: [Pw_forum] MPI detection by configure In-Reply-To: <200603170947.50646.giannozz@nest.sns.it> Message-ID: <20060317112716.86079.qmail@web60311.mail.yahoo.com> > say, "mpif90". All MPI installations should have a > more or less working "mpif77" script, but the > "mpif90" will work only if explicitly configured. I just paid attention to a fact that in a precompiled LAM/MPI RPM-file (lam-7.1.2-1.i586.rpm) taken from the developers website did not contain mpif90, because of that I sed mpif77 instead of mpif90. Bests, Eyvaz. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From eyvaz_isaev at yahoo.com Fri Mar 17 12:34:01 2006 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Fri, 17 Mar 2006 03:34:01 -0800 (PST) Subject: [Pw_forum] Sorry In-Reply-To: <200603171213.41671.giannozz@nest.sns.it> Message-ID: <20060317113401.98157.qmail@web60323.mail.yahoo.com> > > > My intel 8.1 (Build 20041118Z) yields no > error... > nor am I, until I try "ifort -V" ! Thanks, I forgot about "-V". Actually, I have a different build number, 20051007Z. Bests, Eyvaz. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From sir_puding at tut.by Fri Mar 17 14:03:57 2006 From: sir_puding at tut.by (sir_puding at tut.by) Date: Fri, 17 Mar 2006 15:03:57 +0200 Subject: [Pw_forum] MPI detection by configure In-Reply-To: <200603170951.24821.giannozz@nest.sns.it> References: <1269071163.20060316202651@tut.by> <200603170951.24821.giannozz@nest.sns.it> Message-ID: <1886448774.20060317150357@tut.by> Very big thanx to all. The problem was that there were no mpif90 wrappers in my MPI installation. Now the problem is fixed and everything compiles. Sergey. From stargmoon at yahoo.com Fri Mar 17 18:06:19 2006 From: stargmoon at yahoo.com (stargmoon) Date: Fri, 17 Mar 2006 09:06:19 -0800 (PST) Subject: [Pw_forum] CVS compiling In-Reply-To: <200603171005.34139.giannozz@nest.sns.it> Message-ID: <20060317170619.97242.qmail@web33209.mail.mud.yahoo.com> Dear PWscf community, I am new in this community. Recently I successfully compiled espresso-3.0 on our machine. When I run the examples. It is almost okay except some numerical accuracy difference compared to the reference supplied in the package. However, for the example14 (D3 code) the output Si.d3X.out is very different from what provided in reference. The same thing happened in the LDA+U test. I am not sure if this related to my compilation or something else. Best, Stargmoon --------------------------------- Yahoo! Mail Bring photos to life! New PhotoMail makes sharing a breeze. -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060317/7f9592cc/attachment.htm From giannozz at nest.sns.it Mon Mar 20 13:48:48 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 20 Mar 2006 13:48:48 +0100 Subject: [Pw_forum] CVS compiling In-Reply-To: <200603201247.11814.p.giannozzi@sns.it> References: <20060316230645.71585.qmail@web60315.mail.yahoo.com> <33106.202.41.111.151.1142590707.squirrel@202.41.111.151> <200603201247.11814.p.giannozzi@sns.it> Message-ID: <200603201348.48304.giannozz@nest.sns.it> On Friday 17 March 2006 11:18, PRASENJIT GHOSH wrote: > while trying to compile PWScf, CVS version using an ifort compiler > (ver. 8.0) I got the following error: > > ../Modules/functionals.o(.text+0x125a): In function `funct_mp_xc_': > : undefined reference to `vwn_' > > [...] > Can someone please help me to sort this out. "vwn" is in flib/flib.a. Check if it is there. Start the procedure from the beginning ("make veryclean", "./configure", "make pw") and look for the first occurrence of an error (if any) 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 prasenjit at jncasr.ac.in Mon Mar 20 14:02:18 2006 From: prasenjit at jncasr.ac.in (PRASENJIT GHOSH) Date: Mon, 20 Mar 2006 18:32:18 +0530 (IST) Subject: [Pw_forum] CVS compiling In-Reply-To: <200603201348.48304.giannozz@nest.sns.it> References: <20060316230645.71585.qmail@web60315.mail.yahoo.com> <33106.202.41.111.151.1142590707.squirrel@202.41.111.151> <200603201247.11814.p.giannozzi@sns.it> <200603201348.48304.giannozz@nest.sns.it> Message-ID: <50324.202.41.111.151.1142859738.squirrel@202.41.111.151> Dear Paolo, On Mon, March 20, 2006 18:18, Paolo Giannozzi said: > On Friday 17 March 2006 11:18, PRASENJIT GHOSH wrote: > >> while trying to compile PWScf, CVS version using an ifort compiler >> (ver. 8.0) I got the following error: >> >> ../Modules/functionals.o(.text+0x125a): In function `funct_mp_xc_': >> : undefined reference to `vwn_' >> >> [...] >> Can someone please help me to sort this out. > > "vwn" is in flib/flib.a. Check if it is there. Start the procedure from > the beginning ("make veryclean", "./configure", "make pw") and > look for the first occurrence of an error (if any) the flib.a file was not present in the flib directory. So I copied flib.a (it has 'vwn') from the older version (2.1.5) and recompiled from the very beginning. But still it gives the same error. Is the flib.a of version 2.1.5 not compatible with the one for CVS version? What should I do now? Regards Prasenjit. PRASENJIT GHOSH, Ph. D STUDENT, THEORETICAL SCIENCES UNIT, JAWAHARLAL NEHRU CENTRE, JAKKUR P. O., BANGALORE - 560064, INDIA. PHONE:+91-80-22082835 (OFFICE) +91 9880519401 (MOBILE) From akohlmey at vitae.cmm.upenn.edu Mon Mar 20 14:40:53 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Mon, 20 Mar 2006 08:40:53 -0500 (EST) Subject: [Pw_forum] CVS compiling In-Reply-To: <50324.202.41.111.151.1142859738.squirrel@202.41.111.151> Message-ID: On Mon, 20 Mar 2006, PRASENJIT GHOSH wrote: [...] PG> > "vwn" is in flib/flib.a. Check if it is there. Start the procedure from PG> > the beginning ("make veryclean", "./configure", "make pw") and PG> > look for the first occurrence of an error (if any) PG> the flib.a file was not present in the flib directory. So I copied flib.a PG> (it has 'vwn') from the older version (2.1.5) and recompiled from the very PG> beginning. But still it gives the same error. Is the flib.a of version PG> 2.1.5 not compatible with the one for CVS version? What should I do now? please do _exactly_ what paolo recommended. flib/flib.a will be build when you recompile. this is a file that must be consistent with your sources, so you cannot mix and match with different versions. please also consider upgrading your compiler. intel 8.0 has quite a few known issues. axel. PG> PG> Regards PG> Prasenjit. PG> PG> PRASENJIT GHOSH, PG> Ph. D STUDENT, PG> THEORETICAL SCIENCES UNIT, PG> JAWAHARLAL NEHRU CENTRE, PG> JAKKUR P. O., PG> BANGALORE - 560064, PG> INDIA. PG> PG> PHONE:+91-80-22082835 (OFFICE) PG> +91 9880519401 (MOBILE) PG> _______________________________________________ PG> Pw_forum mailing list PG> Pw_forum at pwscf.org PG> http://www.democritos.it/mailman/listinfo/pw_forum PG> -- ======================================================================= Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Center for Molecular Modeling -- University of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From giannozz at nest.sns.it Mon Mar 20 14:44:03 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 20 Mar 2006 14:44:03 +0100 Subject: [Pw_forum] CVS compiling In-Reply-To: <20060317170619.97242.qmail@web33209.mail.mud.yahoo.com> References: <20060317170619.97242.qmail@web33209.mail.mud.yahoo.com> Message-ID: <200603201444.03769.giannozz@nest.sns.it> On Friday 17 March 2006 18:06, stargmoon wrote: > Recently I successfully compiled espresso-3.0 on our machine. espresso-3.0 (from the web site) or the CVS version? examples for the latter have not been updated. Some exotic parts of the code (D3 and LDA+U are among these) have to be verified. > However, for the example14 (D3 code) the output Si.d3X.out > is very different from what provided in reference. The same > thing happened in the LDA+U test. numercal differences may or may not be significant. It is hard to tell whether the results are good or not if you do not know what the results mean 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 hisahsi821 at yahoo.com.tw Mon Mar 20 15:04:02 2006 From: hisahsi821 at yahoo.com.tw (=?big5?q?=AAa=BE^?=) Date: Mon, 20 Mar 2006 22:04:02 +0800 (CST) Subject: [Pw_forum] How to construction of Si(100)-2x2 surface : Message-ID: <20060320140402.73890.qmail@web17705.mail.tpe.yahoo.com> How to construction of Si(100)-2x2 surface to calculate : Hi : I aimed to construct a three-layered Si(100)-2x2 size . but i don't understand how to set up parameters , like how much the atoms needs ? how to set up lattice parameter ? I try to see "al001.rx.in" this example , it write in file : ***************** &SYSTEM ibrav = 6, celldm(1) = 5.3033D0, celldm(3) = 8.D0, ***************** but, i still don't understand why it should be set up by this way , i think , In celldm(1) and celldm(3) , they must have some correlations . Why it should be to set celldm(1) and celldm(3) ? In Surface Calculation , whether it can use other way to set up model , or not !? And , Have any other examples can be understood easily !? request your advise . thank you . ___________________________________________________ ??? Yahoo!?????? 7.0??????????? http://messenger.yahoo.com.tw/ -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060320/bbe900c3/attachment.htm From giannozz at nest.sns.it Mon Mar 20 21:55:40 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 20 Mar 2006 21:55:40 +0100 Subject: [Pw_forum] How to construction of Si(100)-2x2 surface : In-Reply-To: <20060320140402.73890.qmail@web17705.mail.tpe.yahoo.com> References: <20060320140402.73890.qmail@web17705.mail.tpe.yahoo.com> Message-ID: <200603202155.40396.giannozz@nest.sns.it> On Monday 20 March 2006 15:04, ?? wrote: > I aimed to construct a three-layered Si(100)-2x2 size . > but i don't understand how to set up parameters detailed instructions are in Doc/INPUT_PW 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 yaoxinxin at mail.sdu.edu.cn Tue Mar 21 03:16:04 2006 From: yaoxinxin at mail.sdu.edu.cn (=?gb2312?B?0qbQwtDA?=) Date: Tue, 21 Mar 2006 10:16:04 +0800 Subject: [Pw_forum] How to read lattice constant from the output file of vc-relax Message-ID: <342907364.22314@mail.sdu.edu.cn> Dear all, I execute a vc-relax calculation, the output file is like this: =============================================================================== ! total energy = -1513.15280271 ryd estimated scf accuracy < 0.00000005 ryd total magnetization = 9.00 Bohr mag/cell absolute magnetization = 9.12 Bohr mag/cell convergence has been achieved Forces acting on atoms (Ry/au): atom 1 type 1 force = -0.00090234 -0.00090236 -0.00060040 atom 2 type 3 force = 0.00025524 0.00025523 0.00032448 atom 3 type 4 force = -0.00023451 -0.00017762 0.00005756 atom 4 type 4 force = -0.00017761 -0.00023452 0.00005754 atom 5 type 4 force = -0.00014720 -0.00014719 -0.00004334 atom 6 type 5 force = 0.00021078 0.00021077 0.00024824 atom 7 type 2 force = 0.00072939 0.00072938 -0.00007323 atom 8 type 3 force = 0.00030165 0.00030164 0.00012308 atom 9 type 4 force = 0.00015559 0.00030045 -0.00009079 atom 10 type 4 force = 0.00030045 0.00015558 -0.00009079 atom 11 type 4 force = 0.00009477 0.00009474 0.00003522 atom 12 type 4 force = 0.00037284 0.00037287 0.00023032 atom 13 type 3 force = -0.00010083 -0.00010056 -0.00011395 atom 14 type 3 force = -0.00014817 -0.00014817 -0.00041716 atom 15 type 4 force = -0.00008397 0.00000251 0.00014874 atom 16 type 4 force = 0.00000267 -0.00008405 0.00014871 atom 17 type 4 force = -0.00011380 -0.00011380 -0.00003731 atom 18 type 4 force = -0.00051496 -0.00051490 0.00009309 Total force = 0.002310 Total SCF correction = 0.000828 entering subroutine stress ... total stress (ryd/bohr**3) (kbar) P= -0.02 -0.00000170 -0.00000001 0.00000121 -0.25 0.00 0.18 -0.00000001 -0.00000170 0.00000121 0.00 -0.25 0.18 0.00000121 0.00000121 0.00000295 0.18 0.18 0.43 Parrinello-Rahman Damped Dynamics: convergence achieved, Efinal= -1513.15280271 ------------------------------------------------------------------------ Final estimate of lattice vectors (input alat units) 0.999218793 0.004883129 0.003921399 0.004883129 0.999218813 0.003921395 0.007955423 0.007955414 2.046656291 final unit-cell volume = 1413.6989 (a.u.)^3 input alat = 8.8445 (a.u.) CELL_PARAMETERS (alat) 0.999218793 0.004883129 0.003921399 0.004883129 0.999218813 0.003921395 0.007955423 0.007955414 2.046656291 ATOMIC_POSITIONS (alat) Fe1 -0.013056076 -0.013055086 0.002515773 Sn 0.497703713 0.497704623 0.354603733 O 0.719819040 0.305839769 0.021489138 O 0.305838560 0.719819831 0.021489205 O 0.842148687 0.842149758 0.340853449 H 0.219947019 0.219947779 0.341994037 Fe2 -0.013973823 -0.013972857 0.708191013 Sn 0.502042637 0.502043667 1.027340878 O 0.721364873 0.314430703 0.685223918 O 0.314429607 0.721365697 0.685223880 O 0.193695096 0.193695837 1.021346052 O 0.811306594 0.811307850 1.038377647 Sn 0.006642077 0.006643077 1.377214153 Sn 0.505715303 0.505716371 1.729800072 O 0.691583090 0.308332725 1.381201005 O 0.308331230 0.691583732 1.381201013 O 0.192814143 0.192814844 1.745050428 O 0.814855563 0.814856839 1.731663985 Writing output data file sno2.save =============================================================================== I propose to execute another calculation of different replaced positions with optimized atomic_positions as the initial condition,which I expect to spend less time to finish,but I am puzzled by the optimized cell_parameters.From previous outcomes,how can I determine the new cell_parameters and new atomic_positions in the inputfile? I have attempted to use a11(the first diagonal element of cell_parameters)*celldm(1) as the new celldm(1),a33(the third diagonal element of cell_parameters) as the new celldm(3),the output atomic_positions(alat) as the new atomic_positions,and neglect all of the nondiagonal elements. After the first self-consistent,I gain stresses with very large nondiagonal elements than diagonal elements like that: =============================================================================== total stress (ryd/bohr**3) (kbar) P= 3.20 0.00000417 0.00011011 0.00005447 0.61 16.20 8.01 0.00011011 0.00000418 0.00005447 16.20 0.61 8.01 0.00005447 0.00005447 0.00005700 8.01 8.01 8.39 =============================================================================== How can I adapt the input parameters to avoid this condition and get smaller nondiagonal elements? In the system block of the input file,there is a parameter "nosym".How does it affect the final results? In my system(1*1*3 units supercells of SnO2 rutile-structure which include 18 atoms,and two Sn atoms are replaced by Fe and one O atom by H),which value should I select,"true" or "false"? Any help would be appreciated. Best regards! ======================================= X.X.Yao School of Physics and Microelectronics, Shandong University, Jinan,Shandong 250100, People's Republic of China. ======================================= From silviu at Princeton.EDU Tue Mar 21 14:06:42 2006 From: silviu at Princeton.EDU (Silviu Zilberman) Date: Tue, 21 Mar 2006 15:06:42 +0200 Subject: [Pw_forum] difficulties with 'ortho' Message-ID: <441FFA62.50802@Princeton.EDU> Dear All, I have been testing the cvs version on an IBM Blue Gene machine. In some cases everything works fine, but in many other I keep having difficulties with the 'ortho' procedures in CP. Below is a small example for a single water molecule in vacuum. I keep getting error messages like: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from ortho : error # 1 ortho went bananas %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% In some (other) cases I got error #1 with the same info. I read in the source code that under AIX it results from a test to trap NaN's. I tried reducing the time step to 1au, but nothing helped. Any ideas? In addition, did anyone get PW (cvs version) to work on AIX? Thanks, Silviu. &CONTROL calculation='cp', restart_mode = 'from_scratch', nstep = 1000, iprint = 10000, isave = 25000, dt = 1.0, pseudo_dir = '$PSEUDO_DIR', outdir = '$TMP_DIR', prefix = '$PREFIX', / &SYSTEM ibrav = 1, celldm(1) = 25.0d0, nat = 3, ntyp = 2, ecutwfc =30.0, ecutrho =180.0, nr1b=18, nr2b=18, nr3b=18, nspin=2, nelec=8, nelup=4, neldw=4, / &ELECTRONS emass = 700.d0, emass_cutoff = 0.8, orthogonalization = 'ortho', ortho_eps = 1.e-6, ortho_max = 100, electron_dynamics= 'damp', electron_damping =0.20, electron_velocities = 'zero', / &IONS ion_dynamics = 'none', ion_damping = 0.001 / AUTOPILOT on_step = 10 : dt = 10 on_step = 20 : dt = 15 on_step = 100 : dt = 7 on_step = 100 : ion_dynamics = 'damp' ENDRULES ATOMIC_SPECIES O 15.9994 008-O-gpbe--bm.van H 1.0079 001-H-gpbe--bm.van ATOMIC_POSITIONS angstrom O 3.385583554 8.277954564 7.514590360 H 3.406852766 7.183986045 7.401542108 H 4.359644270 8.695739475 7.220207334 EOF From giannozz at nest.sns.it Tue Mar 21 16:32:11 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 21 Mar 2006 16:32:11 +0100 Subject: [Pw_forum] difficulties with 'ortho' In-Reply-To: <441FFA62.50802@Princeton.EDU> References: <441FFA62.50802@Princeton.EDU> Message-ID: <200603211632.11358.giannozz@nest.sns.it> On Tuesday 21 March 2006 14:06, Silviu Zilberman wrote: > I have been testing the cvs version on an IBM Blue Gene machine. > In some cases everything works fine, but in many other I keep > having difficulties with the 'ortho' procedures in CP [...] Any ideas? support for IBM Blue Gene is very preliminary. Please try to find out when exactly ortho doesn't work and why. It is an iterative procedure and it is quite easy to see if it is converging or "going bananas". > In addition, did anyone get PW (cvs version) to work on AIX? everybody who tried, I guess. I for sure did. Parallel subspace diagonalization in the Gamma-only case doesn't work on SP5 and has been disabled. 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 Mar 21 16:33:13 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 21 Mar 2006 16:33:13 +0100 Subject: [Pw_forum] Fwd: Dear Sir! Please help me PWscf Message-ID: <200603211633.13435.giannozz@nest.sns.it> ---------- Forwarded Message ---------- Subject: Dear Sir! Please help me PWscf Date: Tuesday 21 March 2006 11:37 From: Nguyen Ngoc Ha To: giannozz at nest.sns.it Dear sir! I want to use VC-Relax to calculate lattice a,b,c and angles. Although I've fhinished succeed job vc-relax, but I don't see them, output don't run with xcrysden. Please help me the problem! Thank very much! Ha,Nguyen! Nguyen, Ngoc Ha Hanoi University of Education Faculty of Chemistry Department of Physical Chemistry Tel: Office: 04/8330842 Home: 04/7681083 Mobile: 0912129517 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------- -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From tone.kokalj at ijs.si Tue Mar 21 17:04:08 2006 From: tone.kokalj at ijs.si (Tone Kokalj) Date: Tue, 21 Mar 2006 17:04:08 +0100 Subject: [Pw_forum] Fwd: Dear Sir! Please help me PWscf In-Reply-To: <200603211633.13435.giannozz@nest.sns.it> References: <200603211633.13435.giannozz@nest.sns.it> Message-ID: <1142957048.6680.109.camel@localhost.localdomain> On Tue, 2006-03-21 at 16:33 +0100, Paolo Giannozzi wrote: > > ---------- Forwarded Message ---------- > > Subject: Dear Sir! Please help me PWscf > Date: Tuesday 21 March 2006 11:37 > From: Nguyen Ngoc Ha > To: giannozz at nest.sns.it > > Dear sir! > > I want to use VC-Relax to calculate lattice a,b,c and > angles. Although I've fhinished succeed job vc-relax, > but I don't see them, output don't run with xcrysden. The vc-relax output of QE 3.0 is written in a non-standard way, so xcrysden cannot understand it. This has been fixed in the CVS version. The fix is simple: edit the PW/vcsmd.f90, and toward the end of the file, you will see these lines: WRITE( stdout, * ) ' new positions in cryst coord' WRITE( stdout,'(A3,3X,3F14.9)') ( atm(ityp(na)), tau(:,na), na = 1, nat ) WRITE( stdout, * ) ' new positions in cart coord (alat unit)' ! CALL cryst_to_cart( nat, tau, at, 1 ) ! WRITE( stdout,'(A3,3X,3F14.9)') ( atm(ityp(na)), tau(:,na), na = 1, nat ) WRITE( stdout, '(/5X,"Ekin = ",F14.8," Ryd T = ",F6.1," K ", & & " Etot = ",F14.8)') ekint, tnew, edyn + e_start After this lines, add the line: CALL output_tau( lmovecell ) And recompile the program. The call to output_tau( lmovecell ) will make a standard output, and xcrysden will be able to parse it. Regards, Tone From giannozz at nest.sns.it Tue Mar 21 17:21:03 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 21 Mar 2006 17:21:03 +0100 Subject: [Pw_forum] How to read lattice constant from the output file of vc-relax In-Reply-To: <342907364.22314@mail.sdu.edu.cn> References: <342907364.22314@mail.sdu.edu.cn> Message-ID: <200603211721.03548.giannozz@nest.sns.it> On Tuesday 21 March 2006 03:16, ??? wrote: > In the system block of the input file, there is a parameter "nosym". > How does it affect the final results? from the Doc/INPUT_PW file: nosym LOGICAL ( default = .FALSE. ) if (.TRUE.) symmetry is not used. Note that a k-point grid provided in input is used "as is"; an automatically generated k-point grid will contain only points in the irreducible BZ of the lattice. Use with care in low-symmetry large cells if you cannot afford a k-point grid with the correct symmetry. 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 Mar 21 17:36:30 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 21 Mar 2006 17:36:30 +0100 Subject: [Pw_forum] dt parameter In-Reply-To: <2fd252650603170059x624e82d2h@mail.gmail.com> References: <2fd252650603170059x624e82d2h@mail.gmail.com> Message-ID: <200603211736.30279.giannozz@nest.sns.it> On Friday 17 March 2006 09:59, Dmitry Korotin wrote: > can anyone describe me the meaning of dt parameter (and give some > advices in choosing it's value) in detail? (I'm going to do vc-relax > calculation) Or, may be, there are some references... the following is in the CVS version of the users' guide: --- A common mistake many new users make is to set the time step dt inproperly to the same order of magnitude as for CP algorithm, or not setting dt at all. This will produce a "not evolving dynamics". Good values for the original RMW (RM Wentzcovitch) dynamics are dt=50 to 70. The choice of the cell mass is a delicate matter. An off-optimal mass will make convergence slower. Too small masses, as well as too long time steps, can make the algorithm unstable. A good cell mass will make the oscillation times for internal degrees of freedom comparable to cell degrees of freedom in non-damped Variable-Cell MD. Test calculations are advisable before extensive calculation. --- 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 silviu at Princeton.EDU Tue Mar 21 23:55:48 2006 From: silviu at Princeton.EDU (Silviu Zilberman) Date: Wed, 22 Mar 2006 00:55:48 +0200 Subject: [Pw_forum] difficulties with 'ortho' In-Reply-To: <200603211632.11358.giannozz@nest.sns.it> References: <441FFA62.50802@Princeton.EDU> <200603211632.11358.giannozz@nest.sns.it> Message-ID: <44208474.9010502@Princeton.EDU> Hi Paolo, In the example I posted, it fails in 'ortho_gamma' at the initial part, right after setting rho, before starting any iteration. It seems that subroutine 'rhoset' does not work very well and there must be NaN's in it's outcome (rho). As a result it fails in 'ortho_gamma' at the first NaN trap. Thanks, Silviu. Paolo Giannozzi wrote: > On Tuesday 21 March 2006 14:06, Silviu Zilberman wrote: > > >> I have been testing the cvs version on an IBM Blue Gene machine. >> In some cases everything works fine, but in many other I keep >> having difficulties with the 'ortho' procedures in CP [...] Any ideas? >> > > support for IBM Blue Gene is very preliminary. Please try to find out > when exactly ortho doesn't work and why. It is an iterative procedure > and it is quite easy to see if it is converging or "going bananas". > > >> In addition, did anyone get PW (cvs version) to work on AIX? >> > > everybody who tried, I guess. I for sure did. Parallel subspace > diagonalization in the Gamma-only case doesn't work on SP5 > and has been disabled. > > Paolo > From alberto.milani at chem.polimi.it Wed Mar 22 13:08:37 2006 From: alberto.milani at chem.polimi.it (Alberto Milani) Date: Wed, 22 Mar 2006 13:08:37 +0100 Subject: [Pw_forum] convergence with ultrasoft pseudopotential Message-ID: <200603221308.37955.alberto.milani@chem.polimi.it> Dear all, I am using ultrasoft pseudopotentials and I am testing the convergence of total energy for different values of ecutwfc and ecutrho. For ecutwfc I have chosen different values between 20 and 50 Ry and for ecutrho both ecutrho=10*ecutwfc and ecutrho=12*ecutwfc. In all cases, the energy does not converge within 10^(-3) Ry. I guess that Increasing ecutwfc beyond 50 Ry does not make any sense with USPP. What can I do? Should I change the USPP or generate another one which is more accurate for the case I am studying? Or does anyone have any other suggestion? Thanks in advance A.M. From prasenjit at jncasr.ac.in Thu Mar 23 04:27:07 2006 From: prasenjit at jncasr.ac.in (PRASENJIT GHOSH) Date: Thu, 23 Mar 2006 08:57:07 +0530 (IST) Subject: [Pw_forum] parallelization of neb images Message-ID: <35830.202.41.111.151.1143084427.squirrel@202.41.111.151> Hi everybody, Does anyone know how to parallelize neb images? Which is faster, k-pt parallelization or image parallelization?? With Regards, Prasenjit. PRASENJIT GHOSH, Ph. D STUDENT, THEORETICAL SCIENCES UNIT, JAWAHARLAL NEHRU CENTRE, JAKKUR P. O., BANGALORE - 560064, INDIA. PHONE:+91-80-22082835 (OFFICE) +91 9880519401 (MOBILE) From sbraccia at sissa.it Thu Mar 23 14:20:30 2006 From: sbraccia at sissa.it (carlo sbraccia) Date: Thu, 23 Mar 2006 08:20:30 -0500 Subject: [Pw_forum] parallelization of neb images In-Reply-To: <35830.202.41.111.151.1143084427.squirrel@202.41.111.151> References: <35830.202.41.111.151.1143084427.squirrel@202.41.111.151> Message-ID: <4422A09E.4060201@sissa.it> The parallelization of neb images (at present available for PWscf only) requires much less interprocessor communication than k-pt parallelization. From this point of view it can be considered "faster" than the other schemes and is particularly indicated on loosely interconnected clusters. On the other hand, load balance can become an issue when you distribute all the neb images to different cpus. The optimal parallelization scheme usually requires the subdivision of all the available cpus into pools and the combination of the three parallelization schemes. Attached are a couple of slides explaining how to set a parallel run (slides are in the openoffice format since the pdf does not fit the limit on the mail-size of this forum). carlo PRASENJIT GHOSH wrote: > Hi everybody, > Does anyone know how to parallelize neb images? > Which is faster, k-pt parallelization or image parallelization?? > With Regards, > Prasenjit. > > PRASENJIT GHOSH, > Ph. D STUDENT, > THEORETICAL SCIENCES UNIT, > JAWAHARLAL NEHRU CENTRE, > JAKKUR P. O., > BANGALORE - 560064, > INDIA. > > PHONE:+91-80-22082835 (OFFICE) > +91 9880519401 (MOBILE) > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > -------------- next part -------------- A non-text attachment was scrubbed... Name: parallel_execution.odp Type: application/vnd.oasis.opendocument.presentation Size: 26922 bytes Desc: not available Url : /pipermail/attachments/20060323/d8d7ecb5/attachment.odp From jamesraynolds at yahoo.com Thu Mar 23 14:33:14 2006 From: jamesraynolds at yahoo.com (james raynolds) Date: Thu, 23 Mar 2006 05:33:14 -0800 (PST) Subject: [Pw_forum] White space error Message-ID: <20060323133314.62535.qmail@web30601.mail.mud.yahoo.com> Dear users, I'm trying to compile pwscf on an AIX machine with xlf90. It compiles with no errors but gives a runtime error of "illegal instruction". Using dbx I find that the error is due to white space in lexical expressions. For example: calling the function f(x) like f (x) with a space between f and (x) gives rise to the error. If I take out the space and call it like f(x) the error goes away. The problem is, there are so many places where this happens that it is impossible to take out all of the spaces. Doing a grep on the string ' (' in the PW directory gives like 9000 places where this happens. Does anyone know a work around?? Any help would be greatly appreciated. Thank you in advance... Sincerely, James E. Raynolds Assistant Professor College of Nanoscale Science and Engineering University at Albany, State University of NY Albany, NY USA __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From giannozz at nest.sns.it Thu Mar 23 14:40:01 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 23 Mar 2006 14:40:01 +0100 Subject: [Pw_forum] White space error In-Reply-To: <20060323133314.62535.qmail@web30601.mail.mud.yahoo.com> References: <20060323133314.62535.qmail@web30601.mail.mud.yahoo.com> Message-ID: <200603231440.02020.giannozz@nest.sns.it> On Thursday 23 March 2006 14:33, james raynolds wrote: > I'm trying to compile pwscf on an AIX machine with xlf90 which version? > It compiles with no errors but gives a runtime error of > "illegal instruction". Using dbx I find that the error is due > to white space in lexical expressions. > > For example: calling the function f(x) like > f (x) > with a space between f and (x) gives rise to the > error. If I take out the space and call it like > f(x) > the error goes away. no way: this doesn't make sense, whatever dbx may say. 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 jamesraynolds at yahoo.com Thu Mar 23 15:01:20 2006 From: jamesraynolds at yahoo.com (james raynolds) Date: Thu, 23 Mar 2006 06:01:20 -0800 (PST) Subject: [Pw_forum] White space error In-Reply-To: <200603231440.02020.giannozz@nest.sns.it> Message-ID: <20060323140120.3092.qmail@web30602.mail.mud.yahoo.com> Paolo, Thank you for the quick reply. The version is 3.0. dbx only tells me the line. When I take the space out it then dies at another similar line. It is probably a faulty compiler. Are there any binaries available? Thanks again. Sincerely, Jim Raynolds --- Paolo Giannozzi wrote: > On Thursday 23 March 2006 14:33, james raynolds > wrote: > > > I'm trying to compile pwscf on an AIX machine with > xlf90 > > which version? > > > It compiles with no errors but gives a runtime > error of > > "illegal instruction". Using dbx I find that the > error is due > > to white space in lexical expressions. > > > > For example: calling the function f(x) like > > f (x) > > with a space between f and (x) gives rise to the > > error. If I take out the space and call it like > > f(x) > > the error goes away. > > no way: this doesn't make sense, whatever dbx may > say. > > 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!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From akohlmey at vitae.cmm.upenn.edu Thu Mar 23 15:51:42 2006 From: akohlmey at vitae.cmm.upenn.edu (Axel Kohlmeyer) Date: Thu, 23 Mar 2006 09:51:42 -0500 (EST) Subject: [Pw_forum] White space error In-Reply-To: <20060323133314.62535.qmail@web30601.mail.mud.yahoo.com> Message-ID: On Thu, 23 Mar 2006, james raynolds wrote: JR> Dear users, JR> JR> I'm trying to compile pwscf on an AIX machine with JR> xlf90. It compiles with no errors but gives a runtime JR> error of "illegal instruction". Using dbx I find that JR> the error is due to white space in lexical JR> expressions. james, this may only be a symptom, e.g. the compiler assumes different semantics and then the linker pics up a different library (or not). 'illegal instruction' happens, if you compile for a different instruction set, e.g. for power5 on a power4 machine, or you are linking the wrong platform specific libraries. please compare the flags in your make.sys file with the hardware you are running on... regards, axel. JR> JR> For example: calling the function f(x) like JR> JR> f (x) JR> JR> with a space between f and (x) gives rise to the JR> error. If I take out the space and call it like JR> JR> f(x) JR> JR> the error goes away. The problem is, there are so JR> many places where this happens that it is impossible JR> to take out all of the spaces. Doing a grep on the JR> string ' (' in the PW directory gives like 9000 JR> places where this happens. JR> JR> Does anyone know a work around?? Any help would be JR> greatly appreciated. Thank you in advance... JR> JR> Sincerely, JR> James E. Raynolds JR> Assistant Professor JR> College of Nanoscale Science and Engineering JR> University at Albany, State University of NY JR> Albany, NY USA JR> JR> __________________________________________________ JR> Do You Yahoo!? JR> Tired of spam? Yahoo! Mail has the best spam protection around JR> http://mail.yahoo.com JR> _______________________________________________ JR> Pw_forum mailing list JR> Pw_forum at pwscf.org JR> http://www.democritos.it/mailman/listinfo/pw_forum JR> -- ======================================================================= Dr. Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu Associate Director - Center for Molecular Modeling - U. of Pennsylvania Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From jamesraynolds at yahoo.com Thu Mar 23 15:59:46 2006 From: jamesraynolds at yahoo.com (james raynolds) Date: Thu, 23 Mar 2006 06:59:46 -0800 (PST) Subject: [Pw_forum] White space error In-Reply-To: Message-ID: <20060323145946.28351.qmail@web30602.mail.mud.yahoo.com> Axel, Excellent! Thanks. I will try it. Jim --- Axel Kohlmeyer wrote: > On Thu, 23 Mar 2006, james raynolds wrote: > > JR> Dear users, > JR> > JR> I'm trying to compile pwscf on an AIX machine > with > JR> xlf90. It compiles with no errors but gives a > runtime > JR> error of "illegal instruction". Using dbx I > find that > JR> the error is due to white space in lexical > JR> expressions. > > james, > this may only be a symptom, e.g. the compiler > assumes > different semantics and then the linker pics up > a different library (or not). > > 'illegal instruction' happens, if you compile for a > different instruction set, e.g. for power5 on a > power4 > machine, or you are linking the wrong platform > specific > libraries. please compare the flags in your make.sys > file > with the hardware you are running on... > > regards, > axel. > > JR> > JR> For example: calling the function f(x) like > JR> > JR> f (x) > JR> > JR> with a space between f and (x) gives rise to the > JR> error. If I take out the space and call it like > JR> > JR> f(x) > JR> > JR> the error goes away. The problem is, there are > so > JR> many places where this happens that it is > impossible > JR> to take out all of the spaces. Doing a grep on > the > JR> string ' (' in the PW directory gives like 9000 > JR> places where this happens. > JR> > JR> Does anyone know a work around?? Any help would > be > JR> greatly appreciated. Thank you in advance... > JR> > JR> Sincerely, > JR> James E. Raynolds > JR> Assistant Professor > JR> College of Nanoscale Science and Engineering > JR> University at Albany, State University of NY > JR> Albany, NY USA > JR> > JR> > __________________________________________________ > JR> Do You Yahoo!? > JR> Tired of spam? Yahoo! Mail has the best spam > protection around > JR> http://mail.yahoo.com > JR> _______________________________________________ > JR> Pw_forum mailing list > JR> Pw_forum at pwscf.org > JR> > http://www.democritos.it/mailman/listinfo/pw_forum > JR> > > -- > ======================================================================= > Dr. Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu > http://www.cmm.upenn.edu > Associate Director - Center for Molecular Modeling - > U. of Pennsylvania > Department of Chemistry, 231 S.34th Street, > Philadelphia, PA 19104-6323 > tel: 1-215-898-1582, fax: 1-215-573-6233, > office-tel: 1-215-898-5425 > ======================================================================= > If you make something idiot-proof, the universe > creates a better idiot. > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From giannozz at nest.sns.it Thu Mar 23 16:05:12 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 23 Mar 2006 16:05:12 +0100 Subject: [Pw_forum] White space error In-Reply-To: <20060323140120.3092.qmail@web30602.mail.mud.yahoo.com> References: <20060323140120.3092.qmail@web30602.mail.mud.yahoo.com> Message-ID: <200603231605.12039.giannozz@nest.sns.it> On Thursday 23 March 2006 15:01, james raynolds wrote: > It is probably a faulty compiler or maybe an old machine for which the default compiler and library options do not apply (see the post by Axel) > Are there any binaries available? as explained in the users' guide, it would be too difficult to have binaries that work for more than a handful of machines. Anyway: AIX is one of the primary development and production platform for this package, so things have to work on any IBM machine running AIX, with a working f90 compiler. If the compiled code fails in such a spectacular way, either the compiler environment and libraries are badly screwed up, or there is some seriously inappropriate option in your make.sys Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From proffess at yandex.ru Thu Mar 23 16:06:05 2006 From: proffess at yandex.ru (Sergey Lisenkov) Date: Thu, 23 Mar 2006 18:06:05 +0300 (MSK) Subject: [Pw_forum] Bi ultrasoft pseudopotential, PBE Message-ID: <4422B95D.000003.28262@pantene.yandex.ru> Dear all, Does anybody have ultrasoft pseudopotential for Bi, PBE approximation? I tried to use LDA parameters as provided on Vanderbilt's website, but the generation was failed... Thanks, Sergey From giannozz at nest.sns.it Thu Mar 23 16:14:07 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 23 Mar 2006 16:14:07 +0100 Subject: [Pw_forum] White space error In-Reply-To: <200603231605.12039.giannozz@nest.sns.it> References: <20060323140120.3092.qmail@web30602.mail.mud.yahoo.com> <200603231605.12039.giannozz@nest.sns.it> Message-ID: <200603231614.07565.giannozz@nest.sns.it> On Thursday 23 March 2006 16:05, Paolo Giannozzi wrote: > AIX is one of the primary development and production platform for > this package, so things have to work on any IBM machine running > AIX, with a working f90 compiler ...and the ESSL libraries, at least for the 3.0 version - P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From eyvaz_isaev at yahoo.com Thu Mar 23 16:41:43 2006 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Thu, 23 Mar 2006 07:41:43 -0800 (PST) Subject: [Pw_forum] Bi ultrasoft pseudopotential, PBE In-Reply-To: <4422B95D.000003.28262@pantene.yandex.ru> Message-ID: <20060323154143.23801.qmail@web60323.mail.yahoo.com> Hi Sergei, I have it. Bests, Eyvaz. --- Sergey Lisenkov wrote: > > Dear all, > > Does anybody have ultrasoft pseudopotential for > Bi, PBE approximation? I tried to use LDA parameters > as provided on Vanderbilt's website, but the > generation was failed... > > Thanks, > Sergey > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From hushujun at mail.sdu.edu.cn Fri Mar 24 07:20:24 2006 From: hushujun at mail.sdu.edu.cn (Shujun Hu) Date: Fri, 24 Mar 2006 14:20:24 +0800 Subject: [Pw_forum] How to extract the new lattice parameter from the output file? Message-ID: <343181224.20114@mail.sdu.edu.cn> Dear Drs, After the vc-relax calculation new lattice vectors are listed at the end of the pw output file: ****************************** Final estimate of lattice vectors (input alat units) 0.995512018 0.003513654 0.003278596 0.003513654 0.995512026 0.003278606 0.006573586 0.006573605 2.028720672 ****************************** It looks like a distorted crystal cell since the input coordinates in tetragonal symmetry are not too nice. I just want to reconstruct the system depending on the new coordinate to do further investigation (scf calculation, not ve-relax again) : ****************************** Fe1 -0.007211587 -0.007210580 0.011331385 Sn 0.492929291 0.492930243 0.346908752 O 0.715072885 0.300388490 0.019456747 O 0.300387360 0.715073779 0.019456807 O 0.834228885 0.834229971 0.329978526 H 0.211445321 0.211446138 0.323097848 ...... ****************************** I found that only the diagonal elements in the new lattice vector matrix above are not enough to reconstructed a healthy suppercell, since if so the output force and stress after a scf calculation are so large, especially for the non-diagonal elements of the stress. But if triclinic symmetry is selected and a1,a2,a3,angle1,angle2 and angle3 are evaluated based on the lattice vector matrix, the final force and stress is small. It seems that the symmetry has been changed. Why does the program not hold the symmetry? The symmetry option in the input file is set as: nosym = .true. An old message from one of our group members had been submitted several days ago, named "How to read lattice constant from the output file of vc-relax". Some help information about the symmetry option from the user's document was posted. Does it means that if .false. is selected, the input symmetry will be maintained? We appreciate for some detailed explanations. Best wishes. Shujun Hu From pwscfklt at gmail.com Fri Mar 24 17:26:31 2006 From: pwscfklt at gmail.com (Konzern) Date: Fri, 24 Mar 2006 11:26:31 -0500 Subject: [Pw_forum] about ph.x Message-ID: Hi everyone, I know that if you want to obtain the phonon DOS or dispersion curve, you should firstly do a scf calculation by pw.x and then an nscf one at a generic q-point followed by a ph.x calculation. When you have finished on a mesh of q-points, you can obtain the real space force constant and then derive the phonon frequencies at any q-point. The ASR is usually applied in the last step. My question is, if it is possible to exert the ASR directly in the ph.x calculation, so we can obtain the same frequencies in that step as those obtained in the last step for a given q-point. Thanks. Konzern -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060324/f111aaa1/attachment.htm From liyanpcl at yahoo.com.cn Tue Mar 28 14:11:35 2006 From: liyanpcl at yahoo.com.cn (li yan) Date: Tue, 28 Mar 2006 20:11:35 +0800 (CST) Subject: [Pw_forum] problem about the calculation of the Raman tensor Message-ID: <20060328121135.31906.qmail@web15605.mail.cnb.yahoo.com> dear all, I calcultated the Raman tensor using the pwscf version 3.0. The scf part run correctly. But the the running of the ph.x will stop unexpectedly. The fowllowing part is the ph.out. Program PHONON v.3.0 starts ... Today is 26Mar2006 at 0:46:20 Ultrasoft (Vanderbilt) Pseudopotentials Reading file SnO.save ... only dimensions read complete Reading file SnO.save ... all except wavefuctions read complete nbndx = 10 nbnd = 10 natomwfc = 64 npwx = 9600 nelec = 20.00 nkb = 52 ngl = 4494 WRITING PATTERNS TO FILE drho.pat phonons of SnO at Gamma ........................ ......................... ........................ Dielectric constant from finite-differences ( 9.668658880 0.000000000 0.000000000 ) ( 0.000000000 9.668658880 0.000000000 ) ( 0.000000000 0.000000000 6.794783712 ) Electro-optic tensor is defined as the derivative of the dielectric tensor with respect to one electric field units are Rydberg a.u. to obtain the static chi^2 multiply by 1/2 to convert to pm/Volt multiply per 2.7502 Electro-optic tensor in cartesian axis: ( 0.000000000 0.000000000 0.000000000 ) ( 0.000000000 0.000000000 0.000000000 ) ( 0.000000000 0.000000000 0.000000000 ) ( 0.000000000 0.000000000 0.000000000 ) ( 0.000000000 0.000000000 0.000000000 ) ( 0.000000000 0.000000000 0.000000000 ) ( 0.000000000 0.000000000 0.000000000 ) ( 0.000000000 0.000000000 0.000000000 ) ( 0.000000000 0.000000000 0.000000000 ) Computing Second order response iter # 1 av.it.: 13.9 thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.476E-02 " It stopped here without any error warning. So I the change parameters such as tr2_ph, kpoints and ecut to the lower limitition. It run correctly. But "Electro-optic tensor in cartesian axis" is the same as above. So please help me with this. ps: the phonon frequencies at Gama point can be calculated freely. --------------------------------- ??1G??????????? ????-????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060328/ee026bef/attachment.htm From giannozz at nest.sns.it Tue Mar 28 14:20:15 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 28 Mar 2006 14:20:15 +0200 Subject: [Pw_forum] problem about the calculation of the Raman tensor In-Reply-To: <20060328121135.31906.qmail@web15605.mail.cnb.yahoo.com> References: <20060328121135.31906.qmail@web15605.mail.cnb.yahoo.com> Message-ID: <200603281420.15076.giannozz@nest.sns.it> On Tuesday 28 March 2006 14:11, li yan wrote: > I calcultated the Raman tensor using the pwscf version 3.0. The scf > part run correctly. But the the running of the ph.x will stop unexpectedly. > [...] > Computing Second order response > > iter # 1 av.it.: 13.9 > thresh= 0.100E-01 alpha_mix = 0.700 |ddv_scf|^2 = 0.476E-02 " > > It stopped here without any error warning. it may have hit a memory limit. It is impossible to say anything without a test job. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From naromero at gmail.com Wed Mar 29 00:04:45 2006 From: naromero at gmail.com (Nichols A. Romero) Date: Tue, 28 Mar 2006 17:04:45 -0500 Subject: [Pw_forum] question on electron_dynamics and orthogonalization Message-ID: <6ac064b60603281404q18c416a4t9a6484ab0abc7ab3@mail.gmail.com> Hey, This is a question about CP code (i.e. not PWSCF). I am using the CVS version. Are the keywords electron_dynamics & orthogonolization completely independent of each other when electron_dynamics = 'cg' Forgive, my ignorance. I am mostly familiar with the PWSCF component of Q-Espresso. When doing an initial 'cg' calculation to get the groundstate on the BO surface, doesn't the 'cg' routines impose the orthonomality constraint automattically? Why does one need a seperate *orthogonalization* keyword? (which has two different options?) Thanks, -- Nichols A. Romero, Ph.D. 1613 Denise Dr. Apt. D Forest Hill, MD 21050 443-567-8328 (C) 410-306-0709 (O) From marzari at MIT.EDU Wed Mar 29 00:45:15 2006 From: marzari at MIT.EDU (Nicola Marzari) Date: Wed, 29 Mar 2006 00:45:15 +0200 Subject: [Pw_forum] question on electron_dynamics and orthogonalization In-Reply-To: <6ac064b60603281404q18c416a4t9a6484ab0abc7ab3@mail.gmail.com> References: <6ac064b60603281404q18c416a4t9a6484ab0abc7ab3@mail.gmail.com> Message-ID: <4429BC7B.4060104@mit.edu> Nichols, I'll let Paolo or Kostya or Ismaila confirm, but my guess is that once electron-dynamics is "cg" you want a gram-schmidt orthogonalization. We might implement an iterative ortho sometimes in the future, but I believe at this stage gram-schmidt is the only choice. Note that the latest CVS (2-3 days ago) has a number of calbec calls removed, and should be faster. We are still optimizing the code, but it should be fairly robust at this stage - let us know of any feedback you might have. nicola Nichols A. Romero wrote: > Hey, > > This is a question about CP code (i.e. not PWSCF). I am using the CVS version. > > Are the keywords > > electron_dynamics & orthogonolization > > completely independent of each other when > electron_dynamics = 'cg' > > Forgive, my ignorance. I am mostly familiar with the PWSCF component > of Q-Espresso. > > When doing an initial 'cg' calculation to get the groundstate on the > BO surface, doesn't the 'cg' routines impose the orthonomality > constraint automattically? Why does one need a seperate > *orthogonalization* keyword? (which has two different options?) > > Thanks, > -- > Nichols A. Romero, Ph.D. > 1613 Denise Dr. Apt. D > Forest Hill, MD 21050 > 443-567-8328 (C) > 410-306-0709 (O) > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum -- --------------------------------------------------------------------- Prof Nicola Marzari Department of Materials Science and Engineering 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu From naromero at gmail.com Wed Mar 29 22:26:39 2006 From: naromero at gmail.com (Nichols A. Romero) Date: Wed, 29 Mar 2006 15:26:39 -0500 Subject: [Pw_forum] question on electron_dynamics and orthogonalization In-Reply-To: <4429BC7B.4060104@mit.edu> References: <6ac064b60603281404q18c416a4t9a6484ab0abc7ab3@mail.gmail.com> <4429BC7B.4060104@mit.edu> Message-ID: <6ac064b60603291226g54593819sabc9a3f9b74897@mail.gmail.com> Nicola (or anyone else on this list), I am going to ask a question that get's asked on this list very frequently (possibly second only to "Why doesn't the code compile?"). I am struggling with trying to get PWSCF and the CP code to agree. I am sure the PWSCF is correct, but I don't know about the CP calculation. All I want to immediately do with the CP is to calculate the ground state and have it agree with PWSCF. Though the next step is to do BO MD with the CP code (which I remember correctly, is still in the testing phase). I'm attaching a model problem I've been playing with for the last two days. I include the input and outputfiles. The US_PP are of the PBE RRKJ type that are found on the PWSCF website. It should run fairly quickly on a desktop computer. I would appreciate any help at this point. I'm sure that I am not understand the definition of some of the CP parameters. FYI, I am using the CVS version of Q-ESPRESSO as stated in my previous e-mail. Bests, On 3/28/06, Nicola Marzari wrote: > > > Nichols, > > I'll let Paolo or Kostya or Ismaila confirm, but my guess is that once > electron-dynamics is "cg" you want a gram-schmidt orthogonalization. > > We might implement an iterative ortho sometimes in the future, but I > believe at this stage gram-schmidt is the only choice. > > Note that the latest CVS (2-3 days ago) has a number of calbec calls > removed, and should be faster. > > We are still optimizing the code, but it should be fairly robust at this > stage - let us know of any feedback you might have. > > nicola > > > Nichols A. Romero wrote: > > > Hey, > > > > This is a question about CP code (i.e. not PWSCF). I am using the CVS version. > > > > Are the keywords > > > > electron_dynamics & orthogonolization > > > > completely independent of each other when > > electron_dynamics = 'cg' > > > > Forgive, my ignorance. I am mostly familiar with the PWSCF component > > of Q-Espresso. > > > > When doing an initial 'cg' calculation to get the groundstate on the > > BO surface, doesn't the 'cg' routines impose the orthonomality > > constraint automattically? Why does one need a seperate > > *orthogonalization* keyword? (which has two different options?) > > > > Thanks, > > -- > > Nichols A. Romero, Ph.D. > > 1613 Denise Dr. Apt. D > > Forest Hill, MD 21050 > > 443-567-8328 (C) > > 410-306-0709 (O) > > _______________________________________________ > > Pw_forum mailing list > > Pw_forum at pwscf.org > > http://www.democritos.it/mailman/listinfo/pw_forum > > -- > --------------------------------------------------------------------- > Prof Nicola Marzari Department of Materials Science and Engineering > 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA > tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > -- Nichols A. Romero, Ph.D. 1613 Denise Dr. Apt. D Forest Hill, MD 21050 443-567-8328 (C) 410-306-0709 (O) -------------- next part -------------- A non-text attachment was scrubbed... Name: nitromethane.tar.gz Type: application/x-gzip Size: 13989 bytes Desc: not available Url : /pipermail/attachments/20060329/6ac17dc6/attachment.bin From marzari at MIT.EDU Wed Mar 29 22:49:05 2006 From: marzari at MIT.EDU (Nicola Marzari) Date: Wed, 29 Mar 2006 15:49:05 -0500 Subject: [Pw_forum] question on electron_dynamics and orthogonalization In-Reply-To: <6ac064b60603291226g54593819sabc9a3f9b74897@mail.gmail.com> References: <6ac064b60603281404q18c416a4t9a6484ab0abc7ab3@mail.gmail.com> <4429BC7B.4060104@mit.edu> <6ac064b60603291226g54593819sabc9a3f9b74897@mail.gmail.com> Message-ID: <442AF2C1.2040203@mit.edu> Hi Nichols, what you are doing is extremely useful. The two calculations seem actually in good agreement, but of course beauty is in the eye of the beholder. The total energies are within 1 mRy of each other, and the forces seem to have a factor of 2 difference (that is correct - in PWSCF the forces are in Ry/bohr, while in CP they are in Ha/bohr; PWSCF labels the forces as Ry/au, that is the same as saying Ry/bohr, and CP says that they are in atomic units, and atomic units for the forces are Ha/bohr). The eigenvalues are different, but as long as it's a rigid shift between the two, we are fine (the two codes have clearly a different measure of what is zero in the energy scale - maybe someone could comment on this). The stresses are wildly different, but this is a bug we also noticed a week ago, and Paolo Giannozzi and Carlo Cavazzoni are tracking it down. Bug in CP. Let us know - if you want an ultimate comparison, try to run both in serial, make sure that the fft grids are the same (they are, in your case, 40 45 64), tighten the tolerance on the energy convergence as much as possible, and see what you get - it helps having an unrelaxed, out of equilibrium structure, so you get forces that are fairly large. But the agreement between the codes seems actually very good, at this stage - a part from the stress. Let us know if you find something else that I might have missed. Thanks, nicola Nichols A. Romero wrote: > Nicola (or anyone else on this list), > > I am going to ask a question that get's asked on this list very > frequently (possibly second only to "Why doesn't the code compile?"). > > I am struggling with trying to get PWSCF and the CP code to agree. I > am sure the PWSCF is correct, but I don't know about the CP > calculation. All I want to immediately do with the CP is to calculate > the ground state and have it agree with PWSCF. Though the next step is > to do BO MD with the CP code (which I remember correctly, is still in > the testing phase). > > I'm attaching a model problem I've been playing with for the last two > days. I include the input and outputfiles. The US_PP are of the PBE > RRKJ type that are found on the PWSCF website. It should run fairly > quickly on a desktop computer. > > I would appreciate any help at this point. I'm sure that I am not > understand the definition of some of the CP parameters. FYI, I am > using the CVS version of Q-ESPRESSO as stated in my previous e-mail. > > > Bests, > On 3/28/06, Nicola Marzari wrote: > >> >>Nichols, >> >>I'll let Paolo or Kostya or Ismaila confirm, but my guess is that once >>electron-dynamics is "cg" you want a gram-schmidt orthogonalization. >> >>We might implement an iterative ortho sometimes in the future, but I >>believe at this stage gram-schmidt is the only choice. >> >>Note that the latest CVS (2-3 days ago) has a number of calbec calls >>removed, and should be faster. >> >>We are still optimizing the code, but it should be fairly robust at this >>stage - let us know of any feedback you might have. >> >> nicola >> >> >>Nichols A. Romero wrote: >> >> >>>Hey, >>> >>>This is a question about CP code (i.e. not PWSCF). I am using the CVS version. >>> >>>Are the keywords >>> >>>electron_dynamics & orthogonolization >>> >>>completely independent of each other when >>>electron_dynamics = 'cg' >>> >>>Forgive, my ignorance. I am mostly familiar with the PWSCF component >>>of Q-Espresso. >>> >>>When doing an initial 'cg' calculation to get the groundstate on the >>>BO surface, doesn't the 'cg' routines impose the orthonomality >>>constraint automattically? Why does one need a seperate >>>*orthogonalization* keyword? (which has two different options?) >>> >>>Thanks, >>>-- >>>Nichols A. Romero, Ph.D. >>>1613 Denise Dr. Apt. D >>>Forest Hill, MD 21050 >>>443-567-8328 (C) >>>410-306-0709 (O) >>>_______________________________________________ >>>Pw_forum mailing list >>>Pw_forum at pwscf.org >>>http://www.democritos.it/mailman/listinfo/pw_forum >> >>-- >>--------------------------------------------------------------------- >>Prof Nicola Marzari Department of Materials Science and Engineering >>13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA >>tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu >>_______________________________________________ >>Pw_forum mailing list >>Pw_forum at pwscf.org >>http://www.democritos.it/mailman/listinfo/pw_forum >> > > > > -- > Nichols A. Romero, Ph.D. > 1613 Denise Dr. Apt. D > Forest Hill, MD 21050 > 443-567-8328 (C) > 410-306-0709 (O) -- --------------------------------------------------------------------- Prof Nicola Marzari Department of Materials Science and Engineering 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu From naromero at gmail.com Wed Mar 29 23:57:37 2006 From: naromero at gmail.com (Nichols A. Romero) Date: Wed, 29 Mar 2006 16:57:37 -0500 Subject: [Pw_forum] question on electron_dynamics and orthogonalization In-Reply-To: <442AF2C1.2040203@mit.edu> References: <6ac064b60603281404q18c416a4t9a6484ab0abc7ab3@mail.gmail.com> <4429BC7B.4060104@mit.edu> <6ac064b60603291226g54593819sabc9a3f9b74897@mail.gmail.com> <442AF2C1.2040203@mit.edu> Message-ID: <6ac064b60603291357s6daa4e5bg1a24339fd13dc983@mail.gmail.com> Hi Nicola, Thanks for pointing out the differences in the units for the forces between the two codes. It was primarily in the stress which I noticed the wild disagreement. I *think* that I saw this problem in Q-Epresso 3.0 but I did not make any comments at the time because I wasn't sure if I was using CP correctly. The model system I gave you was nitromethane obtained via PWSCF using vc-relax with a target stress of 5 GPa at T=0. It's probably near equilibrium at that pressure. I will play with it a bit more to see if I can isolate the problem. I do recall that the stress changes on the order of 0.5 GPa per component when I changed either emass_cutoff or nr1b,nr2b,nr3b However, given that the total energy convergence was not set particularly high in my calculation to begin with, this behavior is not a surprise. Bests, On 3/29/06, Nicola Marzari wrote: > > > Hi Nichols, > > what you are doing is extremely useful. > > The two calculations seem actually in good agreement, but of > course beauty is in the eye of the beholder. > > The total energies are within 1 mRy of each other, and the forces > seem to have a factor of 2 difference (that is correct - in PWSCF > the forces are in Ry/bohr, while in CP they are in Ha/bohr; PWSCF > labels the forces as Ry/au, that is the same as saying Ry/bohr, > and CP says that they are in atomic units, and atomic units for the > forces are Ha/bohr). > > The eigenvalues are different, but as long as it's a rigid shift between > the two, we are fine (the two codes have clearly a different measure of > what is zero in the energy scale - maybe someone could comment on this). > > The stresses are wildly different, but this is a bug we also noticed a > week ago, and Paolo Giannozzi and Carlo Cavazzoni are tracking it down. > Bug in CP. > > Let us know - if you want an ultimate comparison, try to run both in > serial, make sure that the fft grids are the same (they are, in your > case, 40 45 64), tighten the tolerance on the energy convergence as much > as possible, and see what you get - it helps having an unrelaxed, out > of equilibrium structure, so you get forces that are fairly large. > > But the agreement between the codes seems actually very good, at this > stage - a part from the stress. > > Let us know if you find something else that I might have missed. > > Thanks, > > nicola > > > Nichols A. Romero wrote: > > > Nicola (or anyone else on this list), > > > > I am going to ask a question that get's asked on this list very > > frequently (possibly second only to "Why doesn't the code compile?"). > > > > I am struggling with trying to get PWSCF and the CP code to agree. I > > am sure the PWSCF is correct, but I don't know about the CP > > calculation. All I want to immediately do with the CP is to calculate > > the ground state and have it agree with PWSCF. Though the next step is > > to do BO MD with the CP code (which I remember correctly, is still in > > the testing phase). > > > > I'm attaching a model problem I've been playing with for the last two > > days. I include the input and outputfiles. The US_PP are of the PBE > > RRKJ type that are found on the PWSCF website. It should run fairly > > quickly on a desktop computer. > > > > I would appreciate any help at this point. I'm sure that I am not > > understand the definition of some of the CP parameters. FYI, I am > > using the CVS version of Q-ESPRESSO as stated in my previous e-mail. > > > > > > Bests, > > On 3/28/06, Nicola Marzari wrote: > > > >> > >>Nichols, > >> > >>I'll let Paolo or Kostya or Ismaila confirm, but my guess is that once > >>electron-dynamics is "cg" you want a gram-schmidt orthogonalization. > >> > >>We might implement an iterative ortho sometimes in the future, but I > >>believe at this stage gram-schmidt is the only choice. > >> > >>Note that the latest CVS (2-3 days ago) has a number of calbec calls > >>removed, and should be faster. > >> > >>We are still optimizing the code, but it should be fairly robust at this > >>stage - let us know of any feedback you might have. > >> > >> nicola > >> > >> > >>Nichols A. Romero wrote: > >> > >> > >>>Hey, > >>> > >>>This is a question about CP code (i.e. not PWSCF). I am using the CVS version. > >>> > >>>Are the keywords > >>> > >>>electron_dynamics & orthogonolization > >>> > >>>completely independent of each other when > >>>electron_dynamics = 'cg' > >>> > >>>Forgive, my ignorance. I am mostly familiar with the PWSCF component > >>>of Q-Espresso. > >>> > >>>When doing an initial 'cg' calculation to get the groundstate on the > >>>BO surface, doesn't the 'cg' routines impose the orthonomality > >>>constraint automattically? Why does one need a seperate > >>>*orthogonalization* keyword? (which has two different options?) > >>> > >>>Thanks, > >>>-- > >>>Nichols A. Romero, Ph.D. > >>>1613 Denise Dr. Apt. D > >>>Forest Hill, MD 21050 > >>>443-567-8328 (C) > >>>410-306-0709 (O) > >>>_______________________________________________ > >>>Pw_forum mailing list > >>>Pw_forum at pwscf.org > >>>http://www.democritos.it/mailman/listinfo/pw_forum > >> > >>-- > >>--------------------------------------------------------------------- > >>Prof Nicola Marzari Department of Materials Science and Engineering > >>13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA > >>tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu > >>_______________________________________________ > >>Pw_forum mailing list > >>Pw_forum at pwscf.org > >>http://www.democritos.it/mailman/listinfo/pw_forum > >> > > > > > > > > -- > > Nichols A. Romero, Ph.D. > > 1613 Denise Dr. Apt. D > > Forest Hill, MD 21050 > > 443-567-8328 (C) > > 410-306-0709 (O) > > -- > --------------------------------------------------------------------- > Prof Nicola Marzari Department of Materials Science and Engineering > 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA > tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > -- Nichols A. Romero, Ph.D. 1613 Denise Dr. Apt. D Forest Hill, MD 21050 443-567-8328 (C) 410-306-0709 (O) From marzari at MIT.EDU Thu Mar 30 00:05:57 2006 From: marzari at MIT.EDU (Nicola Marzari) Date: Wed, 29 Mar 2006 17:05:57 -0500 Subject: [Pw_forum] question on electron_dynamics and orthogonalization In-Reply-To: <6ac064b60603291357s6daa4e5bg1a24339fd13dc983@mail.gmail.com> References: <6ac064b60603281404q18c416a4t9a6484ab0abc7ab3@mail.gmail.com> <4429BC7B.4060104@mit.edu> <6ac064b60603291226g54593819sabc9a3f9b74897@mail.gmail.com> <442AF2C1.2040203@mit.edu> <6ac064b60603291357s6daa4e5bg1a24339fd13dc983@mail.gmail.com> Message-ID: <442B04C5.6090109@mit.edu> Thanks. > I will play with it a bit more to see if I can isolate the problem. I > do recall that the stress changes on the order of 0.5 GPa per > component when I changed either > emass_cutoff > or > nr1b,nr2b,nr3b > The only reason while it would change with emass_cutoff is that you are not perfectly converged (I think). With enough iterations, emass_cutoff shouldn't matter; it is just a preconditioning to take into account that the hamiltonian is diagonally dominanant, in a plane wave basis set, with the diagonal diverging as G^2. nr1b... etc: well, let's revisit this as soon as CP is fixed. Paolo and Carlo have been kindly working on this. nicola --------------------------------------------------------------------- Prof Nicola Marzari Department of Materials Science and Engineering 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu From naromero at gmail.com Thu Mar 30 00:41:11 2006 From: naromero at gmail.com (Nichols A. Romero) Date: Wed, 29 Mar 2006 17:41:11 -0500 Subject: [Pw_forum] question on electron_dynamics and orthogonalization In-Reply-To: <442B04C5.6090109@mit.edu> References: <6ac064b60603281404q18c416a4t9a6484ab0abc7ab3@mail.gmail.com> <4429BC7B.4060104@mit.edu> <6ac064b60603291226g54593819sabc9a3f9b74897@mail.gmail.com> <442AF2C1.2040203@mit.edu> <6ac064b60603291357s6daa4e5bg1a24339fd13dc983@mail.gmail.com> <442B04C5.6090109@mit.edu> Message-ID: <6ac064b60603291441m4f2b14c2i8b9d8e8aed3b8717@mail.gmail.com> Nicola, I notice that when I compile the code in serial mode (i.e. removed both -D__MPI and -D__PARA) and then run the same calculation I get a stress tensor of zero. I'm attaching my output. The forces and energies do not change. On 3/29/06, Nicola Marzari wrote: > > Thanks. > > > I will play with it a bit more to see if I can isolate the problem. I > > do recall that the stress changes on the order of 0.5 GPa per > > component when I changed either > > emass_cutoff > > or > > nr1b,nr2b,nr3b > > > > The only reason while it would change with emass_cutoff is that > you are not perfectly converged (I think). With enough iterations, > emass_cutoff shouldn't matter; it is just a preconditioning to take > into account that the hamiltonian is diagonally dominanant, in a plane > wave basis set, with the diagonal diverging as G^2. > > nr1b... etc: well, let's revisit this as soon as CP is fixed. Paolo > and Carlo have been kindly working on this. > > nicola > > > --------------------------------------------------------------------- > Prof Nicola Marzari Department of Materials Science and Engineering > 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA > tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > -- Nichols A. Romero, Ph.D. 1613 Denise Dr. Apt. D Forest Hill, MD 21050 443-567-8328 (C) 410-306-0709 (O) -------------- next part -------------- A non-text attachment was scrubbed... Name: nitromethane.cp.out.serial Type: application/octet-stream Size: 22456 bytes Desc: not available Url : /pipermail/attachments/20060329/7824e453/attachment.obj From silviu at Princeton.EDU Thu Mar 30 08:33:16 2006 From: silviu at Princeton.EDU (Silviu Zilberman) Date: Thu, 30 Mar 2006 08:33:16 +0200 Subject: [Pw_forum] question on electron_dynamics and orthogonalization In-Reply-To: <6ac064b60603291226g54593819sabc9a3f9b74897@mail.gmail.com> References: <6ac064b60603281404q18c416a4t9a6484ab0abc7ab3@mail.gmail.com> <4429BC7B.4060104@mit.edu> <6ac064b60603291226g54593819sabc9a3f9b74897@mail.gmail.com> Message-ID: <442B7BAC.1070201@Princeton.EDU> Nicolas, There is a difference in the way CP and PW handle USPP. In CP you have the small boxes around the augmented charge, that help reduce the unphysical charge oscillations. There should be a small difference between CP ans PW results. There are two ways to validate it: (a) use norm-conserving PP instead of USPP, or (b) increase the cut-off to reduce the charge oscillations in PW. In the former case the results should be identical, while in the later the difference should become smaller as you increase the cut-off. Regards, Silviu. Nichols A. Romero wrote: > Nicola (or anyone else on this list), > > I am going to ask a question that get's asked on this list very > frequently (possibly second only to "Why doesn't the code compile?"). > > I am struggling with trying to get PWSCF and the CP code to agree. I > am sure the PWSCF is correct, but I don't know about the CP > calculation. All I want to immediately do with the CP is to calculate > the ground state and have it agree with PWSCF. Though the next step is > to do BO MD with the CP code (which I remember correctly, is still in > the testing phase). > > I'm attaching a model problem I've been playing with for the last two > days. I include the input and outputfiles. The US_PP are of the PBE > RRKJ type that are found on the PWSCF website. It should run fairly > quickly on a desktop computer. > > I would appreciate any help at this point. I'm sure that I am not > understand the definition of some of the CP parameters. FYI, I am > using the CVS version of Q-ESPRESSO as stated in my previous e-mail. > > > Bests, > On 3/28/06, Nicola Marzari wrote: > >> Nichols, >> >> I'll let Paolo or Kostya or Ismaila confirm, but my guess is that once >> electron-dynamics is "cg" you want a gram-schmidt orthogonalization. >> >> We might implement an iterative ortho sometimes in the future, but I >> believe at this stage gram-schmidt is the only choice. >> >> Note that the latest CVS (2-3 days ago) has a number of calbec calls >> removed, and should be faster. >> >> We are still optimizing the code, but it should be fairly robust at this >> stage - let us know of any feedback you might have. >> >> nicola >> >> >> Nichols A. Romero wrote: >> >> >>> Hey, >>> >>> This is a question about CP code (i.e. not PWSCF). I am using the CVS version. >>> >>> Are the keywords >>> >>> electron_dynamics & orthogonolization >>> >>> completely independent of each other when >>> electron_dynamics = 'cg' >>> >>> Forgive, my ignorance. I am mostly familiar with the PWSCF component >>> of Q-Espresso. >>> >>> When doing an initial 'cg' calculation to get the groundstate on the >>> BO surface, doesn't the 'cg' routines impose the orthonomality >>> constraint automattically? Why does one need a seperate >>> *orthogonalization* keyword? (which has two different options?) >>> >>> Thanks, >>> -- >>> Nichols A. Romero, Ph.D. >>> 1613 Denise Dr. Apt. D >>> Forest Hill, MD 21050 >>> 443-567-8328 (C) >>> 410-306-0709 (O) >>> _______________________________________________ >>> Pw_forum mailing list >>> Pw_forum at pwscf.org >>> http://www.democritos.it/mailman/listinfo/pw_forum >>> >> -- >> --------------------------------------------------------------------- >> Prof Nicola Marzari Department of Materials Science and Engineering >> 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA >> tel 617.4522758 fax 2586534 marzari at mit.edu http://quasiamore.mit.edu >> _______________________________________________ >> Pw_forum mailing list >> Pw_forum at pwscf.org >> http://www.democritos.it/mailman/listinfo/pw_forum >> >> > > > -- > Nichols A. Romero, Ph.D. > 1613 Denise Dr. Apt. D > Forest Hill, MD 21050 > 443-567-8328 (C) > 410-306-0709 (O) > From hjlyw1983 at gmail.com Thu Mar 30 10:35:36 2006 From: hjlyw1983 at gmail.com (hjlyw1983 hjlyw1983) Date: Thu, 30 Mar 2006 16:35:36 +0800 Subject: [Pw_forum] a error when caculate phonon using version3.0! Message-ID: Dear all: When I caculated the phonon of SnO at Gamma point using the version3.0, a part of the result as below: Raman tensor (A^2) atom # 1 pol. 1 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 atom # 1 pol. 2 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 atom # 1 pol. 3 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 atom # 2 pol. 1 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 atom # 2 pol. 2 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 atom # 2 pol. 3 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 atom # 3 pol. 1 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 atom # 3 pol. 2 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 atom # 3 pol. 3 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 atom # 4 pol. 1 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 atom # 4 pol. 2 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 atom # 4 pol. 3 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00 all the values or Raman tensor are zero, I think there is no error in my inputfile, and my input file as below: phonons of SnO at Gamma &inputph tr2_ph=1.0d-15, prefix='SnO', epsil=.true., amass(1)=118.69, amass(2)=15.999, trans=.true., lraman=.true., elop=.true. recover=.true. outdir='/pwscftmp/lyw/tmp/tmp1/', fildyn='SnO.dynG', fildrho='SnO.drho', / 0.0 0.0 0.0 Waiting for your help! thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060330/b44d9724/attachment.htm From davegp at civet.berkeley.edu Thu Mar 30 11:37:32 2006 From: davegp at civet.berkeley.edu (David Prendergast) Date: Thu, 30 Mar 2006 01:37:32 -0800 Subject: [Pw_forum] Modification of sort.f90 in v-3.0 Message-ID: <442BA6DC.5070507@civet.berkeley.edu> Hi users, If this issue has already been addressed, please forgive me for producing spam... Please note that there is a significant change to the subroutine hpsort_eps in the espresso-3.0 distribution with respect to previous versions. (look in $ESPRESSO/flib/sort.f90) This routine is used in ordering the list of G-vectors by magnitude ($ESPRESSO/PW/ggen.f90) and is important for those who wish to know the mapping between G-vectors and wave function coefficients, as stored in the .save file. Previous versions (before 3.0) contained a sort algorithm which reordered G-vectors even if they had the same magnitude. Please note that this is no cause for alarm. This had no bad effects since the ordering was kept consistent throughout the code. The new, modified sort algorithm preserves the original ordering if the magnitudes are the same. Fixing this bug is a definite improvement, however, it would be good to list such a major change in the log files provided in the directory $ESPRESSO/Doc/. This would allow users to more effectively update their own tools between new releases of espresso. David. -- OoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo David Prendergast University of California, Berkeley phone: (510) 642-2635 Department of Physics fax: (510) 643-9473 366 LeConte Hall #7300 email: davegp at civet.berkeley.edu Berkeley, CA 94720-7300 web: http://civet.berkeley.edu/~davegp OoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo From giannozz at nest.sns.it Thu Mar 30 11:55:38 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 30 Mar 2006 11:55:38 +0200 Subject: [Pw_forum] question on electron_dynamics and orthogonalization In-Reply-To: <6ac064b60603291226g54593819sabc9a3f9b74897@mail.gmail.com> References: <6ac064b60603281404q18c416a4t9a6484ab0abc7ab3@mail.gmail.com> <4429BC7B.4060104@mit.edu> <6ac064b60603291226g54593819sabc9a3f9b74897@mail.gmail.com> Message-ID: <200603301155.38618.giannozz@nest.sns.it> On Wednesday 29 March 2006 22:26, Nichols A. Romero wrote: > I am struggling with trying to get PWSCF and the CP code to agree. > [...] I'm attaching a model problem I've been playing with for the > last two days. thank you for providing simple, useful examples. * as mentioned by Nicola M., the agreement between energies and forces in PW and CP in your test is very good, once you take into account the different units * there is a difference in the definition of V(0) that affects, as a rigid shift, the eigenvalues: see attached notes. I don't know which one is "better" (i.e. converges faster to the limit of infinite cell size). I like the PW definition better: the CP one is in my opinion arbitrary. * The convergence of eigenvalues with cutoff may be quite slow, expecially for higher-energy states, and different in CP and PW (because of the "small boxes" in CP, as mentioned by Silviu) * two rather exotic bugs in stress calculation in PW: - gamma point + l=0 nonlocality only + parallelization - gamma point + LSDA have been fixed only very recently (8 and 16 march) * there is a known problem with stress calculation in CP, related to l>0 nonlocality. The error is rather small but not negligible. Sooner or later we'll find it. This is the bug Nicola M. was referring to. * Stresses calculated in CP with the 'cg' option in your example are completely bogus. Most likely, stress calculation is not implemented in the 'cg' case. This is a different bug from the one above Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy -------------- next part -------------- A non-text attachment was scrubbed... Name: ewald.tex Type: text/x-tex Size: 15178 bytes Desc: not available Url : /pipermail/attachments/20060330/c1890b30/attachment.tex From giannozz at nest.sns.it Thu Mar 30 12:26:29 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 30 Mar 2006 12:26:29 +0200 Subject: [Pw_forum] a error when caculate phonon using version3.0! In-Reply-To: References: Message-ID: <200603301226.29324.giannozz@nest.sns.it> On Thursday 30 March 2006 10:35, hjlyw1983 hjlyw1983 wrote: > I think there is no error in my inputfile, and my input file as below: we need the input file for pw.x as well 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 hjlyw1983 at gmail.com Thu Mar 30 12:43:51 2006 From: hjlyw1983 at gmail.com (hjlyw1983 hjlyw1983) Date: Thu, 30 Mar 2006 18:43:51 +0800 Subject: [Pw_forum] Re: a error when caculate phonon using version3.0! Message-ID: hello! My input file for pw.x as follow: &control calculation = 'scf' restart_mode='from_scratch', prefix='SnO', tstress = .true. tprnfor = .true. pseudo_dir = '/home/user56/pwwork/pseudo/', outdir='/pwscftmp/lyw/tmp/tmp1/' / &system ibrav= 6, celldm(1) =7.2662,celldm(3) =1.2784, nat= 4, ntyp= 2, ecutwfc =110, / &electrons mixing_beta = 0.7 conv_thr = 1.0d-8 / ATOMIC_SPECIES Sn 118.69 Sn.cpi.UPF O 15.999 O.cpi.UPF ATOMIC_POSITIONS {crystal} Sn 0.5 0.0 0.2345447 Sn 0.0 0.5 0.7654553 O 0.0 0.0 0.000 O 0.5 0.5 0.000 K_POINTS {automatic} 8 8 6 0 0 0 Please help me! Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20060330/7b41e5bd/attachment.htm From quevedin at gmail.com Thu Mar 30 15:57:41 2006 From: quevedin at gmail.com (Lucas Fernandez Seivane) Date: Thu, 30 Mar 2006 15:57:41 +0200 Subject: [Pw_forum] Help generating Pd pseudo Message-ID: <2ebe300a0603300557q47243a0bx539bb36fc6e70376@mail.gmail.com> Hi to all in the list I am trying to generate a fully relativistic pseudo for Pd. But with these parameters I always get magnetic Pd! Do you see anything wrong in the input? Best wishes to all Lucas Fern?ndez Seivane Ph.D. student, Universidad de Oviedo, Spain &input title='Pd', zed=46.0, rel=2, iswitch=3, rlderiv=2.50, eminld=-3.0, emaxld=3.0, deld=0.02, nld=5, config='[Kr] 4d9 5s1 5p0', dft='LDA' / &inputp pseudotype=3, lloc=0, file_pseudopw='PdrelNN.RRKJ3', nlcc=.false. / 7 4D 3 2 4.00 0.00 1.80 2.40 1.50 4D 3 2 0.00 -0.20 1.80 2.40 1.50 4D 3 2 5.00 0.00 1.80 2.40 2.50 4D 3 2 0.00 -0.20 1.80 2.40 2.50 5P 2 1 0.00 0.00 2.40 2.40 0.50 5P 2 1 0.00 -0.00 2.40 2.40 1.50 5S 1 0 1.00 0.00 2.40 2.40 0.50 From stewart at cnf.cornell.edu Thu Mar 30 16:55:54 2006 From: stewart at cnf.cornell.edu (stewart at cnf.cornell.edu) Date: Thu, 30 Mar 2006 09:55:54 -0500 Subject: [Pw_forum] Re: Help generating Pd pseudo In-Reply-To: <2ebe300a0603300557q47243a0bx539bb36fc6e70376@mail.gmail.com> References: <2ebe300a0603300557q47243a0bx539bb36fc6e70376@mail.gmail.com> Message-ID: <20060330145554.13379.qmail@xuxa.iecc.com> Hi Lucas, Palladium has a high magnetic susceptibility and sits right on the edge of magnetism. I have been looking at nanostructures based on Pd and I have found that the pseudopotential choice is very crucial in determining whether you get the correct non-magnetic fcc ground state. All pseudopotentials predict that as you expand the palladium lattice, you should see a transition to a magnetic state. However, of the four pseudopotentials available on the PWscf website, only the Perdew-Zunger (LDA) with non-linear core correction and the semi-core d valence state (Pd.pz-nd-rrkjus.UPF) gives the correct non-magnetic fcc ground state. All varieties of GGA psp predict a ground magnetic state, most likely due to the fact that they slightly overestimate the lattice constant. This problem is something that has been observed over a wide range of codes including Siesta, VASP, and Wien2k. See the comment by S. Alexendre et al., PRL 96 079701 (2006) for more details. For your calculations, I would suggest including non-collinear core corrections and seeing if this helps. Best regards, Derek Lucas Fernandez Seivane writes: > Hi to all in the list > > I am trying to generate a fully relativistic pseudo for Pd. But with > these parameters I always get magnetic Pd! Do you see anything wrong > in the input? > > > Best wishes to all > Lucas Fern?ndez Seivane > Ph.D. student, Universidad de Oviedo, Spain > > &input > title='Pd', > zed=46.0, > rel=2, > iswitch=3, > rlderiv=2.50, > eminld=-3.0, > emaxld=3.0, > deld=0.02, > nld=5, > config='[Kr] 4d9 5s1 5p0', > dft='LDA' > / > &inputp > pseudotype=3, > lloc=0, > file_pseudopw='PdrelNN.RRKJ3', > nlcc=.false. > / > 7 > 4D 3 2 4.00 0.00 1.80 2.40 1.50 > 4D 3 2 0.00 -0.20 1.80 2.40 1.50 > 4D 3 2 5.00 0.00 1.80 2.40 2.50 > 4D 3 2 0.00 -0.20 1.80 2.40 2.50 > 5P 2 1 0.00 0.00 2.40 2.40 0.50 > 5P 2 1 0.00 -0.00 2.40 2.40 1.50 > 5S 1 0 1.00 0.00 2.40 2.40 0.50 > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum ################################ Derek Stewart, Ph. D. Scientific Computation Associate 250 Duffield Hall Cornell Nanoscale Facility (CNF) Ithaca, NY 14853 stewart (at) cnf.cornell.edu (607) 255-2856 From giannozz at nest.sns.it Thu Mar 30 17:23:24 2006 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 30 Mar 2006 17:23:24 +0200 Subject: [Pw_forum] a error when caculate phonon using version3.0! In-Reply-To: References: Message-ID: <200603301723.24557.giannozz@nest.sns.it> On Thursday 30 March 2006 10:35, hjlyw1983 hjlyw1983 wrote: > When I caculated the phonon of SnO at Gamma point using the > version3.0, a part of the result as below [...] I tried your job and the results I got look sensible. I used the CVS version, different pseudopotentials, a smaller cutoff, and a much smaller k-point grid (see attached). Note that - in PC with the intel compiler, I got a crash. This is due to a compiler weirdness with large arrays. - you must be careful when using you restart from an interrupted run (recover=.true.): you may easily end up reading bad files - the third-order electro-optic coefficients are zero by symmetry, I think Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy -------------- next part -------------- A non-text attachment was scrubbed... Name: SnO.tgz Type: application/x-tgz Size: 7357 bytes Desc: not available Url : /pipermail/attachments/20060330/3266594c/attachment.bin From quevedin at gmail.com Thu Mar 30 17:37:32 2006 From: quevedin at gmail.com (Lucas Fernandez Seivane) Date: Thu, 30 Mar 2006 17:37:32 +0200 Subject: [Pw_forum] Re: Help generating Pd pseudo In-Reply-To: <20060330145554.13379.qmail@xuxa.iecc.com> References: <2ebe300a0603300557q47243a0bx539bb36fc6e70376@mail.gmail.com> <20060330145554.13379.qmail@xuxa.iecc.com> Message-ID: <2ebe300a0603300737h5776899eje897b96b8313fe7d@mail.gmail.com> Hi Derek Thanks for your reply. I was aware of some of the problems you comment, but mine is that in fact this pseudo gives always a magnetic ground state, even at lattice constants more compressed that experimental one! I will check with nlcc! Best regards Lucas Fern?ndez Seivane Ph.D. student, Universidad de Oviedo, Spain On 3/30/06, stewart at cnf.cornell.edu wrote: > Hi Lucas, > > Palladium has a high magnetic susceptibility and sits right on the edge > of magnetism. I have been looking at nanostructures based on Pd and I have > found that the pseudopotential choice is very crucial in determining whether > you get the correct non-magnetic fcc ground state. All pseudopotentials > predict that as you expand the palladium lattice, you should see a > transition to a magnetic state. > > However, of the four pseudopotentials available on the PWscf website, only > the Perdew-Zunger (LDA) with non-linear core correction and the semi-core d > valence state (Pd.pz-nd-rrkjus.UPF) gives the correct non-magnetic fcc > ground state. All varieties of GGA psp predict a ground magnetic state, > most likely due to the fact that they slightly overestimate the lattice > constant. This problem is something that has been observed over a wide > range of codes including Siesta, VASP, and Wien2k. See the comment by S. > Alexendre et al., PRL 96 079701 (2006) for more details. > > For your calculations, I would suggest including non-collinear core > corrections and seeing if this helps. > > Best regards, > > Derek > > > > Lucas Fernandez Seivane writes: > > > Hi to all in the list > > > > I am trying to generate a fully relativistic pseudo for Pd. But with > > these parameters I always get magnetic Pd! Do you see anything wrong > > in the input? > > > > > > Best wishes to all > > Lucas Fern?ndez Seivane > > Ph.D. student, Universidad de Oviedo, Spain > > > > &input > > title='Pd', > > zed=46.0, > > rel=2, > > iswitch=3, > > rlderiv=2.50, > > eminld=-3.0, > > emaxld=3.0, > > deld=0.02, > > nld=5, > > config='[Kr] 4d9 5s1 5p0', > > dft='LDA' > > / > > &inputp > > pseudotype=3, > > lloc=0, > > file_pseudopw='PdrelNN.RRKJ3', > > nlcc=.false. > > / > > 7 > > 4D 3 2 4.00 0.00 1.80 2.40 1.50 > > 4D 3 2 0.00 -0.20 1.80 2.40 1.50 > > 4D 3 2 5.00 0.00 1.80 2.40 2.50 > > 4D 3 2 0.00 -0.20 1.80 2.40 2.50 > > 5P 2 1 0.00 0.00 2.40 2.40 0.50 > > 5P 2 1 0.00 -0.00 2.40 2.40 1.50 > > 5S 1 0 1.00 0.00 2.40 2.40 0.50 > > _______________________________________________ > > Pw_forum mailing list > > Pw_forum at pwscf.org > > http://www.democritos.it/mailman/listinfo/pw_forum > > > > ################################ > Derek Stewart, Ph. D. > Scientific Computation Associate > 250 Duffield Hall > Cornell Nanoscale Facility (CNF) > Ithaca, NY 14853 > stewart (at) cnf.cornell.edu > (607) 255-2856 > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From sir_puding at tut.by Thu Mar 30 19:11:03 2006 From: sir_puding at tut.by (sir_puding at tut.by) Date: Thu, 30 Mar 2006 20:11:03 +0300 Subject: [Pw_forum] Possible bug Message-ID: <38937465.20060330201103@tut.by> Hi, All. Strictly speaking it is not a bug, but a misspell in INPUT.HOWTO at line 69 ----- an example: Si, omega_0=15 THz, 1/omega_0=60 ps, time step=1 fs or so. ----- i think 1/omega_0 should be 1/omega_0=60 fs or maybe i am wrong -- it was a hard day. Sergey -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From konstantin_kudin at yahoo.com Fri Mar 31 04:41:02 2006 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Thu, 30 Mar 2006 18:41:02 -0800 (PST) Subject: [Pw_forum] Question on phonons at non-Gamma points Message-ID: <20060331024102.51082.qmail@web52008.mail.yahoo.com> Hi all, I am looking for an accessible reference on how non-Gamma phonons are computed analytically in PWSCF or other similar codes. Any other related comments on such phonon evaluation are appreciated as well! Thanks! Kostya __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com