From breezejd at lsbu.ac.uk Mon Mar 1 13:29:09 2004 From: breezejd at lsbu.ac.uk (Jonathan Breeze) Date: Mon, 01 Mar 2004 12:29:09 +0000 Subject: [Pw_forum] Compiling pwscf using ifc 7.1 on a x64-64 system References: <1077724187.29727.50.camel@pc-ballabio> <403DE71C.7080603@lsbu.ac.uk> <1077801422.28897.3.camel@pc-ballabio> Message-ID: <40432C95.6000807@lsbu.ac.uk> Gerardo Ballabio wrote: >On Thu, 2004-02-26 at 13:31, Jonathan Breeze wrote: > > >>Just thought I would share some of my experiences getting pwscf (version >>1.3 and 2.0) to compile using Intel Fortran Compiler (IFC) on a 64-bit >>linux system (AMD64 on Suse 9.0 x86_64). >> >> > >Hi Jonathan, >I see you compiled PWscf as 32-bit code. Have you tried a 64-bit >install? We would be very interested in getting that to work. > >Gerardo > > Dear Garardo, Actually I have had a spot of bother trying to get pwscf going using the PGI compiler for x86-64 architechtures. Everything compiles OK but there are constant segmentation faults occuring. I'm not sure if it is a compiler bug or not at the moment. From philippe.baranek at edfgdf.fr Mon Mar 1 13:28:05 2004 From: philippe.baranek at edfgdf.fr (Philippe BARANEK) Date: Mon, 1 Mar 2004 13:28:05 +0100 Subject: [Pw_forum] Memory limit of pwscf, and, LDA+U and 4f systems Message-ID: Dear pwscf users, I have further questions: 1) I would like to use pwscf code and hubbard model to describe system with actinides and lanthanides. Is it possible ? Anyone of you have used pwscf with hubbard correction and could he explain me how to use it because I must do something wrong, each time I am trying I have got this error message "From set_hubbard_l : error # 1 pseudopotential not yet inserted Stopping" 2) When my systems exceed 12 atoms whatever the systems and atoms involve in the system, pw.x crashes with the message "Memory Fault" when the calculations should use 20% of my memory. Is there a memory limit for the use of Pwscf since I must create supercell with further tens of atoms at low symmetry ? I am using PGF compiler on a linux system. 3) Is it possible to define "automatically" a supercell in terms of the primitive cell vectors ( Sa = n1 * a + n2 * b + n3 * c, ....) with pwscf ? If yes, how to do it ? With my thanks for your help Best regards Philippe Baranek philippe.baranek at edfgdf.fr From phyche1 at bo.imm.cnr.it Mon Mar 1 13:27:45 2004 From: phyche1 at bo.imm.cnr.it (Eros Albertazzi) Date: Mon, 01 Mar 2004 13:27:45 +0100 Subject: [Pw_forum] Compiling pwscf using ifc 7.1 on a x64-64 system In-Reply-To: <40432C95.6000807@lsbu.ac.uk> References: <1077724187.29727.50.camel@pc-ballabio> <403DE71C.7080603@lsbu.ac.uk> <1077801422.28897.3.camel@pc-ballabio> <40432C95.6000807@lsbu.ac.uk> Message-ID: <40432C41.1070905@bo.imm.cnr.it> Jonathan Breeze wrote: > Dear Garardo, > > Actually I have had a spot of bother trying to get pwscf going using the > PGI compiler for x86-64 architechtures. Everything compiles OK but > there are constant segmentation faults occuring. I'm not sure if it is > a compiler bug or not at the moment. there is a problem w/PGI SUM function.. I reported it to Dave Borer and they have created tpr3142 to address it. In setup just substitute !!! IF ( nelec == 0.D0 ) nelec = SUM( zv(ityp(1:nat)) ) if( nelec == 0.0d0 ) then do na = 1, nat nelec = nelec + zv (ityp (na) ) end do endif -- Eros Albertazzi CNR-IMM, Sez. Bologna Via P.Gobetti 101 I-40129 Bologna, Italy Tel:(+39)-051-639 9179 Fax:(+39)-051-639 9216 From breezejd at lsbu.ac.uk Tue Mar 2 16:44:43 2004 From: breezejd at lsbu.ac.uk (Jonathan Breeze) Date: Tue, 02 Mar 2004 15:44:43 +0000 Subject: [Pw_forum] Compiling pwscf using ifc 7.1 on a x64-64 system References: <1077724187.29727.50.camel@pc-ballabio> <403DE71C.7080603@lsbu.ac.uk> <1077801422.28897.3.camel@pc-ballabio> <40432C95.6000807@lsbu.ac.uk> <40432C41.1070905@bo.imm.cnr.it> Message-ID: <4044ABEB.1090809@lsbu.ac.uk> > > >> Dear Garardo, >> >> Actually I have had a spot of bother trying to get pwscf going using >> the PGI compiler for x86-64 architechtures. Everything compiles OK >> but there are constant segmentation faults occuring. I'm not sure if >> it is a compiler bug or not at the moment. > > > > there is a problem w/PGI SUM function.. > I reported it to Dave Borer and they have created tpr3142 to address it. > > In setup just substitute > > !!! IF ( nelec == 0.D0 ) nelec = SUM( zv(ityp(1:nat)) ) > if( nelec == 0.0d0 ) then > do na = 1, nat > nelec = nelec + zv (ityp (na) ) > end do > endif I still get STOP errors and "segmentation faults". I'm using PGI 5.1 by the way. -- Jonathan Breeze Research Fellow Centre for Physical Electronics and Materials London South Bank University 103 Borough Road London SE1 0AA Tel: +44(0)20 7815 7582 Fax: +44(0)20 7815 7599 From giannozz at nest.sns.it Tue Mar 2 18:49:41 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 2 Mar 2004 18:49:41 +0100 (CET) Subject: [Pw_forum] Memory limit of pwscf, and, LDA+U and 4f systems In-Reply-To: References: Message-ID: On Mon, 1 Mar 2004, Philippe BARANEK wrote: > Anyone of you have used pwscf with hubbard correction and > could he explain me how to use it because I must do something > wrong, each time I am trying I have got this error message > > "From set_hubbard_l : error # 1 > pseudopotential not yet inserted > Stopping" $ grep set_hubbard_l PW/*f90 $ PW/set_hubbard_l.f90:integer function set_hubbard_l(psd) result (hubbard_l) $ PW/set_hubbard_l.f90: call errore ('set_hubbard_l','pseudopotential not yet inserted', 1) if you look into PW/set_hubbard_l.f90 you will see that only for a few selected elements is the variable hubbard_l defined. If your preferred element (U, I guess) is not in the list, you have to add it: elseif (psd .eq.'Ce' .or. psd .eq.'U') then hubbard_l = 3 else ... > 2) When my systems exceed 12 atoms whatever the systems and atoms > involve in the system, pw.x crashes with the message "Memory Fault" > when the calculations should use 20% of my memory. Is there a > memory limit for the use of Pwscf [...] no: I ran your job (with just one k-point, but this does not affect the memory usage) on a laptop > I am using PGF compiler on a linux system. other people have reported a similar problem with the Portland compiler Paolo From g.ballabio at cineca.it Wed Mar 3 11:01:32 2004 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Wed, 03 Mar 2004 11:01:32 +0100 Subject: [Pw_forum] Re: pw.2.0 vs. pw.1.3 In-Reply-To: References: Message-ID: <1078308092.22646.2.camel@pc-ballabio> Hi Aaron, I'm forwarding your message to the pw_forum mailing list (pw_forum at pwscf.org). I'm not able to answer your question, but I'm sure that someone there can. Gerardo On Tue, 2004-03-02 at 15:40, aaron at nemo.physics.ncsu.edu wrote: > Hi Gerardo, > > As you probably know I am working to implement an algorithm with meta > dynamics based on the recent work by M Iannuizzi, A. Laio and M. > Parrinello (PRL 90, 238302). In pw.1.3.0 the calculation was specified as > 'md', ion_dynamics='meta' and the result was the flow of control was > directed toward my module metadynamics rather than dynamics. Now the > pw.2.0 code comments the flow of control is obsolete (below is printed the > lines from ./PW/input.f90). This was accomplished by setting iswitch > value appropriately (3) and calc='me'. I'd like to ask you or any of the > other authors to suggest how to accomplish this in pw.2.0 ? > > Thanks > > Aaron > <> > ! My first attempt at implementation of md with metadynamics module in > pw.2.0 > > IF ( TRIM( calculation ) == 'md' ) THEN > SELECT CASE ( TRIM( ion_dynamics ) ) > CASE ( 'verlet' ) > iswitch = 3 ! ... obsolescent: do not use in new code ( 29/10/2003 > C.S.) > CASE ( 'constrained-verlet' ) > iswitch = 4 ! ... obsolescent: do not use in new code ( 29/10/2003 > C.S.) > CASE ( 'beeman' ) > iswitch = 3 ! ... obsolescent: do not use in new code ( 29/10/2003 > C.S.) > calc = 'md' > ntcheck = nstep + 1 > CASE ('meta') > iswitch = 3 > calc = 'me' > CASE DEFAULT > CALL errore( ' iosys ', 'calculation=' // TRIM( calculation ) // & > & ': ion_dynamics=' // TRIM( ion_dynamics ) // & > & ' not supported', 1 ) > END SELECT > END IF > > > From mousumi at jncasr.ac.in Mon Mar 8 07:30:52 2004 From: mousumi at jncasr.ac.in (Mousumi Upadhyay) Date: Mon, 8 Mar 2004 12:00:52 +0530 (IST) Subject: [Pw_forum] GGA Message-ID: Hi all, I want to use PB_GGA approximation for the exchange correlation part. How to insert that in my input file? Should I bring that in picture in the pseudopotential generation file as well? regards, mousumi. From mousumi at jncasr.ac.in Mon Mar 8 07:38:12 2004 From: mousumi at jncasr.ac.in (Mousumi Upadhyay) Date: Mon, 8 Mar 2004 12:08:12 +0530 (IST) Subject: [Pw_forum] GGA Message-ID: Hi all, I want to use PB_GGA approximation for the exchange correlation part. How to insert that in my input file? Should I bring that in picture in the pseudopotential generation file as well? regards, mousumi. _______________________________________________ Pw_forum mailing list Pw_forum at pwscf.org http://www.democritos.it/mailman/listinfo/pw_forum From massimiliano.bonomi at mi.infn.it Mon Mar 8 15:51:52 2004 From: massimiliano.bonomi at mi.infn.it (Massimiliano Bonomi) Date: Mon, 08 Mar 2004 15:51:52 +0100 Subject: [Pw_forum] Problems with ph.x in pwscf2.0 Message-ID: <404C8888.2070403@mi.infn.it> I compiled pwscf2.0 on a linux cluster with PGI IA-32. I had no problem with pw.x using mpiexec v. 0.74 for parallel use, but when i tried to use ph.x the program stopped after a few seconds without any error message in the standard output. This is the last part of the output file: Representation 22 1 modes - To be done Representation 23 1 modes - To be done Representation 24 1 modes - To be done PHONON : 8.47s CPU time Alpha used in Ewald sum = 1.3000 Representation # 1 mode # 1 Thanks for your help. Massimiliano Bonomi. From giannozz at nest.sns.it Mon Mar 8 18:23:01 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 8 Mar 2004 18:23:01 +0100 Subject: [Pw_forum] Problems with ph.x in pwscf2.0 In-Reply-To: <404C8888.2070403@mi.infn.it> References: <404C8888.2070403@mi.infn.it> Message-ID: <200403081823.01416.giannozz@nest.sns.it> On Monday 08 March 2004 15:51, Massimiliano Bonomi wrote: > I compiled pwscf2.0 on a linux cluster with PGI IA-32. > I had no problem with pw.x using mpiexec v. 0.74 for parallel use, > but when i tried to use ph.x the program stopped after a few seconds > without any error message in the standard output. if you are using k-point parallelization, you need to install the patch I sent a few days ago (or simply to remove the call to "init_pool" from PH/phq_readin.f90). Otherwise, this is what the manual says: --- Linux PCs with Portland Group compiler (pgf90) Use the latest version of each release of the compiler, with patches if available: see the Portland Group web site, http://www.pgroup.com/faq/install.htm#release_info. PWscf does not work reliably, or not at all, with some versions of the Portland compiler. --- 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 eyvaz_isaev at yahoo.com Mon Mar 8 21:38:30 2004 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Mon, 8 Mar 2004 12:38:30 -0800 (PST) Subject: [Pw_forum] GGA In-Reply-To: Message-ID: <20040308203830.38921.qmail@web60301.mail.yahoo.com> Hi, As I know exchange-correlation functional is usually given via pseudopotential file. Therefore, you can bring the PBE type functional to your system generation of a pseudopotential. Bests, Eyvaz. --- Mousumi Upadhyay wrote: > > > Hi all, > > I want to use PB_GGA approximation for the > exchange correlation > part. How to insert that in my input file? Should I > bring that in picture > in the pseudopotential generation file as well? > > regards, mousumi. > > > > > > > > > > > > > > > > > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum __________________________________ Do you Yahoo!? Yahoo! Search - Find what you?re looking for faster http://search.yahoo.com From konstantin_kudin at yahoo.com Mon Mar 8 23:07:29 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Mon, 8 Mar 2004 14:07:29 -0800 (PST) Subject: [Pw_forum] Restarting PWSCF - usability issues In-Reply-To: <20040308203830.38921.qmail@web60301.mail.yahoo.com> Message-ID: <20040308220729.37436.qmail@web21206.mail.yahoo.com> I've been running some PWSCF (v2.0.0 from the web) jobs that needed restarts because they ran out of "nstep". So I used restart_mode='restart' to handle that. Now, one of the issues that came up in the context of multi-node jobs is the management of "*.wfc*" files. It seems like only the master node stores all kinds of temporary and semi-temporary files, while the slave nodes only have "*.wfc*" files. Ideally, I'd like a script that would move such files from a central location to the master node before the job starts, and then moves them back after the job finishes. The presence of "*.wfc*" files complicates the matter. First of all, it is a rather non-trivial shell programming to first copy the needed (and only needed) for a given node *.wfc* files to its scratch space, and then copy them back. If I copy all *.wfc* I have for a given prefix, some of them won't be used on a given node, and when I move them back, the last node will overwrite the recent *.wfc* files with the older ones. So one would need extra code to handle that. More serious, however, is the fact that restarting a calculation with a mismatched set of *.wfc* files causes crashes. These *.wfc* files also get in the way when one changes the number of processors for the jobs. When I restart a job on 8 cpus that ran before on 4 cpus, there are missing *.wfc* files and the job seems to hang forever right before the message "Starting wfc from file". I guess some safeguards are missing there at the moment, so this is a BUG. I modified the code to do a restart with atomic wfc (line change in PW/input.f90 "startingwfc = 'atomic'"), and it appears that as long as the *.rho file is read in, it takes very little extra time to converge the wfcs from an atomic guess. Thus keeping these *.wfc* files around is at best a very minor help, and at worst a very major headache in a parallel environment. So I suggest that either startingwfc=atomic could be a default for restarts, or, the program should understand the startingwfc=atomic line even when a restart is requested. Of course, there is always that option to merge the *wfc* files into one, but why should one even bother to keep them if it does not save anything in cpu time? A second point is the file "*.rho". When changing geometry manually and reading in a "*.rho" file, it gives a very poor approximation to the first density if the geometrical change was large. On the other hand, the optimization process does something that prints out the line: "NEW-OLD atomic charge density approx. for the potential". This "NEW-OLD" approach works quite well, and the first density after it is quite good. Would it be possible to save some minimal information on the file "*.rho" to do this "NEW-OLD" thing whenever the "*.rho" file is used? Alternatively, one could probably read the file "*.save" to figure out the old coordinates, and do this "NEW-OLD" projection on the density from the "*.rho" file. Kostya __________________________________ Do you Yahoo!? Yahoo! Search - Find what you?re looking for faster http://search.yahoo.com From konstantin_kudin at yahoo.com Mon Mar 8 23:18:19 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Mon, 8 Mar 2004 14:18:19 -0800 (PST) Subject: [Pw_forum] ifc 8.0 and PWSCF 2.0.0 - finally works? In-Reply-To: <20040308203830.38921.qmail@web60301.mail.yahoo.com> Message-ID: <20040308221819.97627.qmail@web21203.mail.yahoo.com> I've compiled PWSCF with ifc 8.0 (with a recent 8.0.039_pe042 set of patches), and it seems like the whole thing is going smoothly and produces executables that run at the same speed or faster than those obtained with ifc 7.1 I did a selective set of small benchmarks to find out the difference between 8.0 and 7.1, and there is either none or the ifc 8.0 code is somewhat faster. So it seems like finally ifc 8.0 is ready for prime time, and there is no more reason to keep using ifc 7.1 If optimizing for P4 with the flags "-tpp7 -xW", one also needs to add a library at the linking stage: LIBS= -lfftw -lsvml ^^^^^^ Kostya __________________________________ Do you Yahoo!? Yahoo! Search - Find what you?re looking for faster http://search.yahoo.com From mousumi at jncasr.ac.in Tue Mar 9 07:49:03 2004 From: mousumi at jncasr.ac.in (Mousumi Upadhyay) Date: Tue, 9 Mar 2004 12:19:03 +0530 (IST) Subject: [Pw_forum] help... taking care of all symmetry operations In-Reply-To: <20040308203830.38921.qmail@web60301.mail.yahoo.com> References: <20040308203830.38921.qmail@web60301.mail.yahoo.com> Message-ID: Hi, I want to know, how all the symmetry operations for my systems can be taken care of, through PWSCF? I'm sending the following warning part, "" input warning: symmetry operation # 7 not allowed. fractionary translation: 0.0000000 0.0000000 0.3333333 in crystal coordinates warning: symmetry operation # 8 not allowed. fractionary translation: 0.0000000 0.0000000 -0.3333333 in crystal coordinates warning: symmetry operation # 11 not allowed. fractionary translation: 0.0000000 0.0000000 -0.3333333 in crystal coordinates warning: symmetry operation # 12 not allowed. fractionary translation: 0.0000000 0.0000000 0.3333333 in crystal coordinates"" But in our system, in a unit cell, three atoms are in three different levels, 0, 1/3 & 2/3. So, this must be taken care of to get relaxed reduced co-ordinates. For example, starting at some lattice constant value, with reduced co-ordinate, 2.16500000000E-01 0.0000000000E+00 -1.8503717077E-17 1 -2.16500000000E-01 -2.16500000000E-01 3.3333333333E-01 1 0.0000000000E+00 2.16500000000E-01 6.6666666667E-01 1 final reduced co-ordinates, we got as, 0.208561119 0.000000000 0.000000000 1 -0.206588002 -0.204614884 0.336091984 1 -0.001973118 0.204614884 0.663908016 1 The values, 0.2085, 0.2065, 0.2046 are all expected to be same atleast upto 4th deecimal places. I believe this discripency is because, all symmetry operations are not taken care of. So, how can we get rid of that in PWSCF??? By which input parameter? Best regards, Mousumi. From giannozz at nest.sns.it Tue Mar 9 09:26:57 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 9 Mar 2004 09:26:57 +0100 Subject: [Pw_forum] help... taking care of all symmetry operations In-Reply-To: References: <20040308203830.38921.qmail@web60301.mail.yahoo.com> Message-ID: <200403090926.57460.giannozz@nest.sns.it> On Tuesday 09 March 2004 07:49, Mousumi Upadhyay wrote: > I want to know, how all the symmetry operations for my systems > can be taken care of, through PWSCF? see http://www.pwscf.org/guide/2.0/html-node/node34.html, under "pw.x does not find all the symmetries you expected" 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 9 10:05:38 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 9 Mar 2004 10:05:38 +0100 Subject: [Pw_forum] ifc 8.0 and PWSCF 2.0.0 - finally works? In-Reply-To: <20040308221819.97627.qmail@web21203.mail.yahoo.com> References: <20040308221819.97627.qmail@web21203.mail.yahoo.com> Message-ID: <200403091005.38422.giannozz@nest.sns.it> On Monday 08 March 2004 23:18, Konstantin Kudin wrote: > So it seems like finally ifc 8.0 is ready for prime time, sort of: PWscf was modified to run with v.8 of Intel compiler. Look for "ifc8" in PW/neb_routines.f90, for instance. The ballistic conductance code (PWCOND) doesn't work for me, but works for other people. Everything else seems to work properly with ifc8. > If optimizing for P4 with the flags "-tpp7 -xW", one > also needs to add a library at the linking stage: > > LIBS= -lfftw -lsvml > ^^^^^^ thank you for the 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 mousumi at jncasr.ac.in Tue Mar 9 10:45:17 2004 From: mousumi at jncasr.ac.in (Mousumi Upadhyay) Date: Tue, 9 Mar 2004 15:15:17 +0530 (IST) Subject: [Pw_forum] help... taking care of all symmetry operations (fwd) Message-ID: THIS ONE WAS THE WHOLE MAIL I SENT. THEN, HOW SHOULD I GET RID OF THE PROBLEM I HAVE MENTIONED??? ---------- Forwarded message ---------- Date: Tue, 9 Mar 2004 12:19:03 +0530 (IST) From: Mousumi Upadhyay To: Eyvaz Isaev Cc: pw_forum at pwscf.org Subject: help... taking care of all symmetry operations Hi, I want to know, how all the symmetry operations for my systems can be taken care of, through PWSCF? I'm sending the following warning part, "" input warning: symmetry operation # 7 not allowed. fractionary translation: 0.0000000 0.0000000 0.3333333 in crystal coordinates warning: symmetry operation # 8 not allowed. fractionary translation: 0.0000000 0.0000000 -0.3333333 in crystal coordinates warning: symmetry operation # 11 not allowed. fractionary translation: 0.0000000 0.0000000 -0.3333333 in crystal coordinates warning: symmetry operation # 12 not allowed. fractionary translation: 0.0000000 0.0000000 0.3333333 in crystal coordinates"" But in our system, in a unit cell, three atoms are in three different levels, 0, 1/3 & 2/3. So, this must be taken care of to get relaxed reduced co-ordinates. For example, starting at some lattice constant value, with reduced co-ordinate, 2.16500000000E-01 0.0000000000E+00 -1.8503717077E-17 1 -2.16500000000E-01 -2.16500000000E-01 3.3333333333E-01 1 0.0000000000E+00 2.16500000000E-01 6.6666666667E-01 1 final reduced co-ordinates, we got as, 0.208561119 0.000000000 0.000000000 1 -0.206588002 -0.204614884 0.336091984 1 -0.001973118 0.204614884 0.663908016 1 The values, 0.2085, 0.2065, 0.2046 are all expected to be same atleast upto 4th deecimal places. I believe this discripency is because, all symmetry operations are not taken care of. So, how can we get rid of that in PWSCF??? By which input parameter? Best regards, Mousumi. From baroni at sissa.it Tue Mar 9 10:50:46 2004 From: baroni at sissa.it (Stefano Baroni) Date: Tue, 9 Mar 2004 10:50:46 +0100 Subject: [Pw_forum] help... taking care of all symmetry operations (fwd) In-Reply-To: References: Message-ID: <3D43CCCB-71AF-11D8-8F18-000A95CDDD16@sissa.it> Please, take a glance at the pwscf users' manual, as suggested by Paolo Giannozzi. I did the same before replying to you, and I can assure that everything is explained in full detailed. Thank you for using PWscf and for reporting your problems to this mailing list. Regards, Stefano Baroni On Mar 9, 2004, at 10:45 AM, Mousumi Upadhyay wrote: > > THIS ONE WAS THE WHOLE MAIL I SENT. THEN, HOW SHOULD I GET RID OF THE > PROBLEM I HAVE MENTIONED??? > > > ---------- Forwarded message ---------- > Date: Tue, 9 Mar 2004 12:19:03 +0530 (IST) > From: Mousumi Upadhyay > To: Eyvaz Isaev > Cc: pw_forum at pwscf.org > Subject: help... taking care of all symmetry operations > > > Hi, > > I want to know, how all the symmetry operations for my systems > can be taken care of, through PWSCF? > I'm sending the following warning part, > "" > input > warning: symmetry operation # 7 not allowed. fractionary > translation: > 0.0000000 0.0000000 0.3333333 in crystal coordinates > warning: symmetry operation # 8 not allowed. fractionary > translation: > 0.0000000 0.0000000 -0.3333333 in crystal coordinates > warning: symmetry operation # 11 not allowed. fractionary > translation: > 0.0000000 0.0000000 -0.3333333 in crystal coordinates > warning: symmetry operation # 12 not allowed. fractionary > translation: > 0.0000000 0.0000000 0.3333333 in crystal coordinates"" > > > But in our system, in a unit cell, three atoms are in > three different levels, 0, 1/3 & 2/3. So, this must be taken care of > to get relaxed reduced co-ordinates. > > For example, starting at some lattice constant value, > with reduced co-ordinate, > 2.16500000000E-01 0.0000000000E+00 -1.8503717077E-17 1 > -2.16500000000E-01 -2.16500000000E-01 3.3333333333E-01 1 > 0.0000000000E+00 2.16500000000E-01 6.6666666667E-01 1 > > final reduced co-ordinates, we got as, > 0.208561119 0.000000000 0.000000000 1 > -0.206588002 -0.204614884 0.336091984 1 > -0.001973118 0.204614884 0.663908016 1 > > The values, 0.2085, 0.2065, 0.2046 are all expected to be same atleast > upto 4th deecimal places. I believe this discripency is because, all > symmetry operations are not taken care of. So, how can we get rid of > that > in PWSCF??? By which input parameter? > > Best regards, Mousumi. > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > --- Stefano Baroni --- SISSA & DEMOCRITOS National Simulation Center via Beirut 2-4 34014 Trieste Grignano / [+39] 040 3787 406 (tel) -528 (fax) From massimiliano.bonomi at mi.infn.it Tue Mar 9 14:31:06 2004 From: massimiliano.bonomi at mi.infn.it (Massimiliano Bonomi) Date: Tue, 09 Mar 2004 14:31:06 +0100 Subject: [Pw_forum] Problems with ph.x in pwscf2.0 Message-ID: <404DC71A.7070901@mi.infn.it> >On Monday 08 March 2004 15:51, Massimiliano Bonomi wrote: > >>/ I compiled pwscf2.0 on a linux cluster with PGI IA-32. >/>/ I had no problem with pw.x using mpiexec v. 0.74 for parallel use, >/>/ but when i tried to use ph.x the program stopped after a few seconds >/>/ without any error message in the standard output. >/ >if you are using k-point parallelization, you need to install the patch >I sent a few days ago (or simply to remove the call to "init_pool" from >PH/phq_readin.f90). Otherwise, this is what the manual says: >--- >Linux PCs with Portland Group compiler (pgf90) > >Use the latest version of each release of the compiler, with patches if >available: see the Portland Group web site, >http://www.pgroup.com/faq/install.htm#release_info. PWscf does not >work reliably, or not at all, with some versions of the Portland compiler. >--- I did not use k-point parallelization, but i launched on a single pool of ten processor. I tried to remove the call to "init_pool", but it doesn't work yet. I did not have this problem with the previous version of the code on the same machine and compilator. Thanks for your help. Massimiliano Bonomi From giannozz at nest.sns.it Tue Mar 9 22:37:12 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 9 Mar 2004 22:37:12 +0100 Subject: [Pw_forum] Restarting PWSCF - usability issues In-Reply-To: <20040308220729.37436.qmail@web21206.mail.yahoo.com> References: <20040308220729.37436.qmail@web21206.mail.yahoo.com> Message-ID: <200403092237.12557.giannozz@nest.sns.it> On Monday 08 March 2004 23:07, Konstantin Kudin wrote: > [...] Now, one of the issues that came up in the context > of multi-node jobs is the management of "*.wfc*" files. it's a known issue, and not a simple one. There is a tradeoff between speed (maximised If each processor writes to its local scratch system, as it happens now), portability of the results (maximised if just one file is written, in a format that can be read independently on the number of processors, as it happens in Car-Parrinello codes), developers' time (minimised if things are kept simple, or if they are kept the way they are). For machines having a parallel file system (i.e. the sp4 in Cineca, Bologna), the problem is not that serious: all files are in the same place, and the I/O is still very fast (or at least, that is what I understood). Trouble arises only if you want to restart with a different number of processors . For machines without a parallel file system (i.e. the sp3 in PMI, Princeton) your *wfc files are scattered on different file systems in different processors (forget using I/O via NFS!). Restarting is a mess: you need a copy of all files on all processors, since there is no way to tell which physical processor corresponds to which logical one in MPI. Car-Parrinello people restart from wavefunctions more often than not, so the possibility to restart from a single file with a different number of processors is essential (and implemented) for them. PWscf people tend to restart less often, so restarting is a rougher process. This will be fixed sooner or later (I hope sooner: all the needed stuff is already there, and maybe it's even working: see __NEW_PUNCH) > the program should understand the startingwfc=atomic > line even when a restart is requested doesn't it? not good Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From francesco.antoniella at aquila.infn.it Wed Mar 10 13:45:41 2004 From: francesco.antoniella at aquila.infn.it (Francesco Antoniella) Date: 10 Mar 2004 13:45:41 +0100 Subject: [Pw_forum] Restarting PWSCF - usability issues In-Reply-To: <200403092237.12557.giannozz@nest.sns.it> References: <20040308220729.37436.qmail@web21206.mail.yahoo.com> <200403092237.12557.giannozz@nest.sns.it> Message-ID: <1078922745.1783.3.camel@altair> > For machines having a parallel file system (i.e. the sp4 in > Cineca, Bologna), the problem is not that serious: all files > are in the same place, and the I/O is still very fast (or at > least, that is what I understood). Trouble arises only if you > want to restart with a different number of processors . > > For machines without a parallel file system (i.e. the sp3 in > PMI, Princeton) your *wfc files are scattered on different file > systems in different processors (forget using I/O via NFS!). > Restarting is a mess: you need a copy of all files on all > processors, since there is no way to tell which physical > processor corresponds to which logical one in MPI. > For a PC cluster a good workaround is to use the openmosix package and its MFS see-all-the-disks filesystems. I implemented it in the Attila cluster at L'Aquila university at permits a quite fast writing via network (better than NFS) and/or accessibility of the nodes' filesystems in a reasonnably simple way. Francesco From yanming_ma at hotmail.com Wed Mar 10 19:04:49 2004 From: yanming_ma at hotmail.com (ma Yanming) Date: Thu, 11 Mar 2004 02:04:49 +0800 Subject: [Pw_forum] Star_q degeneracy error Message-ID: Dear Users, I am trying to calculate the phonon dispersion curve for the hcp structure. But for the q points, say, 0.5 0.2887 0.0, 0.5 0.2887 0.26695, I got the following errors. "Star_q degeneracy error". I worked for many other structures (FCC, bcc, Cmca,..). I do not have this problem. Is this a Bug? Does anyone have the similar experience for the error? I will highly appreciate your help. Yanming Ma PhD Steacie Institute for Molecular Sciences, National Research Councils of Canada. 100 Sussex K1A 0R6 _________________________________________________________________ ?????????????? MSN Messenger: http://messenger.msn.com/cn From giannozz at nest.sns.it Wed Mar 10 19:54:31 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 10 Mar 2004 19:54:31 +0100 Subject: [Pw_forum] Star_q degeneracy error In-Reply-To: References: Message-ID: <200403101954.31589.giannozz@nest.sns.it> On Wednesday 10 March 2004 19:04, ma Yanming wrote: > "Star_q degeneracy error". very nice error indeed. Which version of the code are you using? If it isn't the last, could you please verify if the error is still there in the last version? Otherwise, please post enough input data to reproduce the error Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From mousumi at jncasr.ac.in Thu Mar 11 12:34:39 2004 From: mousumi at jncasr.ac.in (Mousumi Upadhyay) Date: Thu, 11 Mar 2004 17:04:39 +0530 (IST) Subject: [Pw_forum] help: usage gga In-Reply-To: <200403101954.31589.giannozz@nest.sns.it> References: <200403101954.31589.giannozz@nest.sns.it> Message-ID: Hi all, I have put in my pseudopotential-file, the GGA option, as I were suggested. But, how, from the output file, should I confirm that the correct form of GGA is being used??? Best regards, Mousumi. From eyvaz_isaev at yahoo.com Thu Mar 11 12:42:55 2004 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Thu, 11 Mar 2004 03:42:55 -0800 (PST) Subject: [Pw_forum] help: usage gga In-Reply-To: Message-ID: <20040311114255.76949.qmail@web60306.mail.yahoo.com> Hi, If you mean the PWSCF output file, please find a line containing "Exchange-coorelation". Bests, Eyvaz. --- Mousumi Upadhyay wrote: > > Hi all, > > I have put in my pseudopotential-file, > the GGA option, > as I were suggested. But, how, from the output file, > should I confirm > that the correct form of GGA is being used??? > > Best regards, Mousumi. > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum __________________________________ Do you Yahoo!? Yahoo! Search - Find what you?re looking for faster http://search.yahoo.com From giannozz at nest.sns.it Thu Mar 11 12:58:10 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 11 Mar 2004 12:58:10 +0100 Subject: [Pw_forum] help: usage gga In-Reply-To: <20040311114255.76949.qmail@web60306.mail.yahoo.com> References: <20040311114255.76949.qmail@web60306.mail.yahoo.com> Message-ID: <200403111258.10103.giannozz@nest.sns.it> On Thursday 11 March 2004 12:42, Eyvaz Isaev wrote: > If you mean the PWSCF output file, please find a line > containing "Exchange-coorelation". I would rather try with "Exchange-correlation" instead :-) This is what the various terms mean: c "sla" Slater Exchange c "nox" No Exchange c "noc" No Correlation c "pz" Perdew-Zunger correlation c "gl" Gunnarson-Lunqvist correlation c "hl" Hedin-Lunqvist correlation c "pw" Perdew-Wang correlation c "vwn" Vosko-Wilk-Nusair correlation c "wig" Wigner correlation c "lyp" Lee-Yang-Parr correlation c "obz" Ortiz-Ballone form for Perdew-Zunger corr. c "obw" Ortiz-Ballone form for Perdew-Wang corr. c "nogx" No Gradient Correction on exchange c "nogc" No Gradient Correction on correlation c "b88" Becke88 grad-corr exchange (beta=0.0042) c "p86" Perdew86 grad-corr correlation c "bp" Becke88 + Perdew86 c "pw91" Perdew-Wang 91 GGA c "blyp" Becke88 + Lee-Yang-Parr c "pbe" Improved GGA by Perdew-Burke-Erzenhof -- 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 yanming_ma at hotmail.com Thu Mar 11 19:30:39 2004 From: yanming_ma at hotmail.com (ma Yanming) Date: Fri, 12 Mar 2004 02:30:39 +0800 Subject: [Pw_forum] Star_q degeneracy error Message-ID: Dear Paolo, The error occurred when I used both the 1.2.0 and the lastest 2.0 versions. I also tried for different PP. It didn't help. My case is Si (metal phase) with simple hcp structure (space group is P6/mmm) a=4.7599 a.u., c=0.9365. This "star_q wrong degeneracy " error only occurs for several q points. I read the source code about this error. It is related to the crystal symmetry. I couldn't figure out what is the reason for this error in my case. I attached my run_scripts file in the attachment. Please have a look. Thanks Yanming Ma PhD Steacie Institute for Molecular Sciences, National Research Councils of Canada. 100 Sussex K1A 0R6 >From: Paolo Giannozzi >Reply-To: pw_forum at pwscf.org >To: pw_forum at pwscf.org >Subject: Re: [Pw_forum] Star_q degeneracy error >Date: Wed, 10 Mar 2004 19:54:31 +0100 > >On Wednesday 10 March 2004 19:04, ma Yanming wrote: > > > "Star_q degeneracy error". > >very nice error indeed. Which version of the code are you using? >If it isn't the last, could you please verify if the error is still there in >the last version? Otherwise, please post enough input data to >reproduce the error > >Paolo > >-- >Paolo Giannozzi e-mail: giannozz at nest.sns.it >Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 >Piazza dei Cavalieri 7 I-56126 Pisa, Italy > >_______________________________________________ >Pw_forum mailing list >Pw_forum at pwscf.org >http://www.democritos.it/mailman/listinfo/pw_forum _________________________________________________________________ ??????????????? MSN Hotmail? http://www.hotmail.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: run_1 Url: /pipermail/attachments/20040312/eb6566de/attachment.txt From konstantin_kudin at yahoo.com Thu Mar 11 20:23:08 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Thu, 11 Mar 2004 11:23:08 -0800 (PST) Subject: [Pw_forum] Restarting PWSCF - usability issues In-Reply-To: <200403092237.12557.giannozz@nest.sns.it> Message-ID: <20040311192308.84468.qmail@web21203.mail.yahoo.com> --- Paolo Giannozzi wrote: > Car-Parrinello people restart from wavefunctions > more often > than not, so the possibility to restart from a > single file with a > different number of processors is essential (and > implemented) > for them. PWscf people tend to restart less often, > so restarting > is a rougher process. This will be fixed sooner or > later (I hope > sooner: all the needed stuff is already there, and > maybe it's > even working: see __NEW_PUNCH) But I was arguing that storing *wfc* files is almost unnecessary in PWSCF since the wavefunctions could be rather trivially regenerated from the atomic guess and the old *.rho file. NOT keeping the *wfc* file around after the job finishes simplifies things quite a bit ... > > the program should understand the > startingwfc=atomic > > line even when a restart is requested > > doesn't it? not good No, not good :-) Also, if node A has the old *.wfc* files, and node B does not, then the code hangs forever . I guess the nodes wait for B to read in the *wfc* file, which never happens since that file does not exist. So this is another bug. Kostya __________________________________ Do you Yahoo!? Yahoo! Search - Find what you?re looking for faster http://search.yahoo.com From konstantin_kudin at yahoo.com Fri Mar 12 02:51:50 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Thu, 11 Mar 2004 17:51:50 -0800 (PST) Subject: [Pw_forum] Grid differences between machines - why? In-Reply-To: <20040311192308.84468.qmail@web21203.mail.yahoo.com> Message-ID: <20040312015150.79926.qmail@web21201.mail.yahoo.com> Here is the situation. I am running PWSCF 2.0.0 on an Intel box and on an IBM SP3 (?). The input files are identical. Intel's code is serial, IBM's is mpi, 32-bit executable. On the IBM SP box I get: G cutoff = 1309.2944 ( 99231 G-vectors) FFT grid: ( 80, 80, 80) G cutoff = 1047.4356 ( 71005 G-vectors) smooth grid: ( 66, 66, 66) On the Intel: G cutoff = 1309.2944 ( 99231 G-vectors) FFT grid: ( 75, 75, 75) G cutoff = 1047.4356 ( 71005 G-vectors) smooth grid: ( 72, 72, 72) Why do I get different grids? They also lead to some differences in the energy ... Kostya __________________________________ Do you Yahoo!? Yahoo! Search - Find what you?re looking for faster http://search.yahoo.com From roma at cea.fr Fri Mar 12 08:51:25 2004 From: roma at cea.fr (Guido Roma) Date: Fri, 12 Mar 2004 08:51:25 +0100 Subject: [Pw_forum] Grid differences between machines - why? References: <20040312015150.79926.qmail@web21201.mail.yahoo.com> Message-ID: <40516BFD.D7654B6B@cea.fr> Hello, it happens that, due to different algorithms, some FFT routines like some prime factors and not others in the grid; either they are not allowed or they are very badly performing, so they are to be avoided. This is what does the function "allowed" in Modules/fft_scalar.f90: it choses a good fft grid for the machine (i.e. FFT routine) you're using, according to your energy cutoff. I suppose on IBM you use ESSL fft routines and on Intel FFTW. Of course the differences in energy should be negligible as you get closer to convergence (in both the smooth and fine grids). Guido Konstantin Kudin wrote: > > Here is the situation. I am running PWSCF 2.0.0 on an > Intel box and on an IBM SP3 (?). The input files are > identical. Intel's code is serial, IBM's is mpi, > 32-bit executable. > > On the IBM SP box I get: > G cutoff = 1309.2944 ( 99231 G-vectors) FFT > grid: ( 80, 80, 80) > G cutoff = 1047.4356 ( 71005 G-vectors) smooth > grid: ( 66, 66, 66) > > On the Intel: > G cutoff = 1309.2944 ( 99231 G-vectors) FFT > grid: ( 75, 75, 75) > G cutoff = 1047.4356 ( 71005 G-vectors) smooth > grid: ( 72, 72, 72) > > > Why do I get different grids? They also lead to some > differences in the energy ... > > Kostya > > __________________________________ > Do you Yahoo!? > Yahoo! Search - Find what you?re looking for faster > http://search.yahoo.com > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum -- Guido Roma -- CEA-Saclay - DEN/DMN/SRMP Bat.520/130 Phone: [+33]-1-69085738 -- Fax: ...6867 -- Mobile: [+33]-6-20069085 From degironc at sissa.it Fri Mar 12 08:56:43 2004 From: degironc at sissa.it (Stefano de Gironcoli) Date: Fri, 12 Mar 2004 08:56:43 +0100 Subject: [Pw_forum] Grid differences between machines - why? References: <20040312015150.79926.qmail@web21201.mail.yahoo.com> Message-ID: <40516D3B.30805@sissa.it> The code choose automatically the smallest grid that is compatible with the specified cutoff AND is a legal value for the FFT library used. Different FFT libraries have different allowed FFT dimensions and this may give different numbers on different machines. This also makes the energy slightly different on different machines: the only piece that depends explicitely on the grid parameters is the XC part of the energy that is computed numerically on the grid. The difference should be small, expecially for LDA calculations. In order to make an exact comparison between different machines one can specify in the &system name list common values for nr1, nr2,nr3 (and if needed nr1s, nr2s, nr3s). Then the results on different machines should be exactly equivalent. Stefano de Gironcoli Konstantin Kudin wrote: > Here is the situation. I am running PWSCF 2.0.0 on an >Intel box and on an IBM SP3 (?). The input files are >identical. Intel's code is serial, IBM's is mpi, >32-bit executable. > >On the IBM SP box I get: > G cutoff = 1309.2944 ( 99231 G-vectors) FFT >grid: ( 80, 80, 80) > G cutoff = 1047.4356 ( 71005 G-vectors) smooth >grid: ( 66, 66, 66) > >On the Intel: > G cutoff = 1309.2944 ( 99231 G-vectors) FFT >grid: ( 75, 75, 75) > G cutoff = 1047.4356 ( 71005 G-vectors) smooth >grid: ( 72, 72, 72) > > > Why do I get different grids? They also lead to some >differences in the energy ... > > Kostya > >__________________________________ >Do you Yahoo!? >Yahoo! Search - Find what you?re looking for faster >http://search.yahoo.com >_______________________________________________ >Pw_forum mailing list >Pw_forum at pwscf.org >http://www.democritos.it/mailman/listinfo/pw_forum > > From giannozz at nest.sns.it Fri Mar 12 09:43:43 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 12 Mar 2004 09:43:43 +0100 Subject: [Pw_forum] Grid differences between machines - why? In-Reply-To: <20040312015150.79926.qmail@web21201.mail.yahoo.com> References: <20040312015150.79926.qmail@web21201.mail.yahoo.com> Message-ID: <200403120943.43490.giannozz@nest.sns.it> On Friday 12 March 2004 02:51, Konstantin Kudin wrote: > On the IBM SP box I get: > G cutoff = 1309.2944 ( 99231 G-vectors) FFT > grid: ( 80, 80, 80) > G cutoff = 1047.4356 ( 71005 G-vectors) smooth > grid: ( 66, 66, 66) > > On the Intel: > G cutoff = 1309.2944 ( 99231 G-vectors) FFT > grid: ( 75, 75, 75) > G cutoff = 1047.4356 ( 71005 G-vectors) smooth > grid: ( 72, 72, 72) Guido and Stefano have already answered with the theory, here is the math: ESSL doesn't like 75=3*5*5 because it is odd (FFTW likes it), so we try 76=2*2*19 (19 is not allowed), 77 is odd, 78=2*3*13 (13 is not allowed), 79 is odd, until 80=2*2*2*2*5 (good) FFTW doesn't like 66=2*3*11 (11 is not allowed; it is with ESSL), 67, 68=2*2*17, 69=3*23, 70=2*5*7 (7 is not allowed), 71, so we reach 72=2*2*2*3*3 (good). (Actually I am not sure whether transforms with dimension > 5 are not allowed in FFTW, not efficiently implemented, or discarded because this is the tradition...) FFT grids calculated by the code are slightly overestimated, so you may try - carefully - to reduce them a little bit (i.e. 64 for the smooth grid in the above example). If the grid is too small, the code will complain. By the way: in parallel execution, it is convenient to have fft grids along z that are a multiple of the number of processors, so consider this as an additional constraint. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From proffess at yandex.ru Fri Mar 12 12:43:07 2004 From: proffess at yandex.ru (Sergei Lisenkov) Date: Fri, 12 Mar 2004 14:43:07 +0300 (MSK) Subject: [Pw_forum] Strange error within linking In-Reply-To: <200403120943.43490.giannozz@nest.sns.it> References: <20040312015150.79926.qmail@web21201.mail.yahoo.com> <200403120943.43490.giannozz@nest.sns.it> Message-ID: <4051A24B.000002.19655@tide.yandex.ru> Dear PWscf users, I met the strange error in linking stage. I have never seen it before. The machine is Xeon, cluster, Scali MPI, ifort 8.0, mkl61 library: bp_radin.o: In function `radlg_': bp_radin.o(.text+0x673): undefined reference to `f_iod' bp_radin.o(.text+0x689): undefined reference to `f_iod' bp_radin.o(.text+0x692): undefined reference to `f_iod' bp_radin.o(.text+0x69e): undefined reference to `f_iod' bp_radin.o(.text+0x6b4): undefined reference to `f_iod' bp_radin.o(.text+0x6c8): more undefined references to `f_iod' follow bp_radin.o: In function `radlg_': bp_radin.o(.text+0x6da): undefined reference to `f_stop' bp_radin.o: In function `radlg1_': bp_radin.o(.text+0x82b): undefined reference to `f_iod' bp_radin.o(.text+0x841): undefined reference to `f_iod' bp_radin.o(.text+0x84a): undefined reference to `f_iod' bp_radin.o(.text+0x856): undefined reference to `f_iod' bp_radin.o(.text+0x86c): undefined reference to `f_iod' bp_radin.o(.text+0x880): more undefined references to `f_iod' follow bp_radin.o: In function `radlg1_': bp_radin.o(.text+0x892): undefined reference to `f_stop' How to solve it? Thanks, Sergey From giannozz at nest.sns.it Fri Mar 12 14:42:33 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 12 Mar 2004 14:42:33 +0100 Subject: [Pw_forum] Strange error within linking In-Reply-To: <4051A24B.000002.19655@tide.yandex.ru> References: <20040312015150.79926.qmail@web21201.mail.yahoo.com> <200403120943.43490.giannozz@nest.sns.it> <4051A24B.000002.19655@tide.yandex.ru> Message-ID: <200403121442.34001.giannozz@nest.sns.it> On Friday 12 March 2004 12:43, Sergei Lisenkov wrote: > I met the strange error in linking stage. I have never seen it before. > The machine is Xeon, cluster, Scali MPI, ifort 8.0, mkl61 library: > > bp_radin.o(.text+0x673): undefined reference to `f_iod' [...] > bp_radin.o(.text+0x6da): undefined reference to `f_stop' [...] it looks like an installation problem of the compiler, or loading of incompatible libraries; it is definitely not a problem of the code Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From konstantin_kudin at yahoo.com Fri Mar 12 17:31:31 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Fri, 12 Mar 2004 08:31:31 -0800 (PST) Subject: [Pw_forum] Grid differences between machines - why? In-Reply-To: <200403120943.43490.giannozz@nest.sns.it> Message-ID: <20040312163131.13963.qmail@web21203.mail.yahoo.com> Guys Thanks to everybody who replied for explanations. My question now is if there is an easy way to use FFTW on IBM instead of essl? Supposedly, FFTW should compile on IBM and give decent speed as well. It does not make me comfortable when I am getting 2 mRyd energy differences between machines, and to hell with performance if things are not directly comparable. Kostya __________________________________ Do you Yahoo!? Yahoo! Search - Find what you?re looking for faster http://search.yahoo.com From sbraccia at sissa.it Fri Mar 12 20:45:09 2004 From: sbraccia at sissa.it (sbraccia carlo) Date: Fri, 12 Mar 2004 20:45:09 +0100 Subject: [Pw_forum] Restarting PWSCF - usability issues In-Reply-To: <20040311192308.84468.qmail@web21203.mail.yahoo.com> References: <20040311192308.84468.qmail@web21203.mail.yahoo.com> Message-ID: <200403122045.09396.sbraccia@sissa.it> Dear Kostya, > But I was arguing that storing *wfc* files is almost > unnecessary in PWSCF since the wavefunctions could be > rather trivially regenerated from the atomic guess and > the old *.rho file. restarting with atomic wfc usually implies that several iterations are needed to diagonalize the hamiltonian because the threshold is more strict than the one used for he first scf iteration of a "from_scratch" calculation. Moreover, since there is no way for the code to know at restart time whether the starting potential is close to the scf one or not, the code doesn't know the correct value for diagonalization threshold. So the code supposes that the wfcs and the potential are "consistent" (at the same level of "self consistency"). If you are restarting the diagonalization with a rough estimate of the wfcs and with a potential close to self consistency, what will probably happens is that rho_out will be far from rho_in and the new potential will be also far from the "almost" scf one you were restarting from => some scf iteration will be needed to restore the "almost" scf potential. > > > the program should understand the > > > > startingwfc=atomic > > > > > line even when a restart is requested > > > > doesn't it? not good > > No, not good :-) This bug has been fixed in he CVS version and, probably, the fix will be contained in the forthcoming patch to version 2.0 carlo sbraccia From giannozz at nest.sns.it Fri Mar 12 21:15:52 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 12 Mar 2004 21:15:52 +0100 Subject: [Pw_forum] Restarting PWSCF - usability issues In-Reply-To: <20040311192308.84468.qmail@web21203.mail.yahoo.com> References: <20040311192308.84468.qmail@web21203.mail.yahoo.com> Message-ID: <200403122115.52400.giannozz@nest.sns.it> On Thursday 11 March 2004 20:23, Konstantin Kudin wrote: > Also, if node A has the old *.wfc* files, and node B does not, > then the code hangs forever. I guess the nodes wait for B to > read in the *wfc* file, which never happens since that file > does not exist. I an not 100% sure, but I am quite confident that node B does the right thing, i.e. it stops and calls the error routine, which aborts MPI among other things. In MPI refuses to die, as it used to happen (and apparently still happens :-) on the SP3 in Princeton, there is little we can do. So i take exception to your last statement: > So this is another bug. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From konstantin_kudin at yahoo.com Fri Mar 12 22:23:55 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Fri, 12 Mar 2004 13:23:55 -0800 (PST) Subject: [Pw_forum] Restarting PWSCF - usability issues In-Reply-To: <200403122045.09396.sbraccia@sissa.it> Message-ID: <20040312212355.95772.qmail@web21202.mail.yahoo.com> > restarting with atomic wfc usually implies that > several iterations are needed > to diagonalize the hamiltonian because the threshold > is more strict than the > one used for he first scf iteration of a > "from_scratch" calculation. > Moreover, since there is no way for the code to know > at restart time whether > the starting potential is close to the scf one or > not, the code doesn't know > the correct value for diagonalization threshold. Dear Carlo It appears that the code is already quite smart and can detect such problems and lower the threshold on the fly at the same cycle. So restarting from *.rho file alone costs only that first diagonalization with large threshold when it finds out that the threshold should be smaller - hardly a big price to pay for the convenience of not dealing with *.wfc* files. Here: The initial density is read from file yz_1s.rho Starting wfc are atomic total cpu time spent up to now is 34.38 secs iteration # 1 ecut= 28.00 ryd beta= .70 Davidson diagonalization with overlap ethr = 1.00E-05, avg # of iterations = 5.0 Threshold (ethr) on eigenvalues was too large: Diagonalizing with lowered threshold Davidson diagonalization with overlap ethr = 2.29E-07, avg # of iterations = 4.0 Kostya __________________________________ Do you Yahoo!? Yahoo! Search - Find what you?re looking for faster http://search.yahoo.com From pushpa at jncasr.ac.in Sat Mar 13 06:02:17 2004 From: pushpa at jncasr.ac.in (Raghani Pushpa) Date: Sat, 13 Mar 2004 10:32:17 +0530 (IST) Subject: [Pw_forum] error in stress calculation Message-ID: Dear users, I am getting the following error while calculating stress in Au/Ag system in a slab calculation. entering subroutine stress ... %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from sph_bes : error # 2 j_{-1}(0) ?!? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... 2 whereas the code works well for ag/pt (slab) system. what could be the problem? pushpa From giannozz at nest.sns.it Sat Mar 13 10:16:00 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Sat, 13 Mar 2004 10:16:00 +0100 Subject: [Pw_forum] error in stress calculation In-Reply-To: References: Message-ID: <200403131016.00881.giannozz@nest.sns.it> On Saturday 13 March 2004 06:02, Raghani Pushpa wrote: > I am getting the following error while calculating stress in Au/Ag system > in a slab calculation [...] > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > from sph_bes : error # 2 > j_{-1}(0) ?!? > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% on which version of the code? There used to be an error in some old versions of the code that caused this kind of problems 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 pushpa at jncasr.ac.in Sat Mar 13 14:37:09 2004 From: pushpa at jncasr.ac.in (Raghani Pushpa) Date: Sat, 13 Mar 2004 19:07:09 +0530 (IST) Subject: [Pw_forum] (no subject) Message-ID: Dear users, I was doing the phonon calculations on bulk alpha-gallium at gamma point. there are 8 atoms in the unit cell and the program achieves the self consistency for all the 24 irreps but at the end 24th irrep, it says 'Found additional translation: -0.5000 0.0000 -0.5000' and the program gets killed. and it doesn't find the frequencies and eigenvectors. what could be the problem for this? thanks, pushpa From giannozz at nest.sns.it Sat Mar 13 15:54:46 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Sat, 13 Mar 2004 15:54:46 +0100 Subject: [Pw_forum] (no subject) In-Reply-To: References: Message-ID: <200403131554.46146.giannozz@nest.sns.it> On Saturday 13 March 2004 14:37, Raghani Pushpa wrote: > I was doing the phonon calculations on bulk alpha-gallium at gamma point. > there are 8 atoms in the unit cell and the program achieves the self > consistency for all the 24 irreps but at the end 24th irrep, it says > 'Found additional translation: -0.5000 0.0000 -0.5000' and the > program gets killed. and it doesn't find the frequencies and eigenvectors. > what could be the problem for this? what I wrote a few days ago: http://www.democritos.it/pipermail/pw_forum/2004-March/000929.html applies to this case 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 sbraccia at sissa.it Sat Mar 13 18:38:52 2004 From: sbraccia at sissa.it (Carlo Sbraccia) Date: Sat, 13 Mar 2004 18:38:52 +0100 (CET) Subject: [Pw_forum] Restarting PWSCF - usability issues In-Reply-To: <20040312212355.95772.qmail@web21202.mail.yahoo.com> Message-ID: On Fri, 12 Mar 2004, Konstantin Kudin wrote: > > > restarting with atomic wfc usually implies that > > several iterations are needed > > to diagonalize the hamiltonian because the threshold > > is more strict than the > > one used for he first scf iteration of a > > "from_scratch" calculation. > > > Moreover, since there is no way for the code to know > > at restart time whether > > the starting potential is close to the scf one or > > not, the code doesn't know > > the correct value for diagonalization threshold. > > Dear Carlo > > It appears that the code is already quite smart and > can detect such problems and lower the threshold on > the fly at the same cycle. So restarting from *.rho > file alone costs only that first diagonalization with > large threshold when it finds out that the threshold > should be smaller - hardly a big price to pay for the > convenience of not dealing with *.wfc* files. > > Here: > The initial density is read from file > yz_1s.rho > Starting wfc are atomic > total cpu time spent up to now is 34.38 secs > iteration # 1 ecut= 28.00 ryd beta= > .70 > Davidson diagonalization with overlap > ethr = 1.00E-05, avg # of iterations = 5.0 > Threshold (ethr) on eigenvalues was too large: > Diagonalizing with lowered threshold > Davidson diagonalization with overlap > ethr = 2.29E-07, avg # of iterations = 4.0 Dear Kostya, I konw that part of the code quite well (I wrote it some weeks ago): it was written to avoid these "restart" problems, but, since then, it has not been widely tested. In the case reported in your mail it seems to work (nice news), but I'm not sure that it is always so and I'd not say that old wfcs are always useless. Indeed you see that starting from atomic 9 davidson iterations are needed (in average) to diagonalize the hamiltonian: using the old wfcs as starting wfc I guess that a smaller number of iterations was probably needed. Of course if you have serious problems in dealing with *.wfc* files this can be considered a worthy price. carlo From degironc at sissa.it Sat Mar 13 19:19:47 2004 From: degironc at sissa.it (Stefano de Gironcoli) Date: Sat, 13 Mar 2004 19:19:47 +0100 (CET) Subject: [Pw_forum] Star_q degeneracy error In-Reply-To: Message-ID: dear Yanming Ma, in your script you are using the following ccordinates q = (0.49999999 0.28868359 0.00000000) I guess you want to study the K point in the BZ q = (0.5, 0.5/sqrt(3.0), 0.0) = (0.50000000 0.288675135 0.0000000) This means that the q-point you are using is NOT the high symmetry K point by an amount of the order of 8.455 x 10^-6 (on the y coordinate). In order to check whether a symmetry operation belongs to the small-group of q the code performs a comparison between q and the rotated q having an aceptance tollerance that is fixed as 1.0x10-5 (in routine PW/eqvect.f90) which is very close to the accuracy you used to specify the K point. Probably the symmetry check is passed for some symmetry operations and not in some other cases in a way that confuses the code. I would say that it is not a bug: some acceptance threshold in the symmetry check need to be set and if the accuracy used in the coordinates is borderline the code my not figure out properly the symmetry and then it MUST stop and complain. Use more accurate values for the coordinates... it works ! Stefano de Gironcoli On Fri, 12 Mar 2004, ma Yanming wrote: > Dear Paolo, > > The error occurred when I used both the 1.2.0 and the lastest 2.0 versions. > I also tried for different PP. It didn't help. > > My case is Si (metal phase) with simple hcp structure (space group is > P6/mmm) a=4.7599 a.u., c=0.9365. > > This "star_q wrong degeneracy " error only occurs for several q points. I > read the source code about this error. It is related to the crystal > symmetry. I couldn't figure out what is the reason for this error in my > case. I attached my run_scripts file in the attachment. Please have a look. > > Thanks > > Yanming Ma PhD > Steacie Institute for Molecular Sciences, > National Research Councils of Canada. > 100 Sussex > K1A 0R6 > > > > > > >From: Paolo Giannozzi > >Reply-To: pw_forum at pwscf.org > >To: pw_forum at pwscf.org > >Subject: Re: [Pw_forum] Star_q degeneracy error > >Date: Wed, 10 Mar 2004 19:54:31 +0100 > > > >On Wednesday 10 March 2004 19:04, ma Yanming wrote: > > > > > "Star_q degeneracy error". > > > >very nice error indeed. Which version of the code are you using? > >If it isn't the last, could you please verify if the error is still there > in > >the last version? Otherwise, please post enough input data to > >reproduce the error > > > >Paolo > > > >-- > >Paolo Giannozzi e-mail: giannozz at nest.sns.it > >Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 > >Piazza dei Cavalieri 7 I-56126 Pisa, Italy > > > >_______________________________________________ > >Pw_forum mailing list > >Pw_forum at pwscf.org > >http://www.democritos.it/mailman/listinfo/pw_forum > > _________________________________________________________________ > ?????????????????????????????? MSN Hotmail?? http://www.hotmail.com > From degironc at sissa.it Sat Mar 13 19:43:22 2004 From: degironc at sissa.it (Stefano de Gironcoli) Date: Sat, 13 Mar 2004 19:43:22 +0100 (CET) Subject: [Pw_forum] error in stress calculation In-Reply-To: Message-ID: This problem should not be appear anymore in pw.2.0 It was due to the fact that the Bessel function of order -1 diverges in zero. One of the stress routines used this function for some intermediate step in the calculation and complained if the radial grid of the pseudopotentential contained the origin. Now it is done differently. Stefano de Gironcoli On Sat, 13 Mar 2004, Raghani Pushpa wrote: > > Dear users, > I am getting the following error while calculating stress in Au/Ag system > in a slab calculation. > > entering subroutine stress ... > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > from sph_bes : error # 2 > j_{-1}(0) ?!? > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > stopping ... > 2 > > whereas the code works well for ag/pt (slab) system. > > what could be the problem? > > pushpa > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From yanming_ma at hotmail.com Mon Mar 15 03:04:28 2004 From: yanming_ma at hotmail.com (ma Yanming) Date: Mon, 15 Mar 2004 10:04:28 +0800 Subject: [Pw_forum] Star_q degeneracy error Message-ID: Dear Stefano de Gironcoli Thanks for your excellent comments. Yes, the things go just like your suggestion. As you know, before we try to calcuate a whole phonon dispersion curves along high symmetry direction in the BZ, the most important thing is to determine how many and which special q points we have to calculate directly for the selected k mesh (say 444 or 666), then after that by using the resulting force constants we can obtain the phonon dispersion. I made my own code to choose the special q points. In my case, due to the numerical error (from my input) instead of (0.50000000 0.288675135 0.0000000), I got the (0.49999999 0.28868359 0.00000000). The discrepancy in y axis is 8x10-6. Actually, in real situation, the difference in phonon for these two q points is negligible, if the codes go through both the two points. The big advantage of linear response theory to calculate the phonons is from the reality of obtaining phonons at any wave vector. By this method, we can always check how good is the phonons we calculate by the interploation of force constant in the BZ. This is also the reason why some people stop using the supercell method in the phonon calculation. It seems that in this hcp case, we don't realize what we are supposed to realize (obtaining the phonons at any wave vectr). The phonons fail at some wave vectors. Is there any good idea to perfect the PWSCF code? Regards! Yanming Ma PhD Steacie Institute for Molecular Sciences, National Research Councils of Canada. 100 Sussex K1A 0R6 >From: Stefano de Gironcoli >Reply-To: pw_forum at pwscf.org >To: pw_forum at pwscf.org >Subject: Re: [Pw_forum] Star_q degeneracy error >Date: Sat, 13 Mar 2004 19:19:47 +0100 (CET) > >dear Yanming Ma, > >in your script you are using the following ccordinates >q = (0.49999999 0.28868359 0.00000000) >I guess you want to study the K point in the BZ >q = (0.5, 0.5/sqrt(3.0), 0.0) = > (0.50000000 0.288675135 0.0000000) > >This means that the q-point you are using is NOT the >high symmetry K point by an amount of the order of >8.455 x 10^-6 (on the y coordinate). > >In order to check whether a symmetry operation belongs >to the small-group of q the code performs a comparison >between q and the rotated q having an aceptance tollerance >that is fixed as 1.0x10-5 (in routine PW/eqvect.f90) which >is very close to the accuracy you used to specify the K point. >Probably the symmetry check is passed for some symmetry >operations and not in some other cases in a way that confuses >the code. > >I would say that it is not a bug: some acceptance threshold in >the symmetry check need to be set and if the accuracy used in >the coordinates is borderline the code my not figure out properly >the symmetry and then it MUST stop and complain. > >Use more accurate values for the coordinates... it works ! > >Stefano de Gironcoli > >On Fri, 12 Mar 2004, ma Yanming wrote: > > > Dear Paolo, > > > > The error occurred when I used both the 1.2.0 and the lastest 2.0 versions. > > I also tried for different PP. It didn't help. > > > > My case is Si (metal phase) with simple hcp structure (space group is > > P6/mmm) a=4.7599 a.u., c=0.9365. > > > > This "star_q wrong degeneracy " error only occurs for several q points. I > > read the source code about this error. It is related to the crystal > > symmetry. I couldn't figure out what is the reason for this error in my > > case. I attached my run_scripts file in the attachment. Please have a look. > > > > Thanks > > > > Yanming Ma PhD > > Steacie Institute for Molecular Sciences, > > National Research Councils of Canada. > > 100 Sussex > > K1A 0R6 > > > > > > > > > > > > >From: Paolo Giannozzi > > >Reply-To: pw_forum at pwscf.org > > >To: pw_forum at pwscf.org > > >Subject: Re: [Pw_forum] Star_q degeneracy error > > >Date: Wed, 10 Mar 2004 19:54:31 +0100 > > > > > >On Wednesday 10 March 2004 19:04, ma Yanming wrote: > > > > > > > "Star_q degeneracy error". > > > > > >very nice error indeed. Which version of the code are you using? > > >If it isn't the last, could you please verify if the error is still there > > in > > >the last version? Otherwise, please post enough input data to > > >reproduce the error > > > > > >Paolo > > > > > >-- > > >Paolo Giannozzi e-mail: giannozz at nest.sns.it > > >Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 > > >Piazza dei Cavalieri 7 I-56126 Pisa, Italy > > > > > >_______________________________________________ > > >Pw_forum mailing list > > >Pw_forum at pwscf.org > > >http://www.democritos.it/mailman/listinfo/pw_forum > > > > _________________________________________________________________ > > ??????????????? MSN Hotmail? http://www.hotmail.com > > > >_______________________________________________ >Pw_forum mailing list >Pw_forum at pwscf.org >http://www.democritos.it/mailman/listinfo/pw_forum _________________________________________________________________ ?????????????? MSN Messenger: http://messenger.msn.com/cn From mousumi at jncasr.ac.in Mon Mar 15 07:46:59 2004 From: mousumi at jncasr.ac.in (Mousumi Upadhyay) Date: Mon, 15 Mar 2004 12:16:59 +0530 (IST) Subject: [Pw_forum] Star_q degeneracy error In-Reply-To: References: Message-ID: Hi all, Am using PWSCF for a hexagonal lattice-system. I want to relax the system fully, i.e. I want to relax lattice parameters a,c and internal structure parameter u, simultaneously through PWSCF (not manually). Earlier we were using option "iswitch"=1, for just relaxing u, ie. structural relaxation. Now what option should we use? Thanks,, Mousumi. From degironc at sissa.it Mon Mar 15 14:24:48 2004 From: degironc at sissa.it (Stefano de Gironcoli) Date: Mon, 15 Mar 2004 14:24:48 +0100 Subject: [Pw_forum] Star_q degeneracy error References: Message-ID: <4055AEA0.4020808@sissa.it> ma Yanming wrote: > ........................ > It seems that in this hcp case, we don't realize what we are supposed > to realize (obtaining the phonons at any wave vectr). The phonons fail > at some wave vectors. Is there any good idea to perfect the PWSCF code? > - One could use a different definition for the check (based on the cartesian distance between q and rotated q and not on a component-by-component check). - One could increse the acceptance threshold or reduce it. - One could do the calculation removing the symmetry. I'm confident that this will never be enough to beat the fantasy of users in finding out a problematic input. I remain of my opinion that this IS NOT A BUG. The code finds correctily that there is a problem in the input ands signal what it is (albeit in a criptic way): the coordinate are such that the symmetry check fails because they are just enough different from an high symmetry point that some symmetry operation is found and some other not in an inpredictable way. In this situation the code CORRECTLY STOPS and let you have the opportunity to fix the input or modifiy the acceptance threshold if you prefere. But some threshold MUST be specified and therefore THERE ALWAYS BE some q point that confuses the code no matter how you define the threshold or the check. You can only shift the problem away from the specific point you are considering. regards, stefano From mpayami at aeoi.org.ir Tue Mar 16 11:14:53 2004 From: mpayami at aeoi.org.ir (Mahmoud Payami) Date: Tue, 16 Mar 2004 14:44:53 +0430 Subject: [Pw_forum] PW_ROOT problem Message-ID: <005401c40b3f$86262af0$1b6710ac@aeoi.org.ir> Dear All, I have installed PWSCF_2.0 successfully(?!). Trying to run the first example, it stops with the following message: "The directory PW_ROOT /home/mahmoud/O-sesame does not exist" I have set the environment with the existing directory names but nothing happened. I would be grateful if someone give me a tip how to get rid of "O-sesame". Best regards, Mahmoud From duanxm at ts.infn.it Tue Mar 16 11:28:04 2004 From: duanxm at ts.infn.it (Xiangmei Duan) Date: Tue, 16 Mar 2004 11:28:04 +0100 (MET) Subject: [Pw_forum] PW_ROOT problem In-Reply-To: <005401c40b3f$86262af0$1b6710ac@aeoi.org.ir> Message-ID: Before running the job, we should change the definiation of the directory (PW_ROOT, PSEUDO_DIR, TMP_DIR)in the file environment_variables under pw_examples directory. Hope it would be helpful. good luck, XM On Tue, 16 Mar 2004, Mahmoud Payami wrote: > Dear All, > > I have installed PWSCF_2.0 successfully(?!). Trying to run the first > example, it stops with the following message: > > "The directory PW_ROOT /home/mahmoud/O-sesame does not exist" > I have set the environment with the existing directory names but nothing > happened. > I would be grateful if someone give me a tip how to get rid of "O-sesame". > > Best regards, > Mahmoud > > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From mpayami at aeoi.org.ir Tue Mar 16 12:06:49 2004 From: mpayami at aeoi.org.ir (Mahmoud Payami) Date: Tue, 16 Mar 2004 15:36:49 +0430 Subject: [Pw_forum] PW_ROOT problem References: Message-ID: <000701c40b46$c78ab8b0$1b6710ac@aeoi.org.ir> Dear Xiangmei, Thank you very much. It is surprising that when I did a search for a filename containig the text "O-sesame", nothing found! Best wishes, Mahmoud > > Before running the job, we should change the definiation of the directory > (PW_ROOT, PSEUDO_DIR, TMP_DIR)in the file environment_variables under > pw_examples directory. > > Hope it would be helpful. > good luck, > XM > > On Tue, 16 Mar 2004, Mahmoud Payami wrote: > > > Dear All, > > > > I have installed PWSCF_2.0 successfully(?!). Trying to run the first > > example, it stops with the following message: > > > > "The directory PW_ROOT /home/mahmoud/O-sesame does not exist" > > I have set the environment with the existing directory names but nothing > > happened. > > I would be grateful if someone give me a tip how to get rid of "O-sesame". > > > > Best regards, > > Mahmoud > > > > > > _______________________________________________ > > Pw_forum mailing list > > Pw_forum at pwscf.org > > http://www.democritos.it/mailman/listinfo/pw_forum > > > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From duanxm at ts.infn.it Tue Mar 16 13:53:19 2004 From: duanxm at ts.infn.it (Xiangmei Duan) Date: Tue, 16 Mar 2004 13:53:19 +0100 (MET) Subject: [Pw_forum] PW_ROOT problem In-Reply-To: <000701c40b46$c78ab8b0$1b6710ac@aeoi.org.ir> References: <000701c40b46$c78ab8b0$1b6710ac@aeoi.org.ir> Message-ID: Dear Mahmoud, I rememebered that I met the same problem. but it worked when I set the necessary directory. The definication looks like: PW_ROOT=/home/Mahmoud/ PSEUDO_DIR=/home/Mahmoud/pseudo/ TMP_DIR=/tmp/Mahmoud/ in the file environment_variable. Right ? BR, XM On Tue, 16 Mar 2004, Mahmoud Payami wrote: > Dear Xiangmei, > > Thank you very much. It is surprising that when I did a search for a > filename containig the text "O-sesame", nothing found! > > Best wishes, > Mahmoud > > > > Before running the job, we should change the definiation of the directory > > (PW_ROOT, PSEUDO_DIR, TMP_DIR)in the file environment_variables under > > pw_examples directory. > > > > Hope it would be helpful. > > good luck, > > XM > > > > On Tue, 16 Mar 2004, Mahmoud Payami wrote: > > > > > Dear All, > > > > > > I have installed PWSCF_2.0 successfully(?!). Trying to run the first > > > example, it stops with the following message: > > > > > > "The directory PW_ROOT /home/mahmoud/O-sesame does not exist" > > > I have set the environment with the existing directory names but nothing > > > happened. > > > I would be grateful if someone give me a tip how to get rid of > "O-sesame". > > > > > > Best regards, > > > Mahmoud > > > > > > > > > _______________________________________________ > > > Pw_forum mailing list > > > Pw_forum at pwscf.org > > > http://www.democritos.it/mailman/listinfo/pw_forum > > > > > > > _______________________________________________ > > Pw_forum mailing list > > Pw_forum at pwscf.org > > http://www.democritos.it/mailman/listinfo/pw_forum > > > > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From mounet at MIT.EDU Wed Mar 17 01:21:01 2004 From: mounet at MIT.EDU (Nicolas Mounet) Date: Tue, 16 Mar 2004 19:21:01 -0500 Subject: [Pw_forum] PW 2.0 - problems with parallelization Message-ID: <405799ED.10708@mit.edu> Dear PW users, Here is the situation: I have installed last week the new release of pwscf. Using the old configuration procedure ("./configure.old"), I was able to compile both in single-processor mode or in parallel. However, while the single-processor version seems to works, the parallel one fails even on simple things like the Si part of "example1" from pw_examples (see input script in attachement). The self-consistent calculation works, but the non self-consistent one has a strange behavior : - sometimes, pw just "hangs" without being killed, CPUs don't work anymore and pw stops writing in the output after the following lines: [...] nbndx = 32 nbnd = 8 natomwfc = 8 npwx = 168 nelec = 8.00 nkb = 8 ngl = 65 - other times (depending on the energy cutoff !), odd errors appear at the end of the non self-consistent output file, like: [...] nbndx = 32 nbnd = 8 natomwfc = 8 npwx = 168 nelec = 8.00 nkb = 8 ngl = 65 The initial potential is read from file silicon.pot Starting wfc are atomic MPI_Recv: message truncated (rank 1, MPI_COMM_WORLD) Rank (1, MPI_COMM_WORLD): Call stack within LAM: Rank (1, MPI_COMM_WORLD): - MPI_Recv() Rank (1, MPI_COMM_WORLD): - MPI_Bcast() Rank (1, MPI_COMM_WORLD): - MPI_Allreduce() Rank (1, MPI_COMM_WORLD): - main() and the output stops there. (If the cutoff energy is put at 20 Ryd, the first case happens, whereas the second case happens for a cutoff of 18 Ryd) The same example works normally if the non-sef consistent calculation is done in single-processor mode instead of parallel. The operating system is Linux, running on a PC cluster (dual Xeon). The same kind of problem occurs when compiling either with ifc 6.0 or ifc 7.0, and using either mkl 5.1 or mkl 6.1. We also use mpif77 compiler and LAM 7.0.3/MPI 2 C++ for parallel implementation (older versions seem to give the same problem). The FFTW environment used is local. Note that the old version of pw (1.3.1) worked perfectly well. An additional fact (that may be of no relevance) is that the new configuration procedure ("./configure") is not able to detect the parallel environment, in particular cannot find "zggev", "dgemm" and "mpi_init" in the various libraries. Nevertheless, the old configuration procedure ("./configure.old") leads to compilation without any problem. Thanks in advance, Best regards, Nicolas PS: I also give the make file used (which compiles well) in attachement -- Nicolas Mounet Prof. Marzari's Group Department of Materials Science and Engineering 13-4084 Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge MA 02139 USA Tel: (+1)617-253-6026 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: input.txt Url: /pipermail/attachments/20040316/c67ba320/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: make.sys.txt Url: /pipermail/attachments/20040316/c67ba320/attachment-0001.txt From giannozz at nest.sns.it Wed Mar 17 23:35:02 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 17 Mar 2004 23:35:02 +0100 Subject: [Pw_forum] PW 2.0 - problems with parallelization In-Reply-To: <405799ED.10708@mit.edu> References: <405799ED.10708@mit.edu> Message-ID: <200403172335.02191.giannozz@nest.sns.it> On Wednesday 17 March 2004 01:21, Nicolas Mounet wrote: > - sometimes, pw just "hangs" without being killed [...] > - other times (depending on the energy cutoff !), odd errors > appear at the end of the non self-consistent output file [...] > > Note that the old version of pw (1.3.1) worked perfectly well. You can use CVS to go back in time (cvs update -D date) until the problem disappear. This might be helpful in locating when the problem originate, but don't assume that you will find why: since nothing relevant about parallelization has changed with the last version, my guess is that your problem comes from incompatible libraries or from compiler bugs. 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 mounet at MIT.EDU Thu Mar 18 04:42:38 2004 From: mounet at MIT.EDU (Nicolas Mounet) Date: Wed, 17 Mar 2004 22:42:38 -0500 Subject: [Pw_forum] PW 2.0 - problems with parallelization In-Reply-To: <200403172335.02191.giannozz@nest.sns.it> References: <405799ED.10708@mit.edu> <200403172335.02191.giannozz@nest.sns.it> Message-ID: <40591AAE.4080200@mit.edu> Thank you very much for the tip. My problem is apparently solved, if I use the 8th March release. Actually, after several tests it appears that releases from Feb 19th to March 8th (included) work fine, while releases after that date don't. Releases from March 9th to March 15th give in fact another kind of error even in simple scf calculations (same input as in my first mail): [...] iteration # 1 ecut= 20.00 ryd beta=0.70 Conjugate-gradient style diagonalization ethr = 1.00E-02, avg # of iterations = 3.0 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from diropn : error # 99 error opening p? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... The release of March 16th gives the errors and strange behavior I described in my first mail yesterday (I did not test release of today, March 17th). Reading the Changelog file makes me think that the changes in the references to mpif.h could be responsible of that (since it seems that problems related to this library are known to lead to such "hangings"). Thanks again for your help ! Nicolas From mousumi at jncasr.ac.in Thu Mar 18 06:09:41 2004 From: mousumi at jncasr.ac.in (Mousumi Upadhyay) Date: Thu, 18 Mar 2004 10:39:41 +0530 (IST) Subject: [Pw_forum] problems with programme stopping In-Reply-To: <200403172335.02191.giannozz@nest.sns.it> References: <405799ED.10708@mit.edu> <200403172335.02191.giannozz@nest.sns.it> Message-ID: Dear All, In PWSCF, am running some structural relaxation jobs. there, most of the times, the jobs are stopping with an error msg, entering subroutine stress ... total stress (a.u.) (kbar) P= -943.01 -0.00641098 0.00000000 0.00000000 -943.09 0.00 0.00 0.00000000 -0.00641098 0.00000000 0.00 -943.09 0.00 0.00000000 0.00000000 -0.00640934 0.00 0.00 -942.85 searching for next position (pslinmin)... Eold = -798.02648163 Etot = -798.02650981 DEold = -0.00005398 DEtot = -0.00322997 linmin: 3rd order interpolation %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from linmin : error # 2 unexpected error %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... can u please tell, why? what is this? regards, mousumi. From mousumi at jncasr.ac.in Thu Mar 18 06:37:43 2004 From: mousumi at jncasr.ac.in (Mousumi Upadhyay) Date: Thu, 18 Mar 2004 11:07:43 +0530 (IST) Subject: [Pw_forum] problems with programme stopping Message-ID: ALSO, PLEASE NOTE THAT STRESSES ARE ALL SO LARGE & ALL NEGATIVE. WHY IT IS SO??? WHAT COULD BE THE SOLUTION? AM USING ULTRASOFT PSP FOR MY SYSTEM. BEST REGARDS, MOUSUMI. ---------- Forwarded message ---------- Date: Thu, 18 Mar 2004 10:39:41 +0530 (IST) From: Mousumi Upadhyay To: pw_forum at pwscf.org, Paolo Giannozzi Subject: problems with programme stopping Dear All, In PWSCF, am running some structural relaxation jobs. there, most of the times, the jobs are stopping with an error msg, entering subroutine stress ... total stress (a.u.) (kbar) P= -943.01 -0.00641098 0.00000000 0.00000000 -943.09 0.00 0.00 0.00000000 -0.00641098 0.00000000 0.00 -943.09 0.00 0.00000000 0.00000000 -0.00640934 0.00 0.00 -942.85 searching for next position (pslinmin)... Eold = -798.02648163 Etot = -798.02650981 DEold = -0.00005398 DEtot = -0.00322997 linmin: 3rd order interpolation %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from linmin : error # 2 unexpected error %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... can u please tell, why? what is this? regards, mousumi. From himanshu at apsara.barc.ernet.in Thu Mar 18 13:13:08 2004 From: himanshu at apsara.barc.ernet.in (himanshu at apsara.barc.ernet.in) Date: Thu, 18 Mar 2004 17:43:08 +0530 (IST) Subject: [Pw_forum] error nvecx too small Message-ID: <1079611988.405992547c64e@bts.barc.ernet.in> Dear pwscf users I was trying to calculate raman activity using Gamma only code.In my unit cell I have 4 types of atoms(totle 12 atoms) when I run the job then it calculates the totel energy and phonon modes but it stops after without calculating raman activity and gives folowing out put omega( 35) = 42.510099 [THz] =1417.993684 [cm-1] omega( 36) = 42.924150 [THz] =1431.805035 [cm-1] ************************************************************************** Starting over from the beginning NEW-OLD atomic charge density approx. for the potential total cpu time spent up to now is 0.16 secs iteration # 1 ecut= 10.00 ryd beta=0.70 Davidson diagonalization with overlap %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from regter : error # 1 nvecx is too small %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... I don't whether one can calculate raman activity with that much number of atoms. I will appreciate very much if anybody can give some comments on it. with best regards himanshu ------------------------------------------------- From mousumi at jncasr.ac.in Thu Mar 18 16:12:01 2004 From: mousumi at jncasr.ac.in (Mousumi Upadhyay) Date: Thu, 18 Mar 2004 20:42:01 +0530 (IST) Subject: [Pw_forum] problems with programme stopping In-Reply-To: References: Message-ID: yes.... my system is hexagonal crystal, with lattice vectors a=b & not equal to c. There are three atoms in unit cell & all three are at different planes along c(z-axis). plzz tell me, why this prob is coming & how can it be solved??? regards, mousumi. On Thu, 18 Mar 2004, Subhradip Ghosh wrote: > On Thu, 18 Mar 2004, Mousumi Upadhyay wrote: > > Dear Mousumi, > The two problems you mentioned could be related. > Can you tell more about your system? > > Subhradip > > > > > ALSO, PLEASE NOTE THAT STRESSES ARE ALL SO LARGE & ALL NEGATIVE. > > WHY IT IS SO??? WHAT COULD BE THE SOLUTION? > > > > AM USING ULTRASOFT PSP FOR MY SYSTEM. > > > > BEST REGARDS, > > MOUSUMI. > > > > ---------- Forwarded message ---------- > > Date: Thu, 18 Mar 2004 10:39:41 +0530 (IST) > > From: Mousumi Upadhyay > > To: pw_forum at pwscf.org, Paolo Giannozzi > > Subject: problems with programme stopping > > > > Dear All, > > > > In PWSCF, am running some structural relaxation jobs. > > there, most of the times, the jobs are stopping with an error > > msg, > > > > > > entering subroutine stress ... > > > > total stress (a.u.) (kbar) P= > > -943.01 > > -0.00641098 0.00000000 0.00000000 -943.09 0.00 0.00 > > 0.00000000 -0.00641098 0.00000000 0.00 -943.09 0.00 > > 0.00000000 0.00000000 -0.00640934 0.00 0.00 -942.85 > > > > searching for next position (pslinmin)... > > Eold = -798.02648163 > > Etot = -798.02650981 > > DEold = -0.00005398 > > DEtot = -0.00322997 > > linmin: 3rd order interpolation > > > > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > from linmin : error # 2 > > unexpected error > > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > stopping ... > > > > > > can u please tell, why? what is this? > > > > regards, > > mousumi. > > _______________________________________________ > > Pw_forum mailing list > > Pw_forum at pwscf.org > > http://www.democritos.it/mailman/listinfo/pw_forum > > > > ******************************************************************* > Subhradip Ghosh > Post doctoral Fellow > Department of Materials Science & Engineering > University of Illinois at Urbana-Champaign > ******************************************************************** > Office Home > ********************************************************************** > MSEB 312C * 2001 South Orchard Street Apt D > 1304 W Green street * Urbana, IL-61801 > Urbana, IL-61801 * Phone # 2173841824 > Phone # 2173336584 * E-mail: subhradip at yahoo.com > E-mail: subhra at uiuc.edu * > ************************************************************************ > From degironc at sissa.it Thu Mar 18 16:23:56 2004 From: degironc at sissa.it (Stefano de Gironcoli) Date: Thu, 18 Mar 2004 16:23:56 +0100 Subject: [Pw_forum] problems with programme stopping References: <405799ED.10708@mit.edu> <200403172335.02191.giannozz@nest.sns.it> Message-ID: <4059BF0C.2060402@sissa.it> Problem wit relaxation: this is a error that occurred more often that one would have liked during structural relaxation when the shape of the potential energy surface was not very parabolic. The new version of pw uses a more robust version of bfgs algorithm that should overcome these problems. Problem with stress calculation: stress tensor is a quantity that converges poorly with cutoff, are you sure the values of ecutwfc and/or ecutrho are sufficiently large ? Stefano de Gironcoli Mousumi Upadhyay wrote: >Dear All, > > In PWSCF, am running some structural relaxation jobs. >there, most of the times, the jobs are stopping with an error >msg, > > > entering subroutine stress ... > > total stress (a.u.) (kbar) P= >-943.01 > -0.00641098 0.00000000 0.00000000 -943.09 0.00 0.00 > 0.00000000 -0.00641098 0.00000000 0.00 -943.09 0.00 > 0.00000000 0.00000000 -0.00640934 0.00 0.00 -942.85 > > searching for next position (pslinmin)... > Eold = -798.02648163 > Etot = -798.02650981 > DEold = -0.00005398 > DEtot = -0.00322997 > linmin: 3rd order interpolation > > >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > from linmin : error # 2 > unexpected error > >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > stopping ... > > > > From giannozz at nest.sns.it Thu Mar 18 19:43:19 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 18 Mar 2004 19:43:19 +0100 Subject: [Pw_forum] problems with programme stopping In-Reply-To: <4059BF0C.2060402@sissa.it> References: <405799ED.10708@mit.edu> <4059BF0C.2060402@sissa.it> Message-ID: <200403181943.19098.giannozz@nest.sns.it> On Thursday 18 March 2004 16:23, Stefano de Gironcoli wrote: > Problem wit relaxation: this is a error that occurred more often that > one would have liked during structural relaxation when the shape of the > potential energy surface was not very parabolic. more info here: http://www.pwscf.org/guide/2.0/html-node/node34.html under "Structural optimization..." 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 18 19:47:26 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 18 Mar 2004 19:47:26 +0100 Subject: [Pw_forum] PW 2.0 - problems with parallelization In-Reply-To: <40591AAE.4080200@mit.edu> References: <405799ED.10708@mit.edu> <200403172335.02191.giannozz@nest.sns.it> <40591AAE.4080200@mit.edu> Message-ID: <200403181947.26720.giannozz@nest.sns.it> On Thursday 18 March 2004 04:42, Nicolas Mounet wrote: > it appears that releases from Feb 19th to March 8th (included) work > fine, while releases after that date don't. wait a minute: were you talking about the CVS version? it may or may not work. Usually, it doesn't :-) 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 18 20:06:03 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 18 Mar 2004 20:06:03 +0100 Subject: [Pw_forum] error nvecx too small In-Reply-To: <1079611988.405992547c64e@bts.barc.ernet.in> References: <1079611988.405992547c64e@bts.barc.ernet.in> Message-ID: <200403182006.03954.giannozz@nest.sns.it> On Thursday 18 March 2004 13:13, himanshu at apsara.barc.ernet.in wrote: > I was trying to calculate raman activity using Gamma only code. the raman activity option is basically not usable, unless you know how to use it :-). I think that nobody has used it recently, so it may not even work (the phonon calculation with Gamma only should work). I'll have a look at it as soon as possible 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 goranka.bilalbegovic at zg.htnet.hr Sun Mar 21 16:19:09 2004 From: goranka.bilalbegovic at zg.htnet.hr (Goranka Bilalbegovic) Date: Sun, 21 Mar 2004 16:19:09 +0100 Subject: [Pw_forum] example 5 of example 3 Message-ID: <405DB26D.7030104@zg.htnet.hr> Hello. I am not able to plot correctly a charge density of the relaxed CO molecule in the example 3. The postprocessing is done as in the example 5, but iflag=3, and output_format is for the XCrySDen, or gOpenMol. When *.xsf file prepared by the pw.2.0.1 (and pw.1.3.0, 1.2.0) opens in the XCrySDen, then the display of the CO molecule geometry is in the default option display/unit of repetition/unit cell, and this is not useful for CO. The choice of the display/unit of repetition/translational asymmetric unit cell produces the correct image of the CO geometry. However, the charge density is still distributed according to the initial unit cell, and this is not the correct geometry. For the gOpenMol both files *.txt and *.txt.xyz are formed, but the number of particles in *.txt.xyz is zero for the CO molecule, and it is wrong for larger molecules/clusters. Thanks for help. Best regards, Goranka From Tone.Kokalj at ijs.si Mon Mar 22 11:24:37 2004 From: Tone.Kokalj at ijs.si (Tone Kokalj) Date: Mon, 22 Mar 2004 11:24:37 +0100 Subject: [Pw_forum] example 5 of example 3 In-Reply-To: <405DB26D.7030104@zg.htnet.hr> References: <405DB26D.7030104@zg.htnet.hr> Message-ID: <20040322102437.GA30659@crysden.ijs.si> On Sun, Mar 21, 2004 at 04:19:09PM +0100, Goranka Bilalbegovic wrote: > > When *.xsf file prepared by the pw.2.0.1 (and pw.1.3.0, 1.2.0) opens in > the XCrySDen, then the display of the CO molecule geometry is in the > default option display/unit of repetition/unit cell, and this is not > useful for CO. The choice of the display/unit of > repetition/translational asymmetric unit cell produces the correct image > of the CO geometry. However, the charge density is still distributed > according to the initial unit cell, and this is not the correct geometry. This behavior is correct: the choice of "display/unit of repetition" affects only the structure, but not the scalar field (charge density in your case). The problem here is the following: the CO molecule is positioned at the edge of the box (unit-cell), and using a "fast 3d plot" (output_format=5) is not very useful here (it would be when the molecule would be positioned at the center of the box). Hence you have two possibilities: either: 1.) choose the coordinates of CO as: ATOMIC_POSITIONS bohr C 8.256 6.0 6.0 O 6.0 6.0 6.0 0 0 0 and recalculate ... or: 2.) select the following plotting box in chdens input (output_format=3 or 4): origin: -0.5 -0.5 -0.5 1st vector: 1.0 0.0 0.0 2nd vector: 0.0 1.0 0.0 3rd vector: 0.0 0.0 1.0 Regards, Tone -- +------------------------------------------------------------------------+ | Anton Kokalj Email: Tone.Kokalj at ijs.si | | Department of Physical and Organic Chemistry Phone: x 386 1 477 3523 | | Jozef Stefan Institute Fax: x 386 1 477 3811 | | Jamova 39, SI-1000 Ljubljana | | SLOVENIA | +------------------------------------------------------------------------+ !!! *** please, do not send me attachments in any Microsoft format *** !!! From massimiliano.bonomi at mi.infn.it Tue Mar 23 10:57:42 2004 From: massimiliano.bonomi at mi.infn.it (Massimiliano Bonomi) Date: Tue, 23 Mar 2004 10:57:42 +0100 Subject: [Pw_forum] phonon frequencies with pwscf and cpmd Message-ID: <40600A16.8070302@mi.infn.it> Dear users, I'm studying a crystal made of small clusters of eight atoms of sodium with FCC simmetry. I'm using both pwscf and cpmd codes with the same parameters (cell dimension, cutoff for the wavefunctions, number of kpoints...), but with two different pseudopotentials. The two codes give the same results as far as the electronic part (energy levels) is concerned. Then I started studying phonons: cpmd does not use a perturbation method, rather it moves ions along each axis in each direction to calculate the forces and the hessian matrix. Here the two codes give very different results: the most striking difference is that pwsf's phonon frequencies are not all positive, as you can see in the attachment, while cpmd's frequencies are all positive and quite different from the previous ones. For comparison I've calculated phonon frequencies with pwscf using car-parrinello finite differences method, moving manually each atoms. I found negative frequencies which are in agreement with the ones I found with perturbation method. How is it possible to explain these differences between the two codes??? Thanks in advance for your help. Massimiliano Bonomi. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ph.out.cpmd Url: /pipermail/attachments/20040323/5ac9d672/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ph.out.pwscf Url: /pipermail/attachments/20040323/5ac9d672/attachment-0001.txt From giannozz at nest.sns.it Tue Mar 23 15:31:03 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 23 Mar 2004 15:31:03 +0100 Subject: [Pw_forum] phonon frequencies with pwscf and cpmd In-Reply-To: <40600A16.8070302@mi.infn.it> References: <40600A16.8070302@mi.infn.it> Message-ID: <200403231531.03587.giannozz@nest.sns.it> On Tuesday 23 March 2004 10:57, Massimiliano Bonomi wrote: > I'm using both pwscf and cpmd codes with the same parameters > (cell dimension, cutoff for the wavefunctions, number of kpoints...) > WAVEFUNCTION CUTOFF(RYDBERG): 15.00000 > DENSITY CUTOFF(RYDBERG): (DUAL= 4.00) 60.00000 > NUMBER OF SPECIAL K POINTS (IN CARTESIAN COORDINATES): 275 > kinetic-energy cut-off = 20.0000 Ry > charge density cut-off = 100.0000 Ry > number of k points= 258 [..] doesn't look the same to me. There is no reason to use a non-default cutoff for the charge density, by the way. > pwscf's phonon frequencies are not all positive see http://www.pwscf.org/guide/2.0/html-node/node34.html , under "ph.x does not yield acoustic modes with omega=0 at q=0" > For comparison I've calculated phonon frequencies with pwscf using > car-parrinello finite differences method moving manually each atom. > I found negative frequencies which are in agreement with the ones > I found with perturbation method. which demonstrates that the phonon code works Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From subhra at ux1.cso.uiuc.edu Tue Mar 23 16:11:28 2004 From: subhra at ux1.cso.uiuc.edu (Subhradip Ghosh) Date: Tue, 23 Mar 2004 09:11:28 -0600 (CST) Subject: [Pw_forum] disk space requirement for phonon calc. Message-ID: Hi, I would like to know how much disk space one needs to accomodate the large files produced by the phonon calculation in the newest version of PWSCF. Each time I try to run a phonon calculation for a 8 atom system the program crashes with 'i/o error in davcio'. The file sizes, particularly, *.wfc is quite large. Therefore, I guess it is a disk space problem. Is there any way to circumvent this problem other than looking for a machine that has large enough disk space? Subhradip ******************************************************************* Subhradip Ghosh Post doctoral Fellow Department of Materials Science & Engineering University of Illinois at Urbana-Champaign ******************************************************************** Office Home ********************************************************************** MSEB 312C * 2001 South Orchard Street Apt D 1304 W Green street * Urbana, IL-61801 Urbana, IL-61801 * Phone # 2173841824 Phone # 2173336584 * E-mail: subhradip at yahoo.com E-mail: subhra at uiuc.edu * ************************************************************************ From massimiliano.bonomi at mi.infn.it Wed Mar 24 14:37:22 2004 From: massimiliano.bonomi at mi.infn.it (Massimiliano Bonomi) Date: Wed, 24 Mar 2004 14:37:22 +0100 Subject: [Pw_forum] phonon frequencies with pwscf and cpmd Message-ID: <40618F12.3020803@mi.infn.it> Just some explanations. I did actually the calculation with the same parameters ( cutoff_wfc=30, cutoff_rho=120, kpoints_mesh=6 6 6): the phonon frequencies of the two codes are more or less the same of the file I have attached. The negative frequencies of pwscf remain unchanged after using dynmat.x. But this is not the point. My real question is if everyone can explain me why this two codes give such different results in this particular calculation, while the other analysis on this system (energies of the occupied and unoccupied states, for example) are exactly the same. Can it be due to the use of two different pseudopotentials? Thanks for your help. Best regards, Massimiliano Bonomi >On Tuesday 23 March 2004 10:57, Massimiliano Bonomi wrote: > >>/ I'm using both pwscf and cpmd codes with the same parameters >/>/ (cell dimension, cutoff for the wavefunctions, number of kpoints...) >/ >>/ WAVEFUNCTION CUTOFF(RYDBERG): 15.00000 >/>/ DENSITY CUTOFF(RYDBERG): (DUAL= 4.00) 60.00000 >/>/ NUMBER OF SPECIAL K POINTS (IN CARTESIAN COORDINATES): 275 >/ >>/ kinetic-energy cut-off = 20.0000 Ry >/>/ charge density cut-off = 100.0000 Ry >/>/ number of k points= 258 [..] >/ >doesn't look the same to me. There is no reason to use a non-default >cutoff for the charge density, by the way. > >>/ pwscf's phonon frequencies are not all positive >/ >see http://www.pwscf.org/guide/2.0/html-node/node34.html , under >"ph.x does not yield acoustic modes with omega=0 at q=0" > >>/ For comparison I've calculated phonon frequencies with pwscf using >/>/ car-parrinello finite differences method moving manually each atom. >/>/ I found negative frequencies which are in agreement with the ones >/>/ I found with perturbation method. >/ >which demonstrates that the phonon code works > From giannozz at nest.sns.it Wed Mar 24 17:29:05 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 24 Mar 2004 17:29:05 +0100 Subject: [Pw_forum] phonon frequencies with pwscf and cpmd In-Reply-To: <40618F12.3020803@mi.infn.it> References: <40618F12.3020803@mi.infn.it> Message-ID: <200403241729.05087.giannozz@nest.sns.it> On Wednesday 24 March 2004 14:37, Massimiliano Bonomi wrote: > My real question is if everyone can explain me are you sure you want explanations from "everyone" ?!? > why this two codes give such different results in this particular > calculation - verify the atomic masses. Remember that "atomic units" means something different in cpmd and in pwscf ! - try simpler systems first: for instance, the normal mode of a sodium dimer; a zone-boundary phonon of fcc Na > Can it be due to the use of two different pseudopotentials? such a large difference seems unlikely (unless one of the two PP is bad, of course) 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 24 17:42:50 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 24 Mar 2004 17:42:50 +0100 Subject: [Pw_forum] disk space requirement for phonon calc. In-Reply-To: References: Message-ID: <200403241742.50940.giannozz@nest.sns.it> On Tuesday 23 March 2004 16:11, Subhradip Ghosh wrote: > I would like to know how much disk space one needs to accomodate > the large files produced by the phonon calculation in the newest version > of PWSCF. the same as in previous versions: you need several files whose size is (number of bands) * (number of plane waves) * (number of k-points). An 8-atom cell shouldn't be such a big deal, though, with today's computers 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 michael.malorny at physik.uni-regensburg.de Thu Mar 25 08:36:33 2004 From: michael.malorny at physik.uni-regensburg.de (Michael Malorny) Date: Thu, 25 Mar 2004 08:36:33 +0100 (CET) Subject: [Pw_forum] Negative frequencies in hcp structure Message-ID: Dear pwscf users, At the moment I am performing studies on the disordered system CdS/CdSe with wurtzite structure. I have severe problems in calculating the dynamical properties of the bulk systems CdS and CdSe: I obtain badly deformed translational branches in the Gamma-A direction after interpolating over a 664 q-mesh leading to negative frequencies in Gamma-A direction (up to -45 cm-1 and reaching from Gamma point to half way to A point). The calculated dynamical matrix between Gamma and A yields negative frequencies. In the Gamma-K-M and Gamma-M direction I have minor problems with negative frequencies in the vicinity of the Gamma point. This could be due to strongly negative frequencies I obtained calculating the dynamical matrix at Gamma (up to -30 cm-1) in conjunction with applying the ASR. In general, the interpolated frequencies do not agree with directly calculated frequencies at the same q-point. Some facts that should help you to understand my situation: 1. The structure has been relaxed and should be okay (I maintain vanishing forces and stress tensors). The structural results lie within an errorbar of around 1.5% with respect to experimental results. 2. I use Vanderbild USPP (GGA) which I found enclosed to the Vanderbild package (and LDA transformed versions of them). 3. Calculating the same materials (CdS, CdSe) with the same USPPs but applying the fcc structure yields no problems at all (no negative frequencies, dispersion looking ok). 4. Calculating hcp SiC with PPs found on pwscf.org applying the very same procedure I used for CdS and CdSe yeilds no problems at all (no negative frequencies, dispersion looking ok). Further calculation details can be given. In my opinion I have a PP problem. :/ In case that's true: Does anyone have a set of working PP for me? I'll be very grateful for all suggestions! Regards Michael Malorny From michael.malorny at physik.uni-regensburg.de Thu Mar 25 09:01:20 2004 From: michael.malorny at physik.uni-regensburg.de (Michael Malorny) Date: Thu, 25 Mar 2004 09:01:20 +0100 (CET) Subject: [Pw_forum] Negative frequencies in hcp structure Message-ID: Dear pwscf users, At the moment I am performing studies on the disordered system CdS/CdSe with wurtzite structure. I have severe problems in calculating the dynamical properties of the bulk systems CdS and CdSe: I obtain badly deformed translational branches in the Gamma-A direction after interpolating over a 664 q-mesh leading to negative frequencies in Gamma-A direction (up to -45 cm-1 and reaching from Gamma point to half way to A point). The calculated dynamical matrix between Gamma and A yields negative frequencies. In the Gamma-K-M and Gamma-M direction I have minor problems with negative frequencies in the vicinity of the Gamma point. This could be due to strongly negative frequencies I obtained calculating the dynamical matrix at Gamma (up to -30 cm-1) in conjunction with applying the ASR. In general, the interpolated frequencies do not agree with directly calculated frequencies at the same q-point. Some facts that should help you to understand my situation: 1. The structure has been relaxed and should be okay (I maintain vanishing forces and stress tensors). The structural results lie within an errorbar of around 1.5% with respect to experimental results. 2. I use Vanderbild USPP (GGA) which I found enclosed to the Vanderbild package (and LDA transformed versions of them). 3. Calculating the same materials (CdS, CdSe) with the same USPPs but applying the fcc structure yields no problems at all (no negative frequencies, dispersion looking ok). 4. Calculating hcp SiC with PPs found on pwscf.org applying the very same procedure I used for CdS and CdSe yeilds no problems at all (no negative frequencies, dispersion looking ok). Further calculation details can be given. In my opinion I have a PP problem. :/ In case that's true: Does anyone have a set of working PP for me? I'll be very grateful for all suggestions! Regards Michael Malorny From massimiliano.bonomi at mi.infn.it Thu Mar 25 15:29:01 2004 From: massimiliano.bonomi at mi.infn.it (Massimiliano Bonomi) Date: Thu, 25 Mar 2004 15:29:01 +0100 Subject: [Pw_forum] pseudopotential conversion Message-ID: <4062ECAD.3020508@mi.infn.it> Dear users, Is it possible to convert a pseudopotential in UPF format to a format suitable for cpmd?? Thanks for your help, Massimilano Bonomi From giannozz at nest.sns.it Thu Mar 25 16:39:25 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 25 Mar 2004 16:39:25 +0100 Subject: [Pw_forum] pseudopotential conversion In-Reply-To: <4062ECAD.3020508@mi.infn.it> References: <4062ECAD.3020508@mi.infn.it> Message-ID: <200403251639.25475.giannozz@nest.sns.it> On Thursday 25 March 2004 15:29, Massimiliano Bonomi wrote: > Is it possible to convert a pseudopotential in UPF format to a format > suitable for cpmd?? it is, but you have to write a converter. A converter for the other way round is available, but little tested. Anyway, the most recent version (> november 2003) of cpmd should read the UPF format, at least for norm-conserving PPs 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 Thu Mar 25 18:20:42 2004 From: silviu at Princeton.EDU (Silviu Zilberman) Date: Thu, 25 Mar 2004 12:20:42 -0500 Subject: [Pw_forum] pseudopotential conversion In-Reply-To: <200403251639.25475.giannozz@nest.sns.it> References: <4062ECAD.3020508@mi.infn.it> <200403251639.25475.giannozz@nest.sns.it> Message-ID: <406314EA.8050800@Princeton.EDU> I tested the converter some time ago, and there are slight disagreements. I generated a NCPP (with the 'atom' code), and used it as input once in the original pw format, and once after converting to UPF. The differences in the energy are not huge, of the order of third/fourth decimal digit. It seems like a roundoff error of the converter. In most cases these would be minor differences, however for me it made a difference. Silviu. Paolo Giannozzi wrote: >On Thursday 25 March 2004 15:29, Massimiliano Bonomi wrote: > > > >>Is it possible to convert a pseudopotential in UPF format to a format >>suitable for cpmd?? >> >> > >it is, but you have to write a converter. A converter for the other way >round is available, but little tested. Anyway, the most recent version >(> november 2003) of cpmd should read the UPF format, at least for >norm-conserving PPs > >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 > > -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Zilberman Silviu, PhD Post doctoral research associate 213 Frick Laboratory, Department of Chemistry Princeton University Princeton, NJ 08544 phone: 609-258-1834 fax: 609-258-6746 silviu at Princeton.EDU Yahoo! Messenger ID: silviu_zilberman %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From francesco.antoniella at aquila.infn.it Thu Mar 25 18:33:13 2004 From: francesco.antoniella at aquila.infn.it (Francesco Antoniella) Date: 25 Mar 2004 18:33:13 +0100 Subject: [Pw_forum] pseudopotential conversion In-Reply-To: <406314EA.8050800@Princeton.EDU> References: <4062ECAD.3020508@mi.infn.it> <200403251639.25475.giannozz@nest.sns.it> <406314EA.8050800@Princeton.EDU> Message-ID: <1080235993.1443.3.camel@altair> Il gio, 2004-03-25 alle 18:20, Silviu Zilberman ha scritto: > I tested the converter some time ago, and there are slight > disagreements. I generated a NCPP (with the 'atom' code), and used it as > input once in the original pw format, and once after converting to UPF. > The differences in the energy are not huge, of the order of third/fourth > decimal digit. It seems like a roundoff error of the converter. I remember a little difference caused from the choice of simpson integration routine: at the time of the writing of the converter we choose to use the integration routine from the PWSCF code that is slightly different from the cmpd one. This can account for the little differences. Francesco > In most > cases these would be minor differences, however for me it made a difference. > > Silviu. > > Paolo Giannozzi wrote: > > >On Thursday 25 March 2004 15:29, Massimiliano Bonomi wrote: > > > > > > > >>Is it possible to convert a pseudopotential in UPF format to a format > >>suitable for cpmd?? > >> > >> > > > >it is, but you have to write a converter. A converter for the other way > >round is available, but little tested. Anyway, the most recent version > >(> november 2003) of cpmd should read the UPF format, at least for > >norm-conserving PPs > > > >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 > > > > > > > -- > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Zilberman Silviu, PhD > Post doctoral research associate > > 213 Frick Laboratory, Department of Chemistry > Princeton University > Princeton, NJ 08544 > > phone: 609-258-1834 > fax: 609-258-6746 > silviu at Princeton.EDU > Yahoo! Messenger ID: silviu_zilberman > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From silviu at Princeton.EDU Thu Mar 25 18:41:14 2004 From: silviu at Princeton.EDU (Silviu Zilberman) Date: Thu, 25 Mar 2004 12:41:14 -0500 Subject: [Pw_forum] pseudopotential conversion In-Reply-To: <1080235993.1443.3.camel@altair> References: <4062ECAD.3020508@mi.infn.it> <200403251639.25475.giannozz@nest.sns.it> <406314EA.8050800@Princeton.EDU> <1080235993.1443.3.camel@altair> Message-ID: <406319BA.4010609@Princeton.EDU> That is not the case for me, since I ran two identical calculations with PW code, just changing the format of the PP. Silviu. Francesco Antoniella wrote: >Il gio, 2004-03-25 alle 18:20, Silviu Zilberman ha scritto: > > >>I tested the converter some time ago, and there are slight >>disagreements. I generated a NCPP (with the 'atom' code), and used it as >>input once in the original pw format, and once after converting to UPF. >>The differences in the energy are not huge, of the order of third/fourth >>decimal digit. It seems like a roundoff error of the converter. >> >> >I remember a little difference caused from the choice of simpson >integration routine: at the time of the writing of the converter we >choose to use the integration routine from the PWSCF code that is >slightly different from the cmpd one. >This can account for the little differences. >Francesco > > >>In most >>cases these would be minor differences, however for me it made a difference. >> >>Silviu. >> >>Paolo Giannozzi wrote: >> >> >> >>>On Thursday 25 March 2004 15:29, Massimiliano Bonomi wrote: >>> >>> >>> >>> >>> >>>>Is it possible to convert a pseudopotential in UPF format to a format >>>>suitable for cpmd?? >>>> >>>> >>>> >>>> >>>it is, but you have to write a converter. A converter for the other way >>>round is available, but little tested. Anyway, the most recent version >>>(> november 2003) of cpmd should read the UPF format, at least for >>>norm-conserving PPs >>> >>>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 >>> >>> >>> >>> >>-- >>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>Zilberman Silviu, PhD >>Post doctoral research associate >> >>213 Frick Laboratory, Department of Chemistry >>Princeton University >>Princeton, NJ 08544 >> >>phone: 609-258-1834 >>fax: 609-258-6746 >>silviu at Princeton.EDU >>Yahoo! Messenger ID: silviu_zilberman >>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> >>_______________________________________________ >>Pw_forum mailing list >>Pw_forum at pwscf.org >>http://www.democritos.it/mailman/listinfo/pw_forum >> >> >> > > >_______________________________________________ >Pw_forum mailing list >Pw_forum at pwscf.org >http://www.democritos.it/mailman/listinfo/pw_forum > > -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Zilberman Silviu, PhD Post doctoral research associate 213 Frick Laboratory, Department of Chemistry Princeton University Princeton, NJ 08544 phone: 609-258-1834 fax: 609-258-6746 silviu at Princeton.EDU Yahoo! Messenger ID: silviu_zilberman %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From francesco.antoniella at aquila.infn.it Thu Mar 25 18:48:58 2004 From: francesco.antoniella at aquila.infn.it (Francesco Antoniella) Date: 25 Mar 2004 18:48:58 +0100 Subject: [Pw_forum] pseudopotential conversion In-Reply-To: <406319BA.4010609@Princeton.EDU> References: <4062ECAD.3020508@mi.infn.it> <200403251639.25475.giannozz@nest.sns.it> <406314EA.8050800@Princeton.EDU> <1080235993.1443.3.camel@altair> <406319BA.4010609@Princeton.EDU> Message-ID: <1080236938.1443.6.camel@altair> Il gio, 2004-03-25 alle 18:41, Silviu Zilberman ha scritto: > That is not the case for me, since I ran two identical calculations with > PW code, just changing the format of the PP. F. You mean that also in the PWSCF code you found a discrepancy between "raw" and UPF pseudo? Which version of the PWSCF code? > > Silviu. From giannozz at nest.sns.it Thu Mar 25 19:06:36 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 25 Mar 2004 19:06:36 +0100 Subject: [Pw_forum] pseudopotential conversion In-Reply-To: <406319BA.4010609@Princeton.EDU> References: <4062ECAD.3020508@mi.infn.it> <1080235993.1443.3.camel@altair> <406319BA.4010609@Princeton.EDU> Message-ID: <200403251906.36460.giannozz@nest.sns.it> On Thursday 25 March 2004 18:41, Silviu Zilberman wrote: > That is not the case for me, since I ran two identical calculations > with PW code, just changing the format of the PP. if you have any evidence that you get an observable difference in physical properties between the two cases, please provide the data. Note that a small difference in the total energy doesn't qualify as "difference in physical properties". 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 Thu Mar 25 20:52:26 2004 From: silviu at Princeton.EDU (Silviu Zilberman) Date: Thu, 25 Mar 2004 14:52:26 -0500 Subject: [Pw_forum] pseudopotential conversion In-Reply-To: <1080236938.1443.6.camel@altair> References: <4062ECAD.3020508@mi.infn.it> <200403251639.25475.giannozz@nest.sns.it> <406314EA.8050800@Princeton.EDU> <1080235993.1443.3.camel@altair> <406319BA.4010609@Princeton.EDU> <1080236938.1443.6.camel@altair> Message-ID: <4063387A.3020501@Princeton.EDU> Yes, I got different results with the PWSCF with "raw" and UPF formats. I am sending now my input files directly, not via the forum. Silviu. Francesco Antoniella wrote: >Il gio, 2004-03-25 alle 18:41, Silviu Zilberman ha scritto: > > >>That is not the case for me, since I ran two identical calculations with >>PW code, just changing the format of the PP. >> >> >F. >You mean that also in the PWSCF code you found a discrepancy between >"raw" and UPF pseudo? >Which version of the PWSCF code? > > >>Silviu. >> >> > > >_______________________________________________ >Pw_forum mailing list >Pw_forum at pwscf.org >http://www.democritos.it/mailman/listinfo/pw_forum > > -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Zilberman Silviu, PhD Post doctoral research associate 213 Frick Laboratory, Department of Chemistry Princeton University Princeton, NJ 08544 phone: 609-258-1834 fax: 609-258-6746 silviu at Princeton.EDU Yahoo! Messenger ID: silviu_zilberman %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From pushpa at jncasr.ac.in Tue Mar 30 09:09:19 2004 From: pushpa at jncasr.ac.in (Raghani Pushpa) Date: Tue, 30 Mar 2004 12:39:19 +0530 (IST) Subject: [Pw_forum] error while compiling pw.1.3.0 Message-ID: Dear all, While compiling pw.1.3.0 code, i m getting the following error. bp_c_phase.o(.text+0x10ce): In function `c_phase_': : undefined reference to `ylm_q_' bp_radin.o(.text+0x180): In function `radlg_': : undefined reference to `s_wsle' bp_radin.o(.text+0x196): In function `radlg_': : undefined reference to `do_lio' bp_radin.o(.text+0x19e): In function `radlg_': : undefined reference to `e_wsle' bp_radin.o(.text+0x1ab): In function `radlg_': : undefined reference to `s_wsle' bp_radin.o(.text+0x1c1): In function `radlg_': : undefined reference to `do_lio' could you please tell me what is the problem. From g.ballabio at cineca.it Tue Mar 30 09:42:40 2004 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Tue, 30 Mar 2004 09:42:40 +0200 (MEST) Subject: [Pw_forum] error while compiling pw.1.3.0 In-Reply-To: References: Message-ID: <1080632521.13195.4.camel@pc-ballabio> On Tue, 2004-03-30 at 09:09, Raghani Pushpa wrote: > Dear all, > While compiling pw.1.3.0 code, i m getting the following error. > > bp_c_phase.o(.text+0x10ce): In function `c_phase_': > : undefined reference to `ylm_q_' > [...] Looks like you should be linking to some missing library. What compiler are you using, and on which kind of machine? Please be aware that version 1.3.0 of PWscf has been surpassed by the new versions 2.0 and 2.0.1, available from www.pwscf.org. You are advised to use the latter. Gerardo Ballabio From proffess at yandex.ru Tue Mar 30 15:10:30 2004 From: proffess at yandex.ru (Sergei Lisenkov) Date: Tue, 30 Mar 2004 17:10:30 +0400 (MSD) Subject: [Pw_forum] -D__NEW_PUNCH optiion Message-ID: <406971C6.000015.11587@tide.yandex.ru> Dear PWscf users, I'd like to use -D__NEW_PUNCH option, but cimpiling was failed (see attach file). I did it on Compaq Alpha machine. Hw to solve it? Thanks, Sergey -------------- next part -------------- A non-text attachment was scrubbed... Name: log Type: application/octet-stream Size: 562 bytes Desc: not available Url : /pipermail/attachments/20040330/b4234153/attachment.obj From giannozz at nest.sns.it Tue Mar 30 19:15:18 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 30 Mar 2004 19:15:18 +0200 Subject: [Pw_forum] -D__NEW_PUNCH optiion In-Reply-To: <406971C6.000015.11587@tide.yandex.ru> References: <406971C6.000015.11587@tide.yandex.ru> Message-ID: <200403301915.18130.giannozz@nest.sns.it> On Tuesday 30 March 2004 15:10, Sergei Lisenkov wrote: > I'd like to use -D__NEW_PUNCH option, but compiling failed the __NEW_PUNCH case has never been really finished and needs some work. Do you really want wavefunctions to be collected into one single file in parallel execution ? If not, you do not need to set the __NEW_PUNCH option Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From proffess at yandex.ru Wed Mar 31 08:17:59 2004 From: proffess at yandex.ru (Sergei Lisenkov) Date: Wed, 31 Mar 2004 10:17:59 +0400 (MSD) Subject: [Pw_forum] -D__NEW_PUNCH optiion In-Reply-To: <200403301915.18130.giannozz@nest.sns.it> References: <406971C6.000015.11587@tide.yandex.ru> <200403301915.18130.giannozz@nest.sns.it> Message-ID: <406A6297.000007.17531@tide.yandex.ru> Dear Paolo, I want to use this option because for restart I need to use the same number of processor I ran before. In my case it is sometime impossible. If there is another solution - please let me know. Best wishes, Sergey From giannozz at nest.sns.it Wed Mar 31 18:21:11 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 31 Mar 2004 18:21:11 +0200 Subject: [Pw_forum] -D__NEW_PUNCH optiion In-Reply-To: <406971C6.000015.11587@tide.yandex.ru> References: <406971C6.000015.11587@tide.yandex.ru> Message-ID: <200403311821.11207.giannozz@nest.sns.it> On Tuesday 30 March 2004 15:10, Sergei Lisenkov wrote: > I'd like to use -D__NEW_PUNCH option, but compiling failed in PW/openfil.f90, change, lines !#ifdef __PARA ! USE para, ONLY : !#endif with #ifdef __PARA USE para, ONLY : kunit #endif Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From konstantin_kudin at yahoo.com Wed Mar 31 18:35:50 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Wed, 31 Mar 2004 08:35:50 -0800 (PST) Subject: [Pw_forum] -D__NEW_PUNCH optiion In-Reply-To: <406A6297.000007.17531@tide.yandex.ru> Message-ID: <20040331163550.95039.qmail@web21202.mail.yahoo.com> Dear Sergei There was a discussion here before on the issue of saving wavefunction files. If you run non-MD PWSCF (no CP), then you can just keep the old *.rho file, trash *.wfc files, and request atomic wavefunctions for restart. When not reading the old *.wfc files the extra work are just few Davidson iterations (~<5) at the very first SCF cycle, which is probably less than ~5% of cpu time for the first energy point. Definitely a worthwhile tradeoff. Kostya --- Sergei Lisenkov wrote: > Dear Paolo, > > I want to use this option because for restart I > need to use the same number of processor I ran > before. In my case it is sometime impossible. If > there is another solution - please let me know. > > Best wishes, > Sergey > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html From konstantin_kudin at yahoo.com Wed Mar 31 18:36:32 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Wed, 31 Mar 2004 08:36:32 -0800 (PST) Subject: [Pw_forum] -D__NEW_PUNCH optiion In-Reply-To: <406A6297.000007.17531@tide.yandex.ru> Message-ID: <20040331163632.59215.qmail@web21201.mail.yahoo.com> Dear Sergei There was a discussion here before on the issue of saving wavefunction files. If you run non-MD PWSCF (no CP), then you can just keep the old *.rho file, trash *.wfc files, and request atomic wavefunctions for restart. When not reading the old *.wfc files the extra work are just few Davidson iterations (~<5) at the very first SCF cycle, which is probably less than ~5% of cpu time for the first energy point. Definitely a worthwhile tradeoff. Kostya --- Sergei Lisenkov wrote: > Dear Paolo, > > I want to use this option because for restart I > need to use the same number of processor I ran > before. In my case it is sometime impossible. If > there is another solution - please let me know. > > Best wishes, > Sergey > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html