From giannozz at nest.sns.it Mon Feb 2 10:36:14 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Mon, 2 Feb 2004 10:36:14 +0100 Subject: [Pw_forum] Error encountered while attempting to allocate a d ata object. In-Reply-To: References: Message-ID: <200402021036.14192.giannozz@nest.sns.it> On Saturday 31 January 2004 21:37, Serguei Patchkovskii wrote: > Fortran-90 provides a portable way of specifying non-default kinds > (through the SELECTED_REAL_KIND and SELECTED_INTEGER_KIND > intrinsics). Why not use those, and make the code portable? those numbers are supposed to be the lengths of real, integer, complex numbers, in bytes. In most cases they coincide with the "kind" parameter, but in principle they aren't the same. I am not aware of any standard and portable way to obtain that information in fortran-90 (but I am not at all an expert in f90). The SIZE command reports the size in elements, not in bytes, of an array. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From breezejd at lsbu.ac.uk Mon Feb 2 14:39:05 2004 From: breezejd at lsbu.ac.uk (breezejd at lsbu.ac.uk) Date: Mon, 2 Feb 2004 13:39:05 -0000 (GMT) Subject: [Pw_forum] AMD64 and IFC In-Reply-To: References: <200401301917.00051.giannozz@nest.sns.it> Message-ID: <1239.80.189.147.209.1075729145.squirrel@webmail.lsbu.ac.uk> So althought ifc compiles 32-bit code and pgf compiles 64-bit code they are still pretty similar in performace ?? Does anyone have data on how PWSCf performs ?? I won't know until a few weeks time. > On Fri, 30 Jan 2004, Paolo Giannozzi wrote: > >> I have heard that you can compile 32-bit executables with Intel >> compilers, but it is not very fast, > > Take a look at AMD SPECfp2000 submissions for opterons - ifc > and pgf submissions for the same system are within a few percent > of each other - sometimes ifc wins; sometimes pgf wins. This is > despite the fact that ifc does not know about AMD64 as such, and > can use only half of the FP registers available to pgf. > > If you look at the individual tests for Opteron 148, for example, > you'll see that ifc generates faster code for 6 of those (swim, > art, equake, ammp, lucas, apsi), while pgf is faster for 8 (wupwise, > mgrid, applu, mesa, galgel, facerec, fma3d, sixtrack) - but none > of the wins are particularly dramatic. > > This also tallies pretty well with my experience - ifc 7.1 and > pgf90 5.0-2 are about neck-to-neck on opterons. > >> and that the only compiler that compiles 64-bit code on AMD >> is PGI. > > There is also Pathscale (http://www.pathscale.com/) - if you are > one of the few lucky people on their beta-testing program. > > Serguei > > --- > Dr. Serguei Patchkovskii > > Tel: +1-(613)-990-0945 > Fax: +1-(613)-947-2838 > E-mail: Serguei.Patchkovskii at nrc.ca > > Coordinator of Modelling Software > Theory and Computation Group > Steacie Institute for Molecular Sciences > National Research Council Canada > Room 2011, 100 Sussex Drive > Ottawa, Ontario > K1A 0R6 Canada > > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From rgebauer at ictp.trieste.it Mon Feb 2 15:38:15 2004 From: rgebauer at ictp.trieste.it (Ralph Gebauer) Date: Mon, 02 Feb 2004 15:38:15 +0100 Subject: [Pw_forum] AMD64 and IFC References: <40193116.7040006@lsbu.ac.uk> <200401301917.00051.giannozz@nest.sns.it> Message-ID: <401E60D7.9050305@ictp.trieste.it> We have been doing some performance-tests of opterons with many programs. In general, the performance (using 64-bit compiled versions) is quite good with respect to dual pentium 4s (one dual opteron equals approx. two dual P4s). This is mainly a result of the very good scalability from 1 to 2 processors on the opteron. These results apply to tests of cpmd, fpmd, and some classical md programs, NOT to pwscf. With pwscf and the pgi 5.0 compiler we are able to obtain a binary executable, however, that executable only works for very small systems. In bigger systems, the program crashes with segmentation faults, which result clearly from a compiler bug. This error is reproducable on a 32 bit compilation with the same pgi 5.0 compiler on a pentium 4, so it is not opteron related. We will soon check pgi 5.1 and the absoft compilers. But up to now, we could not run pwscf properly on an opteron in 64 bit mode. Ralph -- Ralph Gebauer The Abdus Salam International Centre for Theoretical Physics (ICTP) Condensed Matter Section Tel: (+39).040.2240.344 Strada Costiera 11 Fax: (+39).040.224163 I-34014 Trieste (Italy) e-mail: rgebauer at ictp.trieste.it Paolo Giannozzi wrote: > On Thursday 29 January 2004 17:13, Jonathan Breeze wrote: > > >>I am soon to be the lucky recipient of an AMD64 computer [....] >>When I come to compiling PWSCF, I'll need to know : >>1) Can one compile 64-bit code for AMD using the Intel Fortran >> Compiler? If not, is there a compiler that can ? > > > I have heard that you can compile 32-bit executables with Intel > compilers, but it is not very fast, and that the only compiler that > compiles 64-bit code on AMD is PGI. The CVS version has been > reported to work (a few days ago) with PGI and 64-bit executables: > you need to define -D__LINUX64 > > Paolo > From ps at ned.sims.nrc.ca Mon Feb 2 16:08:00 2004 From: ps at ned.sims.nrc.ca (Serguei Patchkovskii) Date: Mon, 2 Feb 2004 10:08:00 -0500 (EST) Subject: [Pw_forum] Error encountered while attempting to allocate a d ata object. In-Reply-To: <200402021036.14192.giannozz@nest.sns.it> Message-ID: On Mon, 2 Feb 2004, Paolo Giannozzi wrote: > On Saturday 31 January 2004 21:37, Serguei Patchkovskii wrote: > > > Fortran-90 provides a portable way of specifying non-default kinds > > (through the SELECTED_REAL_KIND and SELECTED_INTEGER_KIND > > intrinsics). Why not use those, and make the code portable? > > those numbers are supposed to be the lengths of real, integer, complex > numbers, in bytes. In most cases they coincide with the "kind" parameter, > but in principle they aren't the same. I am not aware of any standard and > portable way to obtain that information in fortran-90 (but I am not at all > an > expert in f90). The SIZE command reports the size in elements, not in > bytes, of an array. OK, I was off the mark here :-) You are right - there is no way to obtain the byte size of Fortran types, most because Fortran is defined to make sense on computers with no concept of byte. However, there is still a reasonably portable way to obtain byte sizes on computers which do. Namely, you can use BIT_SIZE intrinsic to get the size of the default integer type. Then, you can use INQUIRY(IOLENGTH) to establish the sizes of all other types. The latter part may get a little tricky (record sizes returned by INQUIRY may include padding) - so I am not at all sure it's worth the trouble ... Best regards, Serguei --- Dr. Serguei Patchkovskii Tel: +1-(613)-990-0945 Fax: +1-(613)-947-2838 E-mail: Serguei.Patchkovskii at nrc.ca Coordinator of Modelling Software Theory and Computation Group Steacie Institute for Molecular Sciences National Research Council Canada Room 2011, 100 Sussex Drive Ottawa, Ontario K1A 0R6 Canada From proffess at yandex.ru Thu Feb 5 11:18:55 2004 From: proffess at yandex.ru (Sergei Lisenkov) Date: Thu, 5 Feb 2004 13:18:55 +0300 (MSK) Subject: [Pw_forum] 64-bit compiling on HP In-Reply-To: References: Message-ID: <4022188F.00000E.19447@soapbox.yandex.ru> Dear PWscf users, I want to add some comment on PWscf compillation on HP workstations. If you want compile PWscf in 64-bit mode you must add the next lines in include/machine.h file: #if defined __HP # if defined __HP64 # define C_POINTER integer(kind=8) # else # define C_POINTER integer(kind=4) # endif #endif and add the -D__HP64 in CPPFLAGS for 64-bit compiling. All options for FFLAGS, CFLAGS, LDFLAGS, LIBS in 64-bit mode must be included. Paolo: the configure.old does not create the file make.rules. Best. Sergey From tangney at civet.berkeley.edu Fri Feb 6 06:06:55 2004 From: tangney at civet.berkeley.edu (Paul Tangney) Date: Thu, 05 Feb 2004 21:06:55 -0800 Subject: [Pw_forum] stress units Message-ID: <402320EF.8050106@civet.berkeley.edu> Dear Pwscf users/developers, This is a minor point, but one that should probably be fixed at some stage.... In the output of pwscf the stress is printed out in units of Ryd/(au^3), but it is stated that it is in atomic units. I forget about this factor of 2 error from time to time and run into problems......it just happened again, and this finally motivated me to point it out. Best regards, Paul Tangney OoOo------------------------------------------------------------- University of California at Berkeley / Phone : (510) 642-2635 Physics Department #7300 / Home Phone : (510) 883-1259 366 Le Conte Hall / Fax : (510) 643-9473 Berkeley, CA 94720 / Email : tangney at civet.berkeley.edu Home page : http://civet.berkeley.edu/tangney/ ----------------------------------------------------------------- From baroni at sissa.it Fri Feb 6 09:50:52 2004 From: baroni at sissa.it (Stefano Baroni) Date: Fri, 6 Feb 2004 09:50:52 +0100 Subject: [Pw_forum] stress units In-Reply-To: <402320EF.8050106@civet.berkeley.edu> References: <402320EF.8050106@civet.berkeley.edu> Message-ID: <91763B29-5881-11D8-A17C-000A95CDDD16@sissa.it> Paul is right, but the one who wrote the output format is probably not wrong. The situation is confused in the literature 1: Ry and 1 Har are equally called 'one atomic unit' of energy. I suggest to explicit distinguish between "Hartree atomic units" (e=\hbar=m=1) and "Rydberg atomic units" (e^2/2=2m=1) and to clearly state which one of the two "atomic units" is being used. Stefano B. On Feb 6, 2004, at 6:06 AM, Paul Tangney wrote: > Dear Pwscf users/developers, > > This is a minor point, but one that should probably be fixed at > some stage.... > > In the output of pwscf the stress is printed out in units > of Ryd/(au^3), but it is stated that it is in atomic units. > I forget about this factor of 2 error from time to time > and run into problems......it just happened again, and this > finally motivated me to point it out. > > Best regards, > > > Paul Tangney > > > > > > > > OoOo------------------------------------------------------------- > University of California at Berkeley / Phone : (510) 642-2635 > Physics Department #7300 / Home Phone : (510) 883-1259 > 366 Le Conte Hall / Fax : (510) 643-9473 > Berkeley, CA 94720 / Email : tangney at civet.berkeley.edu > Home page : http://civet.berkeley.edu/tangney/ > ----------------------------------------------------------------- > > > > _______________________________________________ > 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 breezejd at lsbu.ac.uk Fri Feb 6 18:13:12 2004 From: breezejd at lsbu.ac.uk (Jonathan Breeze) Date: Fri, 06 Feb 2004 17:13:12 +0000 Subject: [Pw_forum] problem with q2r.x Message-ID: <4023CB28.6030407@lsbu.ac.uk> When I use q2r.x to calculate the IFC's for a displaced structure using pw.1.2.0 I have no problems, but when using the pw.1.3.0 CVS version I get an error: nqs= 1 q= 0.00000000 0.00000000 1.00000000 %%%%%%%%%%%%%%%%%%%% from init : error # 1 missing q-point(s)! %%%%%%%%%%%%%%%%%%%% I used exactly the same scripts in both cases (with tmp_dir replaced by outdir). I used the 8 Monkhorst-Pack points of a 4x4x4 mesh. Any ideas ?? -- Jonathan Breeze Research Fellow Centre for Physical Electronics and Materials London South Bank University 103 Borough Road London SE1 0AA Tel: +44(0)20 7815 7582 Fax: +44(0)20 7815 7599 From breezejd at lsbu.ac.uk Fri Feb 6 18:26:51 2004 From: breezejd at lsbu.ac.uk (Jonathan Breeze) Date: Fri, 06 Feb 2004 17:26:51 +0000 Subject: [Pw_forum] problem with q2r.x References: <4023CB28.6030407@lsbu.ac.uk> Message-ID: <4023CE5B.1070009@lsbu.ac.uk> Sorry about that last message: It seems that q2r.x in pw.1.2.0 doesn't produce a STOP error whereas it does in pw.1.3.0. The missing point message appeared in both. My apologies! Jonathan Breeze wrote: > When I use q2r.x to calculate the IFC's for a displaced structure > using pw.1.2.0 I have no problems, but when using the pw.1.3.0 CVS > version I get an error: > > nqs= 1 > q= 0.00000000 0.00000000 1.00000000 > > %%%%%%%%%%%%%%%%%%%% > from init : error # 1 > missing q-point(s)! > %%%%%%%%%%%%%%%%%%%% > > I used exactly the same scripts in both cases (with tmp_dir replaced > by outdir). I used the 8 Monkhorst-Pack points of a 4x4x4 mesh. > > Any ideas ?? > -- 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 pushpa at jncasr.ac.in Mon Feb 9 07:41:26 2004 From: pushpa at jncasr.ac.in (Raghani Pushpa) Date: Mon, 9 Feb 2004 12:11:26 +0530 (IST) Subject: [Pw_forum] (no subject) Message-ID: Dear users, I want to do the car parrinello md but I am not able to find where the CP code is. Do I have to download it separately from some website? Thanks, Pushpa From eyvaz_isaev at yahoo.com Mon Feb 9 10:09:18 2004 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Mon, 9 Feb 2004 01:09:18 -0800 (PST) Subject: [Pw_forum] (no subject) In-Reply-To: Message-ID: <20040209090918.94872.qmail@web60304.mail.yahoo.com> Hi, You can download it separatly from the PWSCF site using CVS. Please have a look at the README.cvs file for details. Bests, Eyvaz. --- Raghani Pushpa wrote: > > Dear users, > I want to do the car parrinello md but I am not > able to find where the > CP code is. Do I have to download it separately from > some website? > > Thanks, > Pushpa > > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html From baroni at sissa.it Mon Feb 9 10:27:56 2004 From: baroni at sissa.it (Stefano Baroni) Date: Mon, 9 Feb 2004 10:27:56 +0100 Subject: [Pw_forum] CP & FPMD Car-Parrinello packages In-Reply-To: <20040209090918.94872.qmail@web60304.mail.yahoo.com> References: <20040209090918.94872.qmail@web60304.mail.yahoo.com> Message-ID: <3E49D236-5AE2-11D8-8BD9-000A95CDDD16@sissa.it> See also: http://www.democritos.it/scientific.php Enjoy! SB On Feb 9, 2004, at 10:09 AM, Eyvaz Isaev wrote: > Hi, > > You can download it separatly from the PWSCF site > using CVS. Please have a look at the README.cvs file > for details. > > Bests, > Eyvaz. > --- Raghani Pushpa wrote: >> >> Dear users, >> I want to do the car parrinello md but I am not >> able to find where the >> CP code is. Do I have to download it separately from >> some website? >> >> Thanks, >> Pushpa >> >> >> _______________________________________________ >> Pw_forum mailing list >> Pw_forum at pwscf.org >> http://www.democritos.it/mailman/listinfo/pw_forum > > > __________________________________ > Do you Yahoo!? > Yahoo! Finance: Get your refund fast by filing online. > http://taxes.yahoo.com/filing.html > _______________________________________________ > 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 konstantin_kudin at yahoo.com Sat Feb 14 23:26:36 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Sat, 14 Feb 2004 14:26:36 -0800 (PST) Subject: [Pw_forum] Recent CVS - problems on SGI In-Reply-To: <3E49D236-5AE2-11D8-8BD9-000A95CDDD16@sissa.it> Message-ID: <20040214222636.14013.qmail@web21204.mail.yahoo.com> Hi there, I am trying to build the whole O-sesame thing downloaded on Feb. 13 on an SGI Origin, and getting the following error (below). After that the build appears to proceed fine. Any pointers? Or was it just the unlucky Friday the 13th? Kostya P.S. The new "configure" procedure is quite cool! f90 -mips4 -64 -O2 -r10000 -r8 -I. -I/scr2/kostya/O-sesame/include -I/scr2/kostya/O-sesame/Modules -I/scr2/kostya/O-sesame/PW -I/scr2/kostya/O-sesame/PH -cpp -D__SGI -D__SGI64 -D__ORIGIN -D__MPI -D__PARA -D__FFTW -D__USE_INTERNAL_FFTW -c move_ions.f90 SUBROUTINE check_constrain( alat, tau, atm, ityp, theta0, nat ) ^ f90-1277 f90: ERROR CHECK_CONSTRAIN, File = move_ions.f90, Line = 296, Column = 12 Procedure "CHECK_CONSTRAIN" is referenced at line 195 (move_ions.f90). It must have an explicit interface specified. f90: MIPSpro Fortran 90 Version 7.3 (f61) Sat Feb 14, 2004 17:20:51 f90: 366 source lines f90: 1 Error(s), 0 Warning(s), 0 Other message(s), 0 ANSI(s) cf90: "explain cf90-message number" gives more information about each message __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html From konstantin_kudin at yahoo.com Mon Feb 16 18:03:31 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Mon, 16 Feb 2004 09:03:31 -0800 (PST) Subject: [Pw_forum] Recent CVS - problems on SGI In-Reply-To: <20040214222636.14013.qmail@web21204.mail.yahoo.com> Message-ID: <20040216170331.55078.qmail@web21202.mail.yahoo.com> This is an update on my previous message. As it turns out, one of my jobs under Linux happened to use that very same routine "check_constrain", and crashed there in the location denoted by "***" below. So while ifc 7.1 did compile the code, there is some problem there that the SGI compiler seems to have spotted already during the compile. Could some F90 expert take a look at that piece of the code? Kostya ! ! ... if the atomic positions have been corrected write them on output ! IF ( i > 1 ) THEN ! WRITE( stdout, '(/5X,"Corrected atomic positions:",/)') DO na = 1, nat *** WRITE( stdout,'(A3,3X,3F14.9)') atm(ityp(na)), ( tau(i,na), i = 1, 3 ) END DO ! END IF ! --- Konstantin Kudin wrote: > Hi there, > > I am trying to build the whole O-sesame thing > downloaded on Feb. 13 on an SGI Origin, and getting > the following error (below). After that the build > appears to proceed fine. Any pointers? Or was it > just > the unlucky Friday the 13th? > > Kostya > > P.S. The new "configure" procedure is quite cool! > > > f90 -mips4 -64 -O2 -r10000 -r8 -I. > -I/scr2/kostya/O-sesame/include > -I/scr2/kostya/O-sesame/Modules > -I/scr2/kostya/O-sesame/PW > -I/scr2/kostya/O-sesame/PH > -cpp -D__SGI -D__SGI64 -D__ORIGIN -D__MPI -D__PARA > -D__FFTW -D__USE_INTERNAL_FFTW -c move_ions.f90 > > SUBROUTINE check_constrain( alat, tau, atm, ityp, > theta0, nat ) > ^ > > > f90-1277 f90: ERROR CHECK_CONSTRAIN, File = > move_ions.f90, Line = 296, Column = 12 > Procedure "CHECK_CONSTRAIN" is referenced at line > 195 (move_ions.f90). It must have an explicit > interface specified. > > f90: MIPSpro Fortran 90 Version 7.3 (f61) Sat Feb > 14, > 2004 17:20:51 > f90: 366 source lines > f90: 1 Error(s), 0 Warning(s), 0 Other message(s), 0 > ANSI(s) > cf90: "explain cf90-message number" gives more > information about each message > > > __________________________________ > Do you Yahoo!? > Yahoo! Finance: Get your refund fast by filing > online. > http://taxes.yahoo.com/filing.html > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html From sbraccia at sissa.it Tue Feb 17 08:24:58 2004 From: sbraccia at sissa.it (Carlo Sbraccia) Date: Tue, 17 Feb 2004 08:24:58 +0100 (CET) Subject: [Pw_forum] Recent CVS - problems on SGI In-Reply-To: <20040216170331.55078.qmail@web21202.mail.yahoo.com> Message-ID: On Mon, 16 Feb 2004, Konstantin Kudin wrote: Dear kostya, try to compile the code with ifc 7.1 and the -CA -CB -CU options and run your job again (it will be slower). Address errors can usually be traced out with the help of these debug flags. carlo > This is an update on my previous message. As it turns > out, one of my jobs under Linux happened to use that > very same routine "check_constrain", and crashed there > in the location denoted by "***" below. So while ifc > 7.1 did compile the code, there is some problem there > that the SGI compiler seems to have spotted already > during the compile. > > Could some F90 expert take a look at that piece of > the code? > > Kostya > > ! > ! ... if the atomic positions have been corrected > write them on output > ! > IF ( i > 1 ) THEN > ! > WRITE( stdout, '(/5X,"Corrected atomic > positions:",/)') > DO na = 1, nat > *** WRITE( stdout,'(A3,3X,3F14.9)') > atm(ityp(na)), ( tau(i,na), i = 1, 3 ) > END DO > ! > END IF > ! > > --- Konstantin Kudin > wrote: > > Hi there, > > > > I am trying to build the whole O-sesame thing > > downloaded on Feb. 13 on an SGI Origin, and getting > > the following error (below). After that the build > > appears to proceed fine. Any pointers? Or was it > > just > > the unlucky Friday the 13th? > > > > Kostya > > > > P.S. The new "configure" procedure is quite cool! > > > > > > f90 -mips4 -64 -O2 -r10000 -r8 -I. > > -I/scr2/kostya/O-sesame/include > > -I/scr2/kostya/O-sesame/Modules > > -I/scr2/kostya/O-sesame/PW > > -I/scr2/kostya/O-sesame/PH > > -cpp -D__SGI -D__SGI64 -D__ORIGIN -D__MPI -D__PARA > > -D__FFTW -D__USE_INTERNAL_FFTW -c move_ions.f90 > > > > SUBROUTINE check_constrain( alat, tau, atm, ityp, > > theta0, nat ) > > ^ > > > > > > f90-1277 f90: ERROR CHECK_CONSTRAIN, File = > > move_ions.f90, Line = 296, Column = 12 > > Procedure "CHECK_CONSTRAIN" is referenced at line > > 195 (move_ions.f90). It must have an explicit > > interface specified. > > > > f90: MIPSpro Fortran 90 Version 7.3 (f61) Sat Feb > > 14, > > 2004 17:20:51 > > f90: 366 source lines > > f90: 1 Error(s), 0 Warning(s), 0 Other message(s), 0 > > ANSI(s) > > cf90: "explain cf90-message number" gives more > > information about each message > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Finance: Get your refund fast by filing > > online. > > http://taxes.yahoo.com/filing.html > > _______________________________________________ > > Pw_forum mailing list > > Pw_forum at pwscf.org > > http://www.democritos.it/mailman/listinfo/pw_forum > > > __________________________________ > Do you Yahoo!? > Yahoo! Finance: Get your refund fast by filing online. > http://taxes.yahoo.com/filing.html > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From giannozz at nest.sns.it Tue Feb 17 10:48:43 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 17 Feb 2004 10:48:43 +0100 Subject: [Pw_forum] Recent CVS - problems on SGI In-Reply-To: <20040214222636.14013.qmail@web21204.mail.yahoo.com> References: <20040214222636.14013.qmail@web21204.mail.yahoo.com> Message-ID: <200402171048.43567.giannozz@nest.sns.it> On Saturday 14 February 2004 23:26, Konstantin Kudin wrote: > I am trying to build the whole O-sesame thing > downloaded on Feb. 13 on an SGI Origin, and getting > the following error [...] > Procedure "CHECK_CONSTRAIN" is referenced at line > 195 (move_ions.f90). It must have an explicit > interface specified. the only thing I can think of is that (your version of) the sgi compiler doesn't like passing arguments as in the following: subroutine something (somearray) ... type_of_array :: somearray(:) without an explicit interface. The Intel compiler doesn't complain, but it doesn't work either. Maybe it is just plain wrong. I have changed the way arguments are passed, can you please try again? BTW: the routine "check_constrain" MUST be adapted to the constrain you desire: right now it keeps the distance of the first two atoms fixed. > P.S. The new "configure" procedure is quite cool! I agree, but the difficult part is configuring "configure" ! 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 Tue Feb 17 19:26:53 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Tue, 17 Feb 2004 10:26:53 -0800 (PST) Subject: [Pw_forum] Recent CVS - problems on SGI In-Reply-To: <200402171048.43567.giannozz@nest.sns.it> Message-ID: <20040217182653.44791.qmail@web21203.mail.yahoo.com> --- Paolo Giannozzi wrote: > the only thing I can think of is that (your version > of) the sgi > compiler doesn't like passing arguments as in the > following: > > subroutine something (somearray) > ... > type_of_array :: somearray(:) > > without an explicit interface. The Intel compiler > doesn't > complain, but it doesn't work either. Maybe it is > just plain > wrong. I have changed the way arguments are passed, > can you please try again? Dear Paolo, Thanks for suggestions! I just downloaded the CVS, but it does not compile, there are errors (see below). Anyway, yesterday after staring at the thing for an hour and finding nothing obviously wrong I did try the very same thing you are suggesting - removed the input arguments to check_constrain and instead got them from the module. This approach worked. The program went through and appears to work as intended. I have not tried a compile on SGI yet. BTW, the SGI compiler is quite developer friendly - it spots problems earlier than other compilers, and by default (no extra options at all!) the "core" files contain the stack trace of the moment when the program crashed such as it is easy to get the crash point. > BTW: the routine "check_constrain" MUST be adapted > to the constrain you desire: right now it keeps the > distance > of the first two atoms fixed. Yeah, I did do that. I do read manuals from time to time :-) While we are on the subject, is there some easy way to pass options to internal routines via the input commands? I would rather have an input switch(es) to setup the constraints than deal with an extra input file, or, worse, differently compiled versions. Kostya *** Current CVS problem ifc -Vaxlib -O2 -tpp6 -align -Zp8 -axK -ipo -ipo_obj -I. -I/home/kostya/Sesame/ver05/O-sesame/include -I/home/kostya/Sesame/ver05/O-sesame/Modules -I/home/kostya/Sesame/ver05/O-sesame/PW -I/home/kostya/Sesame/ver05/O-sesame/PH -nomodule -fpp -D__LINUX -D__INTEL -D__FFTW -c input.f90 external subroutine IOSYS edir, emaxpos, eopreg, eamp, starting_ns_eigenvalue, & ^ Error 208 at (145:input.f90) : No such entity in the module Error 355 : In program unit IOSYS variable STARTING_NS_EIGENVALUE has not been given a type external subroutine READ_CARDS __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html From giannozz at nest.sns.it Tue Feb 17 19:44:24 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 17 Feb 2004 19:44:24 +0100 Subject: [Pw_forum] Recent CVS - problems on SGI In-Reply-To: <20040217182653.44791.qmail@web21203.mail.yahoo.com> References: <20040217182653.44791.qmail@web21203.mail.yahoo.com> Message-ID: <200402171944.24357.giannozz@nest.sns.it> On Tuesday 17 February 2004 19:26, Konstantin Kudin wrote: > Yeah, I did do that. I do read manuals from time to > time :-) you are one of the few :-) > While we are on the subject, is there some easy way > to pass options to internal routines via the input > commands? easy maybe not... > I would rather have an input switch(es) to setup the > constraints than deal with an extra input file, or, worse, > differently compiled versions. the constraint section is far from satisfactory in its present status. Some major restructuring is needed. Stay tuned... > Error 208 at (145:input.f90) : No such entity in the > module > Error 355 : In program unit IOSYS variable > STARTING_NS_EIGENVALUE has not been given a type > external subroutine READ_CARDS did you "make clean" and recompile everything? It looks like the compiled module is not updated. The variable STARTING_NS_EIGENVALUE is there (it was added very recently) 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 Tue Feb 17 19:49:54 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Tue, 17 Feb 2004 10:49:54 -0800 (PST) Subject: [Pw_forum] Recent CVS - problems on SGI In-Reply-To: <200402171944.24357.giannozz@nest.sns.it> Message-ID: <20040217184954.79832.qmail@web21206.mail.yahoo.com> --- Paolo Giannozzi wrote: > > While we are on the subject, is there some easy > way > > to pass options to internal routines via the > input > > commands? > > easy maybe not... Well, if there is not - such a feature is badly needed. It just makes adding new things and testing them quickly so much easier ... > the constraint section is far from satisfactory in > its > present status. Some major restructuring is needed. > Stay tuned... Well, but I need to run some stuff NOW ! :-) Anyway, it is good to hear that in the future things will be great :-) > did you "make clean" and recompile everything? It > looks > like the compiled module is not updated. The > variable > STARTING_NS_EIGENVALUE is there (it was added > very recently) Yeah, I copied a customized make.sys from a different directory and thus the $TOPDIR variable was wrong. Once that is fixed, the build goes fine. That is not the first time I am messing up the $TOPDIR, would it be possible to have something like `pwd` there or something such as $TOPDIR is always the current dir of make.sys? Kostya __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html From eesantis at unity.ncsu.edu Wed Feb 18 03:36:23 2004 From: eesantis at unity.ncsu.edu (Erik Santiso) Date: Tue, 17 Feb 2004 21:36:23 -0500 (EST) Subject: [Pw_forum] NLCC with vdb pseudopotentials Message-ID: <1870.24.74.147.123.1077071783.squirrel@webmail.ncsu.edu> Dear pwscf users, I've been trying to run some scf calculations on simple hydrocarbon molecules using pwscf with vdb pseudopotentials. Before using pwscf, I was working with the CPMD code. I found that whenever I use a vdb pseudopotential that was generated with non-linear core correction, pwscf gives me different results. I also have trouble converging 'relax' calculations when nlcc is included. Has anybody else experienced the same kind of problem? Do you know of a solution, other than generating the pseudopotentials again without the nlcc? Thanks! Erik Santiso. North Carolina State University. ------------------------------------- Vir prudens non contra ventum mingit. From g.ballabio at cineca.it Wed Feb 18 10:04:58 2004 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Wed, 18 Feb 2004 10:04:58 +0100 Subject: [Pw_forum] Recent CVS - problems on SGI In-Reply-To: <20040217184954.79832.qmail@web21206.mail.yahoo.com> References: <20040217184954.79832.qmail@web21206.mail.yahoo.com> Message-ID: <1077095097.10897.28.camel@pc-ballabio> On Tue, 2004-02-17 at 19:49, Konstantin Kudin wrote: > Yeah, I copied a customized make.sys from a different > directory and thus the $TOPDIR variable was wrong. > Once that is fixed, the build goes fine. That is not > the first time I am messing up the $TOPDIR, would it > be possible to have something like `pwd` there or > something such as $TOPDIR is always the current dir of > make.sys? I don't know whether this may be useful: if you generated make.sys via the new "configure" script, $TOPDIR is set to `pwd` by default -- that is, the directory you run configure from. However you can specify a different directory by running: ./configure TOPDIR=/whatever/you/want In all cases however $TOPDIR is presently hardcoded into make.sys as an absolute path: thus, the same make.sys can't work for multiple build trees without editing. Using a relative path for $TOPDIR looks rather tricky, because make.sys is included both by the top-level Makefile, and by the Makefiles of the subdirectories: for this reason `pwd` isn't going to work either, and I don't know of a command that computes "the directory this file is in". Thus, right now, I can't see how that could be done. If you can, I'm open for suggestions. Gerardo From g.ballabio at cineca.it Wed Feb 18 11:38:44 2004 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Wed, 18 Feb 2004 11:38:44 +0100 Subject: [Pw_forum] Recent CVS - problems on SGI In-Reply-To: <1077095097.10897.28.camel@pc-ballabio> References: <20040217184954.79832.qmail@web21206.mail.yahoo.com> <1077095097.10897.28.camel@pc-ballabio> Message-ID: <1077100724.8592.1.camel@pc-ballabio> On Wed, 2004-02-18 at 10:04, Gerardo Ballabio wrote: > Using a relative path for $TOPDIR looks rather tricky, because make.sys > is included both by the top-level Makefile, and by the Makefiles of the > subdirectories: As Paolo pointed to me, I was wrong: make.sys is only included by subdirectories. Thus ".." is a good replacement for "$(TOPDIR)" in make.sys. Change committed. Gerardo From giannozz at nest.sns.it Wed Feb 18 12:07:08 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 18 Feb 2004 12:07:08 +0100 Subject: [Pw_forum] NLCC with vdb pseudopotentials In-Reply-To: <1870.24.74.147.123.1077071783.squirrel@webmail.ncsu.edu> References: <1870.24.74.147.123.1077071783.squirrel@webmail.ncsu.edu> Message-ID: <200402181207.08575.giannozz@nest.sns.it> On Wednesday 18 February 2004 03:36, Erik Santiso wrote: > I've been trying to run some scf calculations on simple hydrocarbon > molecules using pwscf with vdb pseudopotentials. Before using pwscf, > I was working with the CPMD code. I found that whenever I use a vdb > pseudopotential that was generated with non-linear core correction, > pwscf gives me different results. and which one is the good one? If you have any evidence that pwscf yields wrong results in a specific case, please submit enough data to allow reproducing the problem (i.e. input, output, pseudopotentials) > I also have trouble converging 'relax' calculations when nlcc is included. this might be an unrelated problem P. -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From subhra at ux1.cso.uiuc.edu Wed Feb 18 17:21:52 2004 From: subhra at ux1.cso.uiuc.edu (Subhradip Ghosh) Date: Wed, 18 Feb 2004 10:21:52 -0600 (CST) Subject: [Pw_forum] compilation error on IBM Message-ID: Hi, I am trying to compile pwscf1.3 on IBM AIX. I am getting the following error: xlf: 1501-228 input file /home/subhra/pwscf/clib/clib.a not found make[1]: *** [memory] Error 252 make[1]: Leaving directory `/home/subhra/pwscf/PW' make: *** [pw] Error 2 Can somebody help? 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 giannozz at nest.sns.it Wed Feb 18 18:19:52 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 18 Feb 2004 18:19:52 +0100 Subject: [Pw_forum] compilation error on IBM In-Reply-To: References: Message-ID: <200402181819.52906.giannozz@nest.sns.it> On Wednesday 18 February 2004 17:21, Subhradip Ghosh wrote: > xlf: 1501-228 input file /home/subhra/pwscf/clib/clib.a not found > Can somebody help? you can: find out why clib/clib.a is not build. The first error is the only one that is important. 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 sp344 at cam.ac.uk Thu Feb 19 14:43:57 2004 From: sp344 at cam.ac.uk (Stefano Piscanec) Date: Thu, 19 Feb 2004 13:43:57 -0000 Subject: [Pw_forum] compilation on SUN Message-ID: <004601c3f6ee$6c98abe0$483ea981@edm.eng.cam.ac.uk> Dear List, I'm trying to compile the 1.3.0 version of PWscf on a SUN machine (based on SunFire F15K nodes), but at the linking stage I'm getting the following errors: Undefined first referenced symbol in file ln_set_ ../Modules/berry_phase.o ln_dealloc_ ../Modules/berry_phase.o ln_activate_ ../Modules/berry_phase.o ln_alloc_ ../Modules/berry_phase.o ln_ind_ ../Modules/berry_phase.o ld: fatal: Symbol referencing errors. No output written to memory.x I edited the cp.h in /clib, trying all the possible combinations of underscores and capital letters in the definition of the LN_* , but nothing changed. Does anyone have a suggestion? Stefano PS: my make.sys is: OSHOME=/auto/users/sp344/PWfranklin # # System-dependent Make definitions, SUN parallel (MPI) machines # (Using sunperf library ) - contributed by Lazaro Caldarin # # To use fftw instead of the sunperf library fft subroutine # add -D__FFTW -D__USE_INTERNAL_FFTW to CPPFLAGS # Preprocessor # CPP = fpp CPPFLAGS = -P -DSUN -D__PARA -D__MPI -DHAS_ZHEGVX -I$(OSHOME)/include # Fortran compiler: F90 = mpf90 F77 = mpf77 # F90FLAGS = -fast -xO3 -xarch=v9b -stackvar -xlic_lib=sunperf F77FLAGS = -fast -xO3 -xarch=v9b -stackvar -xlic_lib=sunperf #F77FLAGS = -fast -xO3 -xchip=ultra3 -xarch=v9b -stackvar -xlic_lib=sunperf # # This is needed to tell the compiler where modules are # MODULEFLAG=-M$(OSHOME)/Modules -M$(OSHOME)/PW -M$(OSHOME)/PH # #LIBS = -L/opt/SUNWhpc/lib \ # -R/opt/SUNWhpc/lib -lmvec -lmpi # LIBS = -lmvec LD=$(F90) LDFLAGS = $(OSHOME)/PW/ptools.a $(OSHOME)/PW/flib.a -fast \ -xarch=v9b -xlic_lib=sunperf $(LIBS) # # ar: # AR = ar ARFLAGS = ruv -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20040219/3f1f9abb/attachment.htm From giannozz at nest.sns.it Thu Feb 19 17:00:33 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 19 Feb 2004 17:00:33 +0100 Subject: [Pw_forum] compilation on SUN In-Reply-To: <004601c3f6ee$6c98abe0$483ea981@edm.eng.cam.ac.uk> References: <004601c3f6ee$6c98abe0$483ea981@edm.eng.cam.ac.uk> Message-ID: <200402191700.33208.giannozz@nest.sns.it> On Thursday 19 February 2004 14:43, Stefano Piscanec wrote: > I'm trying to compile the 1.3.0 version of PWscf on a SUN machine > (based on SunFire F15K nodes), but at the linking stage I'm getting > the following errors: > > Undefined first referenced > symbol in file > ln_set_ ../Modules/berry_phase.o > [...] > I edited the cp.h in /clib, trying all the possible combinations of > underscores and capital letters in the definition of the LN_* which is actually the right thing to do > but nothing changed [...] Does anyone have a suggestion? 1) verify that every time you changed cp.h, both the library and the object codes were correctly recompiled 2) use "nm" to determine what the correct combination of underscores and capital letters is. Yes, there must be one, try again :-) If you find the solution and let me know it before tomorrow morning (GMT+1), it might even appear in the next release 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 sp344 at hermes.cam.ac.uk Fri Feb 20 17:07:40 2004 From: sp344 at hermes.cam.ac.uk (Stefano Piscanec) Date: Fri, 20 Feb 2004 16:07:40 +0000 (GMT) Subject: [Pw_forum] compilation on SUN In-Reply-To: <20040220063659.6581.16436.Mailman@democritos.sissa.it> Message-ID: Dear Paolo, thanks a lot for your suggestions! Following your advice, I recompiled the code again, using all the combinations of underscors and capital character in the definition of the LN_*. To be sure that all the parts of the code were poperly recompiled, I always performed a 'make clean' before a new compilation. Unfortunately I couldn't get rid of the error message. Maybe I am doing something wrong at an earlier stage, so I'll try to give you as many details as possible: 1) I replaced the cp.h with a new file where: a) no #if instructions is used b) and which is made by lines like ''# define LN_SET ln_set__'' 2) I changed those lines in the following way: compilation 1:# define LN_SET ln_set__ compilation 2:# define LN_SET ln_set_ ... compilation 6:# define LN_SET LN_SET 3) After modification of cp.h I: a) checked the file again (es: grep LN_SET ./clib/cp.h) b) cleaned the installation ( make clean) c) recompiled the code (make all > & log.file &) ...and I always got the same error message. Looking at the log_files, I also found these messages: "indici.c", line 81: warning: implicit function declaration: abs "indici.c", line 145: warning: implicit function declaration: malloc "indici.c", line 151: warning: implicit function declaration: free "indici.c", line 158: warning: implicit function declaration: exit "cptimer.c", line 81: warning: implicit function declaration: times and Warning: -O5 overwrites previously set optimization level of -O3 Finally, I also had to modify cft3.f90 in order to avoid the following error: mc = dfftp%ismap (i) ^ "cft3.F90", Line = 152, Column = 14: ERROR: IMPLICIT NONE is specified in the local scope, therefore an explicit type must be specified for data object "DFFTP". the modification I did (which I hope doesn't affect the behaviour of the code) is just replacing: #if defined __FFT_MODULE_DRV use fft_scalar, only : cft_1z, cft_2xy use sticks, only: dfftp #endif with: #if defined __FFT_MODULE_DRV use fft_scalar, only : cft_1z, cft_2xy ! use sticks, only: dfftp #endif use sticks, only: dfftp I hope someone can give me some more advice on how to work out the compilations. Regards, Stefano From giannozz at nest.sns.it Fri Feb 20 17:31:49 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 20 Feb 2004 17:31:49 +0100 Subject: [Pw_forum] compilation on SUN In-Reply-To: References: Message-ID: <200402201731.49849.giannozz@nest.sns.it> On Friday 20 February 2004 17:07, Stefano Piscanec wrote: > I hope someone can give me some more advice on how to work > out the compilations. use nm: nm Modules/berry_phase.o | grep -i ln_ nm clib/indici.o | grep -i ln_ when they are the same, you have won. BTW: the module berry_phase is actually never used, so you might try "touch Modules/berry_phase.o" 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 Feb 20 18:20:39 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Fri, 20 Feb 2004 09:20:39 -0800 (PST) Subject: [Pw_forum] SCF convergence - proposal In-Reply-To: <200402201731.49849.giannozz@nest.sns.it> Message-ID: <20040220172039.85655.qmail@web21208.mail.yahoo.com> Hello, I've been running ZrO2 oxide unit cells for few days now, and it appears that the very first convergence is quite hard to achieve starting from the atomic guess if the geometry is not too close to the optimized one. Of course, if I knew the optimized geometry beforehand, I would not run the whole thing in the first place! So, I used some broadening first, and then imported that density and potential into an insulator calculation, and that worked. Perhaps I could also play with the mixing coefficient, but, again, when there are several structures to optimize, this is quite time consuming. My proposal is to try to make the convergence more robust, such that regardless of how things are started, they always converge. That would make jobs more "start and forget" kind of proposition. I've worked on a method that guarantees the SCF convergence regardless of the starting guess, but I do not know enough about programming PWSCF to implement it. {J.Chem.Phys. 116, 8255 (2002).} What is needed for the method is the storage of the several previous densitites and potentials {probably last 3 ones is fine). Then the mixing coefficients are determined, and the rho_ = c1*rho_i + c2*rho_i-1 + c3*rho_i-2. However, there is no need to compute V(rho_) since it is (roughly) V(rho_) = c1*V(rho_i) + c2*V(rho_i-1) + c3*V(rho_i-2) This V(rho_) is then used to generate bands. The trick is that c1,c2,c3 are determined from a solid mathematical approach, and so they always work. Right now the code uses fixed mixing (0.7), which is sort of similar to doing V(rho_) with c1 and c2 always fixed, and V(c1*rho_i+c2*rho_i-1) is honestly computed. Anybody is interested in trying to get this in the code? Kostya __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools From sp344 at hermes.cam.ac.uk Fri Feb 20 18:30:32 2004 From: sp344 at hermes.cam.ac.uk (Stefano Piscanec) Date: Fri, 20 Feb 2004 17:30:32 +0000 (GMT) Subject: [Pw_forum] compilation on SUN In-Reply-To: <200402201731.49849.giannozz@nest.sns.it> Message-ID: > use nm: > > nm Modules/berry_phase.o | grep -i ln_ > nm clib/indici.o | grep -i ln_ > > when they are the same, you have won. BTW: the module > berry_phase is actually never used, so you might try > "touch Modules/berry_phase.o" Dear Paolo, ...my system seems to be very nasty. I used this cp.h: /* Copyright (C) 2002 FPMD group This file is distributed under the terms of the GNU General Public License. See the file `License' in the root directory of the present distribution, or http://www.gnu.org/copyleft/gpl.txt . */ # define LN_ALLOC ln_alloc_ # define LN_DEALLOC ln_dealloc_ # define LN_SET ln_set_ # define LN_ACTIVATE ln_activate_ # define LN_IND ln_ind_ I recompiled (after a make clean, as usual), and again I got errors: tail -n 13 log.nm Undefined first referenced symbol in file ln_set_ ../Modules/berry_phase.o ln_dealloc_ ../Modules/berry_phase.o ln_activate_ ../Modules/berry_phase.o ln_alloc_ ../Modules/berry_phase.o ln_ind_ ../Modules/berry_phase.o ld: fatal: Symbol referencing errors. No output written to memory.x Then I checked /Modules/berry_phase.o and /clib/indici.o franklin-1 [261] nm ./Modules/berry_phase.o | grep -i ln_ [48] | 3936| 12|FUNC |GLOB |0 |2 |berry_phase.ln_closeup_ [58] | 3968| 184|FUNC |GLOB |0 |2 |berry_phase.ln_setup_ [62] | 0| 0|FUNC |GLOB |0 |UNDEF |ln_activate_ [61] | 0| 0|FUNC |GLOB |0 |UNDEF |ln_alloc_ [60] | 0| 0|FUNC |GLOB |0 |UNDEF |ln_dealloc_ [59] | 0| 0|FUNC |GLOB |0 |UNDEF |ln_ind_ [63] | 0| 0|FUNC |GLOB |0 |UNDEF |ln_set_ franklin-1 [262] nm ./clib/indici.o | grep -i ln_ [10] | 24| 4|OBJT |LOCL |0 |3 |LN_SIZE [34] | 1568| 56|FUNC |GLOB |0 |2 |ln_activate_ [28] | 1248| 88|FUNC |GLOB |0 |2 |ln_alloc_ [30] | 1344| 48|FUNC |GLOB |0 |2 |ln_dealloc_ [35] | 1632| 128|FUNC |GLOB |0 |2 |ln_ind_ [32] | 1408| 152|FUNC |GLOB |0 |2 |ln_set_ They look the same. Nevertheless, the compilation fails. After this unsuccesful attempt I tried: touch /Modules/berry_phase.o make all but nothing changed Any idea? Stefano From giannozz at nest.sns.it Fri Feb 20 19:19:45 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 20 Feb 2004 19:19:45 +0100 Subject: [Pw_forum] SCF convergence - proposal In-Reply-To: <20040220172039.85655.qmail@web21208.mail.yahoo.com> References: <20040220172039.85655.qmail@web21208.mail.yahoo.com> Message-ID: <200402201919.45122.giannozz@nest.sns.it> On Friday 20 February 2004 18:20, Konstantin Kudin wrote: > Right now the code uses fixed mixing (0.7), which is > sort of similar to doing V(rho_) with c1 and c2 always > fixed, and V(c1*rho_i+c2*rho_i-1) is honestly > computed. it's not that simple. Early versions of PWscf used Anderson mixing:'s Algorithm: D.G. Anderson, J. Assoc. Comput. Mach. 12, 547 (1965). -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From giannozz at nest.sns.it Fri Feb 20 19:34:08 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 20 Feb 2004 19:34:08 +0100 Subject: [Pw_forum] SCF convergence - proposal In-Reply-To: <20040220172039.85655.qmail@web21208.mail.yahoo.com> References: <20040220172039.85655.qmail@web21208.mail.yahoo.com> Message-ID: <200402201934.08832.giannozz@nest.sns.it> [sorry for the previous truncated message, trying again...] On Friday 20 February 2004 18:20, Konstantin Kudin wrote: > Right now the code uses fixed mixing (0.7), which is > sort of similar to doing V(rho_) with c1 and c2 always > fixed it's not that simple. Early versions of PWscf used Anderson mixing: D.G. Anderson, J. Assoc. Comput. Mach. 12, 547 (1965). Later, we moved to a modified Broyden method: D.D. Johnson, Phys. Rev. B 38, 12807 (1988). Recently we have started to use mixing of charge density instead of potential, a better criterion for the error to be minimized, and an estimate for the dielectric response for highly inhomogeneous cases. The present algorithm is quite sophisticated. It may require some tuning, however, and how to tune it is not always obvious. Anyway: your suggestion is most welcome. An algorithm that converges no matter what would be highly desirable. 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 Fri Feb 20 19:43:44 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 20 Feb 2004 19:43:44 +0100 Subject: [Pw_forum] compilation on SUN In-Reply-To: References: Message-ID: <200402201943.44836.giannozz@nest.sns.it> On Friday 20 February 2004 18:30, Stefano Piscanec wrote: > They look the same. Nevertheless, the compilation fails. then you might try, in this order: - "nm clib/clib.a | grep -i ln_" and see what is inside - "ranlib clib/clib.a" (once upon a time it was needed) - add clib/indici.o to the list of objects at loading - add "clib/clib.a" at the end of the list of objects at loading - remove Modules/berry_phase.o from the list of objects at loading - inquire with your system wizard - dump your sun and get a linux PC... Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From marzari at MIT.EDU Fri Feb 20 19:55:40 2004 From: marzari at MIT.EDU (Nicola Marzari) Date: Fri, 20 Feb 2004 13:55:40 -0500 Subject: [Pw_forum] SCF convergence - proposal References: <20040220172039.85655.qmail@web21208.mail.yahoo.com> <200402201934.08832.giannozz@nest.sns.it> Message-ID: <4036582C.9090001@mit.edu> > > Anyway: your suggestion is most welcome. An algorithm that > converges no matter what would be highly desirable. Well, just to make the point - we developed one years ago (ensemble-DFT, Marzari, Vanderbilt, and Payne, PRL 79 1337 (1997)). This is a truly variational formulation of the problem on all degrees of freedom (wavefunction, orbitals, and subspace rotations), so that the total (free) energy is bound to get closer to self-consistency at every time step. We have used it happily everafter (in our own code, that is a Castep derivative), and a few other groups have implemented it (Francois Gygi in Jeep, Sohrab Ismail-Beigi in DFT++). Another implementation is in PARATEC, and one is in some stage of completion (I believe) for the Accelrys commercial copy of Castep. The CP code linked to PWSCF/Democritos will soon have it, albeit with Car-Parrinello evolution on the orbitals (this complicates matters, and decreases efficiency). Putting such an algorithm in PWSCF is not out of the question, but requires someone doing dedicated work. Also, for systems where charge-density mixing converges smoothly, getting to selfconsistency from scratch tends to be faster. The strengths of ensemble-DFT are in the ab-initio molecular dynamics, and in its formal guarantee to converge "no matter what"... All the best, nicola --------------------------------------------------------------------- Prof Nicola Marzari Department of Materials Science and Engineering 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA tel 617.4522758 fax 617.2586534 marzari at mit.edu http://nnn.mit.edu From baroni at sissa.it Sat Feb 21 07:53:21 2004 From: baroni at sissa.it (Stefano Baroni) Date: Sat, 21 Feb 2004 07:53:21 +0100 Subject: [Pw_forum] SCF convergence - proposal In-Reply-To: <4036582C.9090001@mit.edu> References: <20040220172039.85655.qmail@web21208.mail.yahoo.com> <200402201934.08832.giannozz@nest.sns.it> <4036582C.9090001@mit.edu> Message-ID: On Feb 20, 2004, at 7:55 PM, Nicola Marzari wrote: > > The CP code linked to PWSCF/Democritos will soon have it, albeit > with Car-Parrinello evolution on the orbitals (this complicates > matters, and decreases efficiency). Putting such an algorithm in > PWSCF is not out of the question, but requires someone doing > dedicated work. Thank you, Nicola: this is good news! May I suggest that not the person(s) who will "soon" make the job on CP try to make a special effort to make the work easily portable to the two other codes of the the O-sesame suit (PWscf/CP/FPMD, ideally, "trivially portable", i.e. a same module to be used for the three codes). This may require more work at this stage, but I believe this is the right policy to save work in the long run. Cheers, Stefano --- Stefano Baroni -- SISSA & DEMOCRITOS National Simulation Center via Beirut 2-4 34014 Trieste Grignano / [+39] 040 3787 406 (tel) -528 (fax) From michele.lazzeri at lmcp.jussieu.fr Mon Feb 23 19:24:25 2004 From: michele.lazzeri at lmcp.jussieu.fr (Michele Lazzeri) Date: Mon, 23 Feb 2004 19:24:25 +0100 Subject: [Pw_forum] position available Message-ID: <403A4559.A0F6B406@lmcp.jussieu.fr> Permanent position available, Paris =================================== We are advertising a permanent position for an "ingenieur de recherche" (the highest position available for a technician at CNRS) to work with the theoretical group of the Laboratoire de Mineralogie-Cristallographie de Paris (LMCP). One of our main activities is the developement of numerical methods for the computation of material properties, based on electronic structure via Density Functional Theory. The role of the selected candidate will be to organize the developement of a user-friendly scientific software for ab-initio prediction of properties of materials. Such software will be made available to a large community of users, including non-experts in electronic structure theory, and will be distributed under the "GNU General Public License". The candidate will assure the links between the users and the developers. He will also be encouraged to pursue an original research activity in the domain of electronic structure theory. The candidate will be selected in the coming spring 2004, to start the activity in autumn 2004. More details about the required profile can be found at the URL: http://www.lmcp.jussieu.fr/~calandra/Poste/ing.html Interested candidates should e-mail a curriculum vitae and a brief letter of motivation as soon as possible to Matteo Calandra LMCP - Universite' Pierre et Marie Curie Case 115, 4 Place Jussieu, F-75252, PARIS cedex 05, FRANCE Tel: +33-1-44275216, Fax: +33-1-44274541 E-mail: matteo.calandra at lmcp.jussieu.fr For any additional information please contact directly one of the followings: matteo.calandra at lmcp.jussieu.fr michele.lazzeri at lmcp.jussieu.fr francesco.mauri at lmcp.jussieu.fr Sincerely, Matteo Calandra From konstantin_kudin at yahoo.com Mon Feb 23 21:43:06 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Mon, 23 Feb 2004 12:43:06 -0800 (PST) Subject: [Pw_forum] SCF convergence - proposal In-Reply-To: <200402201934.08832.giannozz@nest.sns.it> Message-ID: <20040223204306.73398.qmail@web21201.mail.yahoo.com> --- Paolo Giannozzi wrote: > it's not that simple. Early versions of PWscf used > Anderson mixing: > D.G. Anderson, J. Assoc. Comput. Mach. 12, 547 > (1965). Later, we > moved to a modified Broyden method: D.D. Johnson, > Phys. Rev. B > 38, 12807 (1988). Recently we have started to use > mixing of charge > density instead of potential, a better criterion for > the error to be > minimized, and an estimate for the dielectric > response for highly > inhomogeneous cases. The present algorithm is quite > sophisticated. > It may require some tuning, however, and how to tune > it is not always > obvious. Thanks for clarification! From what I observe the method that is in PWSCF works great for things which are reasonably close to convergence, but can have problems in situations when the starting density is very different from the converged one. > Anyway: your suggestion is most welcome. An > algorithm that > converges no matter what would be highly desirable. OK. Would any of you guys be willing to help me out with that? As I mentioned, the EDIIS method is both very simple and robust. There is a mathematical proof that it always works for Hartree-Fock, and in practice it very often works for DFT except when the fractional occupations are present where the method drives the solution to fractional occupations and that can interfere with the integer only occupations. Nicola Marzari mentioned another method with a guaranteed convergence. But it seems like it is quite complex to implement, and thus something simplier could be advantageous at this stage before anybody attempts to take a shot at Nicola's method :-) EDIIS works well for initial steps, after that the traditional techniques are usually faster. This is currently an area of technical deficiency. In practice, the region of convergence is usually achieved in 5-10 steps. Since EDIIS is designed to mix densities such that the energy is minimized - any kind of charge waves die immediately because having separated charges in not energetically favourable. In order to implement this few high level changes are needed, which are better done by somebody who is an "architect" of PWSCF. Otherwise it will have to be redone to fit into the overall scheme. Here is what would be needed. Several previous Rho_i, and their potential V(Rho_i). These are used to figure out the optimal mixing coefficients. The mixing is done right before the new bands are obtained. When far from convergence V(c1*Rho_i+c2*Rho_i-1) ~ c1*V(Rho_i) + c2*V(Rho_i-1). This potential {c1*V(Rho_i) + c2*V(Rho_i-1)} is used to obtain new bands. c1,c2 are chosen such that the energy E(c1*Rho_i+c2*Rho_i-1) is minimum in the space where 0<={c1,c2}<=1. It is unnecessary to compute the true V(c1*Rho_i+c2*Rho_i-1) because at that level of convergence {c1*V(Rho_i) + c2*V(Rho_i-1)} is just as good, and most of V is the Coulomb contribution anyway. To get {c1,c2,...,c_n} one needs E(Rho_i) {really trivial}, and dE(Rho_i)/dRho_i which is roughly V(Rho_i)*Rho_i. Other V(Rho_i)*Rho_j are needed to minimize the energy for a mix of densities. I can get the coefficients from E(Rho_i) and V(Rho_i)*Rho_j. If there is a setup for the above procedure available, I'll plug in the coefficients, and we are in business :-) Kostya __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools From konstantin_kudin at yahoo.com Mon Feb 23 23:50:13 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Mon, 23 Feb 2004 14:50:13 -0800 (PST) Subject: [Pw_forum] Building CVS - problems In-Reply-To: Message-ID: <20040223225013.34515.qmail@web21208.mail.yahoo.com> I've encountered a couple of CVS issues. First, if I check out just PWSCF {cvs co pwscf}, I end up with some missing files such as {install-sh, *.dep files}. So the whole thing won't even go through "configure". Next, when I try to configure the whole O-Sesame under IBM AIX, it quits with an error. Perhaps, the relevant part is below. Kostya configure:1600: $? = 255 configure:1607: error: cannot run Fortran 77 compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools From subhra at ux1.cso.uiuc.edu Tue Feb 24 01:52:34 2004 From: subhra at ux1.cso.uiuc.edu (Subhradip Ghosh) Date: Mon, 23 Feb 2004 18:52:34 -0600 (CST) Subject: [Pw_forum] Error during relaxation Message-ID: Hi, I was trying to use the BFGS algorithm to relax the atomic positions. After a couple of iterations of BFGS, the code stops with the following error message: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from linmin : error # 2 unexpected error %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... Does it happen because the search direction for minima is wrong? The other relevent info is the following: In a previous calculation I used the default value for the energy convergence (etot_conv_thr) and now I am using a higher tolerance (10^{-7} a.u.). The previous one worked but this one stops. Can somebody explain the connection? Thanks, 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 giannozz at nest.sns.it Tue Feb 24 11:38:52 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 24 Feb 2004 11:38:52 +0100 Subject: [Pw_forum] Error during relaxation In-Reply-To: References: Message-ID: <200402241138.52462.giannozz@nest.sns.it> On Tuesday 24 February 2004 01:52, Subhradip Ghosh wrote: > from linmin : error # 2 > unexpected error unexpected, but not unexplained: see the manual. The next version of PWscf (soon available on the web site) will have a different and hopefully more robust optimization algorithm by default. 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 Feb 24 11:50:19 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 24 Feb 2004 11:50:19 +0100 Subject: [Pw_forum] Building CVS - problems In-Reply-To: <20040223225013.34515.qmail@web21208.mail.yahoo.com> References: <20040223225013.34515.qmail@web21208.mail.yahoo.com> Message-ID: <200402241150.19733.giannozz@nest.sns.it> On Monday 23 February 2004 23:50, Konstantin Kudin wrote: > if I check out just PWSCF {cvs co pwscf}, I end up with > some missing files such as {install-sh, *.dep files}. oops, fixed (I think). Old-style configuration not supported any longer in this case. > Next, when I try to configure the whole O-Sesame > under IBM AIX, it quits with an error [...] > > configure:1600: $? = 255 > configure:1607: error: cannot run Fortran 77 compiled > programs. which means exactly that: "cannot run Fortran 77 compiled programs". On the IBM-SP machine I used, this morning I had the same problem. It was driving me nuts until Gerardo explained what was happening: interactive programs are executed in a special job queue. The queue was full and configure didn't work. Maybe something similar applies to your case as well: if you cannot execute an executable as "./a.out", configure will not work. 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 sp344 at cam.ac.uk Tue Feb 24 16:40:17 2004 From: sp344 at cam.ac.uk (Stefano Piscanec) Date: Tue, 24 Feb 2004 15:40:17 -0000 Subject: [Pw_forum] compilation on SUN References: <200402201943.44836.giannozz@nest.sns.it> Message-ID: <006901c3faec$816631d0$483ea981@edm.eng.cam.ac.uk> Unortunately troubles did not come to an end... > - "nm clib/clib.a | grep -i ln_" and see what is inside > - "ranlib clib/clib.a" (once upon a time it was needed) > - add clib/indici.o to the list of objects at loading > - add "clib/clib.a" at the end of the list of objects at loading > - remove Modules/berry_phase.o from the list of objects at loading > - inquire with your system wizard checking more carefully the logfiles I found lines like: cc -c c_getenv.c You are strongly advised to use the mpcc command for MPI and S3L code This is a Sun recommendation, as the path requirements are very complex This may affect clib.a and indici.o, and could explain why all my attempts of compilation failed. I searched for c compiler name and flags in both make.sys and /clib/Makefile, but I couldn't find anything. It seems to me that a line with those information should be added, but I don't know where and how. Finally, I'would like to know where the ln_* are defined. They seem not to belong to any common library (lapack, blas, sunperf, etc.), and I couldn't find their definition in the source code either. If I knew where they are placed, I can ask my sistem wizards to help me in linking them properly. Stefano From konstantin_kudin at yahoo.com Tue Feb 24 17:32:39 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Tue, 24 Feb 2004 08:32:39 -0800 (PST) Subject: [Pw_forum] Building CVS - problems In-Reply-To: <200402241150.19733.giannozz@nest.sns.it> Message-ID: <20040224163239.49610.qmail@web21206.mail.yahoo.com> --- Paolo Giannozzi wrote: > which means exactly that: "cannot run Fortran 77 > compiled > programs". On the IBM-SP machine I used, this > morning I > had the same problem. It was driving me nuts until > Gerardo > explained what was happening: interactive programs > are > executed in a special job queue. The queue was full > and > configure didn't work. Maybe something similar > applies to your > case as well: if you cannot execute an executable as > "./a.out", > configure will not work. But this does not seem to make sense. I was trying to compile on a fully interactive machine. What is this magic queue anyway and how does one go about detecting it? Kostya __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools From g.ballabio at cineca.it Tue Feb 24 17:51:15 2004 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Tue, 24 Feb 2004 17:51:15 +0100 Subject: [Pw_forum] compilation on SUN In-Reply-To: <006901c3faec$816631d0$483ea981@edm.eng.cam.ac.uk> References: <200402201943.44836.giannozz@nest.sns.it> <006901c3faec$816631d0$483ea981@edm.eng.cam.ac.uk> Message-ID: <1077641475.2181.9.camel@pc-ballabio> On Tue, 2004-02-24 at 16:40, Stefano Piscanec wrote: > cc -c c_getenv.c > You are strongly advised to use the mpcc command for MPI and S3L code > This is a Sun recommendation, as the path requirements are very complex > > This may affect clib.a and indici.o, and could explain why all my attempts > of compilation failed. I searched for c compiler name and flags in both > make.sys and /clib/Makefile, but I couldn't find anything. It seems to me > that a line with those information should be added, but I don't know where > and how. It is in make.sys indeed, the very first two lines: CC = C compiler CCFLAGS = C compiler flags If your make.sys doesn't have them, you must be using an old version. Try regenerating it with the new "configure" script. (You've downloaded the latest CVS version, haven't you?) Run it this way: ./configure CC=mpcc and it should detect your parallel compiler out of the box. Gerardo From g.ballabio at cineca.it Tue Feb 24 18:08:44 2004 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Tue, 24 Feb 2004 18:08:44 +0100 Subject: [Pw_forum] Building CVS - problems In-Reply-To: <20040224163239.49610.qmail@web21206.mail.yahoo.com> References: <20040224163239.49610.qmail@web21206.mail.yahoo.com> Message-ID: <1077642524.2238.15.camel@pc-ballabio> On Tue, 2004-02-24 at 17:32, Konstantin Kudin wrote: > But this does not seem to make sense. I was trying to > compile on a fully interactive machine. What is this > magic queue anyway and how does one go about detecting > it? There's nothing magic. Our IBM SP4 machine here at Cineca (sp.sp4.cineca.it) is configured so as to enforce the policy that no parallel job can be run outside the LoadLeveler batch queuing system. Among the configured queues there is an "interactive" queue, and parallel programs run from the command line are automatically routed through that queue. If there aren't available processors when the command is issued, LoadLeveler tries a few times and then gives up -- as configure sees it, your program "fails to run". If your machine doesn't have LoadLeveler (or any other queuing system) up and running and configured this way, you should be able to run parallel programs truly interactively. Try compiling a minimal program like this, using your parallel compiler (mpxlf90_r or whatever you have): program main end and then run it. (This should be exactly what "configure" tries to do.) Does it execute correctly? Gerardo From giannozz at nest.sns.it Tue Feb 24 18:22:22 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 24 Feb 2004 18:22:22 +0100 Subject: [Pw_forum] compilation on SUN In-Reply-To: <006901c3faec$816631d0$483ea981@edm.eng.cam.ac.uk> References: <200402201943.44836.giannozz@nest.sns.it> <006901c3faec$816631d0$483ea981@edm.eng.cam.ac.uk> Message-ID: <200402241822.22620.giannozz@nest.sns.it> On Tuesday 24 February 2004 16:40, Stefano Piscanec wrote: > Finally, I'would like to know where the ln_* are defined. grep -i ln_alloc */*.[hcf] */*.f90 It's a little bit tricky: they are called in Modules/berry_phase.f90, the sources are in clib/indici.c as LN_*. LN_* is pre-preprocessed (see clib/cp.h) to something else. Why? because passing C to fortran or vice versa is a machine-dependent mess. 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 Tue Feb 24 18:27:05 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Tue, 24 Feb 2004 09:27:05 -0800 (PST) Subject: [Pw_forum] Building CVS - problems In-Reply-To: <1077642524.2238.15.camel@pc-ballabio> Message-ID: <20040224172705.57683.qmail@web21203.mail.yahoo.com> --- Gerardo Ballabio wrote: > > There's nothing magic. Our IBM SP4 machine here at > Cineca > (sp.sp4.cineca.it) is configured so as to enforce > the policy that no > parallel job can be run outside the LoadLeveler > batch queuing system. > Among the configured queues there is an > "interactive" queue, and > parallel programs run from the command line are > automatically routed > through that queue. If there aren't available > processors when the > command is issued, LoadLeveler tries a few times and > then gives up -- as > configure sees it, your program "fails to run". > Since this whole business seems to have gotten way to complicated for an average user to handle, should there be like a flag saying that "forget this test", and assume yes? Adding flags to bypass certain tests in "configure" is a slippery slope, but it seems to be worth it in this situation. Kostya __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools From giannozz at nest.sns.it Wed Feb 25 14:33:09 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 25 Feb 2004 14:33:09 +0100 Subject: [Pw_forum] New PWscf version Message-ID: <200402251433.09925.giannozz@nest.sns.it> A new version (2.0) of the PWscf package is available for download on the web site http://www.pwscf.org. The new version contains many changes, improvements, bug fixes. Everybody who is using the PWscf package is encouraged to upgrade and to report problems to the mailing list. This release is another step towards full integration and interoperability of PWscf with the Car-Parrinello codes FPMD and CP. The entire updated package is available for download from http://www.democritos.it Major changes: - various bug fixes - automatic installation procedure via a "configure" script - new features: - noncolinear magnetism - transition paths and barriers with the Nudged Elastic Band (NEB) method (also available with CP and FPMD) - new algorithms for structural relaxation - effective charges with ultrasoft pseudopotentials and linear response Incompatibilities: - files produced by preceding versions may be unreadable Note that the Gamma-point version of the code for electronic-structure self-consistent calculation has been merged into the main code. -- 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 Wed Feb 25 16:21:24 2004 From: subhra at ux1.cso.uiuc.edu (Subhradip Ghosh) Date: Wed, 25 Feb 2004 09:21:24 -0600 (CST) Subject: [Pw_forum] Feedback on new PWSCF Message-ID: Hi, I tried to compile the new version in linux PC with Intel fortran compiler. I get the following message: ------------------------------------------------------ WARNING: the following problems were detected: unsupported C/Fortran compilers combination: CC=cc, F77=f77, F90=f77 you may not be able to compile this program ------------------------------------------------------ Could it be because of the fact that I am not using a Intel C compiler? 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 profeta at sissa.it Wed Feb 25 16:26:47 2004 From: profeta at sissa.it (Mickael Profeta) Date: Wed, 25 Feb 2004 16:26:47 +0100 Subject: [Pw_forum] Feedback on new PWSCF In-Reply-To: References: Message-ID: <403CBEB7.2070100@sissa.it> Subhradip Ghosh wrote: > Hi, > I tried to compile the new version in linux PC with Intel fortran > compiler. I get the following message: > ------------------------------------------------------ > WARNING: the following problems were detected: > > unsupported C/Fortran compilers combination: > CC=cc, F77=f77, F90=f77 > > you may not be able to compile this program > ------------------------------------------------------ > Could it be because of the fact that I am not using a Intel C compiler? No, It seems that the configure script does not find your intel fortrant compiler. Do you place it in a 'exotic' place?? Mike From felipe at titan.ipicyt.edu.mx Wed Feb 25 16:30:10 2004 From: felipe at titan.ipicyt.edu.mx (FELIPE VALENCIA) Date: Wed, 25 Feb 2004 09:30:10 -0600 (CST) Subject: [Pw_forum] Feedback on new PWSCF In-Reply-To: <403CBEB7.2070100@sissa.it> Message-ID: Dear Suhradip, Well the error message means just what it says: you may not be able to compile the program, and, as you said, that is because you have not got the intel C compiler. The combination of ifc/gcc is rather uncomfortable and you may encounter a lot of errors during compilation. regards, Felipe > Subhradip Ghosh wrote: > > Hi, > > I tried to compile the new version in linux PC with Intel fortran > > compiler. I get the following message: > > ------------------------------------------------------ > > WARNING: the following problems were detected: > > > > unsupported C/Fortran compilers combination: > > CC=cc, F77=f77, F90=f77 > > > > you may not be able to compile this program > > ------------------------------------------------------ > > Could it be because of the fact that I am not using a Intel C compiler? > > No, It seems that the configure script does not find your intel fortrant > compiler. > Do you place it in a 'exotic' place?? > > > > Mike > > > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From g.ballabio at cineca.it Wed Feb 25 16:49:47 2004 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Wed, 25 Feb 2004 16:49:47 +0100 Subject: [Pw_forum] Feedback on new PWSCF In-Reply-To: References: Message-ID: <1077724187.29727.50.camel@pc-ballabio> On Wed, 2004-02-25 at 16:21, Subhradip Ghosh wrote: > Hi, > I tried to compile the new version in linux PC with Intel fortran > compiler. I get the following message: > ------------------------------------------------------ > WARNING: the following problems were detected: > > unsupported C/Fortran compilers combination: > CC=cc, F77=f77, F90=f77 > > you may not be able to compile this program > ------------------------------------------------------ > Could it be because of the fact that I am not using a Intel C compiler? Using gcc together with Intel Fortran compiler is ok, that was even the default some time ago. The problem is that your Intel F90 compiler isn't found by the configure script, the reason can be either of these: - it isn't in your executable path. Set PATH as needed and retry. - it has a name other than "ifc" (default for versions 7 or earlier) or "ifort" (default for version 8). In this case, try "configure F90=name". Gerardo From mutombo at fzu.cz Wed Feb 25 13:12:22 2004 From: mutombo at fzu.cz (Mutombo) Date: Wed, 25 Feb 2004 13:12:22 +0100 Subject: [Pw_forum] Feedback on new PWSCF In-Reply-To: <1077724187.29727.50.camel@pc-ballabio> References: <1077724187.29727.50.camel@pc-ballabio> Message-ID: <403C9126.6000608@fzu.cz> Hello, I am trying to compile the new PWSCF code and I am getting this following error : My system is PC linux,intel compiler. Any idea about how to solve this? Best regards, Pingo WRITE( stdout,"( 8X,'The calculation of phases done along the direction of vector ',I1, /,8X,'of the reciprocal lattice gives the following contribution to', /,8X,'the polarization vector (in different units, and being Omega', /,8X,'the vol ^ Error 2 at (797:bp_c_phase.f90) : line exceeds 254 characters ^ Error 5 at (797:bp_c_phase.f90) : incomplete string ^ Error 3 at (797:bp_c_phase.f90) : unbalanced parenthesis ^ Error 7 at (797:bp_c_phase.f90) : incomplete statement ) & ^ Error 3 at (801:bp_c_phase.f90) : unbalanced parenthesis & gdir ^ Error 7 at (802:bp_c_phase.f90) : incomplete statement 6 Errors compilation aborted for bp_c_phase.f90 (code 1) make[1]: *** [bp_c_phase.o] Error 1 make[1]: Leaving directory `/home/crystal/pwscf2.0/PW' make: *** [pw] Error 2 > > From breezejd at lsbu.ac.uk Thu Feb 26 13:31:24 2004 From: breezejd at lsbu.ac.uk (Jonathan Breeze) Date: Thu, 26 Feb 2004 12:31:24 +0000 Subject: [Pw_forum] Compiling pwscf using ifc 7.1 on a x64-64 system References: <1077724187.29727.50.camel@pc-ballabio> Message-ID: <403DE71C.7080603@lsbu.ac.uk> Dear Pwscf users, 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). I had a few tiny troubles getting pwscf to compile so here goes. I use IFC version 7.1 build 20030307Z. 1) Getting IFC to compiler and link 32-bit code and libraries. ifc needs to be in the execution path, so in a bash shell run : export PATH=$PATH:/opt/intel/compiler70/ia32/bin To prevent having to do this every time you open a new terminal, add this to the .bashrc file. IFC needs the '-Wl,-melf_i386' option in order to compile and link 32-bit code and libraries. To make life easier and not have to add this option explicitly everytime IFC is called (i.e. editing makefiles), edit the file /opt/intel/compiler70/ia32/bin/ifc.cfg and add '-Wl,-melf_i386' at the end of the first line. ifc.cfg should now look like; -Xlinker -rpath -Xlinker /opt/intel/compiler70/ia32/lib -I/opt/intel/compiler70/ia32/include -Wl,-melf_i386 Test that ifc work properly my running it from the command-line. You should see something like; /usr/lib/crt1.o(.text+0x18): In function `_start': ../sysdeps/i386/elf/start.S:98: undefined reference to `main' So far so good. 2) evironment variables for configure script. Make IFC the default Fortran compiler by executing export F90=ifc export F77=ifc and make gnu C compiler generate 32-bit code by executing export CC="gcc -m32" 3) Optimisations (I found that the -axW or -xW option wouldn't compile, but it may for your configuration). export FFLAGS="-Vaxlib -O3 -tpp7" 4) Configure The x86_64-unkown-linux-gnu architecture is presently not recognised by the configure script. So, instead of ./configure type ./configure --build=i686-pc-linux-gnu for pw.1.3.0 ./configure should be replaced by ./configure.new 3) Make everything as usual make all; make links ---------------------- This should work hopfeully, as it did for me using Suse 9.0, but it might not for other x86_64 distributions. Please let me know if otherwise or if I have made some grevious mistakes in the above. Thanks. Kind regards to all Pwscf users, Jnathan Breeze From g.ballabio at cineca.it Thu Feb 26 14:17:03 2004 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Thu, 26 Feb 2004 14:17:03 +0100 Subject: [Pw_forum] Compiling pwscf using ifc 7.1 on a x64-64 system In-Reply-To: <403DE71C.7080603@lsbu.ac.uk> References: <1077724187.29727.50.camel@pc-ballabio> <403DE71C.7080603@lsbu.ac.uk> Message-ID: <1077801422.28897.3.camel@pc-ballabio> 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 From giannozz at nest.sns.it Thu Feb 26 14:35:12 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 26 Feb 2004 14:35:12 +0100 Subject: [Pw_forum] Feedback on new PWSCF In-Reply-To: <403C9126.6000608@fzu.cz> References: <1077724187.29727.50.camel@pc-ballabio> <403C9126.6000608@fzu.cz> Message-ID: <200402261435.12711.giannozz@nest.sns.it> On Wednesday 25 February 2004 13:12, Mutombo wrote: > Error 2 at (797:bp_c_phase.f90) : line exceeds 254 characters either the package you transferred is corrupted, or your compiler is very weird or very old, or you did something (edit, unpack the code, I don't know) on a machine running Windows Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From breezejd at lsbu.ac.uk Thu Feb 26 15:02:01 2004 From: breezejd at lsbu.ac.uk (Jonathan Breeze) Date: Thu, 26 Feb 2004 14:02:01 +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: <403DFC59.4090608@lsbu.ac.uk> As far as I know, IFC can only generate 32-bit code that is compatible with an AMD64 processor. There is a version for IA-64 chips but I don't think it would be compatible with AMD64. The PGI compiler can generate 64-bit code apparently, I'll be trying that next I think, then I will be able to compare performance. 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 > > >_______________________________________________ >Pw_forum mailing list >Pw_forum at pwscf.org >http://www.democritos.it/mailman/listinfo/pw_forum > > > -- 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 mutombo at fzu.cz Thu Feb 26 15:20:41 2004 From: mutombo at fzu.cz (Mutombo) Date: Thu, 26 Feb 2004 15:20:41 +0100 Subject: [Pw_forum] Feedback on new PWSCF In-Reply-To: <200402261435.12711.giannozz@nest.sns.it> References: <1077724187.29727.50.camel@pc-ballabio> <403C9126.6000608@fzu.cz> <200402261435.12711.giannozz@nest.sns.it> Message-ID: <403E00B9.1010406@fzu.cz> Hi Paolo, I used intel compiler : l_fc_pu_7.0.076. Maybe I need to upgrade to the latest version(8.0). Since I worked in Linux and assuming that the package was corrupted I downloaded again PWSCF2.0 and try to install it . I did not manipulate with the "PW" module . I am still getting the same error: Best wishes, Pingo 81 Lines Compiled ifc -Vaxlib -O2 -tpp5 -fpp -DMKL -D__LINUX -D__INTEL -D__FFTW -D__USE_INTERNAL_F FTW -I/home/crystal/zkouska/include -I./ -nomodule -I /home/crystal/zkouska/Modu les -I/home/crystal/zkouska/PW -I/home/crystal/zkouska/PH -c bp_c_phase.f90 external subroutine C_PHASE WRITE( stdout,"( 8X,'The calculation of phases done along the direction of vector ',I1, /,8X,'of the reciprocal lattice gives the following contributio n to', /,8X,'the polarization vector (in different units, and being Omega', /,8X,'the vol ^ Error 2 at (797:bp_c_phase.f90) : line exceeds 254 characters ^ Error 5 at (797:bp_c_phase.f90) : incomplete string ^ Error 3 at (797:bp_c_phase.f90) : unbalanced parenthesis ^ Error 7 at (797:bp_c_phase.f90) : incomplete statement ) & ^ Error 3 at (801:bp_c_phase.f90) : unbalanced parenthesis & gdir ^ Error 7 at (802:bp_c_phase.f90) : incomplete statement 6 Errors compilation aborted for bp_c_phase.f90 (code 1) make[1]: *** [bp_c_phase.o] Error 1 make[1]: Leaving directory `/home/crystal/zkouska/PW' make: *** [pw] Error 2 o Giannozzi wrote: >On Wednesday 25 February 2004 13:12, Mutombo wrote: > > > >>Error 2 at (797:bp_c_phase.f90) : line exceeds 254 characters >> >> > >either the package you transferred is corrupted, or your compiler >is very weird or very old, or you did something (edit, unpack the >code, I don't know) on a machine running Windows > >Paolo > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20040226/04e3c757/attachment.htm From giannozz at nest.sns.it Thu Feb 26 15:50:03 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Thu, 26 Feb 2004 15:50:03 +0100 Subject: [Pw_forum] Feedback on new PWSCF In-Reply-To: <403E00B9.1010406@fzu.cz> References: <200402261435.12711.giannozz@nest.sns.it> <403E00B9.1010406@fzu.cz> Message-ID: <200402261550.03577.giannozz@nest.sns.it> On Thursday 26 February 2004 15:20, Mutombo wrote: > I am still getting the same error [...] > Error 2 at (797:bp_c_phase.f90) : line exceeds 254 characters if it was working with the preceding version, there is no reason why it shouldn't work now. The limit of 254 characters applies to the single line, not to continuation lines. Maybe that particular version of the compiler has some problem. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From mutombo at fzu.cz Thu Feb 26 16:53:15 2004 From: mutombo at fzu.cz (Mutombo) Date: Thu, 26 Feb 2004 16:53:15 +0100 Subject: [Pw_forum] Feedback on new PWSCF In-Reply-To: <200402261550.03577.giannozz@nest.sns.it> References: <200402261435.12711.giannozz@nest.sns.it> <403E00B9.1010406@fzu.cz> <200402261550.03577.giannozz@nest.sns.it> Message-ID: <403E166B.6020008@fzu.cz> Hi Paolo, You were right. I just upgraded the compiler and it works fine. Best regards, Pingo Paolo Giannozzi wrote: >On Thursday 26 February 2004 15:20, Mutombo wrote: > > > >> I am still getting the same error [...] >>Error 2 at (797:bp_c_phase.f90) : line exceeds 254 characters >> >> > >if it was working with the preceding version, there is no reason why >it shouldn't work now. The limit of 254 characters applies to the >single line, not to continuation lines. Maybe that particular version >of the compiler has some problem. > >Paolo > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20040226/9d4dee42/attachment.htm From subhra at ux1.cso.uiuc.edu Thu Feb 26 21:19:46 2004 From: subhra at ux1.cso.uiuc.edu (Subhradip Ghosh) Date: Thu, 26 Feb 2004 14:19:46 -0600 (CST) Subject: [Pw_forum] Error while relaxation Message-ID: Hi, I was trying to run a relaxation calculation. It stops with the error message: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from davcio : error # 10 i/o error in davcio %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... I tried both Conjugate Gradient and Davidson diagonalization. The end result is the same. Funny thing is that it worked perfectly yesterday but I can't reproduce it today. I didn't change anything in the input file, yet it happens. 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 * ************************************************************************