From wang.yuanxu at nims.go.jp Fri Oct 1 00:34:19 2004 From: wang.yuanxu at nims.go.jp (WANG Yuan Xu) Date: Fri, 1 Oct 2004 07:34:19 +0900 Subject: [Pw_forum] scf for BaTiO3 Message-ID: <20040930223645.51F8A67F47@kugane.nims.go.jp> Dear Paolo Giannozzi, Thank you for you email! I see it , I must generate the UPF file by myslef. I still not successful compiling Pwscf on Hitachi. I am not the root user. I want to know whether the shmem_include.f90 is necessary for Pwscf or it just be an option? what is useful for this file. the include file shmem.fh, where can i download it or install a lib? Best WANG Yuan Xu National Institute for Materials Science Computational Materials Science Center Namiki 1-1, Tsukuba 305-0044, Japan Phone +81-29-8513354-8092; Fax +81-29-8541207 wang.yuanxu at nims.go.jp 2004-10-01 ======= 2004-09-30 20:18:45 you wrote======= >On Thursday 30 September 2004 07:55, WANG Yuan Xu wrote: > >> I use the Ba pseudo file from PWscf web site. And O an Ti was >> Ti.vdb.UPF and O.vdb.UPF >> >> I get the error information "from readpp # 2 inconsistent DFT read" > >for PWscf, the exchange-correlation used in the calculation is read from >the PP files, and it must be the same in all PP's (of course). One can >edit the PP files and modify the exch-corr field, but it is not a good idea. > >Note that FPMD uses a different approach: you have to write the exch-corr >you want in the input data (variable "xc_type" in namelist &system) > >Does PWscf work now on the Hitachi machine, by the way? > >Paolo >-- >Paolo Giannozzi e-mail: giannozz at nest.sns.it >Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 >Piazza dei Cavalieri 7 I-56126 Pisa, Italy >_______________________________________________ >Pw_forum mailing list >Pw_forum at pwscf.org >http://www.democritos.it/mailman/listinfo/pw_forum > = = = = = = = = = = = = = = = = = = = = From aaron at nemo.physics.ncsu.edu Fri Oct 1 00:02:23 2004 From: aaron at nemo.physics.ncsu.edu (aaron at nemo.physics.ncsu.edu) Date: Thu, 30 Sep 2004 18:02:23 -0400 (EDT) Subject: [Pw_forum] espresso compilation error IBM SP4 arch In-Reply-To: <1096557073.2994.73.camel@dhpc-5-40.sissa.it> Message-ID: Hi, I'm very excited to try the new release. However I've run into a small compilation error as follows: *********************************************************** *********************************************************** mpxlf -qalias=noaryovrlp -I../include -O3 -qstrict -qarch=auto -qtune=auto -qsuffix=cpp=f90 -qdpc -Q -qalias=nointptr -qfree=f90 -I/tmp/work/amgeorge/pw2.1/install -WF,-D__AIX,-D__PARA,-D__MPI,-DHAS_ZHEGVX -I/tmp/work/amgeorge/pw2.1/Modules -I/tmp/work/amgeorge/pw2.1/PW -I/tmp/work/amgeorge/pw2.1/PH -c parser.f90 "parser.f90", 1514-286 (S) The variable, j, has the SAVE or STATIC attribute. A variable declared in a pure subprogram must not have the SAVE or STATIC attribute. You may have specified the SAVE option explicitly or by default. "parser.f90", 1514-286 (S) The variable, sep2, has the SAVE or STATIC attribute. A variable declared in a pure subprogram must not have the SAVE or STATIC attribute. You may have specified the SAVE option explicitly or by default. "parser.f90", 1514-286 (S) The variable, sep1, has the SAVE or STATIC attribute. A variable declared in a pure subprogram must not have the SAVE or STATIC attribute. You may have specified the SAVE option explicitly or by default. ** parser === End of Compilation 1 === *********************************************************** *********************************************************** Please advise. Thanks in advance, Aaron From likedew at phys.ksu.edu Fri Oct 1 02:18:08 2004 From: likedew at phys.ksu.edu (Hong, SamPyo) Date: Thu, 30 Sep 2004 19:18:08 -0500 Subject: [Pw_forum] Cu US PP with PBE exchange Message-ID: Hello, Just for a test purpose, I picked up the pseudopotential 'Cu.pbe-d-rrkjus.UPF' for Cu bulk, which I downloaded from web. The known experimental a0 is 3.61 Angstrom but I could get at best 3.80 angstrom, which is huge off from the value. I wonder why this PP performs that poorly.....I think ecut of 20 ryd and k-sampling of 15x15x15 should be enough for test. Does anybody have an idea? Best regards, Sampyo From sbraccia at sissa.it Fri Oct 1 09:28:22 2004 From: sbraccia at sissa.it (carlo sbraccia) Date: Fri, 01 Oct 2004 09:28:22 +0200 Subject: [Pw_forum] espresso compilation error IBM SP4 arch In-Reply-To: References: Message-ID: <1096615702.3102.27.camel@dhpc-5-40.sissa.it> Dear Aaron, with some version of the AIX compiler, some combination of flags lead to variables being defined as static, hence giving a conflict with PURE function. To solve the problem (or compiler bug) we must force the variable to be AUTOMATIC. Try with the attached routine. carlo On Fri, 2004-10-01 at 00:02, aaron at nemo.physics.ncsu.edu wrote: > Hi, > > I'm very excited to try the new release. > However I've run into a small compilation error as follows: > > *********************************************************** > *********************************************************** > mpxlf -qalias=noaryovrlp -I../include -O3 -qstrict -qarch=auto > -qtune=auto -qsuffix=cpp=f90 -qdpc -Q -qalias=nointptr -qfree=f90 > -I/tmp/work/amgeorge/pw2.1/install > -WF,-D__AIX,-D__PARA,-D__MPI,-DHAS_ZHEGVX > -I/tmp/work/amgeorge/pw2.1/Modules -I/tmp/work/amgeorge/pw2.1/PW > -I/tmp/work/amgeorge/pw2.1/PH -c parser.f90 > "parser.f90", 1514-286 (S) The variable, j, has the SAVE or STATIC > attribute. A variable declared in a pure subprogram must not have the > SAVE or STATIC attribute. You may have specified the SAVE option > explicitly or by default. > "parser.f90", 1514-286 (S) The variable, sep2, has the SAVE or STATIC > attribute. A variable declared in a pure subprogram must not have the > SAVE or STATIC attribute. You may have specified the SAVE option > explicitly or by default. > "parser.f90", 1514-286 (S) The variable, sep1, has the SAVE or STATIC > attribute. A variable declared in a pure subprogram must not have the > SAVE or STATIC attribute. You may have specified the SAVE option > explicitly or by default. > ** parser === End of Compilation 1 === > *********************************************************** > *********************************************************** > > Please advise. > > Thanks in advance, > > Aaron > > > > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum -------------- next part -------------- ! ! Copyright (C) 2001-2004 Carlo Cavazzoni and PWSCF group ! This file is distributed under the terms of the ! GNU General Public License. See the file `License' ! in the root directory of the present distribution, ! or http://www.gnu.org/copyleft/gpl.txt . ! ! ! ... SUBROUTINE con_cam: counts the number of fields in a string ! separated by the optional character ! ! ... SUBROUTINE field_count: accepts two string (one of them is optional) ! and one integer and count the number of fields ! in the string separated by a blank or a tab ! character. If the optional string is specified ! (it has anyway len=1) it is assumed as the ! separator character. ! Ignores any charcter following the exclamation ! mark (fortran comment) ! ! ... SUBROUTINE field_compare: accepts two strings and one integer. Counts the ! fields contained in the first string and ! compares it with the integer. ! If they are less than the integer calls the ! routine error and show by the second string the ! name of the field where read-error occurred. ! #include "f_defs.h" ! !---------------------------------------------------------------------------- MODULE parser !---------------------------------------------------------------------------- ! USE io_global, ONLY : stdout USE kinds ! CONTAINS ! !----------------------------------------------------------------------- PURE FUNCTION int_to_char( int ) !----------------------------------------------------------------------- ! IMPLICIT NONE ! INTEGER, INTENT(IN) :: int CHARACTER (LEN=6) :: int_to_char ! ! IF ( int < 10 ) THEN ! WRITE( UNIT = int_to_char , FMT = "(I1)" ) int ! ELSE IF ( int < 100 ) THEN ! WRITE( UNIT = int_to_char , FMT = "(I2)" ) int ! ELSE IF ( int < 1000 ) THEN ! WRITE( UNIT = int_to_char , FMT = "(I3)" ) int ! ELSE IF ( int < 10000 ) THEN ! WRITE( UNIT = int_to_char , FMT = "(I4)" ) int ! ELSE ! WRITE( UNIT = int_to_char , FMT = "(I5)" ) int ! END IF ! RETURN ! END FUNCTION int_to_char ! ! !-------------------------------------------------------------------------- SUBROUTINE delete_if_present( filename, in_warning ) !-------------------------------------------------------------------------- ! IMPLICIT NONE ! CHARACTER(LEN=*), INTENT(IN) :: filename LOGICAL, OPTIONAL, INTENT(IN) :: in_warning LOGICAL :: exst, opnd, warning INTEGER :: iunit ! INQUIRE( FILE = filename, EXIST = exst ) ! IF ( exst ) THEN ! unit_loop: DO iunit = 99, 1, - 1 ! INQUIRE( UNIT = iunit, OPENED = opnd ) ! IF ( .NOT. opnd ) THEN ! warning = .FALSE. ! IF ( PRESENT( in_warning ) ) warning = in_warning ! OPEN( UNIT = iunit, FILE = filename , STATUS = 'OLD' ) CLOSE( UNIT = iunit, STATUS = 'DELETE' ) ! IF ( warning ) & WRITE( UNIT = stdout, FMT = '(/,5X,"WARNING: ",A, & & " file was present; old file deleted")' ) filename ! RETURN ! END IF ! END DO unit_loop ! CALL errore( 'delete_if_present', 'free unit not found ?!?', 1 ) ! END IF ! RETURN ! END SUBROUTINE delete_if_present ! !-------------------------------------------------------------------------- PURE SUBROUTINE field_count( num, line, car ) !-------------------------------------------------------------------------- ! IMPLICIT NONE ! INTEGER, INTENT(OUT) :: num CHARACTER(LEN=*), INTENT(IN) :: line CHARACTER(LEN=1), OPTIONAL, INTENT(IN) :: car #if defined __AIX ! with AIX compiler some combination of flags lead to ! variables being defined as static, hence giving a conflict ! with PURE function. We then force the variable be AUTOMATIC CHARACTER(LEN=1), AUTOMATIC :: sep1, sep2 INTEGER, AUTOMATIC :: j #else CHARACTER(LEN=1) :: sep1, sep2 INTEGER :: j #endif ! ! num = 0 ! IF ( .NOT. present(car) ) THEN ! sep1 = char(32) ! ... blank character sep2 = char(9) ! ... tab character ! DO j = 2, MAX( LEN( line ), 256 ) ! IF ( line(j:j) == '!' .OR. line(j:j) == char(0) ) THEN ! IF ( line(j-1:j-1) /= sep1 .AND. line(j-1:j-1) /= sep2 ) THEN ! num = num + 1 ! END IF ! EXIT ! END IF ! IF ( ( line(j:j) == sep1 .OR. line(j:j) == sep2 ) .AND. & ( line(j-1:j-1) /= sep1 .AND. line(j-1:j-1) /= sep2 ) ) THEN ! num = num + 1 ! END IF ! END DO ! ELSE ! sep1 = car ! DO j = 2, MAX( LEN( line ), 256 ) ! IF ( line(j:j) == '!' .OR. & line(j:j) == char(0) .OR. line(j:j) == char(32) ) THEN ! IF ( line(j-1:j-1) /= sep1 ) num = num + 1 ! EXIT ! END IF ! IF ( line(j:j) == sep1 .AND. line(j-1:j-1) /= sep1 ) num = num + 1 ! END DO ! END IF ! RETURN ! END SUBROUTINE field_count ! ! !-------------------------------------------------------------------------- SUBROUTINE read_line( line, nfield, field, end_of_file ) !-------------------------------------------------------------------------- ! USE mp, ONLY : mp_bcast USE mp_global, ONLY : group USE io_global, ONLY : ionode, ionode_id ! IMPLICIT NONE ! CHARACTER(LEN=*), INTENT(OUT) :: line CHARACTER(LEN=*), OPTIONAL, INTENT(IN) :: field INTEGER, OPTIONAL, INTENT(IN) :: nfield LOGICAL, OPTIONAL, INTENT(OUT) :: end_of_file LOGICAL :: tend ! ! IF( LEN( line ) < 256 ) THEN CALL errore(' read_line ', ' input line too short ', LEN( line ) ) END IF ! IF ( ionode ) THEN READ (5, fmt='(A256)', END=10) line tend = .FALSE. GO TO 20 10 tend = .TRUE. 20 CONTINUE END IF ! CALL mp_bcast( tend, ionode_id, group ) CALL mp_bcast( line, ionode_id, group ) ! IF( PRESENT(end_of_file) ) THEN end_of_file = tend ELSE IF( tend ) THEN CALL errore(' read_line ', ' end of file ', 0 ) ELSE IF( PRESENT(field) ) CALL field_compare( line, nfield, field ) END IF ! RETURN ! END SUBROUTINE read_line ! ! !-------------------------------------------------------------------------- SUBROUTINE field_compare( str, nf, var ) !-------------------------------------------------------------------------- ! IMPLICIT NONE ! CHARACTER(LEN=*), INTENT(IN) :: var INTEGER, INTENT(IN) :: nf CHARACTER(LEN=*), INTENT(IN) :: str INTEGER :: nc ! CALL field_count( nc, str ) ! IF( nc < nf ) & CALL errore( ' field_compare ', & & ' wrong number of fields: ' // TRIM( var ), 1 ) ! RETURN ! END SUBROUTINE field_compare ! ! !-------------------------------------------------------------------------- SUBROUTINE con_cam(num, line, car) !-------------------------------------------------------------------------- CHARACTER(LEN=*) :: line CHARACTER(LEN=1) :: sep CHARACTER(LEN=1), OPTIONAL :: car INTEGER :: num, j num = 0 IF (len(line) .GT. 256 ) THEN WRITE( stdout,*) 'riga ', line WRITE( stdout,*) 'lunga ', len(line) num = -1 RETURN END IF WRITE( stdout,*) '1riga ', line WRITE( stdout,*) '1lunga ', len(line) IF ( .NOT. present(car) ) THEN sep=char(32) !char(32) is the blank character ELSE sep=car END IF DO j=2, MAX(len(line),256) IF ( line(j:j) == '!' .OR. line(j:j) == char(0)) THEN RETURN END IF IF ( (line(j:j) .EQ. sep) .AND. & (line(j-1:j-1) .NE. sep) ) THEN num = num + 1 END IF END DO RETURN END SUBROUTINE con_cam ! END MODULE parser From eyvaz_isaev at yahoo.com Fri Oct 1 10:07:08 2004 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Fri, 1 Oct 2004 01:07:08 -0700 (PDT) Subject: [Pw_forum] Cu US PP with PBE exchange In-Reply-To: Message-ID: <20041001080708.64632.qmail@web60303.mail.yahoo.com> Hi, 20 Ry, definitely, is not enough. It should be, perhaps, about 30-35Ry. You can try to do some tests for total energy calculations, say, for experimental lattice parameter with increasing Encut. When you have converged with this you can recalculate lattice parameter using converged Encut. K-sampling should be enough, but again, you can try more fine k-mesh. Bests, Eyvaz. --- "Hong, SamPyo" wrote: > Hello, > Just for a test purpose, I picked up the > pseudopotential > 'Cu.pbe-d-rrkjus.UPF' for Cu bulk, which I > downloaded from web. > The known experimental a0 is 3.61 Angstrom but I > could get at best 3.80 > angstrom, which is huge off from the value. > I wonder why this PP performs that poorly.....I > think ecut of 20 ryd and > k-sampling of 15x15x15 should be enough for test. > Does anybody have an idea? > > Best regards, > > Sampyo > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From giannozz at nest.sns.it Fri Oct 1 10:14:10 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 1 Oct 2004 10:14:10 +0200 Subject: [Pw_forum] Cu US PP with PBE exchange In-Reply-To: References: Message-ID: <200410011014.11130.giannozz@nest.sns.it> On Friday 01 October 2004 02:18, Hong, SamPyo wrote: > I think ecut of 20 ryd and k-sampling of 15x15x15 should be > enough for test. you think or you did convergence tests? -- 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 Oct 1 10:14:46 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 1 Oct 2004 10:14:46 +0200 Subject: [Pw_forum] scf for BaTiO3 In-Reply-To: <20040930223645.51F8A67F47@kugane.nims.go.jp> References: <20040930223645.51F8A67F47@kugane.nims.go.jp> Message-ID: <200410011014.46326.giannozz@nest.sns.it> On Friday 01 October 2004 00:34, WANG Yuan Xu wrote: > I still not successful compiling Pwscf on Hitachi [...] I want to know > whether the shmem_include.f90 is necessary for Pwscf or it just be > an option? it is an option for a specific library on a specific machine (T3E). I am not sure that it still works, by the way. If you have -D__SHMEM among the postprocessor options in make.sys, just remove -D__SHMEM, "make clean" and recompile If you do not have -D__SHMEM among the postprocessor options in make.sys, it is set by your preprocessor by defaut. Inquire with your system manager or user support. 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 a.soon at auckland.ac.nz Fri Oct 1 13:05:49 2004 From: a.soon at auckland.ac.nz (Aloysius Soon SL) Date: Fri, 1 Oct 2004 23:05:49 +1200 Subject: [Pw_forum] Cu US PP with PBE exchange Message-ID: <1096628749.252a4426f44fc@webmail.auckland.ac.nz> Hi Sampyo, I have used this pseudo and I have tested this pseudo in Cu2O and it should be around 50-60 Ry (kpoints depends on unit cell used). The lattice constant and bulk modulus are well represented. This was also reported in the literature. Cheers! -- Aloysius Soon SL Postgraduate Student Structural & Computational Chemistry Chemistry Department The University Of Auckland, New Zealand Phone: +64 9 373 7599 ext 88291 Email: a.soon at auckland.ac.nz ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ From likedew at phys.ksu.edu Fri Oct 1 19:07:31 2004 From: likedew at phys.ksu.edu (Hong, SamPyo) Date: Fri, 1 Oct 2004 12:07:31 -0500 Subject: [Pw_forum] Cu US PP with PBE exchange Message-ID: I tried several Ecut values and realized at least 30 Ryd is needed for 'slow' convergence with 'Cu.pbe-d-rrkjus.UPF', which is pretty going beyond my expectation. The best value for Cu bulk I've got is 3.673, approximately 1.7% larger than that of experimental a0. I appreciate Eyvaz and Aloysius for their valuable comments. Sampyo From giannozz at nest.sns.it Fri Oct 1 20:13:13 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 1 Oct 2004 20:13:13 +0200 Subject: [Pw_forum] Cu US PP with PBE exchange In-Reply-To: References: Message-ID: <200410012013.13744.giannozz@nest.sns.it> On Friday 01 October 2004 19:07, Hong, SamPyo wrote: > I tried several Ecut values and realized at least 30 Ryd is needed there are two cutoffs for ultrasoft PP's, one for the expansion of the Kohn-Sham orbitals and one for the expansion of the charge density. By default, and in norm-conserving PP's, the latter is four times the former, but in ultrasoft PP's it is often convenient to use a cutoff for the charge density that is larger than this Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy From proffess at yandex.ru Sat Oct 2 10:47:00 2004 From: proffess at yandex.ru (Sergey Lisenkov) Date: Sat, 2 Oct 2004 12:47:00 +0400 (MSD) Subject: [Pw_forum] Restart error Message-ID: <415E6B04.000017.10472@soapbox.yandex.ru> Dear PWscf authors and users, I have restarted my calculations from previous one. The code ran 1 iterations, printed forces and stopped with error: 1525-001 The READ statement on the file ./60-1bn.bfgs cannot be completed because the end of the file was reached. The program will stop. Is it my fault? Best wishes, Sergey From aaron at nemo.physics.ncsu.edu Sat Oct 2 15:45:37 2004 From: aaron at nemo.physics.ncsu.edu (aaron at nemo.physics.ncsu.edu) Date: Sat, 2 Oct 2004 09:45:37 -0400 (EDT) Subject: [Pw_forum] espresso compilation error IBM SP4 arch In-Reply-To: <1096615702.3102.27.camel@dhpc-5-40.sissa.it> Message-ID: Hi All, Carlo, Thanks very much for the help. I was able to move past that point with your file parser.f90. Now I'm stuck again, but I really want the functionality I read about. Here's the error: > > *********************************************************** > > *********************************************************** cc -Wp,-D__AIX,-D__PARA,-D__MPI,-DHAS_ZHEGVX -O2 -c c_mkdir.c "c_mkdir.c", line 17.10: 1506-296 (S) #include file "c_defs.h" not found. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. > > *********************************************************** > > *********************************************************** Usually I would expect the c-compiler to find these ~.h files on its own. I can really make use of the functionality to specify intermediate images in the NEB. Thanks Aaron On Fri, 1 Oct 2004, carlo sbraccia wrote: > Dear Aaron, > with some version of the AIX compiler, some combination of flags lead to > variables being defined as static, hence giving a conflict with PURE > function. To solve the problem (or compiler bug) we must force the > variable to be AUTOMATIC. Try with the attached routine. > carlo > > On Fri, 2004-10-01 at 00:02, aaron at nemo.physics.ncsu.edu wrote: > > Hi, > > > > I'm very excited to try the new release. > > However I've run into a small compilation error as follows: > > > > *********************************************************** > > mpxlf -qalias=noaryovrlp -I../include -O3 -qstrict -qarch=auto > > -qtune=auto -qsuffix=cpp=f90 -qdpc -Q -qalias=nointptr -qfree=f90 > > -I/tmp/work/amgeorge/pw2.1/install > > -WF,-D__AIX,-D__PARA,-D__MPI,-DHAS_ZHEGVX > > -I/tmp/work/amgeorge/pw2.1/Modules -I/tmp/work/amgeorge/pw2.1/PW > > -I/tmp/work/amgeorge/pw2.1/PH -c parser.f90 > > "parser.f90", 1514-286 (S) The variable, j, has the SAVE or STATIC > > attribute. A variable declared in a pure subprogram must not have the > > SAVE or STATIC attribute. You may have specified the SAVE option > > explicitly or by default. > > "parser.f90", 1514-286 (S) The variable, sep2, has the SAVE or STATIC > > attribute. A variable declared in a pure subprogram must not have the > > SAVE or STATIC attribute. You may have specified the SAVE option > > explicitly or by default. > > "parser.f90", 1514-286 (S) The variable, sep1, has the SAVE or STATIC > > attribute. A variable declared in a pure subprogram must not have the > > SAVE or STATIC attribute. You may have specified the SAVE option > > explicitly or by default. > > ** parser === End of Compilation 1 === > > *********************************************************** > > *********************************************************** > > > > Please advise. > > > > Thanks in advance, > > > > Aaron > > > > > > > > > > _______________________________________________ > > Pw_forum mailing list > > Pw_forum at pwscf.org > > http://www.democritos.it/mailman/listinfo/pw_forum > From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Sat Oct 2 20:06:54 2004 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Sat, 2 Oct 2004 20:06:54 +0200 (CEST) Subject: [Pw_forum] espresso compilation error IBM SP4 arch In-Reply-To: Message-ID: On Sat, 2 Oct 2004 aaron at nemo.physics.ncsu.edu wrote: A> Hi All, Carlo, A> A> Thanks very much for the help. I was able to move past that point with A> your file parser.f90. Now I'm stuck again, but I really want the A> functionality I read about. A> A> Here's the error: A> A> > > *********************************************************** A> > > *********************************************************** A> A> cc -Wp,-D__AIX,-D__PARA,-D__MPI,-DHAS_ZHEGVX -O2 -c c_mkdir.c A> "c_mkdir.c", line 17.10: 1506-296 (S) #include file "c_defs.h" not found. A> make: 1254-004 The error code from the last command is 1. A> A> A> Stop. A> make: 1254-004 The error code from the last command is 2. A> A> A> Stop. A> A> > > *********************************************************** A> > > *********************************************************** A> A> Usually I would expect the c-compiler to find these ~.h files on its own. aaron, this is only true for (some of) the system headers. c_defs.h is part of the espresso package, and thus you have to make sure, that a) the IFLAGS definition contains -I../include and b) definition of CCFLAGS contains $(IFLAGS) so that the preprocessor knows how to find that file. regards, axel. A> A> I can really make use of the functionality to specify intermediate images A> in the NEB. A> A> Thanks A> A> Aaron A> A> On A> Fri, 1 Oct 2004, carlo sbraccia wrote: A> A> > Dear Aaron, A> > with some version of the AIX compiler, some combination of flags lead to A> > variables being defined as static, hence giving a conflict with PURE A> > function. To solve the problem (or compiler bug) we must force the A> > variable to be AUTOMATIC. Try with the attached routine. A> > carlo A> > A> > On Fri, 2004-10-01 at 00:02, aaron at nemo.physics.ncsu.edu wrote: A> > > Hi, A> > > A> > > I'm very excited to try the new release. A> > > However I've run into a small compilation error as follows: A> > > A> > > *********************************************************** A> > > mpxlf -qalias=noaryovrlp -I../include -O3 -qstrict -qarch=auto A> > > -qtune=auto -qsuffix=cpp=f90 -qdpc -Q -qalias=nointptr -qfree=f90 A> > > -I/tmp/work/amgeorge/pw2.1/install A> > > -WF,-D__AIX,-D__PARA,-D__MPI,-DHAS_ZHEGVX A> > > -I/tmp/work/amgeorge/pw2.1/Modules -I/tmp/work/amgeorge/pw2.1/PW A> > > -I/tmp/work/amgeorge/pw2.1/PH -c parser.f90 A> > > "parser.f90", 1514-286 (S) The variable, j, has the SAVE or STATIC A> > > attribute. A variable declared in a pure subprogram must not have the A> > > SAVE or STATIC attribute. You may have specified the SAVE option A> > > explicitly or by default. A> > > "parser.f90", 1514-286 (S) The variable, sep2, has the SAVE or STATIC A> > > attribute. A variable declared in a pure subprogram must not have the A> > > SAVE or STATIC attribute. You may have specified the SAVE option A> > > explicitly or by default. A> > > "parser.f90", 1514-286 (S) The variable, sep1, has the SAVE or STATIC A> > > attribute. A variable declared in a pure subprogram must not have the A> > > SAVE or STATIC attribute. You may have specified the SAVE option A> > > explicitly or by default. A> > > ** parser === End of Compilation 1 === A> > > *********************************************************** A> > > *********************************************************** A> > > A> > > Please advise. A> > > A> > > Thanks in advance, A> > > A> > > Aaron A> > > A> > > A> > > A> > > A> > > _______________________________________________ A> > > Pw_forum mailing list A> > > Pw_forum at pwscf.org A> > > http://www.democritos.it/mailman/listinfo/pw_forum A> > A> A> _______________________________________________ A> Pw_forum mailing list A> Pw_forum at pwscf.org A> http://www.democritos.it/mailman/listinfo/pw_forum A> A> -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at rub.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= From aaron at nemo.physics.ncsu.edu Sat Oct 2 18:51:46 2004 From: aaron at nemo.physics.ncsu.edu (aaron at nemo.physics.ncsu.edu) Date: Sat, 2 Oct 2004 12:51:46 -0400 (EDT) Subject: [Pw_forum] espresso compilation error IBM SP4 arch In-Reply-To: Message-ID: Thanks very much. On Sat, 2 Oct 2004, Axel Kohlmeyer wrote: > > On Sat, 2 Oct 2004 aaron at nemo.physics.ncsu.edu wrote: > > A> Hi All, Carlo, > A> > A> Thanks very much for the help. I was able to move past that point with > A> your file parser.f90. Now I'm stuck again, but I really want the > A> functionality I read about. > A> > A> Here's the error: > A> > A> > > *********************************************************** > A> > > *********************************************************** > A> > A> cc -Wp,-D__AIX,-D__PARA,-D__MPI,-DHAS_ZHEGVX -O2 -c c_mkdir.c > A> "c_mkdir.c", line 17.10: 1506-296 (S) #include file "c_defs.h" not found. > A> make: 1254-004 The error code from the last command is 1. > A> > A> > A> Stop. > A> make: 1254-004 The error code from the last command is 2. > A> > A> > A> Stop. > A> > A> > > *********************************************************** > A> > > *********************************************************** > A> > A> Usually I would expect the c-compiler to find these ~.h files on its own. > > aaron, > > this is only true for (some of) the system headers. c_defs.h is part of > the espresso package, and thus you have to make sure, that a) the IFLAGS > definition contains -I../include and b) definition of CCFLAGS contains > $(IFLAGS) so that the preprocessor knows how to find that file. > > regards, > axel. > > A> > A> I can really make use of the functionality to specify intermediate images > A> in the NEB. > A> > A> Thanks > A> > A> Aaron > A> > A> On > A> Fri, 1 Oct 2004, carlo sbraccia wrote: > A> > A> > Dear Aaron, > A> > with some version of the AIX compiler, some combination of flags lead to > A> > variables being defined as static, hence giving a conflict with PURE > A> > function. To solve the problem (or compiler bug) we must force the > A> > variable to be AUTOMATIC. Try with the attached routine. > A> > carlo > A> > > A> > On Fri, 2004-10-01 at 00:02, aaron at nemo.physics.ncsu.edu wrote: > A> > > Hi, > A> > > > A> > > I'm very excited to try the new release. > A> > > However I've run into a small compilation error as follows: > A> > > > A> > > *********************************************************** > A> > > mpxlf -qalias=noaryovrlp -I../include -O3 -qstrict -qarch=auto > A> > > -qtune=auto -qsuffix=cpp=f90 -qdpc -Q -qalias=nointptr -qfree=f90 > A> > > -I/tmp/work/amgeorge/pw2.1/install > A> > > -WF,-D__AIX,-D__PARA,-D__MPI,-DHAS_ZHEGVX > A> > > -I/tmp/work/amgeorge/pw2.1/Modules -I/tmp/work/amgeorge/pw2.1/PW > A> > > -I/tmp/work/amgeorge/pw2.1/PH -c parser.f90 > A> > > "parser.f90", 1514-286 (S) The variable, j, has the SAVE or STATIC > A> > > attribute. A variable declared in a pure subprogram must not have the > A> > > SAVE or STATIC attribute. You may have specified the SAVE option > A> > > explicitly or by default. > A> > > "parser.f90", 1514-286 (S) The variable, sep2, has the SAVE or STATIC > A> > > attribute. A variable declared in a pure subprogram must not have the > A> > > SAVE or STATIC attribute. You may have specified the SAVE option > A> > > explicitly or by default. > A> > > "parser.f90", 1514-286 (S) The variable, sep1, has the SAVE or STATIC > A> > > attribute. A variable declared in a pure subprogram must not have the > A> > > SAVE or STATIC attribute. You may have specified the SAVE option > A> > > explicitly or by default. > A> > > ** parser === End of Compilation 1 === > A> > > *********************************************************** > A> > > *********************************************************** > A> > > > A> > > Please advise. > A> > > > A> > > Thanks in advance, > A> > > > A> > > Aaron > A> > > > A> > > > A> > > > A> > > > A> > > _______________________________________________ > A> > > Pw_forum mailing list > A> > > Pw_forum at pwscf.org > A> > > http://www.democritos.it/mailman/listinfo/pw_forum > A> > > A> > A> _______________________________________________ > A> Pw_forum mailing list > A> Pw_forum at pwscf.org > A> http://www.democritos.it/mailman/listinfo/pw_forum > A> > A> > > From eyvaz_isaev at yahoo.com Mon Oct 4 00:01:59 2004 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Sun, 3 Oct 2004 15:01:59 -0700 (PDT) Subject: [Pw_forum] espresso compilation error IBM SP4 arch In-Reply-To: Message-ID: <20041003220159.32434.qmail@web60301.mail.yahoo.com> Hi, In addition to Axel's comment. The best solution was proposed by Kostya Kudin: add -I$(OSHOME)/include to CPPFLAGS. On some IBM machines where new "configure" does not work, configuring a make.sys in old manner and then adding aforemwntioned keyword works well. Bests, Eyvaz. --- Axel Kohlmeyer wrote: > > On Sat, 2 Oct 2004 aaron at nemo.physics.ncsu.edu > wrote: > > A> Hi All, Carlo, > A> > A> Thanks very much for the help. I was able to > move past that point with > A> your file parser.f90. Now I'm stuck again, but I > really want the > A> functionality I read about. > A> > A> Here's the error: > A> > A> > > > *********************************************************** > A> > > > *********************************************************** > A> > A> cc > -Wp,-D__AIX,-D__PARA,-D__MPI,-DHAS_ZHEGVX -O2 -c > c_mkdir.c > A> "c_mkdir.c", line 17.10: 1506-296 (S) #include > file "c_defs.h" not found. > A> make: 1254-004 The error code from the last > command is 1. > A> > A> > A> Stop. > A> make: 1254-004 The error code from the last > command is 2. > A> > A> > A> Stop. > A> > A> > > > *********************************************************** > A> > > > *********************************************************** > A> > A> Usually I would expect the c-compiler to find > these ~.h files on its own. > > aaron, > > this is only true for (some of) the system headers. > c_defs.h is part of > the espresso package, and thus you have to make > sure, that a) the IFLAGS > definition contains -I../include and b) definition > of CCFLAGS contains > $(IFLAGS) so that the preprocessor knows how to find > that file. > > regards, > axel. > > A> > A> I can really make use of the functionality to > specify intermediate images > A> in the NEB. > A> > A> Thanks > A> > A> Aaron > A> > A> On > A> Fri, 1 Oct 2004, carlo sbraccia wrote: > A> > A> > Dear Aaron, > A> > with some version of the AIX compiler, some > combination of flags lead to > A> > variables being defined as static, hence giving > a conflict with PURE > A> > function. To solve the problem (or compiler > bug) we must force the > A> > variable to be AUTOMATIC. Try with the attached > routine. > A> > carlo > A> > > A> > On Fri, 2004-10-01 at 00:02, > aaron at nemo.physics.ncsu.edu wrote: > A> > > Hi, > A> > > > A> > > I'm very excited to try the new release. > A> > > However I've run into a small compilation > error as follows: > A> > > > A> > > > *********************************************************** > A> > > mpxlf -qalias=noaryovrlp -I../include > -O3 -qstrict -qarch=auto > A> > > -qtune=auto -qsuffix=cpp=f90 -qdpc -Q > -qalias=nointptr -qfree=f90 > A> > > -I/tmp/work/amgeorge/pw2.1/install > A> > > -WF,-D__AIX,-D__PARA,-D__MPI,-DHAS_ZHEGVX > A> > > -I/tmp/work/amgeorge/pw2.1/Modules > -I/tmp/work/amgeorge/pw2.1/PW > A> > > -I/tmp/work/amgeorge/pw2.1/PH -c parser.f90 > A> > > "parser.f90", 1514-286 (S) The variable, j, > has the SAVE or STATIC > A> > > attribute. A variable declared in a pure > subprogram must not have the > A> > > SAVE or STATIC attribute. You may have > specified the SAVE option > A> > > explicitly or by default. > A> > > "parser.f90", 1514-286 (S) The variable, > sep2, has the SAVE or STATIC > A> > > attribute. A variable declared in a pure > subprogram must not have the > A> > > SAVE or STATIC attribute. You may have > specified the SAVE option > A> > > explicitly or by default. > A> > > "parser.f90", 1514-286 (S) The variable, > sep1, has the SAVE or STATIC > A> > > attribute. A variable declared in a pure > subprogram must not have the > A> > > SAVE or STATIC attribute. You may have > specified the SAVE option > A> > > explicitly or by default. > A> > > ** parser === End of Compilation 1 === > A> > > > *********************************************************** > A> > > > *********************************************************** > A> > > > A> > > Please advise. > A> > > > A> > > Thanks in advance, > A> > > > A> > > Aaron > A> > > > A> > > > A> > > > A> > > > A> > > > _______________________________________________ > A> > > Pw_forum mailing list > A> > > Pw_forum at pwscf.org > A> > > > http://www.democritos.it/mailman/listinfo/pw_forum > A> > > A> > A> _______________________________________________ > A> Pw_forum mailing list > A> Pw_forum at pwscf.org > A> > http://www.democritos.it/mailman/listinfo/pw_forum > A> > A> > > -- > > > ======================================================================= > Dr. Axel Kohlmeyer e-mail: > axel.kohlmeyer at rub.de > Lehrstuhl fuer Theoretische Chemie Phone: > ++49 (0)234/32-26673 > Ruhr-Universitaet Bochum - NC 03/53 Fax: > ++49 (0)234/32-14045 > D-44780 Bochum > http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ > ======================================================================= > > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From aaron at nemo.physics.ncsu.edu Sun Oct 3 22:55:56 2004 From: aaron at nemo.physics.ncsu.edu (aaron at nemo.physics.ncsu.edu) Date: Sun, 3 Oct 2004 16:55:56 -0400 (EDT) Subject: [Pw_forum] espresso compilation error IBM SP4 arch In-Reply-To: <20041003220159.32434.qmail@web60301.mail.yahoo.com> Message-ID: Thanks to all for clearing that up. In fact I was using a make.sys circa pw.1.2 and the below mentioned configure strategy. I had no trouble for each consecutive release until now. I guess you could say I got a little spoiled. Also I'm finding the espresso to be much faster for the neb calculations. Thanks again, Aaron On Sun, 3 Oct 2004, Eyvaz Isaev wrote: > Hi, > > In addition to Axel's comment. The best solution was > proposed by Kostya Kudin: > add -I$(OSHOME)/include to CPPFLAGS. > On some IBM machines where new "configure" does not > work, configuring a make.sys in old manner and then > adding aforemwntioned keyword works well. > > Bests, > Eyvaz. > > --- Axel Kohlmeyer > wrote: > > > > > On Sat, 2 Oct 2004 aaron at nemo.physics.ncsu.edu > > wrote: > > > > A> Hi All, Carlo, > > A> > > A> Thanks very much for the help. I was able to > > move past that point with > > A> your file parser.f90. Now I'm stuck again, but I > > really want the > > A> functionality I read about. > > A> > > A> Here's the error: > > A> > > A> > > > > > *********************************************************** > > A> > > > > > *********************************************************** > > A> > > A> cc > > -Wp,-D__AIX,-D__PARA,-D__MPI,-DHAS_ZHEGVX -O2 -c > > c_mkdir.c > > A> "c_mkdir.c", line 17.10: 1506-296 (S) #include > > file "c_defs.h" not found. > > A> make: 1254-004 The error code from the last > > command is 1. > > A> > > A> > > A> Stop. > > A> make: 1254-004 The error code from the last > > command is 2. > > A> > > A> > > A> Stop. > > A> > > A> > > > > > *********************************************************** > > A> > > > > > *********************************************************** > > A> > > A> Usually I would expect the c-compiler to find > > these ~.h files on its own. > > > > aaron, > > > > this is only true for (some of) the system headers. > > c_defs.h is part of > > the espresso package, and thus you have to make > > sure, that a) the IFLAGS > > definition contains -I../include and b) definition > > of CCFLAGS contains > > $(IFLAGS) so that the preprocessor knows how to find > > that file. > > > > regards, > > axel. > > > > A> > > A> I can really make use of the functionality to > > specify intermediate images > > A> in the NEB. > > A> > > A> Thanks > > A> > > A> Aaron > > A> > > A> On > > A> Fri, 1 Oct 2004, carlo sbraccia wrote: > > A> > > A> > Dear Aaron, > > A> > with some version of the AIX compiler, some > > combination of flags lead to > > A> > variables being defined as static, hence giving > > a conflict with PURE > > A> > function. To solve the problem (or compiler > > bug) we must force the > > A> > variable to be AUTOMATIC. Try with the attached > > routine. > > A> > carlo > > A> > > > A> > On Fri, 2004-10-01 at 00:02, > > aaron at nemo.physics.ncsu.edu wrote: > > A> > > Hi, > > A> > > > > A> > > I'm very excited to try the new release. > > A> > > However I've run into a small compilation > > error as follows: > > A> > > > > A> > > > > > *********************************************************** > > A> > > mpxlf -qalias=noaryovrlp -I../include > > -O3 -qstrict -qarch=auto > > A> > > -qtune=auto -qsuffix=cpp=f90 -qdpc -Q > > -qalias=nointptr -qfree=f90 > > A> > > -I/tmp/work/amgeorge/pw2.1/install > > A> > > -WF,-D__AIX,-D__PARA,-D__MPI,-DHAS_ZHEGVX > > A> > > -I/tmp/work/amgeorge/pw2.1/Modules > > -I/tmp/work/amgeorge/pw2.1/PW > > A> > > -I/tmp/work/amgeorge/pw2.1/PH -c parser.f90 > > A> > > "parser.f90", 1514-286 (S) The variable, j, > > has the SAVE or STATIC > > A> > > attribute. A variable declared in a pure > > subprogram must not have the > > A> > > SAVE or STATIC attribute. You may have > > specified the SAVE option > > A> > > explicitly or by default. > > A> > > "parser.f90", 1514-286 (S) The variable, > > sep2, has the SAVE or STATIC > > A> > > attribute. A variable declared in a pure > > subprogram must not have the > > A> > > SAVE or STATIC attribute. You may have > > specified the SAVE option > > A> > > explicitly or by default. > > A> > > "parser.f90", 1514-286 (S) The variable, > > sep1, has the SAVE or STATIC > > A> > > attribute. A variable declared in a pure > > subprogram must not have the > > A> > > SAVE or STATIC attribute. You may have > > specified the SAVE option > > A> > > explicitly or by default. > > A> > > ** parser === End of Compilation 1 === > > A> > > > > > *********************************************************** > > A> > > > > > *********************************************************** > > A> > > > > A> > > Please advise. > > A> > > > > A> > > Thanks in advance, > > A> > > > > A> > > Aaron > > A> > > > > A> > > > > A> > > > > A> > > > > A> > > > > _______________________________________________ > > A> > > Pw_forum mailing list > > A> > > Pw_forum at pwscf.org > > A> > > > > http://www.democritos.it/mailman/listinfo/pw_forum > > A> > > > A> > > A> _______________________________________________ > > A> Pw_forum mailing list > > A> Pw_forum at pwscf.org > > A> > > http://www.democritos.it/mailman/listinfo/pw_forum > > A> > > A> > > > > -- > > > > > > > ======================================================================= > > Dr. Axel Kohlmeyer e-mail: > > axel.kohlmeyer at rub.de > > Lehrstuhl fuer Theoretische Chemie Phone: > > ++49 (0)234/32-26673 > > Ruhr-Universitaet Bochum - NC 03/53 Fax: > > ++49 (0)234/32-14045 > > D-44780 Bochum > > > http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ > > > ======================================================================= > > > > > > _______________________________________________ > > Pw_forum mailing list > > Pw_forum at pwscf.org > > http://www.democritos.it/mailman/listinfo/pw_forum > > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - 50x more storage than other providers! > http://promotions.yahoo.com/new_mail > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From mutombo at fzu.cz Mon Oct 4 22:40:17 2004 From: mutombo at fzu.cz (Pingo Mutombo) Date: Mon, 04 Oct 2004 16:40:17 -0400 Subject: [Pw_forum] espresso compilation error on PC (Xeon) In-Reply-To: <1096615702.3102.27.camel@dhpc-5-40.sissa.it> References: <1096615702.3102.27.camel@dhpc-5-40.sissa.it> Message-ID: <4161B531.9030307@fzu.cz> Hello, I am trying to compile the espresso package but I am getting the following message error: Can this be related to the code or to the Intel fortran compiler? Many thanks, Pingo home/crystal/espresso/include -I./ -nomodule -I /home/crystal/espresso/Modules -I/ home/crystal/espresso/PW -I/home/crystal/espresso/PH -c path_opt_routines.f90 ifort -Vaxlib -O2 -tpp6 -fpp -D__LINUX -D__INTEL -D__FFTW -D__USE_INTERNAL_FFTW -I/ home/crystal/espresso/include -I./ -nomodule -I /home/crystal/espresso/Modules -I/ home/crystal/espresso/PW -I/home/crystal/espresso/PH -c path_base.f90 0_9458 fortcom: Severe: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. in file (null), line 0, column 0 compilation aborted for path_base.f90 (code 3) make[1]: *** [path_base.o] Error 3 make[1]: Leaving directory `/home/crystal/espresso/Modules' make: *** [mods] Error 2 From sbraccia at sissa.it Mon Oct 4 16:45:52 2004 From: sbraccia at sissa.it (carlo sbraccia) Date: Mon, 04 Oct 2004 16:45:52 +0200 Subject: [Pw_forum] espresso compilation error on PC (Xeon) In-Reply-To: <4161B531.9030307@fzu.cz> References: <1096615702.3102.27.camel@dhpc-5-40.sissa.it> <4161B531.9030307@fzu.cz> Message-ID: <1096901152.3127.20.camel@dhpc-5-40.sissa.it> Dear Pingo, to compile the espresso package with the ifort compiler you need the latest version (8.1). Previous versions of this compiler have several bugs that prevent a successful compilation. carlo On Mon, 2004-10-04 at 22:40, Pingo Mutombo wrote: > Hello, > I am trying to compile the espresso package but I am getting the > following message error: > Can this be related to the code or to the Intel fortran compiler? > Many thanks, > Pingo > > home/crystal/espresso/include -I./ -nomodule -I > /home/crystal/espresso/Modules -I/ > home/crystal/espresso/PW -I/home/crystal/espresso/PH -c > path_opt_routines.f90 > ifort -Vaxlib -O2 -tpp6 -fpp -D__LINUX -D__INTEL -D__FFTW > -D__USE_INTERNAL_FFTW -I/ > home/crystal/espresso/include -I./ -nomodule -I > /home/crystal/espresso/Modules -I/ > home/crystal/espresso/PW -I/home/crystal/espresso/PH -c path_base.f90 > 0_9458 > > fortcom: Severe: **Internal compiler error: internal abort** Please > report this error along with the circumstances in which it occurred in a > Software Problem Report. Note: File and line given may not be explicit > cause of this error. > in file (null), line 0, column 0 > > compilation aborted for path_base.f90 (code 3) > make[1]: *** [path_base.o] Error 3 > make[1]: Leaving directory `/home/crystal/espresso/Modules' > make: *** [mods] Error 2 > > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Mon Oct 4 18:24:28 2004 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Mon, 4 Oct 2004 18:24:28 +0200 (CEST) Subject: [Pw_forum] .xsf format reader plugin for VMD available Message-ID: hello everybody, some of you may be interested to have access to an(other) alternative for visualizing results from PWScf (and other espresso package) caculations. i have just written a reader plugin for the VMD program (http://www.ks.uiuc.edu/Research/vmd/) that allows the direct import of files in the .xsf format (including 3d data grids, and cell vectors for periodic display). while VMD is not (yet) as good in handling periodic systems as, e.g., xcrysden, or very well suited for simply having a quick look at the results, it's flexible visualization facilities, its powerful atom selection mechanism and the ability to add arbitrary graphics to a visualization, make it very useful for visualizing and analysing results from electron structure or (CP- or BO-) MD calculations. since it will take some time until the next release of VMD will happen or updated plugins are available, i'd be willing to send out either sourcecode or a 32bit x86 linux binary (for VMD version 1.8.2) to anybody who is willing to help in testing it, so that the plugin in the next version of VMD will be as complete and as bug-free as possible. some examples for what can be done (originally created with examples from CPMD simulations, but of course applicable to PWScf and any related programs that can be interfaced as well.) are at: http://www.theochem.rub.de/~axel.kohlmeyer/cpmd-vmd/ any comments or suggestions are welcome. best regards, axel kohlmeyer. -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at rub.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= From proffess at yandex.ru Tue Oct 5 11:09:01 2004 From: proffess at yandex.ru (Sergey Lisenkov) Date: Tue, 5 Oct 2004 13:09:01 +0400 (MSD) Subject: [Pw_forum] Many tests failed on new platform Message-ID: <416264AD.000046.10726@tide.yandex.ru> Dear PWscf authors and users, I compiled new PWscf (espresso) package on IBM PPC970 cluster both in 32-bit and 64-bit mode. First, I tested the code on example03. The Aliminium test is passed succesfully, but CO example is not passed, convergence did not reach ( number of scf cycles = 50, number of bfgs steps = 1). It is very strange, because on other machines this test is passed. On my inputs, the results are the same. On my HP cluster code finished with results 44 scf sycles, 43 bfgs sycles, but on IBM PPC970 cluster this test did 520 scf sycles, 209 bfgs sycles, and did not finish. So, the question is, what is the problem? I checked all libraries (atlas, lapack, lapack3e, goto-blas, essl for fftw, local fftw) - the results are the same, only the time for calculation was changed. I used different optmization flags - it did not help. Any hints? Thanks a lot, Best wishes, Sergey From sbraccia at sissa.it Tue Oct 5 11:41:57 2004 From: sbraccia at sissa.it (carlo sbraccia) Date: Tue, 05 Oct 2004 11:41:57 +0200 Subject: [Pw_forum] Many tests failed on new platform In-Reply-To: <416264AD.000046.10726@tide.yandex.ru> References: <416264AD.000046.10726@tide.yandex.ru> Message-ID: <1096969316.2341.8.camel@dhpc-5-40.sissa.it> Dear Sergey, is BFGS optimization the only case in which you find this strange behaviour ? If this is the case, try to change in the header of the file Modules/basic_algebra_routines.f90 the line: #undef __NOBLAS with #define __NOBLAS Let me know if this makes some difference. carlo On Tue, 2004-10-05 at 11:09, Sergey Lisenkov wrote: > Dear PWscf authors and users, > > I compiled new PWscf (espresso) package on IBM PPC970 cluster both in 32-bit and 64-bit mode. First, I tested the code on example03. The Aliminium test is passed succesfully, but CO example is not passed, convergence did not reach ( number of scf cycles = 50, number of bfgs steps = 1). It is very strange, because on other machines this test is passed. > On my inputs, the results are the same. On my HP cluster code finished with results 44 scf sycles, 43 bfgs sycles, but on IBM PPC970 cluster this test did 520 scf sycles, 209 bfgs sycles, and did not finish. > > So, the question is, what is the problem? I checked all libraries (atlas, lapack, lapack3e, goto-blas, essl for fftw, local fftw) - the results are the same, only the time for calculation was changed. I used different optmization flags - it did not help. > > Any hints? > > Thanks a lot, > Best wishes, > Sergey > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum From proffess at yandex.ru Tue Oct 5 11:59:27 2004 From: proffess at yandex.ru (Sergey Lisenkov) Date: Tue, 5 Oct 2004 13:59:27 +0400 (MSD) Subject: [Pw_forum] Many tests failed on new platform In-Reply-To: <1096969316.2341.8.camel@dhpc-5-40.sissa.it> References: <416264AD.000046.10726@tide.yandex.ru> <1096969316.2341.8.camel@dhpc-5-40.sissa.it> Message-ID: <4162707F.000006.29929@colgate.yandex.ru> Dear Carlo, Thank you very much for your hints. I changed the file basic_algebra_routines.f90 but it does not help. May be, I should add anything else? Thanks, Sergey From sbraccia at sissa.it Tue Oct 5 12:24:54 2004 From: sbraccia at sissa.it (carlo sbraccia) Date: Tue, 05 Oct 2004 12:24:54 +0200 Subject: [Pw_forum] Many tests failed on new platform In-Reply-To: <4162707F.000006.29929@colgate.yandex.ru> References: <416264AD.000046.10726@tide.yandex.ru> <1096969316.2341.8.camel@dhpc-5-40.sissa.it> <4162707F.000006.29929@colgate.yandex.ru> Message-ID: <1096971894.2341.11.camel@dhpc-5-40.sissa.it> Dear Sergey, can you post me the output of example03 ? I'll try to understand where is the problem. carlo On Tue, 2004-10-05 at 11:59, Sergey Lisenkov wrote: > Dear Carlo, > > Thank you very much for your hints. I changed the file basic_algebra_routines.f90 > but it does not help. May be, I should add anything else? > > Thanks, > Sergey > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum From g0202429 at nus.edu.sg Wed Oct 6 16:15:49 2004 From: g0202429 at nus.edu.sg (Lee Tiong Seng Norman) Date: Wed, 6 Oct 2004 22:15:49 +0800 Subject: [Pw_forum] Installing PWSCF Message-ID: <49AEB33EA724D24B886C08FB7871645E101DBB@MBOX23.stu.nus.edu.sg> Hi I am having problems with installing PwSCF. I am using a Pentium 4 with Fedora Core 1. 1. With the following command, ./configure F90=g95 CC=gcc LIBDIRS="/home/norman/ATLAS/lib/Linux_P4SSE2 /home/norman/FFTW/fftw-2.1.5/fftw /usr/lib" CFLAGS="-lm -lg2c" the outcome is as follows checking build system type... i686-pc-linux-gnu checking architecture... linux32 checking for g95... g95 checking for Fortran 77 compiler default output file name... configure: error: Fortran 77 compiler cannot create executables See `config.log' for more details. 2. When I used F90=g77, it was successful, but after keying in "make all" the outcome was as follows.. (after a whole bunch of commands) ar: avrec.o: No such file or directory make[1]: *** [flib.a] Error 1 make[1]: Leaving directory `/home/norman/espresso/flib' make: *** [libs] Error 2 can anyone help? Much appreciated. Norman Lee National University of Singapore From swblelia at sw.ehu.es Wed Oct 6 16:19:30 2004 From: swblelia at sw.ehu.es (Aritz Leonardo) Date: Wed, 6 Oct 2004 16:19:30 +0200 Subject: [Pw_forum] execution error Message-ID: <002701c4abaf$81d4f420$9dace39e@swpx57> Hello: I wonder if you could help with an execution error of PWscf. I am performing a Lambda calculation for magnesium and whenever the output of nscf has more than 9999 k-points (see below) The program stops without aborting the process. Helpful data: I am running on a Alpha server GS1280 with 8 cpu-s 1,2 Ghz. 10Gb RAM and has Tru64 Unix 5.1 This is the error file. stty: tcgetattr: Not a typewriter forrtl: error (72): floating overflow 0: __FINI_00_remove_gp_range [0x3ff81a6de38] 1: __FINI_00_remove_gp_range [0x3ff81a76a20] 2: __FINI_00_remove_gp_range [0x3ff800d5b90] 3: WFCINIT_K ldreadst: WARNING iline index(817112) exceeds ilineMax(817112) forrtl: error (78): process killed (SIGTERM) 0: __FINI_00_remove_gp_range [0x3ff81a6de38] 1: __FINI_00_remove_gp_range [0x3ff81a772c0] 2: __FINI_00_remove_gp_range [0x3ff800d5b90] 3: __FINI_00_remove_gp_range [0x3ff81ac9bcc] 4: __FINI_00_remove_gp_range [0x3ff81aaf3c0] 5: __FINI_00_remove_gp_range [0x3ff81a6de38] 6: __FINI_00_remove_gp_range [0x3ff81a76a20] 7: __FINI_00_remove_gp_range [0x3ff800d5b90] 8: WFCINIT_K ldreadst: WARNING iline index(817112) exceeds ilineMax(817112) This is the output file of the non-self consistent calculus: k(9997) = ( 0.2777778 -0.4169752 0.0000000), wk = 0.0003429 k(9998) = ( 0.4444445 -0.0641500 0.1026905), wk = 0.0000000 k(9999) = ( -0.2777778 -0.4169752 0.0000000), wk = 0.0003429 k(****) = ( -0.1111111 -0.0641500 0.1026905), wk = 0.0000000 k(****) = ( 0.5000000 -0.0320750 0.0000000), wk = 0.0003429 k(****) = ( 0.6666667 0.3207502 0.1026905), wk = 0.0000000 Thank you very much!! Aritz Leonardo ---> swblelia at sw.ehu.es Phd, student at Donostia International Physics Center phone (+34) 943015626) -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20041006/8912f683/attachment.htm From FB153746 at ATIL.CEA.FR Thu Oct 7 09:15:44 2004 From: FB153746 at ATIL.CEA.FR (=?iso-8859-1?Q?BOUYER_Fr=E9d=E9ric_153746?=) Date: Thu, 7 Oct 2004 09:15:44 +0200 Subject: [Pw_forum] Compilation troubles on PC/linux Message-ID: <884193C06D478A4B97B5212C8120A501DC4E0C@atil.intra.cea.fr> Dear All, Sorry to be boring with such question about compilation, but I installed yesterday the version 8.1 of the ifort intel compiler (on a PC/Xeon Linux RedHat 9), and have always the error message : ifort: error : could not find directory on which g++ resides and the compilation cannot begin. Does anybody have encounter this problem (environment variables to set, ...) ? Many thanks in advance for any replies that could help me. Fr?d?ric -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20041007/a9d16f83/attachment.htm From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Thu Oct 7 09:36:38 2004 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Thu, 7 Oct 2004 09:36:38 +0200 (CEST) Subject: [Pw_forum] Installing PWSCF In-Reply-To: <49AEB33EA724D24B886C08FB7871645E101DBB@MBOX23.stu.nus.edu.sg> Message-ID: On Wed, 6 Oct 2004, Lee Tiong Seng Norman wrote: NL> Hi NL> NL> I am having problems with installing PwSCF. I am using a Pentium 4 with Fedora Core 1. NL> NL> 1. With the following command, NL> NL> ./configure F90=g95 CC=gcc LIBDIRS="/home/norman/ATLAS/lib/Linux_P4SSE2 /home/norman/FFTW/fftw-2.1.5/fftw /usr/lib" CFLAGS="-lm -lg2c" NL> NL> the outcome is as follows NL> NL> checking build system type... i686-pc-linux-gnu NL> checking architecture... linux32 NL> checking for g95... g95 NL> checking for Fortran 77 compiler default output file name... configure: error: Fortran 77 compiler cannot create executables NL> See `config.log' for more details. hi, this is probably not a problem of the fortran 77 compiler, but the result of some incompatible library or linker flags. please check out the config.log file as suggested. if you have trouble with the atlas library, you may want to check out the libraries i have put up for download at: http:/www.theochem.rub.de/~axel.kohlmeyer/cpmd-linux.html#atlas these libraries contain the full BLAS/LAPACK/ATLAS and are built specially, so that they are compatible to _any_ current fortran compiler currently avaible for linux. to have the configure script recognize them, however, you have to emulate a full ATLAS install via creating symlinks for libf77blas.a, liblapack.a, libcblas.a, and libatlas.a. e.g. like this ls -l ~/lib/ lrwxrwxrwx 1 akohlmey theochem 17 Sep 19 16:37 libatlas.a -> libatlas_athlon.a lrwxrwxrwx 1 akohlmey theochem 10 Jul 1 09:32 libblas.a -> libatlas.a lrwxrwxrwx 1 akohlmey theochem 10 Jul 1 09:32 libcblas.a -> libatlas.a lrwxrwxrwx 1 akohlmey theochem 10 Jul 1 09:32 libf77blas.a -> libatlas.a lrwxrwxrwx 1 akohlmey theochem 10 Jul 1 09:32 liblapack.a -> libatlas.a NL> 2. When I used F90=g77, it was successful, but after keying in "make all" the outcome was as follows.. NL> NL> (after a whole bunch of commands) NL> ar: avrec.o: No such file or directory NL> make[1]: *** [flib.a] Error 1 NL> make[1]: Leaving directory `/home/norman/espresso/flib' NL> make: *** [libs] Error 2 NL> NL> can anyone help? Much appreciated. espresso needs a usable fortran 90/95 compiler. i doubt that g95 in anywhere near what is needed. g77 does not understand fortran 90/95 at all (but it can compile simple free format fortran programs which is why the configure does not barf). you can get a personal, unsupported, non-commercial license for the intel compiler (version 8.1 works nicely) free of charge. you should then also register for premier support (which is also free of charge for a year) to get access to updated versions and an x86_64 (a.k.a. E64MT) version for athlon64/opteron machines. if you just want to try it out, i do occasionally create linux binaries for a few colleagus and put them at http://ftp.theochem.rub.de/outgoing/axel_kohlmeyer/pwscf-bin/ feel free to download them, but don't expect me to fix them, if they don't work for you. they may have some additional changes that i need, but are not (yet) in the official espresso version. regards, axel kohlmeyer. NL> NL> Norman Lee NL> National University of Singapore NL> NL> _______________________________________________ NL> Pw_forum mailing list NL> Pw_forum at pwscf.org NL> http://www.democritos.it/mailman/listinfo/pw_forum NL> NL> -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at rub.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= From g.ballabio at cineca.it Thu Oct 7 11:01:03 2004 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Thu, 7 Oct 2004 11:01:03 +0200 (MEST) Subject: [Pw_forum] Installing PWSCF In-Reply-To: References: Message-ID: <1097139663.13453.35.camel@localhost.localdomain> On Thu, 2004-10-07 at 09:36, Axel Kohlmeyer wrote: > On Wed, 6 Oct 2004, Lee Tiong Seng Norman wrote: > NL> ./configure F90=g95 CC=gcc LIBDIRS="/home/norman/ATLAS/lib/Linux_P4SSE2 /home/norman/FFTW/fftw-2.1.5/fftw /usr/lib" CFLAGS="-lm -lg2c" > NL> > NL> the outcome is as follows > NL> > NL> checking build system type... i686-pc-linux-gnu > NL> checking architecture... linux32 > NL> checking for g95... g95 > NL> checking for Fortran 77 compiler default output file name... configure: error: Fortran 77 compiler cannot create executables > NL> See `config.log' for more details. > > this is probably not a problem of the fortran 77 compiler, but > the result of some incompatible library or linker flags. Actually, if configure stops this early, that's definitely a problem of the fortran compiler. Your g95 seems not to be working correctly. > NL> 2. When I used F90=g77, it was successful, but after keying in "make all" the outcome was as follows.. > NL> > NL> (after a whole bunch of commands) > NL> ar: avrec.o: No such file or directory > NL> make[1]: *** [flib.a] Error 1 > NL> make[1]: Leaving directory `/home/norman/espresso/flib' > NL> make: *** [libs] Error 2 > NL> > NL> can anyone help? Much appreciated. > > espresso needs a usable fortran 90/95 compiler. i doubt that > g95 in anywhere near what is needed. In fact, g95 is capable to build PWscf/ESPRESSO and has been for a few months. However the best supported compiler is Intel's, for a safe bet you should go with it. Gerardo From g.ballabio at cineca.it Thu Oct 7 11:01:07 2004 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Thu, 7 Oct 2004 11:01:07 +0200 (MEST) Subject: [Pw_forum] Installing PWSCF In-Reply-To: References: Message-ID: <1097139663.13453.37.camel@localhost.localdomain> On Thu, 2004-10-07 at 09:36, Axel Kohlmeyer wrote: > On Wed, 6 Oct 2004, Lee Tiong Seng Norman wrote: > NL> ./configure F90=g95 CC=gcc LIBDIRS="/home/norman/ATLAS/lib/Linux_P4SSE2 /home/norman/FFTW/fftw-2.1.5/fftw /usr/lib" CFLAGS="-lm -lg2c" > NL> > NL> the outcome is as follows > NL> > NL> checking build system type... i686-pc-linux-gnu > NL> checking architecture... linux32 > NL> checking for g95... g95 > NL> checking for Fortran 77 compiler default output file name... configure: error: Fortran 77 compiler cannot create executables > NL> See `config.log' for more details. > > this is probably not a problem of the fortran 77 compiler, but > the result of some incompatible library or linker flags. Actually, if configure stops this early, that's definitely a problem of the fortran compiler. Your g95 seems not to be working correctly. > NL> 2. When I used F90=g77, it was successful, but after keying in "make all" the outcome was as follows.. > NL> > NL> (after a whole bunch of commands) > NL> ar: avrec.o: No such file or directory > NL> make[1]: *** [flib.a] Error 1 > NL> make[1]: Leaving directory `/home/norman/espresso/flib' > NL> make: *** [libs] Error 2 > NL> > NL> can anyone help? Much appreciated. > > espresso needs a usable fortran 90/95 compiler. i doubt that > g95 in anywhere near what is needed. In fact, g95 is capable to build PWscf/ESPRESSO and has been for a few months. However the best supported compiler is Intel's, for a safe bet you should go with it. Gerardo From cjtan at OptimaNumerics.com Thu Oct 7 14:00:08 2004 From: cjtan at OptimaNumerics.com (C J Kenneth Tan -- OptimaNumerics) Date: Thu, 7 Oct 2004 12:00:08 +0000 (UTC) Subject: [Pw_forum] [Announcement] CFP: ICCSA 2005: Technical Session on Molecular Structures and Processes Message-ID: ICCSA2005 2005 International Conference on Computational Science and its Applications Singapore, May 09-12, 2005 http://www.iccsa.org TECHNICAL SESSION ON MOLECULAR STRUCTURES AND PROCESSES We are organizing a technical session on "Molecular Structures and Processes" at the ICCSA-2005 to be held in Singapore on May 09-12. You are cordially invited to SUBMIT a SHORT PAPER (from 6 to 10 pages Letter or A4 format) for oral presentation. The paper should contain new unpublished results and will appear (after passing the standard reviewing process) in a special issue of "Lecture Notes in Computer Science" (LNCS), Springer-Verlag, that will be delivered at the Conference. The DEADLINE for the submission of the paper is December 10. Editing information and other details can be obtained from the iccsa2005 web site. The paper should be submitted in the camera-ready format of Lecture Notes in Computer Science (http://www.springer.de/comp/lncs/authors.html) The motivation for organizing a technical session on this subject stems out from the fact that the increased capability of integrating electronic structure, dynamics, kinetics, fluid dynamics, electrodynamics and statistical treatments to reproduce observable properties and thermodynamics quantities has made > computational chemistry an important test bed for innovative computational tools and enviroments. The technical session will represent a high level forum for exchanging information and ideas about computational molecular sciences and the use of modern computing technologies to support the advance in research, applications and educational tools in several innovative fields. 2. Important Dates and contact information Paper submission deadline : December 10, 2004 Notification of acceptance : January 10, 2005 Camera ready papers and Pre-registration: February 10, 2005 ICCSA 2005 Conference : May 09-12, 2005 For further details please contact noelia at dyn.unipg.it or Prof. Antonio Lagana' at the address below Prof. Antonio Lagana' Department of Chemistry University of Perugia Via Elce di Sotto, 8 06123, Perugia Italy e-mail: noelia at dyn.unipg.it tel: +39 075 585 5527 fax: +39 075 585 5606 From eyvaz_isaev at yahoo.com Thu Oct 7 15:48:41 2004 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Thu, 7 Oct 2004 06:48:41 -0700 (PDT) Subject: [Pw_forum] Compilation troubles on PC/linux In-Reply-To: <884193C06D478A4B97B5212C8120A501DC4E0C@atil.intra.cea.fr> Message-ID: <20041007134841.74071.qmail@web60303.mail.yahoo.com> Dear Frederic, Did you try IFC v.8.0 or earlier version? May be it is due to compiler error? Just enter g++ and it should work replying "no input file". If you got another reply (file not found) that means you have no installed g++ or it is installed not properly. Best regards, Eyvaz. --- BOUYER Fr?d?ric 153746 wrote: > Dear All, > > Sorry to be boring with such question about > compilation, but I installed > yesterday the version 8.1 of the ifort intel > compiler (on a PC/Xeon Linux > RedHat 9), and have always the error message : > > ifort: error : could not find directory on which g++ > resides > > and the compilation cannot begin. > > Does anybody have encounter this problem > (environment variables to set, ...) > ? Many thanks in advance for any replies that could > help me. > > Fr?d?ric > __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From FB153746 at ATIL.CEA.FR Thu Oct 7 15:58:20 2004 From: FB153746 at ATIL.CEA.FR (=?iso-8859-1?Q?BOUYER_Fr=E9d=E9ric_153746?=) Date: Thu, 7 Oct 2004 15:58:20 +0200 Subject: [Pw_forum] Compilation troubles on PC/linux Message-ID: <884193C06D478A4B97B5212C8120A501DC4E0F@atil.intra.cea.fr> I had information on the site of Intel directly (softwareforums.intel.com ...). Since the package has to work with the ifort 8.1, it could be useful to have this information. If anyone has the following error message : Ifort : error : cannot find the directory in which g++ resides One can do : unsetenv LANG. And it is running ! Incredible, but so. The whole ESPRESSO has been compiled, and I have to work on it ... Hope this will help. Fr?d?ric PS: of course, the g++ is installed, and works. It is a known problem at Intel ... -----Message d'origine----- De?: pw_forum-admin at pwscf.org [mailto:pw_forum-admin at pwscf.org] De la part de Eyvaz Isaev Envoy??: jeudi 7 octobre 2004 15:49 ??: pw_forum at pwscf.org Objet?: Re: [Pw_forum] Compilation troubles on PC/linux Dear Frederic, Did you try IFC v.8.0 or earlier version? May be it is due to compiler error? Just enter g++ and it should work replying "no input file". If you got another reply (file not found) that means you have no installed g++ or it is installed not properly. Best regards, Eyvaz. --- BOUYER Fr?d?ric 153746 wrote: > Dear All, > > Sorry to be boring with such question about > compilation, but I installed > yesterday the version 8.1 of the ifort intel > compiler (on a PC/Xeon Linux > RedHat 9), and have always the error message : > > ifort: error : could not find directory on which g++ > resides > > and the compilation cannot begin. > > Does anybody have encounter this problem > (environment variables to set, ...) > ? Many thanks in advance for any replies that could > help me. > > Fr?d?ric > __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail _______________________________________________ Pw_forum mailing list Pw_forum at pwscf.org http://www.democritos.it/mailman/listinfo/pw_forum From ganapati_natarajan at yahoo.co.uk Fri Oct 8 12:03:45 2004 From: ganapati_natarajan at yahoo.co.uk (Ganapati Natarajan) Date: Fri, 8 Oct 2004 11:03:45 +0100 (BST) Subject: [Pw_forum] vc-relax Message-ID: <20041008100345.132.qmail@web86908.mail.ukl.yahoo.com> Dear users, I am trying to use the vc-relax option to optimise the cell parameters for silicon. But in the output file there are no updated cell parameters or atomic positions. Please explain how to get these. Thanks, Gana My input file is: &control calculation = 'vc-relax' restart_mode ='from_scratch', prefix='silicon', tstress = .true. tprnfor = .true. pseudo_dir = '...' outdir= '...' / &system ibrav= 2, celldm(1) =15.20, nat= 2, ntyp= 1, ecutwfc =18.0, / &electrons mixing_mode = 'plain' mixing_beta = 0.7 conv_thr = 1.0d-8 / &ions ion_dynamics='damp' / &cell cell_dynamics='damp-pr' wmass=1.0 press=0.001 / ATOMIC_SPECIES Si 28.086 Si.vbc.UPF ATOMIC_POSITIONS crystal Si 0.00 0.00 0.00 Si 0.25 0.25 0.25 K_POINTS 10 0.1250000 0.1250000 0.1250000 1.00 0.1250000 0.1250000 0.3750000 3.00 0.1250000 0.1250000 0.6250000 3.00 0.1250000 0.1250000 0.8750000 3.00 0.1250000 0.3750000 0.3750000 3.00 0.1250000 0.3750000 0.6250000 6.00 0.1250000 0.3750000 0.8750000 6.00 0.1250000 0.6250000 0.6250000 3.00 0.3750000 0.3750000 0.3750000 1.00 0.3750000 0.3750000 0.6250000 3.00 A sample of my output is as follows: ! total energy = -15.84452726 ryd estimated scf accuracy < 2.6E-11 ryd convergence has been achieved Forces acting on atoms (Ry/au): atom 1 type 1 force = 0.00000000 0.00000000 0.00000000 atom 2 type 1 force = 0.00000000 0.00000000 0.00000000 Total force = 0.000000 Total SCF correction = 0.000000 entering subroutine stress ... total stress (ryd/bohr**3) (kbar) P= -10.24 -0.00006964 0.00000000 0.00000000 -10.24 0.00 0.00 0.00000000 -0.00006964 0.00000000 0.00 -10.24 0.00 0.00000000 0.00000000 -0.00006964 0.00 0.00 -10.24 NEW-OLD atomic charge density approx. for the potential NEW K-POINTS 0.1250000 0.1250000 0.1250000 0.0625000 0.1250000 0.1250000 0.3750000 0.1875000 0.1250000 0.1250000 0.6250000 0.1875000 0.1250000 0.1250000 0.8750000 0.1875000 0.1250000 0.3750000 0.3750000 0.1875000 0.1250000 0.3750000 0.6250000 0.3750000 0.1250000 0.3750000 0.8750000 0.3750000 0.1250000 0.6250000 0.6250000 0.1875000 0.3750000 0.3750000 0.3750000 0.0625000 0.3750000 0.3750000 0.6250000 0.1875000 total cpu time spent up to now is 37.29 secs ___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com From giacomo.saielli at unipd.it Fri Oct 8 18:17:48 2004 From: giacomo.saielli at unipd.it (Giacomo Saielli) Date: Fri, 08 Oct 2004 18:17:48 +0200 Subject: [Pw_forum] pseudopotential for ions Message-ID: <4166BDAC.802@unipd.it> An HTML attachment was scrubbed... URL: /pipermail/attachments/20041008/8cd6c230/attachment.htm From baroni at sissa.it Sat Oct 9 09:21:21 2004 From: baroni at sissa.it (Stefano Baroni) Date: Sat, 9 Oct 2004 09:21:21 +0200 Subject: [Pw_forum] pseudopotential for ions In-Reply-To: <4166BDAC.802@unipd.it> References: <4166BDAC.802@unipd.it> Message-ID: Giacomo: if the pp is good (technically, one says "transferable") it is supposed to work in any "reasonable" chemical environment. That's what pp's are designed for! On the other hand, if a given complex turns out to be charged or not, it is not you who decide, but the charge rearrangement determined by self consistency. Of course, the pp is an input o such a procedure, and it cannot be made depend on the output! In summary, read some literature (even old one) on on pp's, and then enjoy your simulations! Yours Stefano B. On Oct 8, 2004, at 6:17 PM, Giacomo Saielli wrote: > Dear developers and users, > I am planning to run a Car-Parrinello simulation with cp.x module > using Vanderbilt PP for a system containing some water and > acetonitrile molecules plus one charged tetramethylammonium ion.? I > wonder if there could be any problem in using the same PPs I use for > the atoms of the neutral molecules also for the atoms of the charged > TMA ion, or if I should build special ultrasoft PPs for the TMA atoms. > I would appreciate any comment on this. > Thank you very much, > best wishes, > Giacomo > > -- > Giacomo Saielli > Istituto per la Tecnologia delle Membrane del CNR, Sezione di Padova; > Via Marzolo, 1 - 35131 Padova, Italy; > Tel: +39-049-8275279; Fax: -5239; > http://www.chfi.unipd.it/home/g.saielli/ > > _______________________________________________ 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) Please, if possible, don't send me MS Word or PowerPoint attachments Why? See: http://www.gnu.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1834 bytes Desc: not available Url : /pipermail/attachments/20041009/bdb724b1/attachment.bin From fsoyalp at yyu.edu.tr Mon Oct 11 20:05:34 2004 From: fsoyalp at yyu.edu.tr (Fethi SOYALP) Date: Mon, 11 Oct 2004 21:05:34 +0300 (EEST) Subject: [Pw_forum] k-points for band structure Message-ID: <32816.194.27.35.62.1097517934.squirrel@194.27.35.62> Dear PWSCF users, I want to calculate band structure of a fcc system I have a problem about k-points. I want to generate high symmetry directions k-points for example W X Gama L W K Gama is there a program to generate k-points for band structure regards, Fethi From adrainzhou at yahoo.com.cn Tue Oct 12 07:08:43 2004 From: adrainzhou at yahoo.com.cn (Adrain Zhou) Date: Tue, 12 Oct 2004 13:08:43 +0800 (CST) Subject: [Pw_forum] Compiling problems on AMD opteron64 under Linux using MPI Message-ID: <20041012050843.98484.qmail@web15807.mail.cnb.yahoo.com> Dear all, I tried to load pwscf on AMD opteron 64 machine under linux. I have obtained a serial executable successfully. But I met the following problems when using MPI. pgf90-Warning-Unknown switch: -pthread PGF90-S-0038-Symbol, mpi_real8, has not been explicitly declared (broadcast.F90) 0 inform, 0 warnings, 1 severes, 0 fatal for broadcast make[1]: *** [broadcast.o] Error 2 Here is the make.sys I used, CPPFLAGS = -D__LINUX64 -D__PGI -D__PARA -D_MPI -D_LAM -D__FFTW -D__USE_INTERNAL_FFTW \ -I$(OSHOME)/include -I./ # # Fortran compiler: F90 = mpif90 F77 = mpif77 CC = mpicc # # Please note: -r8 is necessary for numerical stability .. # F90FLAGS = -fast -r8 F77FLAGS = -fast -r8 CCFLAGS = $(CPPFLAGS) Many thanks in advance. Regards, Adrain --------------------------------- Do You Yahoo!? 150??MP3???????????? ??????????????????? 1G??1000??????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20041012/bb1f5822/attachment.htm From marzari at mit.edu Tue Oct 12 07:55:04 2004 From: marzari at mit.edu (Nicola Marzari) Date: Tue, 12 Oct 2004 01:55:04 -0400 Subject: [Pw_forum] Compiling problems on AMD opteron64 under Linux using MPI In-Reply-To: <20041012050843.98484.qmail@web15807.mail.cnb.yahoo.com> References: <20041012050843.98484.qmail@web15807.mail.cnb.yahoo.com> Message-ID: <1097560504.3952.3.camel@localhost.localdomain> Not sure if this is relevant, but does mpif.h include real8 ? mpif.h can be found in /usr/local/include or /usr/include, and we found (for dual Xeon, lam-mpi) that we needed to add real8 in there, as in: integer MPI_INTEGER, MPI_REAL, MPI_DOUBLE_PRECISION integer MPI_REAL8 integer MPI_COMPLEX, MPI_LOGICAL, MPI_CHARACTER and parameter (MPI_REAL=12) parameter (MPI_REAL8=13) parameter (MPI_DOUBLE_PRECISION=13) parameter (MPI_COMPLEX=14) nicola On Tue, 2004-10-12 at 01:08, Adrain Zhou wrote: > Dear all, > > I tried to load pwscf on AMD opteron 64 machine under linux. I have > obtained a serial executable successfully. But I met the following > problems when using MPI. > > pgf90-Warning-Unknown switch: -pthread > PGF90-S-0038-Symbol, mpi_real8, has not been explicitly declared > (broadcast.F90) > 0 inform, 0 warnings, 1 severes, 0 fatal for broadcast > make[1]: *** [broadcast.o] Error 2 > > Here is the make.sys I used, > CPPFLAGS = -D__LINUX64 -D__PGI -D__PARA -D_MPI -D_LAM -D__FFTW > -D__USE_INTERNAL_FFTW \ > -I$(OSHOME)/include -I./ > # > # Fortran compiler: > F90 = mpif90 > F77 = mpif77 > CC = mpicc > # > # Please note: -r8 is necessary for numerical stability .. > # > F90FLAGS = -fast -r8 > F77FLAGS = -fast -r8 > CCFLAGS = $(CPPFLAGS) > > Many thanks in advance. > > Regards, > Adrain > > > > ______________________________________________________________________ > Do You Yahoo!? > 150??MP3???????????? > ??????????????????? > 1G??1000??????????? -- --------------------------------------------------------------------- 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 axel.kohlmeyer at theochem.ruhr-uni-bochum.de Tue Oct 12 09:16:26 2004 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Tue, 12 Oct 2004 09:16:26 +0200 (CEST) Subject: [Pw_forum] Compiling problems on AMD opteron64 under Linux using MPI In-Reply-To: <20041012050843.98484.qmail@web15807.mail.cnb.yahoo.com> Message-ID: On Tue, 12 Oct 2004, Adrain Zhou wrote: AZ> Dear all, hello (again) adrain, AZ> AZ> I tried to load pwscf on AMD opteron 64 machine under linux. I have obtained a serial executable successfully. But I met the following problems when using MPI. it would help A LOT, if you could state, _which_ version of PWScf you are trying to compile. AZ> pgf90-Warning-Unknown switch: -pthread ^^^^^^^^^ this indicates, that you are using LAM-MPI and your lam binaries were compiled with threading, but also with g77 as the default compiler and not the pgi compiler, but are using export LAMHF77=pgf90 to use pgi instead of g77. am i right? so it would probably be better to use either a lam-mpi package which uses pgf90 (not pgf77!!) as fortran compiler or recompile with threading disabled and FFLAGS=-fno-second-underscore so that you can link properly. ready to use RPMS, that are compiled that way (but also a source RPM) with added wrapper scripts to automatically pick up the corresponding compiler are at: http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/cpmd-linux.html#mpi AZ> PGF90-S-0038-Symbol, mpi_real8, has not been explicitly declared (broadcast.F90) AZ> 0 inform, 0 warnings, 1 severes, 0 fatal for broadcast AZ> make[1]: *** [broadcast.o] Error 2 ok, it seems that you are using pwscf 2.0.x. try putting #include "machine.h" as the first line into the file PW/broadcast.f90 you may also want to try new version 2.1 instead. axel. AZ> Here is the make.sys I used, AZ> CPPFLAGS = -D__LINUX64 -D__PGI -D__PARA -D_MPI -D_LAM -D__FFTW -D__USE_INTERNAL_FFTW \ AZ> -I$(OSHOME)/include -I./ AZ> # AZ> # Fortran compiler: AZ> F90 = mpif90 AZ> F77 = mpif77 AZ> CC = mpicc AZ> # AZ> # Please note: -r8 is necessary for numerical stability .. AZ> # AZ> F90FLAGS = -fast -r8 AZ> F77FLAGS = -fast -r8 AZ> CCFLAGS = $(CPPFLAGS) AZ> AZ> Many thanks in advance. AZ> AZ> Regards, AZ> Adrain AZ> AZ> AZ> AZ> --------------------------------- AZ> Do You Yahoo!? AZ> 150????MP3???????????????????????? AZ> ?????????????????????????????????????? AZ> 1G????1000?????????????????????? -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at rub.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= From adrainzhou at yahoo.com.cn Wed Oct 13 03:38:36 2004 From: adrainzhou at yahoo.com.cn (Adrain Zhou) Date: Wed, 13 Oct 2004 09:38:36 +0800 (CST) Subject: [Pw_forum] Compiling problems on AMD opteron64 under Linux using MPI Message-ID: <20041013013836.89999.qmail@web15802.mail.cnb.yahoo.com> Dear all, Many thanks to Axel and Nicola . The former problem has been solved. But I met the following new problems at linking stages. ..... ..... : undefined reference to `mpi_barrier_' init_pool.o(.text+0x74): In function `init_pool_': : undefined reference to `mpi_comm_split_' init_pool.o(.text+0xaf): In function `init_pool_': : undefined reference to `mpi_barrier_' init_pool.o(.text+0xeb): In function `init_pool_': : undefined reference to `mpi_comm_split_' init_us_1.o(.text+0x2783): In function `init_us_1_': : undefined reference to `dscal__' interpolate.o(.text+0x2087): In function `cinterpolate_': : undefined reference to `zcopy__' interpolate.o(.text+0x2617): In function `cinterpolate_': : undefined reference to `zcopy__' invmat.o(.text+0x57): In function `invmat_': : undefined reference to `dcopy__' invmat.o(.text+0x75): In function `invmat_': : undefined reference to `dgetrf__' invmat.o(.text+0xcf): In function `invmat_': : undefined reference to `dgetri__' irrek.o(.text+0xee4): In function `irrek_': : undefined reference to `dscal__' maximum.o(.text+0x17): In function `extreme_': : undefined reference to `mpi_barrier_' maximum.o(.text+0x49): In function `extreme_': : undefined reference to `mpi_allreduce_' maximum.o(.text+0x78): In function `extreme_': : undefined reference to `mpi_allreduce_' mix_pot.o(.text+0x243): In function `mix_potential_': : undefined reference to `dnrm2__' mix_pot.o(.text+0xcd5): In function `mix_potential_': : undefined reference to `dnrm2__' mix_pot.o(.text+0xd50): In function `mix_potential_': : undefined reference to `dscal__' mix_pot.o(.text+0xd9f): In function `mix_potential_': : undefined reference to `dscal__' mix_pot.o(.text+0xf9f): In function `mix_potential_': : undefined reference to `dcopy__' mix_pot.o(.text+0x1098): In function `mix_potential_': : undefined reference to `ddot__' mix_pot.o(.text+0x119b): In function `mix_potential_': : undefined reference to `dsytrf__' mix_pot.o(.text+0x11f9): In function `mix_potential_': : undefined reference to `dsytri__' mix_pot.o(.text+0x1606): In function `mix_potential_': : undefined reference to `ddot__' mix_pot.o(.text+0x1b94): In function `mix_potential_': : undefined reference to `dcopy__' mix_pot.o(.text+0x1bcd): In function `mix_potential_': : undefined reference to `dcopy__' mix_rho.o(.text+0x2866): In function `mix_rho_': : undefined reference to `dcopy__' mix_rho.o(.text+0x2e20): In function `mix_rho_': : undefined reference to `daxpy__' mix_rho.o(.text+0x308d): In function `mix_rho_': : undefined reference to `daxpy__' mix_rho.o(.text+0x30ec): In function `mix_rho_': : undefined reference to `daxpy__' mix_rho.o(.text+0x3174): In function `mix_rho_': : undefined reference to `daxpy__' mix_rho.o(.text+0x31ed): In function `mix_rho_': : undefined reference to `daxpy__' mix_rho.o(.text+0x376a): In function `mix_rho_': : undefined reference to `dcopy__' mix_rho.o(.text+0x37a8): In function `mix_rho_': : undefined reference to `dcopy__' mix_rho.o(.text+0x37fe): In function `mix_rho_': : undefined reference to `dcopy__' mix_rho.o(.text+0x3845): In function `mix_rho_': : undefined reference to `dcopy__' mix_rho.o(.text+0x39b7): In function `mix_rho_': : undefined reference to `dsytrf__' mix_rho.o(.text+0x3a15): In function `mix_rho_': : undefined reference to `dsytri__' mix_rho.o(.text+0x4058): In function `mix_rho_': : undefined reference to `daxpy__' mix_rho.o(.text+0x40d3): In function `mix_rho_': : undefined reference to `daxpy__' mix_rho.o(.text+0x4170): In function `mix_rho_': : undefined reference to `daxpy__' mix_rho.o(.text+0x41f9): In function `mix_rho_': : undefined reference to `daxpy__' mix_rho.o(.text+0x43eb): In function `mix_rho_': : undefined reference to `dcopy__' mix_rho.o(.text+0x445e): In function `mix_rho_': : undefined reference to `dcopy__' mix_rho.o(.text+0x450d): In function `mix_rho_': : undefined reference to `dcopy__' mix_rho.o(.text+0x4565): In function `mix_rho_': : undefined reference to `dcopy__' mix_rho.o(.text+0x4640): In function `mix_rho_': : undefined reference to `daxpy__' mix_rho.o(.text+0x4ba0): In function `mix_rho_': : undefined reference to `daxpy__' mix_rho.o(.text+0x4c12): In function `mix_rho_': : undefined reference to `daxpy__' mix_rho.o(.text+0x7630): In function `approx_screening2_': : undefined reference to `dscal__' mix_rho.o(.text+0x906a): In function `approx_screening2_': : undefined reference to `dcopy__' mix_rho.o(.text+0x90af): In function `approx_screening2_': : undefined reference to `dsytrf__' mix_rho.o(.text+0x910d): In function `approx_screening2_': : undefined reference to `dsytri__' mix_rho.o(.text+0x9a4b): In function `approx_screening2_': : undefined reference to `daxpy__' mix_rho.o(.text+0x9ac1): In function `approx_screening2_': : undefined reference to `daxpy__' move_ions.o(.text+0x1a6a): In function `new_force_': : undefined reference to `ddot__' move_ions.o(.text+0x1aae): In function `new_force_': : undefined reference to `daxpy__' move_ions.o(.text+0x1ada): In function `new_force_': : undefined reference to `ddot__' move_ions.o(.text+0x1b68): In function `new_force_': : undefined reference to `ddot__' move_ions.o(.text+0x22a9): In function `check_constrain_': : undefined reference to `daxpy__' new_ns.o(.text+0xd65): In function `new_ns_': : undefined reference to `ddot__' new_ns.o(.text+0xebc): In function `new_ns_': : undefined reference to `zdotc__' newd.o(.text+0x13a1): In function `newd_': : undefined reference to `ddot__' poolbcast.o(.text+0x28): In function `poolbcast_': : undefined reference to `mpi_barrier_' poolbcast.o(.text+0x48): In function `poolbcast_': : undefined reference to `mpi_bcast_' poolextreme.o(.text+0x24): In function `poolextreme_': : undefined reference to `mpi_barrier_' poolextreme.o(.text+0x75): In function `poolextreme_': : undefined reference to `mpi_allreduce_' poolextreme.o(.text+0xc8): In function `poolextreme_': : undefined reference to `mpi_allreduce_' poolrecover.o(.text+0x95): In function `poolrecover_': : undefined reference to `mpi_barrier_' poolrecover.o(.text+0xe1): In function `poolrecover_': : undefined reference to `mpi_send_' poolrecover.o(.text+0x1de): In function `poolrecover_': : undefined reference to `mpi_recv_' poolrecover.o(.text+0x2c5): In function `ipoolrecover_': : undefined reference to `mpi_barrier_' poolrecover.o(.text+0x311): In function `ipoolrecover_': : undefined reference to `mpi_send_' poolrecover.o(.text+0x40e): In function `ipoolrecover_': : undefined reference to `mpi_recv_' poolreduce.o(.text+0x4d): In function `poolreduce_': : undefined reference to `mpi_barrier_' poolreduce.o(.text+0xc8): In function `poolreduce_': : undefined reference to `mpi_allreduce_' poolreduce.o(.text+0x104): In function `poolreduce_': : undefined reference to `dcopy__' poolreduce.o(.text+0x165): In function `poolreduce_': : undefined reference to `mpi_allreduce_' poolreduce.o(.text+0x1c1): In function `poolreduce_': : undefined reference to `dcopy__' poolscatter.o(.text+0xbc): In function `poolscatter_': : undefined reference to `dcopy__' potinit.o(.text+0xb5e): In function `potinit_': : undefined reference to `dcopy__' potinit.o(.text+0xcb9): In function `potinit_': : undefined reference to `dcopy__' potinit.o(.text+0xde5): In function `potinit_': : undefined reference to `daxpy__' pw_gemm.o(.text+0x100): In function `pw_gemm_': : undefined reference to `dgemm__' pw_gemm.o(.text+0x151): In function `pw_gemm_': : undefined reference to `dger__' rdiaghg.o(.text+0x134): In function `rdiaghg_': : undefined reference to `ilaenv__' rdiaghg.o(.text+0x503): In function `rdiaghg_': : undefined reference to `dcopy__' Apparently, it is due to underscore. Could anybody tell me how to remove it by just adding some options. Here is the makefile # Use the local copy of fftw CPPFLAGS = -DADD_BLAS_ONE_UNDERSCORE -D__LINUX64 -D__PGI -D__PARA -D_MPI -D_LAM -D__FFTW -D__USE_INTERNAL_FFTW \ -I$(OSHOME)/include -I./ # # Fortran compiler: F90 =mpif90 F77 =mpif77 CC =mpicc # # Please note: -r8 is necessary for numerical stability .. # F90FLAGS = -fast -r8 F77FLAGS = -fast -r8 CCFLAGS = $(CPPFLAGS) # # This is needed to tell the compiler where modules are # MODULEFLAG= -I$(OSHOME)/Modules -I$(OSHOME)/PW -I$(OSHOME)/PH # # Loader: # this below uses precompiled pgi libraries ( not very efficient but stable ) # LIBS = -L/opt/pgi/linux86-64/5.2/lib -llapack -lblas $(FFTW_LIB) # # for cineca machines: # #LIBS = -L/usr/local/pgi/linux86/lib/ -llapack -L/cineca/lib/ATLAS -lf77blas -latlas $(FFTW_LIB) # LD=$(F90) LDFLAGS = $(OSHOME)/flib/ptools.a $(OSHOME)/flib/flib.a $(OSHOME)/clib/clib.a $(LIBS) $(MODULEFLAG) --------------------------------- Do You Yahoo!? 150??MP3???????????? ??????????????????? 1G??1000??????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20041013/e4787acd/attachment.htm From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Wed Oct 13 07:27:48 2004 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Wed, 13 Oct 2004 07:27:48 +0200 (CEST) Subject: [Pw_forum] Compiling problems on AMD opteron64 under Linux using MPI In-Reply-To: <20041013013836.89999.qmail@web15802.mail.cnb.yahoo.com> Message-ID: On Wed, 13 Oct 2004, Adrain Zhou wrote: AZ> Dear all, AZ> AZ> Many thanks to Axel and Nicola . The former problem has been solved. AZ> But I met the following new problems at linking stages. AZ> ..... AZ> ..... AZ> : undefined reference to `mpi_barrier_' AZ> init_pool.o(.text+0x74): In function `init_pool_': AZ> : undefined reference to `mpi_comm_split_' AZ> init_pool.o(.text+0xaf): In function `init_pool_': AZ> : undefined reference to `mpi_barrier_' AZ> init_pool.o(.text+0xeb): In function `init_pool_': AZ> : undefined reference to `mpi_comm_split_' hello again. seems, like you have compiled your LAM-MPI library with g77 underscoring rules, but have not instructed the pgi compiler to do so. try adding -Msecond_underscore to F90FLAGS and F77FLAGS, and recompile everything (make clean ; make all). AZ> init_us_1.o(.text+0x2783): In function `init_us_1_': AZ> : undefined reference to `dscal__' AZ> interpolate.o(.text+0x2087): In function `cinterpolate_': AZ> : undefined reference to `zcopy__' so here your BLAS symbols have two underscores, that's weird for linux machines... [...] AZ> AZ> Apparently, it is due to underscore. Could anybody tell me how to remove it by just adding some options. Here is the makefile AZ> # Use the local copy of fftw AZ> CPPFLAGS = -DADD_BLAS_ONE_UNDERSCORE -D__LINUX64 -D__PGI -D__PARA -D_MPI -D_LAM -D__FFTW -D__USE_INTERNAL_FFTW \ AZ> -I$(OSHOME)/include -I./ aha! why do you use -DADD_BLAS_ONE_UNDERSCORE ??? you seem to have deleted the comment block preceding the CPPFLAGS definition, which already gives the explanation: # Add -DADD_BLAS_ONE_UNDERSCORE to CPPFLAGS if your blas/lapack library # names contain two underscores at the end bingo. your blas does not have two underscores, so you don't need it. AZ> # AZ> # Fortran compiler: AZ> F90 =mpif90 AZ> F77 =mpif77 AZ> CC =mpicc AZ> # AZ> # Please note: -r8 is necessary for numerical stability .. AZ> # AZ> F90FLAGS = -fast -r8 AZ> F77FLAGS = -fast -r8 AZ> CCFLAGS = $(CPPFLAGS) AZ> # AZ> # This is needed to tell the compiler where modules are AZ> # AZ> MODULEFLAG= -I$(OSHOME)/Modules -I$(OSHOME)/PW -I$(OSHOME)/PH AZ> # AZ> # Loader: AZ> # this below uses precompiled pgi libraries ( not very efficient but stable ) AZ> # AZ> LIBS = -L/opt/pgi/linux86-64/5.2/lib -llapack -lblas $(FFTW_LIB) don't use these. their performance is HORRIBLE. use ATLAS (which you should already have, according to your post to the cpmd mailing list) or ACML (best version 2.1, which should have been bundled with PGI). regards, axel. AZ> # AZ> # for cineca machines: AZ> # AZ> #LIBS = -L/usr/local/pgi/linux86/lib/ -llapack -L/cineca/lib/ATLAS -lf77blas -latlas $(FFTW_LIB) AZ> # AZ> LD=$(F90) AZ> LDFLAGS = $(OSHOME)/flib/ptools.a $(OSHOME)/flib/flib.a $(OSHOME)/clib/clib.a $(LIBS) $(MODULEFLAG) AZ> AZ> AZ> AZ> AZ> AZ> --------------------------------- AZ> Do You Yahoo!? AZ> 150????MP3???????????????????????? AZ> ?????????????????????????????????????? AZ> 1G????1000?????????????????????? -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at rub.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= From adrainzhou at yahoo.com.cn Thu Oct 14 06:07:08 2004 From: adrainzhou at yahoo.com.cn (Adrain Zhou) Date: Thu, 14 Oct 2004 12:07:08 +0800 (CST) Subject: [Pw_forum] Compiling problems on AMD opteron64 under Linux using MPI Message-ID: <20041014040708.23960.qmail@web15810.mail.cnb.yahoo.com> Dear all, Many thanks to Axel, I have removed most part of underscore problem. There are still some problems existed. input.o(.text+0x7857): In function `verify_tmpdir__': : undefined reference to `c_mkdir__' ../Modules/berry_phase.o(.text+0x4b): In function `berry_phase_ln_setup__': : undefined reference to `ln_alloc__' ../Modules/berry_phase.o(.text+0xa8): In function `berry_phase_ln_setup__': : undefined reference to `ln_set__' ../Modules/berry_phase.o(.text+0xb7): In function `berry_phase_ln_setup__': : undefined reference to `ln_activate__' ../Modules/berry_phase.o(.text+0xd5): In function `berry_phase_ln_closeup__': : undefined reference to `ln_dealloc__' ../Modules/berry_phase.o(.text+0x11bb): In function `berry_phase_indi_of_ig__': : undefined reference to `ln_ind__' ../Modules/berry_phase.o(.text+0x11f6): In function `berry_phase_indi_of_ig__': : undefined reference to `ln_ind__' ../Modules/berry_phase.o(.text+0x1231): In function `berry_phase_indi_of_ig__': : undefined reference to `ln_ind__' ../Modules/berry_phase.o(.text+0x1270): In function `berry_phase_indi_of_ig__': : undefined reference to `ln_ind__' ../Modules/berry_phase.o(.text+0x129f): In function `berry_phase_indi_of_ig__': : undefined reference to `ln_ind__' ../Modules/berry_phase.o(.text+0x1303): more undefined references to `ln_ind__' follow ../Modules/fft_scalar.o(.text+0x147): In function `fft_scalar_cft_1z__': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x169): In function `fft_scalar_cft_1z__': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x18f): In function `fft_scalar_cft_1z__': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x1b5): In function `fft_scalar_cft_1z__': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x252): In function `fft_scalar_cft_1z__': : undefined reference to `fft_z_stick__' ../Modules/fft_scalar.o(.text+0x2bd): In function `fft_scalar_cft_1z__': : undefined reference to `fft_z_stick__' ../Modules/fft_scalar.o(.text+0x789): In function `fft_scalar_cft_2xy__': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x7ab): In function `fft_scalar_cft_2xy__': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x7d3): In function `fft_scalar_cft_2xy__': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x7fb): In function `fft_scalar_cft_2xy__': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x81d): In function `fft_scalar_cft_2xy__': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x83f): In function `fft_scalar_cft_2xy__': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x869): In function `fft_scalar_cft_2xy__': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x893): In function `fft_scalar_cft_2xy__': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x93c): In function `fft_scalar_cft_2xy__': : undefined reference to `fft_x_stick__' ../Modules/fft_scalar.o(.text+0x9f4): In function `fft_scalar_cft_2xy__': : undefined reference to `fft_y_stick__' ../Modules/fft_scalar.o(.text+0xb34): In function `fft_scalar_cft_2xy__': : undefined reference to `fft_y_stick__' ../Modules/fft_scalar.o(.text+0xb8d): In function `fft_scalar_cft_2xy__': : undefined reference to `fft_x_stick__' ../Modules/fft_scalar.o(.text+0xccf): In function `fft_scalar_cfft3d_': : undefined reference to `destroy_plan_3d__' ../Modules/fft_scalar.o(.text+0xcee): In function `fft_scalar_cfft3d_': : undefined reference to `destroy_plan_3d__' ../Modules/fft_scalar.o(.text+0xd16): In function `fft_scalar_cfft3d_': : undefined reference to `create_plan_3d__' ../Modules/fft_scalar.o(.text+0xd3e): In function `fft_scalar_cfft3d_': : undefined reference to `create_plan_3d__' ../Modules/fft_scalar.o(.text+0xdbf): In function `fft_scalar_cfft3d_': : undefined reference to `fftw_inplace_drv_3d__' ../Modules/fft_scalar.o(.text+0xe44): In function `fft_scalar_cfft3d_': : undefined reference to `fftw_inplace_drv_3d__' ../Modules/fft_scalar.o(.text+0xff9): In function `fft_scalar_cfft3ds_': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x101b): In function `fft_scalar_cfft3ds_': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x103d): In function `fft_scalar_cfft3ds_': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x105f): In function `fft_scalar_cfft3ds_': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x1081): In function `fft_scalar_cfft3ds_': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x10a3): more undefined references to `destroy_plan_1d__' follow ../Modules/fft_scalar.o(.text+0x10d0): In function `fft_scalar_cfft3ds_': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x10fd): In function `fft_scalar_cfft3ds_': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x112a): In function `fft_scalar_cfft3ds_': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x1157): In function `fft_scalar_cfft3ds_': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x1181): In function `fft_scalar_cfft3ds_': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x11ab): more undefined references to `create_plan_1d__' follow ../Modules/fft_scalar.o(.text+0x130d): In function `fft_scalar_cfft3ds_': : undefined reference to `fftw_inplace_drv_1d__' ../Modules/fft_scalar.o(.text+0x13dd): In function `fft_scalar_cfft3ds_': : undefined reference to `fftw_inplace_drv_1d__' ../Modules/fft_scalar.o(.text+0x1445): In function `fft_scalar_cfft3ds_': : undefined reference to `fftw_inplace_drv_1d__' ../Modules/fft_scalar.o(.text+0x14a6): In function `fft_scalar_cfft3ds_': : undefined reference to `fftw_inplace_drv_1d__' ../Modules/fft_scalar.o(.text+0x153d): In function `fft_scalar_cfft3ds_': : undefined reference to `fftw_inplace_drv_1d__' ../Modules/fft_scalar.o(.text+0x163d): more undefined references to `fftw_inplace_drv_1d__' follow ../Modules/fft_scalar.o(.text+0x1864): In function `fft_scalar_cft_b__': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x1880): In function `fft_scalar_cft_b__': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x189f): In function `fft_scalar_cft_b__': : undefined reference to `destroy_plan_2d__' ../Modules/fft_scalar.o(.text+0x18be): In function `fft_scalar_cft_b__': : undefined reference to `create_plan_2d__' ../Modules/fft_scalar.o(.text+0x195d): In function `fft_scalar_cft_b__': : undefined reference to `fftw_inplace_drv_1d__' ../Modules/fft_scalar.o(.text+0x199f): In function `fft_scalar_cft_b__': : undefined reference to `fftw_inplace_drv_2d__' make[1]: *** [memory.x] Error 2 The make.sys file is as follows, # Use the local copy of fftw CPPFLAGS = -D__LINUX64 -D__PGI -D__PARA -D_MPI -D_LAM -D__FFTW -D__USE_INTERNAL_FFTW \ -I$(OSHOME)/include -I./ # # Fortran compiler: F90 =mpif90 F77 =mpif77 CC =mpicc # # Please note: -r8 is necessary for numerical stability .. # F90FLAGS = -w -fast -r8 -Msecond_underscore F77FLAGS = -w -fast -r8 -Msecond_underscore CCFLAGS = $(CPPFLAGS) # # This is needed to tell the compiler where modules are # MODULEFLAG= -I$(OSHOME)/Modules -I$(OSHOME)/PW -I$(OSHOME)/PH # # LIBS = -L/opt/pgi/linux86-64/5.2/lib $(OSHOME)/acml/libacml.a $(FFTW_LIB) # # LD=$(F90) LDFLAGS = -lg2c -lpthread -lm $(OSHOME)/flib/ptools.a $(OSHOME)/flib/flib.a $(OSHOME)/clib/clib.a $(LIBS) $(MODULEFLAG) Any comments are highly appreciated. Many thanks. Regards, Adrain --------------------------------- Do You Yahoo!? 150??MP3???????????? ??????????????????? 1G??1000??????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20041014/e27c8908/attachment.htm From eyvaz_isaev at yahoo.com Mon Oct 11 22:09:39 2004 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Mon, 11 Oct 2004 13:09:39 -0700 (PDT) Subject: [Pw_forum] k-points for band structure In-Reply-To: <32816.194.27.35.62.1097517934.squirrel@194.27.35.62> Message-ID: <20041011200939.24127.qmail@web60302.mail.yahoo.com> Dear Fethi, I am very sorry, some time ago I promised you the program, but always a lot of things to do. You can try an attached file. Very brief comment for bands.f. After band-structure calculations using k-points you generated you should edit output file (nscf-file) removing a lot of lines up to a line "Band structure calculation". Further follow an example file Bands.in. Hope it helps. Please feel free to ask if you have any troubles . Best regards, Eyvaz. --- Fethi SOYALP wrote: > Dear PWSCF users, > I want to calculate band structure of a fcc system > I have a problem about k-points. > I want to generate high symmetry directions k-points > for example W X Gama L W K Gama > is there a program to generate k-points for band > structure > regards, > > Fethi > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail -------------- next part -------------- A non-text attachment was scrubbed... Name: k_for_bands.f Type: application/octet-stream Size: 4235 bytes Desc: k_for_bands.f Url : /pipermail/attachments/20041011/112ca8f0/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: FCC-kpoints Type: application/octet-stream Size: 285 bytes Desc: FCC-kpoints Url : /pipermail/attachments/20041011/112ca8f0/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: HCP_kpoints Type: application/octet-stream Size: 314 bytes Desc: HCP_kpoints Url : /pipermail/attachments/20041011/112ca8f0/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: BCC_kpoints Type: application/octet-stream Size: 174 bytes Desc: BCC_kpoints Url : /pipermail/attachments/20041011/112ca8f0/attachment-0003.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: PrimitiveTetragonal.dat Type: application/octet-stream Size: 157 bytes Desc: PrimitiveTetragonal.dat Url : /pipermail/attachments/20041011/112ca8f0/attachment-0004.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: SimpleCube Type: application/octet-stream Size: 251 bytes Desc: SimpleCube Url : /pipermail/attachments/20041011/112ca8f0/attachment-0005.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: bands.f Type: application/octet-stream Size: 642 bytes Desc: bands.f Url : /pipermail/attachments/20041011/112ca8f0/attachment-0006.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Bands.in Type: application/octet-stream Size: 24799 bytes Desc: Bands.in Url : /pipermail/attachments/20041011/112ca8f0/attachment-0007.obj From cjtan at OptimaNumerics.com Thu Oct 14 14:12:42 2004 From: cjtan at OptimaNumerics.com (C J Kenneth Tan -- OptimaNumerics) Date: Thu, 14 Oct 2004 12:12:42 +0000 (UTC) Subject: [Pw_forum] Compiling problems on AMD opteron64 under Linux using MPI In-Reply-To: <20041014040708.23960.qmail@web15810.mail.cnb.yahoo.com> References: <20041014040708.23960.qmail@web15810.mail.cnb.yahoo.com> Message-ID: Adrian, This looks like an FFTW linking problem. I believe the linker is looking for symbols with only 1 underscore. So remove the second underscore option from the Fortran compiler flags: > F90FLAGS = -w -fast -r8 > F77FLAGS = -w -fast -r8 > CCFLAGS = $(CPPFLAGS) Kenneth Tan ----------------------------------------------------------------------- News: OptimaNumerics Enables Higher Performance at Russian Supercomputer Center ----------------------------------------------------------------------- C. J. Kenneth Tan, Ph.D. OptimaNumerics Ltd. E-mail: cjtan at OptimaNumerics.com Telephone: +44 798 941 7838 Web: http://www.OptimaNumerics.com Facsimile: +44 289 066 3015 ----------------------------------------------------------------------- On 2004-10-14 12:07 +0800 Adrain Zhou (adrainzhou at yahoo.com.cn) wrote: > Date: Thu, 14 Oct 2004 12:07:08 +0800 (CST) > From: Adrain Zhou > Reply-To: pw_forum at pwscf.org > To: pw_forum at pwscf.org > Subject: [Pw_forum] Compiling problems on AMD opteron64 under Linux using MPI > > Dear all, > > Many thanks to Axel, I have removed most part of underscore problem. There are still some problems existed. > > input.o(.text+0x7857): In function `verify_tmpdir__': > : undefined reference to `c_mkdir__' > ../Modules/berry_phase.o(.text+0x4b): In function `berry_phase_ln_setup__': > : undefined reference to `ln_alloc__' > ../Modules/berry_phase.o(.text+0xa8): In function `berry_phase_ln_setup__': > : undefined reference to `ln_set__' > ../Modules/berry_phase.o(.text+0xb7): In function `berry_phase_ln_setup__': > : undefined reference to `ln_activate__' > ../Modules/berry_phase.o(.text+0xd5): In function `berry_phase_ln_closeup__': > : undefined reference to `ln_dealloc__' > ../Modules/berry_phase.o(.text+0x11bb): In function `berry_phase_indi_of_ig__': > : undefined reference to `ln_ind__' > ../Modules/berry_phase.o(.text+0x11f6): In function `berry_phase_indi_of_ig__': > : undefined reference to `ln_ind__' > ../Modules/berry_phase.o(.text+0x1231): In function `berry_phase_indi_of_ig__': > : undefined reference to `ln_ind__' > ../Modules/berry_phase.o(.text+0x1270): In function `berry_phase_indi_of_ig__': > : undefined reference to `ln_ind__' > ../Modules/berry_phase.o(.text+0x129f): In function `berry_phase_indi_of_ig__': > : undefined reference to `ln_ind__' > ../Modules/berry_phase.o(.text+0x1303): more undefined references to `ln_ind__' follow > ../Modules/fft_scalar.o(.text+0x147): In function `fft_scalar_cft_1z__': > : undefined reference to `destroy_plan_1d__' > ../Modules/fft_scalar.o(.text+0x169): In function `fft_scalar_cft_1z__': > : undefined reference to `destroy_plan_1d__' > ../Modules/fft_scalar.o(.text+0x18f): In function `fft_scalar_cft_1z__': > : undefined reference to `create_plan_1d__' > ../Modules/fft_scalar.o(.text+0x1b5): In function `fft_scalar_cft_1z__': > : undefined reference to `create_plan_1d__' > ../Modules/fft_scalar.o(.text+0x252): In function `fft_scalar_cft_1z__': > : undefined reference to `fft_z_stick__' > ../Modules/fft_scalar.o(.text+0x2bd): In function `fft_scalar_cft_1z__': > : undefined reference to `fft_z_stick__' > ../Modules/fft_scalar.o(.text+0x789): In function `fft_scalar_cft_2xy__': > : undefined reference to `destroy_plan_1d__' > ../Modules/fft_scalar.o(.text+0x7ab): In function `fft_scalar_cft_2xy__': > : undefined reference to `destroy_plan_1d__' > ../Modules/fft_scalar.o(.text+0x7d3): In function `fft_scalar_cft_2xy__': > : undefined reference to `create_plan_1d__' > ../Modules/fft_scalar.o(.text+0x7fb): In function `fft_scalar_cft_2xy__': > : undefined reference to `create_plan_1d__' > ../Modules/fft_scalar.o(.text+0x81d): In function `fft_scalar_cft_2xy__': > : undefined reference to `destroy_plan_1d__' > ../Modules/fft_scalar.o(.text+0x83f): In function `fft_scalar_cft_2xy__': > : undefined reference to `destroy_plan_1d__' > ../Modules/fft_scalar.o(.text+0x869): In function `fft_scalar_cft_2xy__': > : undefined reference to `create_plan_1d__' > ../Modules/fft_scalar.o(.text+0x893): In function `fft_scalar_cft_2xy__': > : undefined reference to `create_plan_1d__' > ../Modules/fft_scalar.o(.text+0x93c): In function `fft_scalar_cft_2xy__': > : undefined reference to `fft_x_stick__' > ../Modules/fft_scalar.o(.text+0x9f4): In function `fft_scalar_cft_2xy__': > : undefined reference to `fft_y_stick__' > ../Modules/fft_scalar.o(.text+0xb34): In function `fft_scalar_cft_2xy__': > : undefined reference to `fft_y_stick__' > ../Modules/fft_scalar.o(.text+0xb8d): In function `fft_scalar_cft_2xy__': > : undefined reference to `fft_x_stick__' > ../Modules/fft_scalar.o(.text+0xccf): In function `fft_scalar_cfft3d_': > : undefined reference to `destroy_plan_3d__' > ../Modules/fft_scalar.o(.text+0xcee): In function `fft_scalar_cfft3d_': > : undefined reference to `destroy_plan_3d__' > ../Modules/fft_scalar.o(.text+0xd16): In function `fft_scalar_cfft3d_': > : undefined reference to `create_plan_3d__' > ../Modules/fft_scalar.o(.text+0xd3e): In function `fft_scalar_cfft3d_': > : undefined reference to `create_plan_3d__' > ../Modules/fft_scalar.o(.text+0xdbf): In function `fft_scalar_cfft3d_': > : undefined reference to `fftw_inplace_drv_3d__' > ../Modules/fft_scalar.o(.text+0xe44): In function `fft_scalar_cfft3d_': > : undefined reference to `fftw_inplace_drv_3d__' > ../Modules/fft_scalar.o(.text+0xff9): In function `fft_scalar_cfft3ds_': > : undefined reference to `destroy_plan_1d__' > ../Modules/fft_scalar.o(.text+0x101b): In function `fft_scalar_cfft3ds_': > : undefined reference to `destroy_plan_1d__' > ../Modules/fft_scalar.o(.text+0x103d): In function `fft_scalar_cfft3ds_': > : undefined reference to `destroy_plan_1d__' > ../Modules/fft_scalar.o(.text+0x105f): In function `fft_scalar_cfft3ds_': > : undefined reference to `destroy_plan_1d__' > ../Modules/fft_scalar.o(.text+0x1081): In function `fft_scalar_cfft3ds_': > : undefined reference to `destroy_plan_1d__' > ../Modules/fft_scalar.o(.text+0x10a3): more undefined references to `destroy_plan_1d__' follow > ../Modules/fft_scalar.o(.text+0x10d0): In function `fft_scalar_cfft3ds_': > : undefined reference to `create_plan_1d__' > ../Modules/fft_scalar.o(.text+0x10fd): In function `fft_scalar_cfft3ds_': > : undefined reference to `create_plan_1d__' > ../Modules/fft_scalar.o(.text+0x112a): In function `fft_scalar_cfft3ds_': > : undefined reference to `create_plan_1d__' > ../Modules/fft_scalar.o(.text+0x1157): In function `fft_scalar_cfft3ds_': > : undefined reference to `create_plan_1d__' > ../Modules/fft_scalar.o(.text+0x1181): In function `fft_scalar_cfft3ds_': > : undefined reference to `create_plan_1d__' > ../Modules/fft_scalar.o(.text+0x11ab): more undefined references to `create_plan_1d__' follow > ../Modules/fft_scalar.o(.text+0x130d): In function `fft_scalar_cfft3ds_': > : undefined reference to `fftw_inplace_drv_1d__' > ../Modules/fft_scalar.o(.text+0x13dd): In function `fft_scalar_cfft3ds_': > : undefined reference to `fftw_inplace_drv_1d__' > ../Modules/fft_scalar.o(.text+0x1445): In function `fft_scalar_cfft3ds_': > : undefined reference to `fftw_inplace_drv_1d__' > ../Modules/fft_scalar.o(.text+0x14a6): In function `fft_scalar_cfft3ds_': > : undefined reference to `fftw_inplace_drv_1d__' > ../Modules/fft_scalar.o(.text+0x153d): In function `fft_scalar_cfft3ds_': > : undefined reference to `fftw_inplace_drv_1d__' > ../Modules/fft_scalar.o(.text+0x163d): more undefined references to `fftw_inplace_drv_1d__' follow > ../Modules/fft_scalar.o(.text+0x1864): In function `fft_scalar_cft_b__': > : undefined reference to `destroy_plan_1d__' > ../Modules/fft_scalar.o(.text+0x1880): In function `fft_scalar_cft_b__': > : undefined reference to `create_plan_1d__' > ../Modules/fft_scalar.o(.text+0x189f): In function `fft_scalar_cft_b__': > : undefined reference to `destroy_plan_2d__' > ../Modules/fft_scalar.o(.text+0x18be): In function `fft_scalar_cft_b__': > : undefined reference to `create_plan_2d__' > ../Modules/fft_scalar.o(.text+0x195d): In function `fft_scalar_cft_b__': > : undefined reference to `fftw_inplace_drv_1d__' > ../Modules/fft_scalar.o(.text+0x199f): In function `fft_scalar_cft_b__': > : undefined reference to `fftw_inplace_drv_2d__' > make[1]: *** [memory.x] Error 2 > > > The make.sys file is as follows, > # Use the local copy of fftw > CPPFLAGS = -D__LINUX64 -D__PGI -D__PARA -D_MPI -D_LAM -D__FFTW -D__USE_INTERNAL_FFTW \ > -I$(OSHOME)/include -I./ > # > # Fortran compiler: > F90 =mpif90 > F77 =mpif77 > CC =mpicc > # > # Please note: -r8 is necessary for numerical stability .. > # > F90FLAGS = -w -fast -r8 -Msecond_underscore > F77FLAGS = -w -fast -r8 -Msecond_underscore > CCFLAGS = $(CPPFLAGS) > # > # This is needed to tell the compiler where modules are > # > MODULEFLAG= -I$(OSHOME)/Modules -I$(OSHOME)/PW -I$(OSHOME)/PH > # > # > LIBS = -L/opt/pgi/linux86-64/5.2/lib $(OSHOME)/acml/libacml.a $(FFTW_LIB) > # > # > LD=$(F90) > LDFLAGS = -lg2c -lpthread -lm $(OSHOME)/flib/ptools.a $(OSHOME)/flib/flib.a $(OSHOME)/clib/clib.a $(LIBS) $(MODULEFLAG) > > Any comments are highly appreciated. Many thanks. > > Regards, > Adrain > > > > > > --------------------------------- > Do You Yahoo!? > 150????MP3???????????????????????? > ?????????????????????????????????????? > 1G????1000?????????????????????? From wang.yuanxu at nims.go.jp Fri Oct 15 03:08:32 2004 From: wang.yuanxu at nims.go.jp (WANG Yuan Xu) Date: Fri, 15 Oct 2004 10:08:32 +0900 Subject: [Pw_forum] Compile Hitachi Message-ID: <20041015010811.2296F67F47@kugane.nims.go.jp> Dear Paolo Giannozzi, Compile on Hitachi is still not successful. I do not define -D_shmem in make.sys. But it still compile it, the shmem_include.f90. I use "./configure.old hitachi" get make.sys and then change some content. Another the file "Modules/.dependences" is from above command. I am not sure if it is correct. My Hitachi is SR11000 and it is different hitachi sr8000. Could you help me to find some reason? make.sys: # System-dependent definitions for Hitachi SR8000 # contributed by Noejung Park # # Use precompiled fftw library (version <= 2.1.5, NOT v.3!) # # In this case, specify also how to load the fftw library (FFTW_LIB) # and the path to the fftw.h include file (FFTW_INC_DIR). Example: FFTW_LIB=-L/home/araimasa/src/fftw-2.1.5/fftw/.libs -lfftw FFTW_INC_DIR=/home/araimasa/fftw-2.1.5/fftw # CPPFLAGS = -DHITACHI -D__PARA -D__MPI -D__FFTW # Use the local copy of fftw CPPFLAGS = -D_HITACHI -D__PARA -D__MPI -D__FFTW -D__USE_INTERNAL_FFTW # # Fortran compiler: # F90 = mpif90_r F77 = f90 -hf77 CC = mpicc_r FFLAGS = -free #FFLAGS = -O4 -32 -noparallel -precexp=basic -conti199 -nosaveallocate \ # -I$(OSHOME)/include -I/usr/mpi/include F77FLAGS = $(FFLAGS) F90FLAGS = $(FFLAGS) $(CPPFLAGS) #CCFLAGS = -D__FFTW -I$(FFTW_INC_DIR) # # This is needed to tell the compiler where modules are # MODULEFLAG = -I$(OSHOME)/Modules -I$(OSHOME)/PW/ -I$(OSHOME)/PH/ # # Libraries: MYLIB = lapack_ibm LAPACKdir = /usr/local/lib #MPIdir = /opt/hitachi/matmpp/lib/ MPIdir = /usr/include/ LIBS= -L$(LAPACKdir) -llapack -lblas -lmpi\ -L$(MPIdir) -lfmpi -lmpi $(FFTW_LIB) -lm # LD=$(F90) LDFLAGS = $(OSHOME)/flib/ptools.a $(OSHOME)/flib/flib.a $(OSHOME)/clib/clib.a $(LIBS) # # ar: # AR = ar ARFLAGS = rv RANLIB = echo make.rules .SUFFIXES : .o .c .f .f90 .f90.o: $(F90) $(F90FLAGS) $(MODULEFLAG) -c $< .f.o: $(F77) $(F77FLAGS) -c $< .c.o: $(CC) $(CCFLAGS) -c $< Best WANG Yuan Xu National Institute for Materials Science Computational Materials Science Center Namiki 1-1, Tsukuba 305-0044, Japan Phone +81-29-8513354-8092; Fax +81-29-8541207 wang.yuanxu at nims.go.jp 2004-10-15 ======= 2004-09-30 20:18:45 you wrote======= >On Thursday 30 September 2004 07:55, WANG Yuan Xu wrote: > >> I use the Ba pseudo file from PWscf web site. And O an Ti was >> Ti.vdb.UPF and O.vdb.UPF >> >> I get the error information "from readpp # 2 inconsistent DFT read" > >for PWscf, the exchange-correlation used in the calculation is read from >the PP files, and it must be the same in all PP's (of course). One can >edit the PP files and modify the exch-corr field, but it is not a good idea. > >Note that FPMD uses a different approach: you have to write the exch-corr >you want in the input data (variable "xc_type" in namelist &system) > >Does PWscf work now on the Hitachi machine, by the way? > >Paolo >-- >Paolo Giannozzi e-mail: giannozz at nest.sns.it >Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 >Piazza dei Cavalieri 7 I-56126 Pisa, Italy >_______________________________________________ >Pw_forum mailing list >Pw_forum at pwscf.org >http://www.democritos.it/mailman/listinfo/pw_forum > = = = = = = = = = = = = = = = = = = = = From uachsmrk at savba.sk Thu Oct 14 10:16:46 2004 From: uachsmrk at savba.sk (uachsmrk at savba.sk) Date: Thu, 14 Oct 2004 10:16:46 +0200 Subject: [Pw_forum] ESpresso with Intel Message-ID: <1097741806.416e35ee426cb@webmail.savba.sk> Hi, trying to compile ESpresso with Linux/Intel IFC I am getting the following messages from the linker (below). Any hint ? Thank you. Lubo Smrcok /opt/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb8): In function `libi_exit': : undefined reference to `pthread_self' /opt/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xc4): In function `libi_exit': : undefined reference to `pthread_equal' /opt/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x23): In function `f_claim_mutex': : undefined reference to `pthread_mutex_lock' /opt/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x33): In function `f_exitthread': : undefined reference to `pthread_exit' /opt/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x53): In function `f_release_mutex': : undefined reference to `pthread_mutex_unlock' From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Fri Oct 15 09:24:31 2004 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Fri, 15 Oct 2004 09:24:31 +0200 Subject: [Pw_forum] ESpresso with Intel In-Reply-To: Your message of "Thu, 14 Oct 2004 10:16:46 +0200." <1097741806.416e35ee426cb@webmail.savba.sk> Message-ID: <200410150724.i9F7OVL14445@yello.theochem.ruhr-uni-bochum.de> >>> "LS" == uachsmrk writes: LS> Hi, LS> trying to compile ESpresso with Linux/Intel IFC I am getting the following LS> messages from the linker (below). Any hint ? LS> Thank you. LS> Lubo Smrcok lubo, please try appending -lpthread to the LIBS= line in make.sys. regards, axel. LS> /opt/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb8): In function LS> `libi_exit': LS> : undefined reference to `pthread_self' LS> /opt/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xc4): In function LS> `libi_exit': LS> : undefined reference to `pthread_equal' LS> /opt/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x23): In LS> function `f_claim_mutex': LS> : undefined reference to `pthread_mutex_lock' LS> /opt/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x33): In LS> function `f_exitthread': LS> : undefined reference to `pthread_exit' LS> /opt/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x53): In LS> function `f_release_mutex': LS> : undefined reference to `pthread_mutex_unlock' LS> _______________________________________________ LS> Pw_forum mailing list LS> Pw_forum at pwscf.org LS> http://www.democritos.it/mailman/listinfo/pw_forum -- ======================================================================= Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From proffess at yandex.ru Fri Oct 15 10:07:30 2004 From: proffess at yandex.ru (Sergey Lisenkov) Date: Fri, 15 Oct 2004 12:07:30 +0400 (MSD) Subject: [Pw_forum] error in davcio during restart calculations Message-ID: <416F8542.000001.31105@tide.yandex.ru> Dear PWscf authors and users, I restarted my calculations with increasing k-points. But I immeduatly got the error: ..... The initial density is read from file 40bn.rho Starting wfc from file total cpu time spent up to now is 3.23 secs Self-consistent Calculation iteration # 1 ecut= 35.00 ryd beta=0.15 Davidson diagonalization (with overlap) IOS = 158 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from davcio : error # 10 i/o error in davcio %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... If I do not use "restart' option, the code will not stop. Why? Thanks a lot, Sergey From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Fri Oct 15 10:08:54 2004 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Fri, 15 Oct 2004 10:08:54 +0200 Subject: [Pw_forum] ESpresso with Intel In-Reply-To: Your message of "Fri, 15 Oct 2004 09:58:23 +0200." Message-ID: <200410150808.i9F88sn00365@yello.theochem.ruhr-uni-bochum.de> >>> "LS" == Lubomir Smrcok writes: lubo, then there must be another screw-up. those missing symbols _are_ in the pthread library. please make sure, that you have the glibc-devel package installed. usually, this is a prerequisite to install any compiler packages on linux machines, but if you only have the intel compiler, this is not enforced, AFAIK. also it would be useful, if you could quote: - the relevant part of the makefile/make.sys - the output, especially the linker command leading up to the error messages. - the exact compiler / linux / libc version, that you are using. regards, axel. LS> Dear Axel, LS> this is, unfortunately, of no help. I have got the same messages. LS> Best wishes, LS> Lubo LS> On Fri, 15 Oct 2004, Axel Kohlmeyer wrote: >> >> >>> "LS" == uachsmrk writes: >> LS> Hi, LS> trying to compile ESpresso with Linux/Intel IFC I am getting the following LS> messages from the linker (below). Any hint ? LS> Thank you. LS> Lubo Smrcok >> >> >> lubo, >> >> please try appending -lpthread to the LIBS= line in make.sys. >> >> regards, >> axel. >> LS> /opt/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb8): In function LS> `libi_exit': LS> : undefined reference to `pthread_self' LS> /opt/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xc4): In function LS> `libi_exit': LS> : undefined reference to `pthread_equal' LS> /opt/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x23): In LS> function `f_claim_mutex': LS> : undefined reference to `pthread_mutex_lock' LS> /opt/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x33): In LS> function `f_exitthread': LS> : undefined reference to `pthread_exit' LS> /opt/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x53): In LS> function `f_release_mutex': LS> : undefined reference to `pthread_mutex_unlock' >> >> >> >> LS> _______________________________________________ LS> Pw_forum mailing list LS> Pw_forum at pwscf.org LS> http://www.democritos.it/mailman/listinfo/pw_forum >> >> >> >> -- >> >> ======================================================================= >> Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de >> Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 >> Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 >> D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ >> ======================================================================= >> If you make something idiot-proof, the universe creates a better idiot. >> -- ======================================================================= Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From giacomo.saielli at unipd.it Fri Oct 15 10:50:40 2004 From: giacomo.saielli at unipd.it (Giacomo Saielli) Date: Fri, 15 Oct 2004 10:50:40 +0200 Subject: [Pw_forum] parallelization issue Message-ID: <416F8F60.7020803@unipd.it> Dear developers, I wonder if the comments of paragraph 7.4 of espresso manual v 2.1, parallelization issue of pw.x, apply also for the cp.x module. This is because I found the md simulations of my system with cp.x to be not as fast as I need it. I have a system made of 242 atoms, 137 of which are protons, the rest C, N, O. This is the relevant input section (I use Vanderbilt PPs): &system ibrav = 14, celldm(1) = 27.5945666, celldm(2) = 1.0, celldm(3) = 1.0, celldm(4) = 0.0, celldm(5) = 0.0, celldm(6) = 0.0, nat = 242, ntyp = 4, nbnd = 316, nelec = 632, ecutwfc = 30.0, ecutrho = 180.0, nr1b= 10, nr2b = 10, nr3b = 10, xc_type = 'PBE', / &electrons emass = 400.d0, emass_cutoff = 2.5d0, orthogonalization = 'ortho', ortho_eps = 5.d-8, ortho_max = 15, electron_dynamics = 'verlet', ! electron_damping = 0.4, ! electron_velocities = 'zero', electron_temperature = 'not_controlled', / &ions ion_dynamics = 'verlet', ! ion_velocities = 'zero', ion_temperature = 'nose', fnosep = 60.0, tempw = 300.0, / A test CPMD run with cp.x takes about 50 hours of total cpu (16 procs on IBM SP4 at CINECA, all PE of the same node) for 100 steps, that is about 15 fs (dt is 6 a.u. about 0.145 fs). This makes inpossible to run the simulation for some tens of picoseconds as I would like, since it would take something of the order of 10^5 cpu hours. The question is if this numbers sounds correct to you, for this system size, so that the only chance is to build a smaller system, or if there is space for improvement playing with the choice of kpoints grid and other grids as mentioned in the Espresso manual,concerning pw.x. Here I attach the beginning of the output file thank you very much best wishes Giacomo ************************************************************************ **** **** **** CPV: variable-cell Car-Parrinello molecular dynamics **** **** using ultrasoft Vanderbilt pseudopotentials - v.2.1 **** **** **** ************************************************************************ Parallel version (MPI) Number of processors in use: 16 Warning: card &CELL ignored Warning: card CELL_DYNAMICS = 'NONE', ignored Warning: card CELL_VELOCITIES = 'ZERO', ignored Warning: card PRESS = 0.0D0, ignored Warning: card WMASS = 70000.0D0 ignored Warning: card / ignored reading ppot for species # 1 from file /scratch/padpdb42/saielli/PWSCF/TMA/CP/O.pbe-van_bm.UPF reading ppot for species # 2 from file /scratch/padpdb42/saielli/PWSCF/TMA/CP/N.pbe-van_bm.UPF reading ppot for species # 3 from file /scratch/padpdb42/saielli/PWSCF/TMA/CP/C.pbe-van_bm.UPF reading ppot for species # 4 from file /scratch/padpdb42/saielli/PWSCF/TMA/CP/H.pbe-van_bm.UPF wmass (calculated) = 233945.31 nbeg= 1 nomore= 100 iprint= 2 reads from 51 writes on 51 time step = 6.0000 parameters for electron dynamics: emass= 400.00 emaec= 2.50ry orthog. with lagrange multipliers: eps= 0.50E-07 max= 15 verlet algorithm for electron dynamics with friction frice = 0.0000 , grease = 1.0000 ions are allowed to move ion dynamics with fricp = 0.0000 and greasp = 1.0000 ion dynamics with nose` temp. control: temperature required= 300.00000(kelvin) nose` mass = 16599.975 internal stress tensor calculated cell parameters are not allowed to move iprsta = 1 unit vectors of full simulation cell in real space: in reciprocal space: 27.5946 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 27.5946 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 27.5946 0.0000 0.0000 1.0000 Proc planes cols G planes cols G columns G (dense grid) (smooth grid) (wavefct grid) 1 8 680 53548 7 456 29172 114 3634 2 8 680 53548 7 456 29172 114 3634 3 8 680 53548 7 456 29172 114 3630 4 8 680 53548 7 456 29152 114 3630 5 8 681 53549 7 455 29151 113 3629 6 8 680 53548 7 456 29168 114 3630 7 8 682 53554 7 456 29132 114 3630 8 8 682 53554 7 456 29132 114 3630 9 7 682 53554 7 454 29126 112 3628 10 7 682 53554 7 454 29118 112 3628 11 7 682 53554 7 454 29126 112 3628 12 7 682 53550 7 456 29160 116 3632 13 7 682 53550 7 456 29148 112 3628 14 7 682 53550 7 456 29156 112 3628 15 7 682 53550 6 456 29168 112 3628 16 7 682 53550 6 456 29164 114 3630 0 120 10901 856809 110 7289 466417 1813 58077 ggen: # of g vectors < gcut ng= 26774 ggen: # of g vectors < gcuts ngs= 14586 ggen: # of g vectors < gcutw ngw= 1817 ggen: # of g shells < gcut ngl= 2655 unit vectors of box grid cell in real space: in reciprocal space: 2.2995 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 2.2995 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 2.2995 0.0000 0.0000 1.0000 ggenb: # of gb vectors < gcutb ngb = 243 ggenb: # of gb shells < gcutb ngbl= 22 initialization ibrav= 14 alat= 27.595 omega=21012.1616 gcut= 3471.84 gcuts= 2314.56 gcutw= 578.64 k-points: nkpt= 1 meshes: dense grid: nr1 ,nr2, nr3 = 120 120 120 nr1x, nr2x, nr3x = 120 120 120 smooth grid: nr1s,nr2s,nr3s = 110 110 110 nr1sx,nr2sx,nr3sx= 110 110 110 box grid: nr1b,nr2b,nr3b = 10 10 10 nr1bx,nr2bx,nr3bx= 10 10 10 exchange-correlation potential: SLA PW PBE PBE ecutw= 30.0 ryd ecuts= 120.0 ryd ecut= 180.0 ryd # of electrons= 632 # of states= 316 nspin= 1 occupation numbers: 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 2.0 # of atomic species 4 is= 1 na= 25 atomic mass= 16.00 gaussian rcmax= 0.50 atomic coordinates: 5.34 27.52 7.83 0.95 14.73 1.13 7.35 10.64 21.18 19.98 18.54 1.18 2.28 5.20 1.24 ..... ..... ..... ..... -- Giacomo Saielli Istituto per la Tecnologia delle Membrane del CNR, Sezione di Padova; Via Marzolo, 1 - 35131 Padova, Italy; Tel: +39-049-8275279; Fax: -5239; http://www.chfi.unipd.it/home/g.saielli/ From eyvaz_isaev at yahoo.com Fri Oct 15 11:27:16 2004 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Fri, 15 Oct 2004 02:27:16 -0700 (PDT) Subject: [Pw_forum] error in davcio during restart calculations In-Reply-To: <416F8542.000001.31105@tide.yandex.ru> Message-ID: <20041015092716.34425.qmail@web60307.mail.yahoo.com> Dear Sergei, More likely it is due to a fact that files you saved are not complete for some reason (time limit, or you exceed your quota, etc.). Bests, Eyvaz. --- Sergey Lisenkov wrote: > Dear PWscf authors and users, > > I restarted my calculations with increasing > k-points. But I immeduatly got the error: > ..... > The initial density is read from file 40bn.rho > Starting wfc from file > > total cpu time spent up to now is 3.23 > secs > > Self-consistent Calculation > > iteration # 1 ecut= 35.00 ryd > beta=0.15 > Davidson diagonalization (with overlap) > IOS = 158 > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > from davcio : error # 10 > i/o error in davcio > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > stopping ... > > If I do not use "restart' option, the code will not > stop. Why? > > Thanks a lot, > Sergey > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From eyvaz_isaev at yahoo.com Fri Oct 15 11:35:34 2004 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Fri, 15 Oct 2004 02:35:34 -0700 (PDT) Subject: [Pw_forum] parallelization issue In-Reply-To: <416F8F60.7020803@unipd.it> Message-ID: <20041015093534.73770.qmail@web60306.mail.yahoo.com> Dear Giacomo, Please pay attention to your cell choice. You used ibrav=14, but with cosines = 0 and celldm(2,3)=1. So, your system is cubic. Bests, Eyvaz. --- Giacomo Saielli wrote: > Dear developers, > I wonder if the comments of paragraph 7.4 of > espresso manual v 2.1, > parallelization issue of pw.x, apply also for the > cp.x module. > This is because I found the md simulations of my > system with cp.x to be > not as fast as I need it. > I have a system made of 242 atoms, 137 of which are > protons, the rest > C, N, O. This is the relevant input section (I use > Vanderbilt PPs): > > &system > ibrav = 14, > > celldm(1) = 27.5945666, > celldm(2) = 1.0, > celldm(3) = 1.0, > celldm(4) = 0.0, > celldm(5) = 0.0, > celldm(6) = 0.0, > nat = 242, > ntyp = 4, > nbnd = 316, > nelec = 632, > ecutwfc = 30.0, > ecutrho = 180.0, > nr1b= 10, nr2b = 10, nr3b = 10, > xc_type = 'PBE', > / > &electrons > emass = 400.d0, > emass_cutoff = 2.5d0, > orthogonalization = 'ortho', > ortho_eps = 5.d-8, > ortho_max = 15, > electron_dynamics = 'verlet', > ! electron_damping = 0.4, > ! electron_velocities = 'zero', > electron_temperature = 'not_controlled', > / > &ions > ion_dynamics = 'verlet', > ! ion_velocities = 'zero', > ion_temperature = 'nose', > fnosep = 60.0, > tempw = 300.0, > / > > A test CPMD run with cp.x takes about 50 hours of > total cpu (16 procs on IBM SP4 at CINECA, all PE of > the same node) for 100 steps, that is about 15 fs > (dt is 6 a.u. about 0.145 fs). This makes inpossible > to run the simulation for some tens of picoseconds > as I would like, since it would take something of > the order of 10^5 cpu hours. > > The question is if this numbers sounds correct to > you, for this system size, so that the only chance > is to build a smaller system, or if there is space > for improvement playing with the choice of kpoints > grid and other grids as mentioned in the Espresso > manual,concerning pw.x. > > Here I attach the beginning of the output file > > thank you very much > best wishes > Giacomo > > ************************************************************************ > **** > **** > **** CPV: variable-cell Car-Parrinello molecular > dynamics **** > **** using ultrasoft Vanderbilt pseudopotentials - > v.2.1 **** > **** > **** > ************************************************************************ > > Parallel version (MPI) > Number of processors in use: 16 > Warning: card &CELL ignored > Warning: card CELL_DYNAMICS = 'NONE', ignored > Warning: card CELL_VELOCITIES = 'ZERO', ignored > Warning: card PRESS = 0.0D0, ignored > Warning: card WMASS = 70000.0D0 ignored > Warning: card / ignored > reading ppot for species # 1 from file > /scratch/padpdb42/saielli/PWSCF/TMA/CP/O.pbe-van_bm.UPF > reading ppot for species # 2 from file > /scratch/padpdb42/saielli/PWSCF/TMA/CP/N.pbe-van_bm.UPF > reading ppot for species # 3 from file > /scratch/padpdb42/saielli/PWSCF/TMA/CP/C.pbe-van_bm.UPF > reading ppot for species # 4 from file > /scratch/padpdb42/saielli/PWSCF/TMA/CP/H.pbe-van_bm.UPF > wmass (calculated) = 233945.31 > > > > nbeg= 1 nomore= 100 iprint= 2 > reads from 51 writes on 51 > time step = 6.0000 > > parameters for electron dynamics: > emass= 400.00 emaec= 2.50ry > orthog. with lagrange multipliers: eps= 0.50E-07 > max= 15 > verlet algorithm for electron dynamics > with friction frice = 0.0000 , grease = 1.0000 > > > ions are allowed to move > ion dynamics with fricp = 0.0000 and greasp = > 1.0000 > ion dynamics with nose` temp. control: > temperature required= 300.00000(kelvin) nose` mass > = 16599.975 > > > internal stress tensor calculated > cell parameters are not allowed to move > > > iprsta = 1 > > unit vectors of full simulation cell > in real space: in > reciprocal space: > 27.5946 0.0000 0.0000 1.0000 > 0.0000 0.0000 > 0.0000 27.5946 0.0000 0.0000 > 1.0000 0.0000 > 0.0000 0.0000 27.5946 0.0000 > 0.0000 1.0000 > Proc planes cols G planes cols G > columns G > (dense grid) (smooth grid) (wavefct > grid) > 1 8 680 53548 7 456 29172 114 > 3634 > 2 8 680 53548 7 456 29172 114 > 3634 > 3 8 680 53548 7 456 29172 114 > 3630 > 4 8 680 53548 7 456 29152 114 > 3630 > 5 8 681 53549 7 455 29151 113 > 3629 > 6 8 680 53548 7 456 29168 114 > 3630 > 7 8 682 53554 7 456 29132 114 > 3630 > 8 8 682 53554 7 456 29132 114 > 3630 > 9 7 682 53554 7 454 29126 112 > 3628 > 10 7 682 53554 7 454 29118 112 > 3628 > 11 7 682 53554 7 454 29126 112 > 3628 > 12 7 682 53550 7 456 29160 116 > 3632 > 13 7 682 53550 7 456 29148 112 > 3628 > 14 7 682 53550 7 456 29156 112 > 3628 > 15 7 682 53550 6 456 29168 112 > 3628 > 16 7 682 53550 6 456 29164 114 > 3630 > 0 120 10901 856809 110 7289 466417 1813 > 58077 > > ggen: # of g vectors < gcut ng= 26774 > ggen: # of g vectors < gcuts ngs= 14586 > ggen: # of g vectors < gcutw ngw= 1817 > ggen: # of g shells < gcut ngl= 2655 > > > unit vectors of box grid cell > in real space: in > reciprocal space: > 2.2995 0.0000 0.0000 1.0000 > 0.0000 0.0000 > 0.0000 2.2995 0.0000 0.0000 > 1.0000 0.0000 > 0.0000 0.0000 2.2995 0.0000 > 0.0000 1.0000 > > ggenb: # of gb vectors < gcutb ngb = 243 > ggenb: # of gb shells < gcutb ngbl= 22 > initialization > > ibrav= 14 alat= 27.595 omega=21012.1616 > gcut= 3471.84 gcuts= 2314.56 gcutw= 578.64 > k-points: nkpt= 1 > > meshes: > === message truncated === _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com From degironc at sissa.it Fri Oct 15 17:54:13 2004 From: degironc at sissa.it (Stefano de Gironcoli) Date: Fri, 15 Oct 2004 17:54:13 +0200 Subject: [Pw_forum] error in davcio during restart calculations References: <416F8542.000001.31105@tide.yandex.ru> Message-ID: <416FF2A5.8080108@sissa.it> When you "restart" a calculation the program try to use the charge density, the potential and the wavefunctions on the disk in order to resume a previously interrupted run. If you increase the number of k-points the information stored in the wfcfile will not be 1) wrong if the order of the first k-points in the list has been modified 2) not sufficient since there will be new k-points with no stored wavefunctions ... You can exploit the results of a previous run only restarting from the scf potential specifying startingpot ="file" in the input. Stefano de Gironcoli Sergey Lisenkov wrote: >Dear PWscf authors and users, > >I restarted my calculations with increasing k-points. But I immeduatly got the error: >..... >The initial density is read from file 40bn.rho > Starting wfc from file > > total cpu time spent up to now is 3.23 secs > > Self-consistent Calculation > > iteration # 1 ecut= 35.00 ryd beta=0.15 > Davidson diagonalization (with overlap) > IOS = 158 > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > from davcio : error # 10 > i/o error in davcio > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > stopping ... > >If I do not use "restart' option, the code will not stop. Why? > >Thanks a lot, > Sergey >_______________________________________________ >Pw_forum mailing list >Pw_forum at pwscf.org >http://www.democritos.it/mailman/listinfo/pw_forum > > From proffess at yandex.ru Fri Oct 15 18:24:50 2004 From: proffess at yandex.ru (Sergey Lisenkov) Date: Fri, 15 Oct 2004 20:24:50 +0400 (MSD) Subject: [Pw_forum] error in davcio during restart calculations In-Reply-To: <416FF2A5.8080108@sissa.it> References: <416F8542.000001.31105@tide.yandex.ru> <416FF2A5.8080108@sissa.it> Message-ID: <416FF9D2.00000B.04947@colgate.yandex.ru> Dear Stefano and Eyvaz, Thank you very much for your help. Stefano: I changed my k-points (2 1 1) to (4 1 1). So, as you explained, it is OK. If I understand you properly, I should NOT specify option: restart_mode='restart', but Should USE restart_mode='from_scratch', and startingpot ="file" Am I right? Thanks a lot, Best wishes, Sergey From degironc at sissa.it Fri Oct 15 23:16:16 2004 From: degironc at sissa.it (Stefano de Gironcoli) Date: Fri, 15 Oct 2004 23:16:16 +0200 (CEST) Subject: [Pw_forum] error in davcio during restart calculations In-Reply-To: <416FF9D2.00000B.04947@colgate.yandex.ru> References: <416F8542.000001.31105@tide.yandex.ru> <416FF2A5.8080108@sissa.it> <416FF9D2.00000B.04947@colgate.yandex.ru> Message-ID: On Fri, 15 Oct 2004, Sergey Lisenkov wrote: > I changed my k-points (2 1 1) to (4 1 1). If I understand you properly, I should NOT specify option: > restart_mode='restart', > > but Should USE > restart_mode='from_scratch', > > and > startingpot ="file" > > Am I right? > Yes, Stefano de Gironcoli From sanix at operamail.com Sat Oct 16 05:46:59 2004 From: sanix at operamail.com (Aleksandr Tkachenko ) Date: Sat, 16 Oct 2004 04:46:59 +0100 Subject: [Pw_forum] Warning: negative or imaginary starting charge Message-ID: <20041016034659.49752398198@ws5-1.us4.outblaze.com> Hello, I'm using the last version of pwscf (2.1) on an Itanium2 architecture. On running example01 files (any calculation) I get the following warning in the output: " Warning: negative or imaginary starting charge -XXX.XXX 0.000000 1". Even with this warning, the al.scf.david is able to converge (in a large number of iterations) and other calculations do not converge at all with "too many bands are not converged" error. What can be the cause of the problem ? Thanks in advance, Alexander Tkachenko -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze From eyvaz_isaev at yahoo.com Sat Oct 16 10:14:42 2004 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Sat, 16 Oct 2004 01:14:42 -0700 (PDT) Subject: [Pw_forum] Warning: negative or imaginary starting charge In-Reply-To: <20041016034659.49752398198@ws5-1.us4.outblaze.com> Message-ID: <20041016081442.89932.qmail@web60301.mail.yahoo.com> Dear Alexander, Go ahead! That is just warning and arises from Fast Fourier Transformation of starting atomic charge density into real space. Doubtless, \rho(r) should be a real function. Best regards, Eyvaz. --- Aleksandr Tkachenko wrote: > Hello, > > I'm using the last version of pwscf (2.1) on an > Itanium2 architecture. On running example01 files > (any calculation) I get the following warning in the > output: > " Warning: negative or imaginary starting charge > -XXX.XXX 0.000000 1". > Even with this warning, the al.scf.david is able to > converge (in a large number of iterations) and other > calculations do not converge at all with "too many > bands are not converged" error. > > What can be the cause of the problem ? > > Thanks in advance, > Alexander Tkachenko > > -- > _____________________________________________________________ > Web-based SMS services available at > http://www.operamail.com. > From your mailbox to local or overseas cell phones. > > Powered by Outblaze > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com From proffess at yandex.ru Sat Oct 16 14:19:51 2004 From: proffess at yandex.ru (Sergey Lisenkov) Date: Sat, 16 Oct 2004 16:19:51 +0400 (MSD) Subject: [Pw_forum] Convergence during vc-relax Message-ID: <417111E7.000036.26678@colgate.yandex.ru> Dear PWscf authors, I am performing variable-cell relaxation of unit cell of my structure. Firstly. I performed atomic relaxation. My calculations were finished without any informations: ... atom 11 type 1 force = -0.00001671 0.00011974 -0.00001286 atom 12 type 1 force = 0.00000952 0.00008130 -0.00004912 atom 13 type 2 force = 0.00004235 0.00005128 -0.00004270 atom 14 type 2 force = 0.00005058 -0.00004839 -0.00005341 atom 15 type 2 force = 0.00004395 -0.00000478 0.00006488 atom 16 type 1 force = -0.00000257 0.00001235 -0.00008447 Total force = 0.000348 Total SCF correction = 0.001318 entering subroutine stress ... total stress (ryd/bohr**3) (kbar) P= -2.02 -0.00001869 0.00000015 -0.00000016 -2.75 0.02 -0.02 0.00000015 -0.00001119 -0.00000001 0.02 -1.65 0.00 -0.00000016 -0.00000001 -0.00001138 -0.02 0.00 -1.67 NEW-OLD atomic charge density approx. for the potential NEW K-POINTS 0.0833333 0.0000000 0.0000000 0.6666667 0.2500000 0.0000000 0.0000000 0.6666667 0.4166667 0.0000000 0.0000000 0.6666667 Writing file 40bn.save for program phonon PWSCF : 14h39m CPU time init_run : 4.90s CPU electrons : 36045.98s CPU ( 1000 calls, 36.046 s avg) forces : 3611.79s CPU ( 1000 calls, 3.612 s avg) stress : 8443.11s CPU ( 1000 calls, 8.443 s avg) electrons : 36045.98s CPU ( 1000 calls, 36.046 s avg) c_bands : 21691.54s CPU ( 4007 calls, 5.413 s avg) sum_band : 6934.47s CPU ( 4007 calls, 1.731 s avg) v_of_rho : 1456.36s CPU ( 8016 calls, 0.182 s avg) newd : 2189.58s CPU ( 4009 calls, 0.546 s avg) mix_rho : 191.46s CPU ( 4007 calls, 0.048 s avg) c_bands : 21691.54s CPU ( 4007 calls, 5.413 s avg) init_us_2 : 245.33s CPU ( 30042 calls, 0.008 s avg) cegterg : 21414.15s CPU ( 12021 calls, 1.781 s avg) sum_band : 6934.47s CPU ( 4007 calls, 1.731 s avg) becsum : 4.53s CPU ( 12021 calls, 0.000 s avg) addusdens : 1508.49s CPU ( 4007 calls, 0.376 s avg) cegterg : 21414.15s CPU ( 12021 calls, 1.781 s avg) Where is output geometry, output cell parameters? As I remember, in past versions it was printed during each step, in this version (2.1) no information at all. Does it mean convergence or not? What is criteria of convergence in vc-relax? Thank you very mcuh, Best wishes, Sergey From vsriniva at Princeton.EDU Sat Oct 16 18:55:32 2004 From: vsriniva at Princeton.EDU (Varadharajan Srinivasan) Date: Sat, 16 Oct 2004 12:55:32 -0400 (EDT) Subject: [Pw_forum] Convergence during vc-relax In-Reply-To: <417111E7.000036.26678@colgate.yandex.ru> References: <417111E7.000036.26678@colgate.yandex.ru> Message-ID: Hello, Could this be because you are using the default number of steps (nsteps = 50 in &control) for relaxation? If you increase this number of ions+electron steps the calculation should proceed to convergence. Regards, Vardha. On Sat, 16 Oct 2004, Sergey Lisenkov wrote: > Dear PWscf authors, > > I am performing variable-cell relaxation of unit cell of my structure. Firstly. I performed atomic relaxation. My calculations were finished without any informations: > ... > > atom 11 type 1 force = -0.00001671 0.00011974 -0.00001286 > atom 12 type 1 force = 0.00000952 0.00008130 -0.00004912 > atom 13 type 2 force = 0.00004235 0.00005128 -0.00004270 > atom 14 type 2 force = 0.00005058 -0.00004839 -0.00005341 > atom 15 type 2 force = 0.00004395 -0.00000478 0.00006488 > atom 16 type 1 force = -0.00000257 0.00001235 -0.00008447 > > Total force = 0.000348 Total SCF correction = 0.001318 > > > entering subroutine stress ... > > total stress (ryd/bohr**3) (kbar) P= -2.02 > -0.00001869 0.00000015 -0.00000016 -2.75 0.02 -0.02 > 0.00000015 -0.00001119 -0.00000001 0.02 -1.65 0.00 > -0.00000016 -0.00000001 -0.00001138 -0.02 0.00 -1.67 > > > NEW-OLD atomic charge density approx. for the potential > NEW K-POINTS > 0.0833333 0.0000000 0.0000000 0.6666667 > 0.2500000 0.0000000 0.0000000 0.6666667 > 0.4166667 0.0000000 0.0000000 0.6666667 > > Writing file 40bn.save for program phonon > > PWSCF : 14h39m CPU time > > init_run : 4.90s CPU > electrons : 36045.98s CPU ( 1000 calls, 36.046 s avg) > forces : 3611.79s CPU ( 1000 calls, 3.612 s avg) > stress : 8443.11s CPU ( 1000 calls, 8.443 s avg) > > electrons : 36045.98s CPU ( 1000 calls, 36.046 s avg) > c_bands : 21691.54s CPU ( 4007 calls, 5.413 s avg) > sum_band : 6934.47s CPU ( 4007 calls, 1.731 s avg) > v_of_rho : 1456.36s CPU ( 8016 calls, 0.182 s avg) > newd : 2189.58s CPU ( 4009 calls, 0.546 s avg) > mix_rho : 191.46s CPU ( 4007 calls, 0.048 s avg) > > c_bands : 21691.54s CPU ( 4007 calls, 5.413 s avg) > init_us_2 : 245.33s CPU ( 30042 calls, 0.008 s avg) > cegterg : 21414.15s CPU ( 12021 calls, 1.781 s avg) > > sum_band : 6934.47s CPU ( 4007 calls, 1.731 s avg) > becsum : 4.53s CPU ( 12021 calls, 0.000 s avg) > addusdens : 1508.49s CPU ( 4007 calls, 0.376 s avg) > > cegterg : 21414.15s CPU ( 12021 calls, 1.781 s avg) > > > Where is output geometry, output cell parameters? As I remember, in past versions it was printed during each step, in this version (2.1) no information at all. Does it mean convergence or not? What is criteria of convergence in vc-relax? > > Thank you very mcuh, > Best wishes, > Sergey > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From sanix at operamail.com Mon Oct 18 00:01:51 2004 From: sanix at operamail.com (Aleksandr Tkachenko ) Date: Sun, 17 Oct 2004 23:01:51 +0100 Subject: [Pw_forum] Warning: negative or imaginary starting charge Message-ID: <20041017220151.68250398198@ws5-1.us4.outblaze.com> Dear Eyvaz: What seems strange to me is that it takes 26 iterations for me to converge al.scf.david input while it takes only 3 iterations in the "reference" case. Another thing is that cu.scf.cg and few other tests from example01 do not converge at all with "too many bands are not converged" error. It seems that the initial density is not same in my case. Could it be some 32-64 bit or endian issue in the compilation? Best Regards, Alexander -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze From adrainzhou at yahoo.com.cn Mon Oct 18 04:51:10 2004 From: adrainzhou at yahoo.com.cn (Adrain Zhou) Date: Mon, 18 Oct 2004 10:51:10 +0800 (CST) Subject: [Pw_forum] Problems on install PWSCF! Message-ID: <20041018025110.66710.qmail@web15808.mail.cnb.yahoo.com> Dear all, I still met some problems on compiling pwscf on AMD opteron64 using LAM-MPI and pgi. pgf90-Warning-Unknown switch: -pthread broadcast.o(.text+0x28): In function `broadcast_': : undefined reference to `mpi_barrier_' broadcast.o(.text+0x48): In function `broadcast_': : undefined reference to `mpi_bcast_' cgather_sym.o(.text+0xfa): In function `cgather_sym_': : undefined reference to `mpi_barrier_' cgather_sym.o(.text+0x13b): In function `cgather_sym_': : undefined reference to `mpi_allgatherv_' cgather_sym.o(.text+0x169): In function `cgather_sym_': : undefined reference to `mpi_barrier_' check.o(.text+0x180): In function `check_': : undefined reference to `mpi_barrier_' check.o(.text+0x1d2): In function `check_': : undefined reference to `mpi_allreduce_' check.o(.text+0x224): In function `check_': : undefined reference to `mpi_allreduce_' check.o(.text+0x446): In function `check_': : undefined reference to `mpi_bcast_' error.o(.text+0x2e4): In function `errore_': : undefined reference to `mpi_abort_' fft_scatter.o(.text+0x43c): In function `fft_scatter1_': : undefined reference to `mpi_barrier_' fft_scatter.o(.text+0x484): In function `fft_scatter1_': : undefined reference to `mpi_alltoallv_' fft_scatter.o(.text+0x4bb): In function `fft_scatter1_': : undefined reference to `mpi_barrier_' fft_scatter.o(.text+0x503): In function `fft_scatter1_': : undefined reference to `mpi_alltoallv_' gather.o(.text+0xfa): In function `gather_': : undefined reference to `mpi_barrier_' gather.o(.text+0x144): In function `gather_': : undefined reference to `mpi_gatherv_' init_pool.o(.text+0x38): In function `init_pool_': : undefined reference to `mpi_barrier_' init_pool.o(.text+0x74): In function `init_pool_': : undefined reference to `mpi_comm_split_' init_pool.o(.text+0xaf): In function `init_pool_': : undefined reference to `mpi_barrier_' init_pool.o(.text+0xeb): In function `init_pool_': : undefined reference to `mpi_comm_split_' maximum.o(.text+0x17): In function `extreme_': : undefined reference to `mpi_barrier_' maximum.o(.text+0x49): In function `extreme_': : undefined reference to `mpi_allreduce_' maximum.o(.text+0x78): In function `extreme_': : undefined reference to `mpi_allreduce_' poolbcast.o(.text+0x28): In function `poolbcast_': : undefined reference to `mpi_barrier_' poolbcast.o(.text+0x48): In function `poolbcast_': : undefined reference to `mpi_bcast_' poolextreme.o(.text+0x24): In function `poolextreme_': : undefined reference to `mpi_barrier_' poolextreme.o(.text+0x75): In function `poolextreme_': : undefined reference to `mpi_allreduce_' poolextreme.o(.text+0xc8): In function `poolextreme_': : undefined reference to `mpi_allreduce_' poolrecover.o(.text+0x95): In function `poolrecover_': : undefined reference to `mpi_barrier_' poolrecover.o(.text+0xe1): In function `poolrecover_': : undefined reference to `mpi_send_' poolrecover.o(.text+0x1de): In function `poolrecover_': : undefined reference to `mpi_recv_' poolrecover.o(.text+0x2c5): In function `ipoolrecover_': : undefined reference to `mpi_barrier_' poolrecover.o(.text+0x311): In function `ipoolrecover_': : undefined reference to `mpi_send_' poolrecover.o(.text+0x40e): In function `ipoolrecover_': : undefined reference to `mpi_recv_' poolreduce.o(.text+0x4d): In function `poolreduce_': : undefined reference to `mpi_barrier_' poolreduce.o(.text+0xc8): In function `poolreduce_': : undefined reference to `mpi_allreduce_' poolreduce.o(.text+0x165): In function `poolreduce_': : undefined reference to `mpi_allreduce_' reduce.o(.text+0x44): In function `reduce_': : undefined reference to `mpi_barrier_' reduce.o(.text+0xc8): In function `reduce_': : undefined reference to `mpi_allreduce_' reduce.o(.text+0x165): In function `reduce_': : undefined reference to `mpi_allreduce_' reduce.o(.text+0x22c): In function `ireduce_': : undefined reference to `mpi_barrier_' reduce.o(.text+0x2b5): In function `ireduce_': : undefined reference to `mpi_allreduce_' reduce.o(.text+0x382): In function `ireduce_': : undefined reference to `mpi_allreduce_' scatter.o(.text+0xfa): In function `scatter_': : undefined reference to `mpi_barrier_' scatter.o(.text+0x145): In function `scatter_': : undefined reference to `mpi_scatterv_' ../Modules/fft_base.o(.text+0x36c0): In function `fft_base_fft_scatter_': : undefined reference to `mpi_barrier_' ../Modules/fft_base.o(.text+0x3711): In function `fft_base_fft_scatter_': : undefined reference to `mpi_alltoallv_' ../Modules/fft_base.o(.text+0x375b): In function `fft_base_fft_scatter_': : undefined reference to `mpi_barrier_' ../Modules/fft_base.o(.text+0x37ac): In function `fft_base_fft_scatter_': : undefined reference to `mpi_alltoallv_' make[1]: *** [memory.x] Error 2 Here is the make.sys file I used at first, # Use the local copy of fftw CPPFLAGS = -D__LINUX64 -D__PGI -D__PARA -D_MPI -D_LAM -D__FFTW -D__USE_INTERNAL_FFTW \ -I$(OSHOME)/include -I./ # # Fortran compiler: F90 =mpif90 F77 =mpif77 CC =mpicc # F90FLAGS = -w -fast -r8 F77FLAGS = -w -fast -r8 CCFLAGS = $(CPPFLAGS) #F90FLAGS = -w -fast -r8 -Msecond_underscore #F77FLAGS = -w -fast -r8 -Msecond_underscore #CCFLAGS = $(CPPFLAGS) # # MODULEFLAG= -I$(OSHOME)/Modules -I$(OSHOME)/PW -I$(OSHOME)/PH # # LIBS = -L/opt/pgi/linux86-64/5.2/lib $(OSHOME)/acml/libacml.a $(FFTW_LIB) # LD=$(F90) LDFLAGS = -lg2c -lpthread -lm $(OSHOME)/flib/ptools.a $(OSHOME)/flib/flib.a $(OSHOME)/clib/clib.a $(LIBS) $(MODULEFLAG) Then I made some changes in make.sys file. I just add Msecond_underscore option in the F90flags and F77flag. F90FLAGS = -w -fast -r8 -Msecond_underscore F77FLAGS = -w -fast -r8 -Msecond_underscore the former problems disappeared, but the new problems is produced input.o(.text+0x7857): In function `verify_tmpdir__': : undefined reference to `c_mkdir__' ../Modules/berry_phase.o(.text+0x4b): In function `berry_phase_ln_setup__': : undefined reference to `ln_alloc__' ../Modules/berry_phase.o(.text+0xa8): In function `berry_phase_ln_setup__': : undefined reference to `ln_set__' ../Modules/berry_phase.o(.text+0xb7): In function `berry_phase_ln_setup__': : undefined reference to `ln_activate__' ../Modules/berry_phase.o(.text+0xd5): In function `berry_phase_ln_closeup__': : undefined reference to `ln_dealloc__' ../Modules/berry_phase.o(.text+0x11bb): In function `berry_phase_indi_of_ig__': : undefined reference to `ln_ind__' ../Modules/berry_phase.o(.text+0x11f6): In function `berry_phase_indi_of_ig__': : undefined reference to `ln_ind__' ../Modules/berry_phase.o(.text+0x1231): In function `berry_phase_indi_of_ig__': : undefined reference to `ln_ind__' ../Modules/berry_phase.o(.text+0x1270): In function `berry_phase_indi_of_ig__': : undefined reference to `ln_ind__' ../Modules/berry_phase.o(.text+0x129f): In function `berry_phase_indi_of_ig__': : undefined reference to `ln_ind__' ../Modules/berry_phase.o(.text+0x1303): more undefined references to `ln_ind__' follow ../Modules/fft_scalar.o(.text+0x147): In function `fft_scalar_cft_1z__': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x169): In function `fft_scalar_cft_1z__': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x18f): In function `fft_scalar_cft_1z__': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x1b5): In function `fft_scalar_cft_1z__': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x252): In function `fft_scalar_cft_1z__': : undefined reference to `fft_z_stick__' ../Modules/fft_scalar.o(.text+0x2bd): In function `fft_scalar_cft_1z__': : undefined reference to `fft_z_stick__' ../Modules/fft_scalar.o(.text+0x789): In function `fft_scalar_cft_2xy__': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x7ab): In function `fft_scalar_cft_2xy__': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x7d3): In function `fft_scalar_cft_2xy__': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x7fb): In function `fft_scalar_cft_2xy__': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x81d): In function `fft_scalar_cft_2xy__': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x83f): In function `fft_scalar_cft_2xy__': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x869): In function `fft_scalar_cft_2xy__': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x893): In function `fft_scalar_cft_2xy__': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x93c): In function `fft_scalar_cft_2xy__': : undefined reference to `fft_x_stick__' ../Modules/fft_scalar.o(.text+0x9f4): In function `fft_scalar_cft_2xy__': : undefined reference to `fft_y_stick__' ../Modules/fft_scalar.o(.text+0xb34): In function `fft_scalar_cft_2xy__': : undefined reference to `fft_y_stick__' ../Modules/fft_scalar.o(.text+0xb8d): In function `fft_scalar_cft_2xy__': : undefined reference to `fft_x_stick__' ../Modules/fft_scalar.o(.text+0xccf): In function `fft_scalar_cfft3d_': : undefined reference to `destroy_plan_3d__' ../Modules/fft_scalar.o(.text+0xcee): In function `fft_scalar_cfft3d_': : undefined reference to `destroy_plan_3d__' ../Modules/fft_scalar.o(.text+0xd16): In function `fft_scalar_cfft3d_': : undefined reference to `create_plan_3d__' ../Modules/fft_scalar.o(.text+0xd3e): In function `fft_scalar_cfft3d_': : undefined reference to `create_plan_3d__' ../Modules/fft_scalar.o(.text+0xdbf): In function `fft_scalar_cfft3d_': : undefined reference to `fftw_inplace_drv_3d__' ../Modules/fft_scalar.o(.text+0xe44): In function `fft_scalar_cfft3d_': : undefined reference to `fftw_inplace_drv_3d__' ../Modules/fft_scalar.o(.text+0xff9): In function `fft_scalar_cfft3ds_': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x101b): In function `fft_scalar_cfft3ds_': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x103d): In function `fft_scalar_cfft3ds_': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x105f): In function `fft_scalar_cfft3ds_': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x1081): In function `fft_scalar_cfft3ds_': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x10a3): more undefined references to `destroy_plan_1d__' follow ../Modules/fft_scalar.o(.text+0x10d0): In function `fft_scalar_cfft3ds_': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x10fd): In function `fft_scalar_cfft3ds_': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x112a): In function `fft_scalar_cfft3ds_': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x1157): In function `fft_scalar_cfft3ds_': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x1181): In function `fft_scalar_cfft3ds_': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x11ab): more undefined references to `create_plan_1d__' follow ../Modules/fft_scalar.o(.text+0x130d): In function `fft_scalar_cfft3ds_': : undefined reference to `fftw_inplace_drv_1d__' ../Modules/fft_scalar.o(.text+0x13dd): In function `fft_scalar_cfft3ds_': : undefined reference to `fftw_inplace_drv_1d__' ../Modules/fft_scalar.o(.text+0x1445): In function `fft_scalar_cfft3ds_': : undefined reference to `fftw_inplace_drv_1d__' ../Modules/fft_scalar.o(.text+0x14a6): In function `fft_scalar_cfft3ds_': : undefined reference to `fftw_inplace_drv_1d__' ../Modules/fft_scalar.o(.text+0x153d): In function `fft_scalar_cfft3ds_': : undefined reference to `fftw_inplace_drv_1d__' ../Modules/fft_scalar.o(.text+0x163d): more undefined references to `fftw_inplace_drv_1d__' follow ../Modules/fft_scalar.o(.text+0x1864): In function `fft_scalar_cft_b__': : undefined reference to `destroy_plan_1d__' ../Modules/fft_scalar.o(.text+0x1880): In function `fft_scalar_cft_b__': : undefined reference to `create_plan_1d__' ../Modules/fft_scalar.o(.text+0x189f): In function `fft_scalar_cft_b__': : undefined reference to `destroy_plan_2d__' ../Modules/fft_scalar.o(.text+0x18be): In function `fft_scalar_cft_b__': : undefined reference to `create_plan_2d__' ../Modules/fft_scalar.o(.text+0x195d): In function `fft_scalar_cft_b__': : undefined reference to `fftw_inplace_drv_1d__' ../Modules/fft_scalar.o(.text+0x199f): In function `fft_scalar_cft_b__': : undefined reference to `fftw_inplace_drv_2d__' Could anybody telll me what is wrong with it? Any comments are highly appreciated. Many thanks! Regards, Adrain --------------------------------- Do You Yahoo!? 150??MP3???????????? ??????????????????? 1G??1000??????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20041018/e34cbf79/attachment.htm From rjxiao at blem.ac.cn Mon Oct 18 05:53:48 2004 From: rjxiao at blem.ac.cn (rjxiao) Date: Mon, 18 Oct 2004 11:53:48 +0800 Subject: [Pw_forum] about Hubbard_alpha Message-ID: <20041018115348.00663db3@server.blem.ac.cn> Dear all, When I use the LDA+U in the PWSCF, I found that there is a parameter which is called "Hubbard_alpha". I can't find its meaning in the help of PWSCF. Can you tell me how to set this parameter? Thank you very much. Best regards, Sincerely, Ruijuan Xiao Institute of Physics, Chinese Academy of Sciences From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Mon Oct 18 09:25:08 2004 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Mon, 18 Oct 2004 09:25:08 +0200 (CEST) Subject: [Pw_forum] Problems on install PWSCF! In-Reply-To: <20041018025110.66710.qmail@web15808.mail.cnb.yahoo.com> Message-ID: On Mon, 18 Oct 2004, Adrain Zhou wrote: dear adrain, AZ> Dear all, AZ> AZ> I still met some problems on compiling pwscf on AMD opteron64 using LAM-MPI and pgi. it would occasionally help, if you'd actually _read_ what people are suggesting. i'v already told you, that your LAM-MPI installation obviously was compiled with g77 and thus different underscoring conventions. for CPMD you may be able to work around this, by just adding -Msecond_underscore but for pwscf, where you have more external dependencies, and more this will be a bit trickier. AZ> AZ> pgf90-Warning-Unknown switch: -pthread AZ> broadcast.o(.text+0x28): In function `broadcast_': AZ> : undefined reference to `mpi_barrier_' AZ> broadcast.o(.text+0x48): In function `broadcast_': [...] AZ> Here is the make.sys file I used at first, AZ> # Use the local copy of fftw AZ> CPPFLAGS = -D__LINUX64 -D__PGI -D__PARA -D_MPI -D_LAM -D__FFTW -D__USE_INTERNAL_FFTW \ AZ> -I$(OSHOME)/include -I./ AZ> # AZ> # Fortran compiler: AZ> F90 =mpif90 AZ> F77 =mpif77 AZ> CC =mpicc AZ> # AZ> F90FLAGS = -w -fast -r8 AZ> F77FLAGS = -w -fast -r8 [...] ok, as i wrote to you before. for this you need to recompile your LAM-MPI package to use the pgf90 compiler by default with default underscoring conventions. there is a ready to use RPM for that at: http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/cpmd-linux.html#mpi just use mpipgf90/mpipgf77 to access the pgi compilers, or you can pick up the corresponding source rpm, and either rebuild it or unpack it and look at the .spec file to see, how it was compiled. you'll run into more problems, if you don't fix this. for espresso, there still is a workaround. AZ> F90FLAGS = -w -fast -r8 -Msecond_underscore AZ> F77FLAGS = -w -fast -r8 -Msecond_underscore AZ> the former problems disappeared, but the new problems is produced AZ> input.o(.text+0x7857): In function `verify_tmpdir__': AZ> : undefined reference to `c_mkdir__' AZ> ../Modules/berry_phase.o(.text+0x4b): In function `berry_phase_ln_setup__': AZ> : undefined reference to `ln_alloc__' [...] of course, now the underscoring conventions don't match the ones, that were found during configuration. now if you just search for the definition of those symbols, e.g. by [91|9:16]~/compile/pwscf> grep -i c_mkdir */*.* clib/c_mkdir.c: fatal( "c_mkdir: virtual memory exhausted" ) ; clib/c_mkdir.c:int C_MKDIR( const char * dirname , const int * length ) clib/c_mkdir.c:} /* c_mkdir_ */ CPV/path_routines.f90: INTEGER, EXTERNAL :: C_MKDIR CPV/path_routines.f90: ios = C_MKDIR( TRIM( outdir ), LEN_TRIM( outdir ) ) FPMD/path_routines.f90: INTEGER, EXTERNAL :: C_MKDIR FPMD/path_routines.f90: ios = C_MKDIR( TRIM( outdir ), LEN_TRIM( outdir ) ) include/c_defs.h:# define C_MKDIR C_MKDIR include/c_defs.h:# define C_MKDIR c_mkdir_ include/c_defs.h:# define C_MKDIR c_mkdir_ include/c_defs.h:# define C_MKDIR c_mkdir_ include/c_defs.h:# define C_MKDIR c_mkdir__ include/c_defs.h:# define C_MKDIR c_mkdir include/c_defs.h:# define C_MKDIR c_mkdir_ include/c_defs.h:# define C_MKDIR c_mkdir__ PW/input.f90: INTEGER, EXTERNAL :: c_mkdir PW/input.f90: ios = c_mkdir( TRIM( tmp_dir ), LEN_TRIM( tmp_dir ) ) you'll see, that those underscoring conventions are set in the file include/c_defs.h (or clib/cp.h if you use the v2.0.x sources). a closer look into that file reveals, that the matching underscoring converntions should be used, when you have define __GNU_LINK in combination with __PGI. so add -D__GNU_LINK to your CPPFLAGS and look forward to having much (negative) fun with the next package, that is not that flexible. regards, axel kohlmeyer. AZ> Adrain AZ> AZ> AZ> AZ> AZ> --------------------------------- AZ> Do You Yahoo!? AZ> 150????MP3???????????????????????? AZ> ?????????????????????????????????????? AZ> 1G????1000?????????????????????? -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at rub.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Mon Oct 18 09:40:34 2004 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Mon, 18 Oct 2004 09:40:34 +0200 (CEST) Subject: [Pw_forum] about Hubbard_alpha In-Reply-To: <20041018115348.00663db3@server.blem.ac.cn> Message-ID: On Mon, 18 Oct 2004, rjxiao wrote: RX> Dear all, RX> RX> When I use the LDA+U in the PWSCF, I found that there is a parameter RX> which is called "Hubbard_alpha". I can't find its meaning in the help RX> of PWSCF. Can you tell me how to set this parameter? the explanation of that parameter in the file Doc/INPUT_PW refers to some papers. you can look up the required parameters for some elements in them. best regards, axel kohlmeyer RX> Thank you very much. RX> RX> Best regards, RX> RX> Sincerely, RX> Ruijuan Xiao RX> Institute of Physics, RX> Chinese Academy of Sciences RX> RX> _______________________________________________ RX> Pw_forum mailing list RX> Pw_forum at pwscf.org RX> http://www.democritos.it/mailman/listinfo/pw_forum RX> RX> -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at rub.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= From g.ballabio at cineca.it Mon Oct 18 09:40:51 2004 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Mon, 18 Oct 2004 09:40:51 +0200 (MEST) Subject: [Pw_forum] Warning: negative or imaginary starting charge In-Reply-To: <20041016034659.49752398198@ws5-1.us4.outblaze.com> References: <20041016034659.49752398198@ws5-1.us4.outblaze.com> Message-ID: <1098085250.19621.4.camel@localhost.localdomain> On Sat, 2004-10-16 at 05:46, Aleksandr Tkachenko wrote: > I'm using the last version of pwscf (2.1) on an Itanium2 architecture. On running example01 files (any calculation) I get the following warning in the output: > " Warning: negative or imaginary starting charge -XXX.XXX 0.000000 1". > Even with this warning, the al.scf.david is able to converge (in a large number of iterations) and other calculations do not converge at all with "too many bands are not converged" error. Aleksandr, I've successfully compiled and run PWscf on an Itanium2 machine using the Intel compilers version 8.0 and the Intel MKL libraries version 7.0. All examples seem to run correctly. Which compiler are you using? Did you use the "configure" script for configuration? Did it give any warnings? Could you post the "make.sys" file used for compilation? Gerardo From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Mon Oct 18 10:15:44 2004 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Mon, 18 Oct 2004 10:15:44 +0200 (CEST) Subject: [Pw_forum] Warning: negative or imaginary starting charge In-Reply-To: <20041017220151.68250398198@ws5-1.us4.outblaze.com> Message-ID: On Sun, 17 Oct 2004, Aleksandr Tkachenko wrote: dear aleksandr, i may have recently stumbled upon a similar problem. in my case it turned out, that the fftw headers and libraries did not match. i had compiled and installed a custom fftw library without the type prefix. since espresso also has an fftw header (which defines a double precision ABI), it can easily happen, that you compile for a double precision fftw, but link to a single precision library. in my case that produced NaNs, but it only fully showed after a fresh recompile, as some parts were previously compiled with a matching header. so you could check where you pick up the fftw headers and libraries. in that light, it may also be a good idea to rename the internal fftw header file, and add support to prefer 'type-renamed' header (dfftw.h) and library (libdfftw.a) to the default names if available. best regards, axel kohlmeyer. AT> Dear Eyvaz: AT> AT> What seems strange to me is that it takes 26 iterations for me to AT> converge al.scf.david input while it takes only 3 iterations in the AT> "reference" case. Another thing is that cu.scf.cg and few other tests AT> from example01 do not converge at all with "too many bands are not AT> converged" error. AT> It seems that the initial density is not same in my case. Could it be some 32-64 bit or endian issue in the compilation? AT> AT> Best Regards, AT> Alexander AT> AT> -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at rub.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= From philippe.baranek at edfgdf.fr Tue Oct 19 12:00:04 2004 From: philippe.baranek at edfgdf.fr (Philippe BARANEK) Date: Tue, 19 Oct 2004 12:00:04 +0200 Subject: [Pw_forum] vc-relax Message-ID: Dear pwscf users, I have got some problems with vc-relax calculations The calculations are running without printing any informations about new cell parameters and atomic positions. Furthermore, the optimisations seems to be locked around the pressure from the starting. The variation of stress matrix components are of the order of the second decimal in kbar. Would anyone of you have the same problems and could help me ? Thanks in advance Best Regards Philippe From xhongjun at mail.ustc.edu.cn Tue Oct 19 15:26:59 2004 From: xhongjun at mail.ustc.edu.cn (xianghjun) Date: Tue, 19 Oct 2004 21:26:59 +0800 Subject: [Pw_forum] About NON COLLINEAR magnetism Message-ID: <41751623.9020505@mail.ustc.edu.cn> Dear all: I want to deal with the non-collinear magnetism systems using pwnc.x, would you please recommend some references about the implementation in PWNC? P.S., I want to get the exchange parameter J using PWNC, is that possible? Best regards, xianghjun From eyvaz_isaev at yahoo.com Tue Oct 19 15:59:56 2004 From: eyvaz_isaev at yahoo.com (Eyvaz Isaev) Date: Tue, 19 Oct 2004 06:59:56 -0700 (PDT) Subject: [Pw_forum] vc-relax In-Reply-To: Message-ID: <20041019135956.8228.qmail@web60304.mail.yahoo.com> Hi, Did you try "verbosity=high"? Another possible solution comes from Axel Kohlmeyer: try nstep >50. Hope it helps. Bests, Eyvaz. --- Philippe BARANEK wrote: > Dear pwscf users, > > I have got some problems with vc-relax calculations > The calculations are running without printing any > informations > about new cell parameters and atomic positions. > Furthermore, > the optimisations seems to be locked around the > pressure from > the starting. The variation of stress matrix > components are of the order > of the second decimal in kbar. > > Would anyone of you have the same problems and could > help me ? > > Thanks in advance > > Best Regards > > Philippe > > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From philippe.baranek at edfgdf.fr Tue Oct 19 16:22:56 2004 From: philippe.baranek at edfgdf.fr (Philippe BARANEK) Date: Tue, 19 Oct 2004 16:22:56 +0200 Subject: [Pw_forum] =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_[Pw=5Fforum]_vc-relax?= Message-ID: Hi Eyvaz, Thank you, I am trying it. But there is another problem as I wrote in my mail it seems to do a loop around the pressure associated to the starting point. It doesn't create also the temporary files associated to the optimisation " ave avec e eal p tv ". So it seems it is doing a loop around the same geometru without stopping. Have you got the same thing, when you had your troubles ? Best Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20041019/c852e4e7/attachment.htm From guoyanjun at yahoo.com Wed Oct 20 04:46:11 2004 From: guoyanjun at yahoo.com (Yan-jun Guo) Date: Tue, 19 Oct 2004 19:46:11 -0700 (PDT) Subject: [Pw_forum] Is that possible to make a parallel version of PwSCF under Win2K? Message-ID: <20041020024611.44020.qmail@web52703.mail.yahoo.com> Dear all: Maybe,it is a silly question. I'm a beginner of PwSCF. But the computer cluster in our lab is built under Win2K/MPI.Is that possible to make a parallel version of PwSCF under Win2K and cygwin? Best regards _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From cbarreteau at cea.fr Wed Oct 20 08:59:58 2004 From: cbarreteau at cea.fr (Cyrille Barreteau) Date: Wed, 20 Oct 2004 08:59:58 +0200 (CEST) Subject: [Pw_forum] difficult problem Message-ID: <34451.132.166.21.1.1098255598.squirrel@132.166.21.1> Dear pwscf users and developpers, I have recently been contacted by a group doing nasty experiments on magnetic materials!! They would be interested in getting the influence of spin-orbit on the conductance of a magnetic material (a break junction, that would be modelized by a simple nanowire:-) I know that one can get conductance with pwscf and that spin-orbit has recently been implemented in the espresso release. But is-it possible to calculate the conductance in presence of spin-orbit? The idea would be to calculate the conductance for various spin orientations (great idea from a weird mind:-) Thanks in advance cyrille -- ================================================ Cyrille Barreteau | phone:+33 (0)1 69 08 29 51 CEA Saclay | fax : +33 (0)1 69 08 84 46 DSM/DRECAM/SPCSI | email: cbarreteau at cea.fr Batiment 462 | 91191 Gif sur Yvette Cedex FRANCE ~~~~~~~~~~~~~~~~~~~~~~~~ web : http://www-drecam.cea.fr/spcsi/groupe1.htm ================================================ From ps at ned.sims.nrc.ca Fri Oct 15 13:38:50 2004 From: ps at ned.sims.nrc.ca (Serguei Patchkovskii) Date: Fri, 15 Oct 2004 07:38:50 -0400 (EDT) Subject: [Pw_forum] ESpresso with Intel In-Reply-To: <200410150808.i9F88sn00365@yello.theochem.ruhr-uni-bochum.de> Message-ID: On Fri, 15 Oct 2004, Axel Kohlmeyer wrote: > then there must be another screw-up. those missing symbols > _are_ in the pthread library. please make sure, that you have > > "LS" == Lubomir Smrcok writes: > > Dear Axel, > > this is, unfortunately, of no help. I have got the same messages. > > Best wishes, For some reason, this occationally happens in static links with ifc. I believe the reason is the library order during the link stage - if pthread appears before the first library which needs it's symbols, static linker won't pull anything from libpthread. Adding this: -Wl,-u,pthread_self -lpthread to LIBS if often easier than trying to debug the link order. 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 ruijuanxiao at yahoo.com Mon Oct 18 05:55:08 2004 From: ruijuanxiao at yahoo.com (Ruijuan Xiao) Date: Sun, 17 Oct 2004 20:55:08 -0700 (PDT) Subject: [Pw_forum] about Hubbard_alpha Message-ID: <20041018035508.48044.qmail@web13124.mail.yahoo.com> Dear all, When I use the LDA+U in the PWSCF, I found that there is a parameter which is called "Hubbard_alpha". I can't find its meaning in the help of PWSCF. Can you tell me how to set this parameter? Thank you very much. Best regards, Sincerely, Ruijuan Xiao --------------------------------- Do you Yahoo!? vote.yahoo.com - Register online to vote today! -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20041017/92897e20/attachment.htm From xhongjun at mail.ustc.edu.cn Wed Oct 20 10:04:45 2004 From: xhongjun at mail.ustc.edu.cn (xianghjun) Date: Wed, 20 Oct 2004 16:04:45 +0800 Subject: [Pw_forum] About NON COLLINEAR magnetism In-Reply-To: <41751623.9020505@mail.ustc.edu.cn> References: <41751623.9020505@mail.ustc.edu.cn> Message-ID: <41761C1D.50509@mail.ustc.edu.cn> xianghjun wrote: > Dear all: > I want to deal with the non-collinear magnetism systems using pwnc.x, > would you please recommend some references about the implementation in > PWNC? > P.S., I want to get the exchange parameter J using PWNC, is that > possible? > > > Best regards, > xianghjun > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum An other related question is: Can PWNC deal with spin spirals? I have examined the input help file "INPUT_NC", it seems that the answer is "no". Am I right? Best regards, xianghjun From rgebauer at ictp.trieste.it Wed Oct 20 10:23:13 2004 From: rgebauer at ictp.trieste.it (Ralph Gebauer) Date: Wed, 20 Oct 2004 10:23:13 +0200 Subject: [Pw_forum] About NON COLLINEAR magnetism In-Reply-To: <41761C1D.50509@mail.ustc.edu.cn> References: <41751623.9020505@mail.ustc.edu.cn> <41761C1D.50509@mail.ustc.edu.cn> Message-ID: <41762071.6050500@ictp.trieste.it> xianghjun wrote: > An other related question is: > Can PWNC deal with spin spirals? > I have examined the input help file "INPUT_NC", > it seems that the answer is "no". > Am I right? > Best regards, > xianghjun > Dear Xianghjun, Unfortunately I'm not very familiar with the current implementation of the noncollinear spin calculations in pwscf. However, concerning your question about spin spirals: Those can be quite easily calculated using a "generalized Bloch theorem" in which a translation by a lattice vector is also associated with a rotation of the spin direction by a given angle. In this way, spin spirals can be calculated without using a large supercell, and spin spirals of arbitrary wave vector can therefore be modelled using just the single unit cell. I'm quite sure that this generalized Bloch theorem is no longer implemented in pwscf, but it is really not difficult to program it (I had done so in a very old version od the code). If you are interested in details of this, and also in how one can estimate the coupling constant J, you might want to have a look at my PhD thesis which can be downloaded from http://www.cecam.fr/activities/theses/theses.html . Hope that helps, 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 From rjxiao at blem.ac.cn Wed Oct 20 12:58:38 2004 From: rjxiao at blem.ac.cn (rjxiao) Date: Wed, 20 Oct 2004 18:58:38 +0800 Subject: [Pw_forum] about Hubbard_alpha In-Reply-To: Message-ID: <20041020185838.4e307083@server.blem.ac.cn> Dear axel kohlmeyer: Thank you very much.I have read those papers. It really helpful. Best regards, Sincerely, Ruijuan Xiao Institute of Physics, Chinese Academy of Sciences ----- Original Message ----- From: Axel Kohlmeyer To: PW Forum , rjxiao Sent: Mon, 18 Oct 2004 15:40:34 +0800 Subject: Re: [Pw_forum] about Hubbard_alpha > On Mon, 18 Oct 2004, rjxiao wrote: > > RX> Dear all, > RX> > > RX> When I use the LDA+U in the PWSCF, I found that there is a parameter > RX> which is called "Hubbard_alpha". I can't find its meaning in the help > RX> of PWSCF. Can you tell me how to set this parameter? > > the explanation of that parameter in the file Doc/INPUT_PW > refers to some papers. you can look up the required parameters for > some elements in them. > > best regards, > axel kohlmeyer > > RX> Thank you very much. > RX> > RX> Best regards, > RX> > RX> Sincerely, > RX> Ruijuan Xiao > RX> Institute of Physics, > RX> Chinese Academy of Sciences > RX> > RX> _______________________________________________ > RX> Pw_forum mailing list > RX> Pw_forum at pwscf.org > RX> http://www.democritos.it/mailman/listinfo/pw_forum > RX> > RX> > > -- > > > ======================================================================= > Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at rub.de > Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 > Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 > D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ > ======================================================================= > > > From rjxiao at blem.ac.cn Wed Oct 20 13:07:31 2004 From: rjxiao at blem.ac.cn (rjxiao) Date: Wed, 20 Oct 2004 19:07:31 +0800 Subject: [Pw_forum] about Hubbard_alpha In-Reply-To: Message-ID: <20041020190731.94860fe2@server.blem.ac.cn> Dear Axel Kohlmeyer, Thank you very much. I have read those papers.They are really helpful. Best regards, Sincerely, Ruijuan Xiao Institute of Physics, Chinese Academy of Sciences ----- Original Message ----- From: Axel Kohlmeyer To: PW Forum , rjxiao Sent: Mon, 18 Oct 2004 15:40:34 +0800 Subject: Re: [Pw_forum] about Hubbard_alpha > On Mon, 18 Oct 2004, rjxiao wrote: > > RX> Dear all, > RX> > > RX> When I use the LDA+U in the PWSCF, I found that there is a parameter > RX> which is called "Hubbard_alpha". I can't find its meaning in the help > RX> of PWSCF. Can you tell me how to set this parameter? > > the explanation of that parameter in the file Doc/INPUT_PW > refers to some papers. you can look up the required parameters for > some elements in them. > > best regards, > axel kohlmeyer > > RX> Thank you very much. > RX> > RX> Best regards, > RX> > RX> Sincerely, > RX> Ruijuan Xiao > RX> Institute of Physics, > RX> Chinese Academy of Sciences > RX> > RX> _______________________________________________ > RX> Pw_forum mailing list > RX> Pw_forum at pwscf.org > RX> http://www.democritos.it/mailman/listinfo/pw_forum > RX> > RX> > > -- > > > ======================================================================= > Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at rub.de > Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 > Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 > D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ > ======================================================================= > > > From Fabris at democritos.it Wed Oct 20 13:24:48 2004 From: Fabris at democritos.it (Stefano Fabris) Date: Wed, 20 Oct 2004 13:24:48 +0200 (CEST) Subject: [Pw_forum] about Hubbard_alpha In-Reply-To: <20041018035508.48044.qmail@web13124.mail.yahoo.com> Message-ID: Dear Ruijuan, the value of "Hubbard_alpha" has to be zero in your routine LDA+U calculations. That variable is used ONLY when you want to estimate the value of the parameter U from a set of calculations. This is done by adding to the effective potential a local perturbation (proportional to the value of "hubbard_alpha") acting on the localized states of a specific site and then calculating the resulting changes in the occupancies of the localized states. The procedure is described in the following paper (M Cococcioni and S de Gironcoli, cond-mat/0405160), and in the PhD thesis of Matteo Cococcioni (http://www.sissa.it/cm/phd.php). Best wishes, Stefano On Sun, 17 Oct 2004, Ruijuan Xiao wrote: > Dear all, > When I use the LDA+U in the PWSCF, I found that there is a > parameter which is called "Hubbard_alpha". I can't find its meaning > in the help of PWSCF. Can you tell me how to set this parameter? > Thank you very much. > > Best regards, > > Sincerely, > Ruijuan Xiao > > > > --------------------------------- > Do you Yahoo!? > vote.yahoo.com - Register online to vote today! ----------------------------------------------------------------- Stefano Fabris fabris at democritos.it INFM DEMOCRITOS - SISSA tel: +39 040 3787405 via Beirut 2-4, I-34014 Trieste, Italy fax: +39 040 3787528 ------------------------------------------------------------------ From baroni at sissa.it Wed Oct 20 13:41:41 2004 From: baroni at sissa.it (Stefano Baroni) Date: Wed, 20 Oct 2004 13:41:41 +0200 Subject: [Pw_forum] About NON COLLINEAR magnetism In-Reply-To: <41761C1D.50509@mail.ustc.edu.cn> References: <41751623.9020505@mail.ustc.edu.cn> <41761C1D.50509@mail.ustc.edu.cn> Message-ID: <02D09A23-228D-11D9-889E-000A95CDDD16@sissa.it> Dear Xianghjun: the present version of PWscf cannot deal with spin spirals. An old version of it actually did. You may want to get in touch with Ralph Gebauer (rgebauer at ictp.trieste.it) for more details on the actual availability of that old version. Even better, you may want to volunteer and patch the routines for spirals contained in that old version into the new one ;-) Some details that you may find interesting (along with some nice ideas on magnon dynamics, constrained DFT, etc.) are contained in Ralph's PhD thesis, available on the web at URL www.cecam.fr Concerning J, the best way to calculate it is by constrained DFT. What ought to be done is to calculate the energy difference between configurations in which the magnetic moments on neighboring atoms are constrained to different directions, and then fit the results to kind of a Heisenberg model. Again, constrained DFT used to be implemented in PWscf in the past, using the penalty function technique that is described e.g. in Ralph's thesis. If it is no longer implemented, it would be very easy to re-implement it. Hope this helps Yours, Stefano B On Oct 20, 2004, at 10:04 AM, xianghjun wrote: > xianghjun wrote: > >> Dear all: >> I want to deal with the non-collinear magnetism systems using >> pwnc.x, >> would you please recommend some references about the implementation >> in PWNC? >> P.S., I want to get the exchange parameter J using PWNC, is that >> possible? >> >> >> Best regards, >> xianghjun >> >> _______________________________________________ >> Pw_forum mailing list >> Pw_forum at pwscf.org >> http://www.democritos.it/mailman/listinfo/pw_forum > > An other related question is: > Can PWNC deal with spin spirals? > I have examined the input help file "INPUT_NC", > it seems that the answer is "no". > Am I right? > Best regards, > xianghjun > > > _______________________________________________ > 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) Please, if possible, don't send me MS Word or PowerPoint attachments Why? See: http://www.gnu.org/philosophy/no-word-attachments.html From xhongjun at mail.ustc.edu.cn Wed Oct 20 16:50:23 2004 From: xhongjun at mail.ustc.edu.cn (xianghjun) Date: Wed, 20 Oct 2004 22:50:23 +0800 Subject: [Pw_forum] About NON COLLINEAR magnetism In-Reply-To: <02D09A23-228D-11D9-889E-000A95CDDD16@sissa.it> References: <41751623.9020505@mail.ustc.edu.cn> <41761C1D.50509@mail.ustc.edu.cn> <02D09A23-228D-11D9-889E-000A95CDDD16@sissa.it> Message-ID: <41767B2F.9020009@mail.ustc.edu.cn> Stefano Baroni wrote: > Dear Xianghjun: > > the present version of PWscf cannot deal with spin spirals. An old > version of it actually did. You may want to get in touch with Ralph > Gebauer (rgebauer at ictp.trieste.it) for more details on the actual > availability of that old version. Even better, you may want to > volunteer and patch the routines for spirals contained in that old > version into the new one ;-) Some details that you may find > interesting (along with some nice ideas on magnon dynamics, > constrained DFT, etc.) are contained in Ralph's PhD thesis, available > on the web at URL www.cecam.fr > > Concerning J, the best way to calculate it is by constrained DFT. What > ought to be done is to calculate the energy difference between > configurations in which the magnetic moments on neighboring atoms are > constrained to different directions, and then fit the results to kind > of a Heisenberg model. Again, constrained DFT used to be implemented > in PWscf in the past, using the penalty function technique that is > described e.g. in Ralph's thesis. If it is no longer implemented, it > would be very easy to re-implement it. > > Hope this helps > Yours, Stefano B > > On Oct 20, 2004, at 10:04 AM, xianghjun wrote: > >> xianghjun wrote: >> >>> Dear all: >>> I want to deal with the non-collinear magnetism systems using >>> pwnc.x, >>> would you please recommend some references about the implementation >>> in PWNC? >>> P.S., I want to get the exchange parameter J using PWNC, is that >>> possible? >>> >>> >>> Best regards, >>> xianghjun >>> >>> _______________________________________________ >>> Pw_forum mailing list >>> Pw_forum at pwscf.org >>> http://www.democritos.it/mailman/listinfo/pw_forum >> >> >> An other related question is: >> Can PWNC deal with spin spirals? >> I have examined the input help file "INPUT_NC", >> it seems that the answer is "no". >> Am I right? >> Best regards, >> xianghjun >> >> >> _______________________________________________ >> 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) > > Please, if possible, don't send me MS Word or PowerPoint attachments > Why? See: http://www.gnu.org/philosophy/no-word-attachments.html > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_foru > m Thank Baroni and Ralph for helpful comments. I have downloaded Ralph's PhD thesis and have found that the thesis is very interesting. If I could and if the developers have no such plans, I will be very happy to patch the routines for spirals into the new PWSCF version. Fortunately, I find that there are some input parameters to constrain the magnetic direction in the INPUT_NC file. So the constrained DFT should be implemented in the present PWSCF version. Best regards, xianghjun From baroni at sissa.it Wed Oct 20 18:39:16 2004 From: baroni at sissa.it (Stefano Baroni) Date: Wed, 20 Oct 2004 18:39:16 +0200 Subject: [Pw_forum] About NON COLLINEAR magnetism In-Reply-To: <41767B2F.9020009@mail.ustc.edu.cn> References: <41751623.9020505@mail.ustc.edu.cn> <41761C1D.50509@mail.ustc.edu.cn> <02D09A23-228D-11D9-889E-000A95CDDD16@sissa.it> <41767B2F.9020009@mail.ustc.edu.cn> Message-ID: <94DF1984-22B6-11D9-9334-000A95CDDD16@sissa.it> Dear Xianghjun: welcome in the family of PWscf developers! Hope you will enjoy - Stefano B. On Oct 20, 2004, at 4:50 PM, xianghjun wrote: > Stefano Baroni wrote: > >> Dear Xianghjun: >> >> the present version of PWscf cannot deal with spin spirals. An old >> version of it actually did. You may want to get in touch with Ralph >> Gebauer (rgebauer at ictp.trieste.it) for more details on the actual >> availability of that old version. Even better, you may want to >> volunteer and patch the routines for spirals contained in that old >> version into the new one ;-) Some details that you may find >> interesting (along with some nice ideas on magnon dynamics, >> constrained DFT, etc.) are contained in Ralph's PhD thesis, available >> on the web at URL www.cecam.fr >> >> Concerning J, the best way to calculate it is by constrained DFT. >> What ought to be done is to calculate the energy difference between >> configurations in which the magnetic moments on neighboring atoms are >> constrained to different directions, and then fit the results to kind >> of a Heisenberg model. Again, constrained DFT used to be implemented >> in PWscf in the past, using the penalty function technique that is >> described e.g. in Ralph's thesis. If it is no longer implemented, it >> would be very easy to re-implement it. >> >> Hope this helps >> Yours, Stefano B >> >> On Oct 20, 2004, at 10:04 AM, xianghjun wrote: >> >>> xianghjun wrote: >>> >>>> Dear all: >>>> I want to deal with the non-collinear magnetism systems using >>>> pwnc.x, >>>> would you please recommend some references about the implementation >>>> in PWNC? >>>> P.S., I want to get the exchange parameter J using PWNC, is that >>>> possible? >>>> >>>> >>>> Best regards, >>>> xianghjun >>>> >>>> _______________________________________________ >>>> Pw_forum mailing list >>>> Pw_forum at pwscf.org >>>> http://www.democritos.it/mailman/listinfo/pw_forum >>> >>> >>> An other related question is: >>> Can PWNC deal with spin spirals? >>> I have examined the input help file "INPUT_NC", >>> it seems that the answer is "no". >>> Am I right? >>> Best regards, >>> xianghjun >>> >>> >>> _______________________________________________ >>> 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) >> >> Please, if possible, don't send me MS Word or PowerPoint attachments >> Why? See: http://www.gnu.org/philosophy/no-word-attachments.html >> >> _______________________________________________ >> Pw_forum mailing list >> Pw_forum at pwscf.org >> http://www.democritos.it/mailman/listinfo/pw_foru >> m > > Thank Baroni and Ralph for helpful comments. > I have downloaded Ralph's PhD thesis and have found that the thesis is > very > interesting. If I could and if the developers have no such plans, I > will be very happy to patch > the routines for spirals into the new PWSCF version. > Fortunately, I find that there are some input parameters to constrain > the magnetic direction > in the INPUT_NC file. So the constrained DFT should be implemented in > the present PWSCF version. > > Best regards, > xianghjun > > _______________________________________________ > 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) Please, if possible, don't send me MS Word or PowerPoint attachments Why? See: http://www.gnu.org/philosophy/no-word-attachments.html From asanna at did.dsf.unica.it Wed Oct 20 19:03:25 2004 From: asanna at did.dsf.unica.it (Antonio Sanna) Date: 20 Oct 2004 19:03:25 +0200 Subject: [Pw_forum] (no subject) Message-ID: <1098291805.1746.4294.camel@pandora> I have the following problem: Because at CINECA parallel jobs can run only up to 6 h, sometimes I have to re-launch some ph.x calculation, but so I obtain incomplete fildvscf. What can I do? or else someone knows how to compile a serial version of pw.x and ph.x in a sp4 machine? Thanks ANtonio From rabrol at us.ibm.com Wed Oct 20 22:30:25 2004 From: rabrol at us.ibm.com (Ravinder Abrol) Date: Wed, 20 Oct 2004 16:30:25 -0400 Subject: [Pw_forum] Efermi error? Message-ID: Hi All, I am getting the following error, when I perform an "nscf " run after an "scf " run, for a model molecular crystal system. -------------------------------nscf.out------------------------------------------- ... ... ... 0: G cutoff = 443.2362 ( 39127 G-vectors) FFT grid: ( 44, 44, 44) 0: 0: nbndx = 240 nbnd = 60 natomwfc = 96 npwx = 824 0: nelec = 96.00 nkb = 20 ngl = 367 0: 0: The initial potential is read from file naph2cubic.1.p 0: Starting wfc are atomic 0: 0: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 0: from Efermi : error # 1 0: unexpected error 0: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 0: 0: stopping ... ----------------------------------nscf.out----------------------------------- The nscf.in input file used is: -----------------------------------nscf.in----------------------------------- &CONTROL calculation = 'nscf', restart_mode='from_scratch', verbosity='default', prefix='naph2cubic.1', nstep=100, tstress = .false., tprnfor = .true., pseudo_dir = './', / &SYSTEM ibrav= 1, celldm(1)=13.2281, nat=36, ntyp=2, ecutwfc=30.0, ecutrho=100.0, occupations='smearing', smearing='marzari-vanderbilt', degauss=0.01, nbnd=60 / &ELECTRONS electron_maxstep = 100, mixing_mode = 'plain', mixing_beta = 0.3, conv_thr = 1.0d-8, / ATOMIC_SPECIES C 12.011 C.blyp-mt.UPF H 1.0079 H.blyp-vbc.UPF ATOMIC_POSITIONS {angstrom} C -0.09520 1.49644 -2.14664 H 0.24324 2.51638 -2.04362 C -0.70999 1.08424 -3.33684 H -0.84398 1.78715 -4.14812 C -1.14877 -0.23717 -3.48597 H -1.61922 -0.53839 -4.40976 C -0.98950 -1.15871 -2.44042 H -1.35232 -2.17078 -2.54951 C -0.20953 -1.66511 -0.19004 H -0.54917 -2.68449 -0.29587 C 0.40782 -1.25440 0.99896 H 0.54113 -1.95914 1.80890 C 0.84850 0.06681 1.14788 H 1.31860 0.36897 2.07219 C 0.68767 0.98979 0.10252 H 1.05273 2.00113 0.21141 C 0.07677 0.58799 -1.09453 C -0.37901 -0.75647 -1.24313 C 2.43402 4.03272 -2.67208 H 1.91750 4.91951 -3.01032 C 2.51716 2.90609 -3.50409 H 2.07021 2.92163 -4.49059 C 3.18371 1.75452 -3.06497 H 3.26175 0.89373 -3.71145 C 3.75517 1.70868 -1.78670 H 4.26089 0.81036 -1.46068 C 4.25864 2.79507 0.33241 H 4.77451 1.90779 0.66857 C 4.17681 3.92201 1.16457 H 4.62581 3.90471 2.14778 C 3.51111 5.07330 0.72653 H 3.43502 5.93401 1.37324 C 2.93756 5.11817 -0.55143 H 2.43546 6.01788 -0.88099 C 3.01111 4.00188 -1.39417 C 3.67911 2.82458 -0.94414 K_POINTS 32 .0 .0 .0 .03125 .0 .0 .50 .03125 .0 .25 .0 .03125 .0 .25 .50 .03125 .0 .50 .0 .03125 .0 .50 .50 .03125 .0 .75 .0 .03125 .0 .75 .50 .03125 .25 .0 .0 .03125 .25 .0 .50 .03125 .25 .25 .0 .03125 .25 .25 .50 .03125 .25 .50 .0 .03125 .25 .50 .50 .03125 .25 .75 .0 .03125 .25 .75 .50 .03125 .50 .0 .0 .03125 .50 .0 .50 .03125 .50 .25 .0 .03125 .50 .25 .50 .03125 .50 .50 .0 .03125 .50 .50 .50 .03125 .50 .75 .0 .03125 .50 .75 .50 .03125 .75 .0 .0 .03125 .75 .0 .50 .03125 .75 .25 .0 .03125 .75 .25 .50 .03125 .75 .50 .0 .03125 .75 .50 .50 .03125 .75 .75 .0 .03125 .75 .75 .50 .03125 -----------------------------------------nscf.in---------------------- The "scf" run was performed using an automatic MP grid with parameters 8 8 8 1 1 1. Any solutions? Thanks. Ravi -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20041020/191b4a69/attachment.htm From sbraccia at sissa.it Thu Oct 21 08:57:52 2004 From: sbraccia at sissa.it (carlo sbraccia) Date: Thu, 21 Oct 2004 08:57:52 +0200 Subject: [Pw_forum] (no subject) In-Reply-To: <1098291805.1746.4294.camel@pandora> References: <1098291805.1746.4294.camel@pandora> Message-ID: <1098341872.3042.2.camel@dhpc-5-40.sissa.it> Dear Antonio, if you want/need to run up to 24 h at CINECA, you can use the longpar queue: # @ job_type = parallel # @ wall_clock_limit = 24:0:00 # @ class = longpar carlo From g.ballabio at cineca.it Thu Oct 21 09:31:14 2004 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Thu, 21 Oct 2004 09:31:14 +0200 (MEST) Subject: [Pw_forum] (no subject) In-Reply-To: <1098291805.1746.4294.camel@pandora> References: <1098291805.1746.4294.camel@pandora> Message-ID: <1098343873.31746.1.camel@localhost.localdomain> On Wed, 2004-10-20 at 19:03, Antonio Sanna wrote: > someone knows how to compile a serial version of pw.x and ph.x in a sp4 > machine? Yes, run "./configure --disable-parallel" and recompile. (To get rid of a previous compilation, do "make veryclean" first.) This is documented in the manual. Gerardo From rjxiao at blem.ac.cn Thu Oct 21 18:08:03 2004 From: rjxiao at blem.ac.cn (rjxiao) Date: Fri, 22 Oct 2004 00:08:03 +0800 Subject: [Pw_forum] a question about LDA+U Message-ID: <20041022000803.d556aead@server.blem.ac.cn> Dear all, I am learning the LDA+U method by reading the PhD thesis of Matteo Cococcioni. I try to do the same calculation of FeO which is mentioned in the thesis. When I use the cell with 2 iron atoms (C1) and set the U=4.29eV abtained directly from the thesis, there is no energy gap appearing. Maybe it is because the interaction of the second nearest neighbours can not be described correctly in such a small cell according to the thesis.So I enlarge the model.Then I use the cell with 8 iron atoms (C4), but the self-consistency does not converge in both the calculation of U=4.29eV and of U=0eV(LDA+U is turned off) even when I change the mixing_beta to 0.1. I realy want to know where I have made mistakes.The input files are affixed. I have puzzled by this problem for many days. I am really thankful to you for your any opinion. ---------- Input file for C1: &CONTROL title = 'FeO' , calculation = 'scf' , restart_mode = 'from_scratch' , outdir = '/home/rjxiao/tmp/' , pseudo_dir = '/home/rjxiao/mydir/pwscf/pseudo/' , prefix = 'FeO+U' , / &SYSTEM ibrav = 5, celldm(1) = 10.026125, celldm(4) = 0.8333333, nat = 4, ntyp = 3, ecutwfc = 40 , ecutrho = 400 , occupations = 'tetrahedra' , degauss = 0.005 , smearing = 'marzari-vanderbilt' , nspin = 2 , starting_magnetization(1) = 1.0, starting_magnetization(2) = -1.0, starting_magnetization(3) = 0.0, lda_plus_u = .true. , Hubbard_U(1) = 4.29, Hubbard_U(2) = 4.29, Hubbard_U(3) = 0.0, Hubbard_alpha(1) = 0.0, Hubbard_alpha(2) = 0.0, Hubbard_alpha(3) = 0.0, / &ELECTRONS / ATOMIC_SPECIES F1 55.84500 Fe.pz-nd-rrkjus.UPF F2 55.84500 Fe.pz-nd-rrkjus.UPF O 15.99940 O.pz-rrkjus.UPF ATOMIC_POSITIONS alat F1 0.000000000 0.000000000 0.000000000 F2 0.000000000 0.000000000 1.414213500 O 0.000000000 0.000000000 0.707106750 O 0.000000000 0.000000000 2.121320300 K_POINTS automatic 4 4 4 0 0 0 ---------------------- INput file for C4: &CONTROL title = 'Fe4+U' , calculation = 'scf' , restart_mode = 'from_scratch' , outdir = '/home/rjxiao/tmp/' , pseudo_dir = '/home/rjxiao/mydir/pwscf/pseudo/' , prefix = 'FeO-C4+U' , / &SYSTEM ibrav = 5, celldm(1) = 11.577172, celldm(4) = 0.5, nat = 16, ntyp = 3, ecutwfc = 40 , ecutrho = 400 , occupations = 'tetrahedra' , degauss = 0.005 , smearing = 'marzari-vanderbilt' , nspin = 2 , starting_magnetization(1) = 1.0, starting_magnetization(2) = -1.0, starting_magnetization(3) = 0.0, lda_plus_u = .true. , Hubbard_U(1) = 4.29, Hubbard_U(2) = 4.29, Hubbard_U(3) = 0.0, / &ELECTRONS mixing_beta = 0.2 , / ATOMIC_SPECIES F1 55.84500 Fe.pz-nd-rrkjus.UPF F2 55.84500 Fe.pz-nd-rrkjus.UPF O 15.99940 O.pz-rrkjus.UPF ATOMIC_POSITIONS crystal F1 0.500000000 0.500000000 0.500000000 F1 0.000000000 0.500000000 0.500000000 F1 0.500000000 0.000000000 0.500000000 F1 0.000000000 0.000000000 0.500000000 F2 0.000000000 0.000000000 0.000000000 F2 0.500000000 0.000000000 0.000000000 F2 0.000000000 0.500000000 0.000000000 F2 0.500000000 0.500000000 0.000000000 O 0.250000000 0.250000000 0.250000000 O 0.750000000 0.750000000 0.750000000 O 0.750000000 0.250000000 0.250000000 O 0.250000000 0.750000000 0.750000000 O 0.250000000 0.750000000 0.250000000 O 0.750000000 0.250000000 0.750000000 O 0.250000000 0.250000000 0.750000000 O 0.750000000 0.750000000 0.250000000 K_POINTS automatic 4 4 4 0 0 0 Best regards, Sincerely, Ruijuan Xiao Institute of Physics, Chinese Academy of Sciences From Fabris at democritos.it Thu Oct 21 18:48:55 2004 From: Fabris at democritos.it (Stefano Fabris) Date: Thu, 21 Oct 2004 18:48:55 +0200 (CEST) Subject: [Pw_forum] a question about LDA+U In-Reply-To: <20041022000803.d556aead@server.blem.ac.cn> Message-ID: Dear Ruijuan, the Hubbard U term should disfavour the fractional occupation of the Fe d orbitals. In practice, your calculations might get trapped in some conducting local minima and/or show bad convergency. To check if you are in one of these situations you should examine the occupation matrix that is printed after each SCF iteration in the output file. In particular, look for fractional occupancies, which are a clear sign that the hubbard term is not doing what it should. In the physical insulating solution the eigenvalues should be close to either 0 or 1. I would suggest you to make the following instructive analysis: run a LDA+U calculation setting the U=0, get the conducting solution and check that the occupancies are fractional (also, look at the corresponding eigenvectors). Now compare these numbers with those of your conducting LDA+U calculation with U=4.29. What do you learn from the comparison? Did the Hubbard-U contribution work the way you expected? Good luck, Stefano. On Fri, 22 Oct 2004, rjxiao wrote: > Dear all, I am learning the LDA+U method by reading the PhD thesis > of Matteo Cococcioni. I try to do the same calculation of FeO which > is mentioned in the thesis. When I use the cell with 2 iron atoms > (C1) and set the U=4.29eV abtained directly from the thesis, there > is no energy gap appearing. Maybe it is because the interaction of > the second nearest neighbours can not be described correctly in such > a small cell according to the thesis.So I enlarge the model.Then I > use the cell with 8 iron atoms (C4), but the self-consistency does > not converge in both the calculation of U=4.29eV and of U=0eV(LDA+U > is turned off) even when I change the mixing_beta to 0.1. I realy > want to know where I have made mistakes.The input files are affixed. > I have puzzled by this problem for many days. I am really thankful > to you for your any opinion. > > ---------- > Input file for C1: > &CONTROL > title = 'FeO' , > calculation = 'scf' , > restart_mode = 'from_scratch' , > outdir = '/home/rjxiao/tmp/' , > pseudo_dir = '/home/rjxiao/mydir/pwscf/pseudo/' , > prefix = 'FeO+U' , > / > &SYSTEM > ibrav = 5, > celldm(1) = 10.026125, > celldm(4) = 0.8333333, > nat = 4, > ntyp = 3, > ecutwfc = 40 , > ecutrho = 400 , > occupations = 'tetrahedra' , > degauss = 0.005 , > smearing = 'marzari-vanderbilt' , > nspin = 2 , > starting_magnetization(1) = 1.0, > starting_magnetization(2) = -1.0, > starting_magnetization(3) = 0.0, > lda_plus_u = .true. , > Hubbard_U(1) = 4.29, > Hubbard_U(2) = 4.29, > Hubbard_U(3) = 0.0, > Hubbard_alpha(1) = 0.0, > Hubbard_alpha(2) = 0.0, > Hubbard_alpha(3) = 0.0, > / > &ELECTRONS > / > ATOMIC_SPECIES > F1 55.84500 Fe.pz-nd-rrkjus.UPF > F2 55.84500 Fe.pz-nd-rrkjus.UPF > O 15.99940 O.pz-rrkjus.UPF > ATOMIC_POSITIONS alat > F1 0.000000000 0.000000000 0.000000000 > F2 0.000000000 0.000000000 1.414213500 > O 0.000000000 0.000000000 0.707106750 > O 0.000000000 0.000000000 2.121320300 > K_POINTS automatic > 4 4 4 0 0 0 > > ---------------------- > INput file for C4: > &CONTROL > title = 'Fe4+U' , > calculation = 'scf' , > restart_mode = 'from_scratch' , > outdir = '/home/rjxiao/tmp/' , > pseudo_dir = '/home/rjxiao/mydir/pwscf/pseudo/' , > prefix = 'FeO-C4+U' , > / > &SYSTEM > ibrav = 5, > celldm(1) = 11.577172, > celldm(4) = 0.5, > nat = 16, > ntyp = 3, > ecutwfc = 40 , > ecutrho = 400 , > occupations = 'tetrahedra' , > degauss = 0.005 , > smearing = 'marzari-vanderbilt' , > nspin = 2 , > starting_magnetization(1) = 1.0, > starting_magnetization(2) = -1.0, > starting_magnetization(3) = 0.0, > lda_plus_u = .true. , > Hubbard_U(1) = 4.29, > Hubbard_U(2) = 4.29, > Hubbard_U(3) = 0.0, > / > &ELECTRONS > mixing_beta = 0.2 , > / > ATOMIC_SPECIES > F1 55.84500 Fe.pz-nd-rrkjus.UPF > F2 55.84500 Fe.pz-nd-rrkjus.UPF > O 15.99940 O.pz-rrkjus.UPF > ATOMIC_POSITIONS crystal > F1 0.500000000 0.500000000 0.500000000 > F1 0.000000000 0.500000000 0.500000000 > F1 0.500000000 0.000000000 0.500000000 > F1 0.000000000 0.000000000 0.500000000 > F2 0.000000000 0.000000000 0.000000000 > F2 0.500000000 0.000000000 0.000000000 > F2 0.000000000 0.500000000 0.000000000 > F2 0.500000000 0.500000000 0.000000000 > O 0.250000000 0.250000000 0.250000000 > O 0.750000000 0.750000000 0.750000000 > O 0.750000000 0.250000000 0.250000000 > O 0.250000000 0.750000000 0.750000000 > O 0.250000000 0.750000000 0.250000000 > O 0.750000000 0.250000000 0.750000000 > O 0.250000000 0.250000000 0.750000000 > O 0.750000000 0.750000000 0.250000000 > K_POINTS automatic > 4 4 4 0 0 0 > > > Best regards, > > Sincerely, > Ruijuan Xiao > Institute of Physics, > Chinese Academy of Sciences > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > ----------------------------------------------------------------- Stefano Fabris fabris at democritos.it INFM DEMOCRITOS - SISSA tel: +39 040 3787405 via Beirut 2-4, I-34014 Trieste, Italy fax: +39 040 3787528 ------------------------------------------------------------------ From vsriniva at Princeton.EDU Thu Oct 21 23:56:02 2004 From: vsriniva at Princeton.EDU (Varadharajan Srinivasan) Date: Thu, 21 Oct 2004 17:56:02 -0400 (EDT) Subject: [Pw_forum] Problem in Variable-cell Message-ID: Dear users, I have been performing some variable-cell relaxation calculations using PWSCF on PbTiO3 and I come across an interesting problem. After having relaxed the unit cell I take the relaxed structure and perform an scf calculation on it to obtain again the forces, stress and energy that vc-relax gives me anyway. (I made sure that I chose the structure corresponding to the final energy and forces, ie. the structure reported before the final estimate) However, I obtain very different answers. The variable-cell gives me : ###################################################################################### new lattice vectors (alat unit) : ..........(input alat = 7.3627 (a.u.)) 0.999624836 0.000000001 0.000000000 0.000000001 0.999624847 0.000000000 0.000000000 0.000000000 1.081152570 new unit-cell volume = 431.1954 (a.u.)^3 new positions in cryst coord Ti 0.499999997 0.500000003 0.535979348 O 0.499999997 0.500000004 0.112901652 O 0.499999997 0.000000004 0.614268219 O -0.000000003 0.500000004 0.614268218 Pb -0.000000002 0.000000003 0.004230374 ! total energy = -332.37904437 ryd estimated scf accuracy < 0.00000000 ryd convergence has been achieved Forces acting on atoms (Ry/au): atom 1 type 1 force = 0.00000000 0.00000000 -0.00000063 atom 2 type 2 force = 0.00000000 0.00000000 -0.00000168 atom 3 type 2 force = 0.00000000 0.00000000 -0.00000253 atom 4 type 2 force = 0.00000000 0.00000000 -0.00000253 atom 5 type 3 force = 0.00000000 0.00000000 0.00000738 Total force = 0.000008 Total SCF correction = 0.000008 entering subroutine stress ... total stress (ryd/bohr**3) (kbar) P= 0.01 0.00000008 0.00000000 0.00000000 0.01 0.00 0.00 0.00000000 0.00000008 0.00000000 0.00 0.01 0.00 0.00000000 0.00000000 0.00000002 0.00 0.00 0.00 Parrinello-Rahman Damped Dynamics: convergence achieved, Efinal= -332.37904437 ####################################################################################### While from the corresponding structure the scf calculation gives me : ####################################################################################### ibrav= 6, celldm(1) =7.359938, celldm(3)=1.081558 Ti 0.499999997 0.500000003 0.535979348 O 0.499999997 0.500000004 0.112901652 O 0.499999997 0.000000004 0.614268219 O -0.000000003 0.500000004 0.614268218 Pb -0.000000002 0.000000003 0.004230374 ! total energy = -332.94499390 ryd estimated scf accuracy < 0.00000000 ryd band energy sum = -12.68025211 ryd one-electron contribution = -93.34743263 ryd hartree contribution = 73.14958559 ryd xc contribution = -50.45891514 ryd ewald contribution = -262.28823173 ryd convergence has been achieved Forces acting on atoms (Ry/au): atom 1 type 1 force = 0.00000000 0.00000000 -0.00108980 atom 2 type 2 force = 0.00000000 0.00000000 0.00054152 atom 3 type 2 force = 0.00000000 0.00000000 0.00008334 atom 4 type 2 force = 0.00000000 0.00000000 0.00008334 atom 5 type 3 force = 0.00000000 0.00000000 0.00038160 Total force = 0.001281 Total SCF correction = 0.000005 entering subroutine stress ... total stress (ryd/bohr**3) (kbar) P= -288.66 -0.00195487 0.00000000 0.00000000 -287.57 0.00 0.00 0.00000000 -0.00195487 0.00000000 0.00 -287.57 0.00 0.00000000 0.00000000 -0.00197707 0.00 0.00 -290.84 ############################################################################## Not only is the total energy very different but also the forces and the stress. I used a ecutwfc=40., ecutrho=240. in both calculations (and ecfixed=35. Ry in variable-cell) to be consistent in the cutoff energies. Is this discrepencancy to be expected or am I doing something wrong? I would greatly appreciate any help/suggestions. Thanks, Vardha. From giannozz at nest.sns.it Fri Oct 22 09:17:11 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 22 Oct 2004 09:17:11 +0200 Subject: [Pw_forum] Restart error In-Reply-To: <415E6B04.000017.10472@soapbox.yandex.ru> References: <415E6B04.000017.10472@soapbox.yandex.ru> Message-ID: <200410220917.11296.giannozz@nest.sns.it> On Saturday 02 October 2004 10:47, Sergey Lisenkov wrote: > I have restarted my calculations from previous one. The code ran 1 > iterations, printed forces and stopped with error: > > 1525-001 The READ statement on the file ./60-1bn.bfgs cannot be completed > because the end of the file was reached. The program will stop. > > Is it my fault? difficult to say. Restarting from an interrupted calculation may be tricky. Maybe the mentioned file was corrupted, or nonexistent. 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 song at cello.t.u-tokyo.ac.jp Fri Oct 22 09:11:05 2004 From: song at cello.t.u-tokyo.ac.jp (Yingwen Song) Date: Fri, 22 Oct 2004 16:11:05 +0900 Subject: [Pw_forum] Re: ask your help! In-Reply-To: <000601c4b7d1$f8779190$1a54a8c0@nano> References: <000601c4b7d1$f8779190$1a54a8c0@nano> Message-ID: <20041022160415.53A4.SONG@cello.t.u-tokyo.ac.jp> Hi, Aijun I am Yingwen Song @ The University of Tokyo. The MPI version of make.sys is attached. I am using MPICH 1.2.5. Please modify "-I/opt/mpich-1.2.5/include" in IFLAGS and "-L/opt/mpich-1.2.5/lib" in LIBS to point to your own MPI path. Good luck. > Dear Dr. Song, > > I am working in the University of Queensland and also using pwscf for my research work. I find your email address from PWSCF email list. I knew you have succeeded in compiling and running PWSCF on AMD opetron64 using pgf90. Have you tried MPI version? Could you send me the Make.sys(MPI) to me? > > I have compiled pwscf on my new AMD opteron64 machine. My test on a big system met some problems and stopped. But for small system it is okay. > > Many thanks, > Regards, > Aijun -------------------------- Yingwen Song, Ph.D. The University of Tokyo Email:song at cello.t.u-tokyo.ac.jp Homepage:http://cello.t.u-tokyo.ac.jp/~song/ Tel/Fax: 03-5841-1286 -------------- next part -------------- A non-text attachment was scrubbed... Name: make.sys Type: application/octet-stream Size: 1907 bytes Desc: not available Url : /pipermail/attachments/20041022/af56fd68/attachment.obj From giannozz at nest.sns.it Fri Oct 22 09:35:02 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 22 Oct 2004 09:35:02 +0200 Subject: [Pw_forum] Compilation troubles on PC/linux In-Reply-To: <884193C06D478A4B97B5212C8120A501DC4E0C@atil.intra.cea.fr> References: <884193C06D478A4B97B5212C8120A501DC4E0C@atil.intra.cea.fr> Message-ID: <200410220935.02817.giannozz@nest.sns.it> On Thursday 07 October 2004 09:15, BOUYER Fr?d?ric 153746 wrote: > Sorry to be boring with such question about compilation, but I installed > yesterday the version 8.1 of the ifort intel compiler (on a PC/Xeon Linux > RedHat 9), and have always the error message : > > ifort: error : could not find directory on which g++ resides hint: whenever you get a strange error message, try a search on google or something similar. This is the first of 8 hits I found in 0.23 s: http://softwareforums.intel.com/ids/board/message?board.id=11&message.id=1883 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 Oct 22 12:32:31 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 22 Oct 2004 12:32:31 +0200 Subject: [Pw_forum] parallelization issue In-Reply-To: <416F8F60.7020803@unipd.it> References: <416F8F60.7020803@unipd.it> Message-ID: <200410221232.31125.giannozz@nest.sns.it> On Friday 15 October 2004 10:50, Giacomo Saielli wrote: > I wonder if the comments of paragraph 7.4 of espresso manual v 2.1, > parallelization issue of pw.x, apply also for the cp.x module. they mostly apply to cp.x as well. Of course there is no k-kpoint parallelization in cp.x. I am not sure about the status of NEB image parallelization in cp.x. > ecutwfc = 30.0, > ecutrho = 180.0, 25 and 100 Ry for C, N, H should be enough > A test CPMD run with cp.x takes about 50 hours of total cpu > (16 procs on IBM SP4 at CINECA, all PE of the same node) > for 100 steps [...]. The question is if this numbers sounds > correct to you, for this system size 1800 s/time step seems to me way too large for a system like yours. You can find reference CPU times on a SP3 here: http://www.nest.sns.it/~giannozz/Papers/JCP_57.pdf Divide by 2 or 3 to get an estimate for SP4. 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 Oct 22 17:00:17 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 22 Oct 2004 17:00:17 +0200 Subject: [Pw_forum] Problem in Variable-cell In-Reply-To: References: Message-ID: <200410221700.17519.giannozz@nest.sns.it> On Thursday 21 October 2004 23:56, Varadharajan Srinivasan wrote: > After having relaxed the unit cell I take the relaxed structure and perform > an scf calculation on it to obtain again the forces, stress and energy that > vc-relax gives me anyway. (I made sure that I chose the structure > corresponding to the final energy and forces, ie. the structure reported > before the final estimate). However, I obtain very different answers. - first of all, check if you can reproduce the results for the relaxed structure by passing the lattice parameters in input as in the variable-cell case, i.e. ibrav=0 and the lattice vectors - check if the atomic positions in cartesian units are actually the same in the two cases - check that you used the same modified, or not modified, kinetic energy functional in both cases 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 Oct 22 17:41:37 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 22 Oct 2004 17:41:37 +0200 Subject: [Pw_forum] Is that possible to make a parallel version of PwSCF under Win2K? In-Reply-To: <20041020024611.44020.qmail@web52703.mail.yahoo.com> References: <20041020024611.44020.qmail@web52703.mail.yahoo.com> Message-ID: <200410221741.37721.giannozz@nest.sns.it> On Wednesday 20 October 2004 04:46, Yan-jun Guo wrote: > the computer cluster in our lab is built under Win2K/MPI. > Is that possible to make a parallel version of PwSCF under > Win2K and cygwin? in principle it is, but you (or somebody else) have to do it: right now PWscf is not supported on windows. Some earlier version used to work with cygwin. See also the thread starting with: http://www.democritos.it/pipermail/pw_forum/2004-July/001128.html 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 Oct 22 19:17:45 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 22 Oct 2004 19:17:45 +0200 Subject: [Pw_forum] Efermi error? In-Reply-To: References: Message-ID: <200410221917.45135.giannozz@nest.sns.it> On Wednesday 20 October 2004 22:30, Ravinder Abrol wrote: > I am getting the following error, when I perform an "nscf " run after an > "scf " run [...] > from Efermi : error # 1 > unexpected error > [...] Any solutions? a quick solution is to remove input data related to metallicity: > occupations='smearing', > smearing='marzari-vanderbilt', > degauss=0.01 from the input for the 'nscf' calculation. These data are used only for the calculation of the Fermi energy, which will not be of much use anyway, unless a uniform grid of k-points is specified. 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 Oct 22 19:33:10 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Fri, 22 Oct 2004 19:33:10 +0200 Subject: [Pw_forum] espresso compilation error on PC (Xeon) In-Reply-To: <4161B531.9030307@fzu.cz> References: <1096615702.3102.27.camel@dhpc-5-40.sissa.it> <4161B531.9030307@fzu.cz> Message-ID: <200410221933.10906.giannozz@nest.sns.it> On Monday 04 October 2004 22:40, Pingo Mutombo wrote: > [...] fortcom: Severe: **Internal compiler error: internal abort** you need to update your version of the Intel compiler to a more recent, or anyway less buggy, version: see the manual 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 rabrol at us.ibm.com Sat Oct 23 06:50:56 2004 From: rabrol at us.ibm.com (Ravinder Abrol) Date: Sat, 23 Oct 2004 00:50:56 -0400 Subject: [Pw_forum] Efermi error? In-Reply-To: <200410221917.45135.giannozz@nest.sns.it> Message-ID: Dear Dr. Giannozzi, Thanks very much for the suggestion. It worked. Is there a place/reference where I can read more about this? Thanks, Ravi Paolo Giannozzi Sent by: pw_forum-admin at pwscf.org 10/22/2004 01:17 PM Please respond to pw_forum To pw_forum at pwscf.org cc Subject Re: [Pw_forum] Efermi error? On Wednesday 20 October 2004 22:30, Ravinder Abrol wrote: > I am getting the following error, when I perform an "nscf " run after an > "scf " run [...] > from Efermi : error # 1 > unexpected error > [...] Any solutions? a quick solution is to remove input data related to metallicity: > occupations='smearing', > smearing='marzari-vanderbilt', > degauss=0.01 from the input for the 'nscf' calculation. These data are used only for the calculation of the Fermi energy, which will not be of much use anyway, unless a uniform grid of k-points is specified. Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy _______________________________________________ Pw_forum mailing list Pw_forum at pwscf.org http://www.democritos.it/mailman/listinfo/pw_forum -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20041023/80f3fbe4/attachment.htm From giannozz at nest.sns.it Sat Oct 23 15:37:31 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Sat, 23 Oct 2004 15:37:31 +0200 Subject: [Pw_forum] Efermi error? In-Reply-To: References: Message-ID: <200410231537.31307.giannozz@nest.sns.it> On Saturday 23 October 2004 06:50, Ravinder Abrol wrote: > Thanks very much for the suggestion. It worked. Is there a place/reference > where I can read more about this? Gaussian broadening: Methfessel, M., and A. Paxton, 1989, Phys. Rev. B 40, 3616 Tetrahedron method: P. E. Bloechl, O. Jepsen and O. K. Andersen, 1994 Phys. Rev. B 49, 16223 Cold Smearing: Marzari, N., D. Vanderbilt, A. De Vita, and M. C. Payne, 1999, Phys. Rev. Lett. 82, 3296. The implementation is contained in a few simple routines in PW/ that should be easily readable: gweights.f90 (calculates gaussian weights) efermig.f90 (calculates Fermi energy with gaussian weights) w0gauss.f90 w1gauss.f90 wgauss.f90 (auxiliary functions) tweights.f90 (calculates weights with tetrahedra) efermit.f90 (calculates Fermi energy with tetrahedra) 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 rjxiao at blem.ac.cn Sat Oct 23 18:07:32 2004 From: rjxiao at blem.ac.cn (rjxiao) Date: Sun, 24 Oct 2004 00:07:32 +0800 Subject: [Pw_forum] a question about LDA+U Message-ID: <20041024000732.d9396747@server.blem.ac.cn> Dear Stefano Fabris, Thank you very much for your instructive advice.I did some calculation as what you have told me.The cell with 2 iron atoms was choose because it can be finished quickly.I did a series of LDA+U by setting U=0.000000001(since the LDA+U can not be done under U=0 in this software,I use this small value to instead U=0),U=4.29,5.29,6.29,7.29,8.29,9.29.For both irons, the eigenvalues of one spin direction are close to 1, while eigenvalues of the other spin direction are fractional.The occupations show the same result.But I also notice that three of the fractional eigenvalues approach to 0 along with the increase of U and the other two approach to 1.For example, when U=0,they are 0.3051347 0.3051347 0.4077667 0.4469277 0.4469277,for U=9.29, they are 0.0544810 0.1226590 0.1226590 0.7087178 0.7087178. It seems that the Hubbard+U does work. But the result is still a conducting solution even if U is as high as 9.29. It is strange to me. Another phenomena puzzled me is the negative occupation.How can the occupation be such as -0.18?It is difficult to understand for me. The problem of convergency in model with 8 iron atoms without U is solved.But the way to slove it is unexpected to me. I just change one position of Fe1 and Fe2,though I think that the two models are equivalent for the FeO with antiferromagnetic between neighour [111] plane.Maybe the model after change is more beautiful:-) I don't know why there is such great differece between them. Also, the model with U=4.29 is not convergency, and the occupations and eigenvalues are fractional. Best regards, Sincerely, Ruijuan Xiao Institute of Physics, Chinese Academy of Sciences From rjxiao at blem.ac.cn Sat Oct 23 18:21:57 2004 From: rjxiao at blem.ac.cn (rjxiao) Date: Sun, 24 Oct 2004 00:21:57 +0800 Subject: [Pw_forum] a question about LDA+U Message-ID: <20041024002157.ce5c9d42@server.blem.ac.cn> Dear Matteo Cococcioni, Thank you for your reminding me to check the position of atoms. I have checked it carefully,but I am sorry that I can not agree with you.Does it because we choose different primitive cell? What I choose is the cell with lattic parameter of 5.30559 angstrom, and the angle between two lattic vector is 33.5573 degree. How about the primitive cell that you have chosen? If they are different, I can try that one.I am really thank you because I learn much from your thesie. Best regards, Sincerely, Ruijuan Xiao Institute of Physics, Chinese Academy of Sciences From marzari at MIT.EDU Sat Oct 23 21:09:58 2004 From: marzari at MIT.EDU (Nicola Marzari) Date: Sat, 23 Oct 2004 15:09:58 -0400 Subject: [Pw_forum] Efermi error? In-Reply-To: References: Message-ID: <417AAC86.1080401@mit.edu> Dear Ravinder, Chap 4 of my PhD ( http://nnn.mit.edu/phd/ ) has a fairly detailied description of all these various issues. It might also help to understand how negative occupations arise when using e.g. Methfessel-Paxton smearing (I believe Ruijuan Xiao was asking about negative occupations). Best, nicola Ravinder Abrol wrote: > > Dear Dr. Giannozzi, > Thanks very much for the suggestion. It worked. Is there a > place/reference where > I can read more about this? > Thanks, > Ravi > --------------------------------------------------------------------- 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 matteoc at MIT.EDU Sat Oct 23 21:42:28 2004 From: matteoc at MIT.EDU (Matteo Cococcioni) Date: Sat, 23 Oct 2004 15:42:28 -0400 Subject: [Pw_forum] a question about LDA+U In-Reply-To: <20041024002157.ce5c9d42@server.blem.ac.cn> References: <20041024002157.ce5c9d42@server.blem.ac.cn> Message-ID: <1098560548.417ab424eb25f@webmail.mit.edu> Dear Ruijuan Xiao I run the calculation of FeO in the smallest cell (the one with two Fe and 2 O) and I attached the input and output to this mail. It seems to me that the atomic coordinates of your input files are wrong. The point, in my opinion, is that you decided to give them in alat units but in the case of rombohedral cell the code fixes the coordinate axes in a strange way (the z-axis is along the 111 direction of the cubic cell and the x and y axes somewhere in the 111 plane). So the coordinate axes are not the edges of the cubic cell anymore and it's constructing a crystal which is not the one you have in mind. My suggestion would be to use always crystal corrdinates (though it may require some initial conversion). You can realize this looking into my output file. Second issue. Even with correct atomic coordinates you still would not have got the sixth electron localized in one state only if you are using the last release (Espresso package). The reason for this, in my opinion, is that the routine ns_adj is not able to suggest to the code which is the correct electronic ground state (in this case the one with the sixth electron in the Z^2 state which is along the 111 cubic diagonal). As Stefano Fabris was explaining in his mail this is sometimes important (crucial for FeO) because avoids that the code gets trapped in some local minima. Attached to this mail you can also find an older version of the ns_adj routine which you can insert in the new code. THe output I attach has been obtained using this routine in an older version. Remind that the ground state with last e- in the Z^2 orbital is not the true ground state of FeO (see my thesis for details) but is for sure the one you should obtain in the small cell. I hope this can help you. Matteo Quoting rjxiao : > Dear Matteo Cococcioni, > > Thank you for your reminding me to check the position of atoms. I have > checked it carefully,but I am sorry that I can not agree with you.Does it > because we choose different primitive cell? What I choose is the cell with > lattic parameter of 5.30559 angstrom, and the angle between two lattic vector > is 33.5573 degree. How about the primitive cell that you have chosen? If they > are different, I can try that one.I am really thank you because I learn much > from your thesie. > > > Best regards, > > Sincerely, > Ruijuan Xiao > Institute of Physics, > Chinese Academy of Sciences > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > -------------- next part -------------- A non-text attachment was scrubbed... Name: FeO_in_out.tar.gz Type: application/x-gzip Size: 9409 bytes Desc: not available Url : /pipermail/attachments/20041023/740d8f1d/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ns_adj.f90 Type: application/octet-stream Size: 4092 bytes Desc: not available Url : /pipermail/attachments/20041023/740d8f1d/attachment.obj From song at cello.t.u-tokyo.ac.jp Mon Oct 25 03:16:05 2004 From: song at cello.t.u-tokyo.ac.jp (Yingwen Song) Date: Mon, 25 Oct 2004 10:16:05 +0900 Subject: [Pw_forum] Re: ask your help! In-Reply-To: <001601c4ba28$78a58c70$1a54a8c0@nano> References: <20041022160415.53A4.SONG@cello.t.u-tokyo.ac.jp> <001601c4ba28$78a58c70$1a54a8c0@nano> Message-ID: <20041025101053.EEEE.SONG@cello.t.u-tokyo.ac.jp> Hi, Aijun I am Yingwen Song @ The University of Tokyo. The following are the contents of make.sys. Remember to change IFLAGS and LIBS as I told you before. Wish you good luck. Yingwen --------------------make.sys START------------------------------ # make.sys. Generated from make.sys.in by configure. CC = pgcc CCFLAGS = -O3 -tp k8-64 -fast -Munroll -Mvect=sse -Mvect=assoc,cachesize:1048576 -Mcache_align -Kieee -Mvect=prefetch $(DFLAGS) $(IFLAGS) # See include/defs.h.README for a list of precompilation options # (possible arguments to -D or -U) and their meaning DFLAGS = -D__LINUX64 -D__PGI -D__PARA -D__MPI -D__FFTW -D__USE_INTERNAL_FFTW IFLAGS = -I. -I../include -I../Modules -I../PW -I../PH -I/opt/mpich-1.2.5/include CPP = cpp CPPFLAGS = -P -traditional $(DFLAGS) $(IFLAGS) F77 = pgf77 F90 = pgf90 FFLAGS = -fast -r8 -O3 -tp k8-64 -Munroll -Mvect=sse -Mvect=assoc,cachesize:1048576 -Mcache_align -Kieee -Mvect=prefetch F77FLAGS = $(FFLAGS) $(IFLAGS) F90FLAGS = $(FFLAGS) $(DFLAGS) $(IFLAGS) F77FLAGS_NOOPT = -O0 LD = pgf90 LDFLAGS = $(LIBOBJS) $(LIBS) LIBOBJS = ../flib/ptools.a ../flib/flib.a ../clib/clib.a # LIBS must contain the location of all needed external libraries LIBS = -lacml -L/opt/mpich-1.2.5/lib -lfmpich -lmpich #LIBS = -llapack -lblas # MYLIB can be one of the following (depending on LIBS): # blas : compile the local copy of blas routines # lapack : compile the local copy of lapack routines # blas_and_lapack : all of the above - use this for a quick test # or if you don't have an optimized blas/lapack library # lapack_ibm : compile only lapack routines not present in IBM ESSL # use this together with IBM ESSL # lapack_t3e : compile only lapack routines not present in T3E scilib # use this together with T3E scilib # lapack_mkl : compile only lapack routines not present in Intel MKL # use this together with Intel MKL MYLIB = AR = ar ARFLAGS = ruv --------------------make.sys END------------------------------ > Hello Yingwen, > > Thanks for your timely reply. > > I am sorry I couldn't receive the attachment successfully. If possible could > you please send to me as mail content or alternative to aijun_du at hotmail.com > ? > > Many thanks, > Aijun > ----- Original Message ----- > From: "Yingwen Song" > To: "Aijun Du" > Cc: > Sent: Friday, October 22, 2004 5:11 PM > Subject: Re: ask your help! > > > > WARNING: This e-mail has been altered by mail systems at > > Information Technology Services at The University of Queensland > > (www.its.uq.edu.au) > > Following this paragraph are indications of the actual > > changes made. > > > > A file named > > > > make.sys > > > > was removed from this email as it constituted a security hazard. > > > > It may be a virus. If you require this file, please contact > > the sender and arrange an alternate means of receiving it. > > For example ask the sender to resend it within > > a non self-extracting archive. > > > > More information can be found at: > > > > http://www.uq.edu.au/uqnet/virus.html > > > > > > > -------------------------------------------------------------------------------- > > > > Hi, Aijun > > > > I am Yingwen Song @ The University of Tokyo. The MPI version of make.sys > > is attached. I am using MPICH 1.2.5. Please modify > > "-I/opt/mpich-1.2.5/include" > > in IFLAGS and > > "-L/opt/mpich-1.2.5/lib" > > in LIBS > > > > to point to your own MPI path. > > > > Good luck. > > > > > >> Dear Dr. Song, > >> > >> I am working in the University of Queensland and also using pwscf for my > >> research work. I find your email address from PWSCF email list. I knew > >> you have succeeded in compiling and running PWSCF on AMD opetron64 using > >> pgf90. Have you tried MPI version? Could you send me the Make.sys(MPI) to > >> me? > >> > >> I have compiled pwscf on my new AMD opteron64 machine. My test on a big > >> system met some problems and stopped. But for small system it is okay. > >> > >> Many thanks, > >> Regards, > >> Aijun > > > > -------------------------- > > Yingwen Song, Ph.D. > > The University of Tokyo > > Email:song at cello.t.u-tokyo.ac.jp > > Homepage:http://cello.t.u-tokyo.ac.jp/~song/ > > Tel/Fax: 03-5841-1286 > > > > -------------------------- Yingwen Song, Ph.D. The University of Tokyo Email:song at cello.t.u-tokyo.ac.jp Homepage:http://cello.t.u-tokyo.ac.jp/~song/ Tel/Fax: 03-5841-1286 From rabrol at us.ibm.com Mon Oct 25 05:40:46 2004 From: rabrol at us.ibm.com (Ravinder Abrol) Date: Sun, 24 Oct 2004 23:40:46 -0400 Subject: [Pw_forum] Efermi error? In-Reply-To: <200410231537.31307.giannozz@nest.sns.it> Message-ID: Dear Dr. Giannozzi and Dr. Marzari, Thanks for the references! Best regards, Ravi ----- Ravinder Abrol, Ph. D. 25-143, Department of Physical Sciences IBM Thomas J. Watson Research Center Yorktown Heights, NY 10598 Phone: 914-945-1617 Email: rabrol at us.ibm.com Paolo Giannozzi Sent by: pw_forum-admin at pwscf.org 10/23/2004 09:37 AM Please respond to pw_forum To pw_forum at pwscf.org cc Subject Re: [Pw_forum] Efermi error? On Saturday 23 October 2004 06:50, Ravinder Abrol wrote: > Thanks very much for the suggestion. It worked. Is there a place/reference > where I can read more about this? Gaussian broadening: Methfessel, M., and A. Paxton, 1989, Phys. Rev. B 40, 3616 Tetrahedron method: P. E. Bloechl, O. Jepsen and O. K. Andersen, 1994 Phys. Rev. B 49, 16223 Cold Smearing: Marzari, N., D. Vanderbilt, A. De Vita, and M. C. Payne, 1999, Phys. Rev. Lett. 82, 3296. The implementation is contained in a few simple routines in PW/ that should be easily readable: gweights.f90 (calculates gaussian weights) efermig.f90 (calculates Fermi energy with gaussian weights) w0gauss.f90 w1gauss.f90 wgauss.f90 (auxiliary functions) tweights.f90 (calculates weights with tetrahedra) efermit.f90 (calculates Fermi energy with tetrahedra) Paolo -- Paolo Giannozzi e-mail: giannozz at nest.sns.it Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 Piazza dei Cavalieri 7 I-56126 Pisa, Italy _______________________________________________ Pw_forum mailing list Pw_forum at pwscf.org http://www.democritos.it/mailman/listinfo/pw_forum -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20041024/c67e178b/attachment.htm From giacomo.saielli at unipd.it Tue Oct 26 10:10:37 2004 From: giacomo.saielli at unipd.it (Giacomo Saielli) Date: Tue, 26 Oct 2004 10:10:37 +0200 Subject: [Pw_forum] parallelization issue In-Reply-To: <200410221232.31125.giannozz@nest.sns.it> References: <416F8F60.7020803@unipd.it> <200410221232.31125.giannozz@nest.sns.it> Message-ID: <417E067D.9030308@unipd.it> Dear Eyvaz and Paolo, thank you very much for your comments. In particular, Paolos' paper, Table IV report a time for cp step, T_i, of 3700 sec, 16 procs on SP3, system of 900 electrons, spin-unrestricted calculation. Then I guess that we can estimate roughly a half (1800 sec) for the same calculation spin-restricted, which would become about 700-800 secs per time step if it were on SP4. Since I have about 600 electrons instead of 900, this time would be reduced again to about 400-500 or so? Then what I have found (1800secs/cp step) is about 4 times larger than expected based on this very approximate estimate. However I have used somewhat larger cutoffs than needed, as suggested by Paolo. Maybe I can improve the performance playing with these parameters. Thank you again, best wishes, Giacomo Paolo Giannozzi wrote: >On Friday 15 October 2004 10:50, Giacomo Saielli wrote: > > > >>I wonder if the comments of paragraph 7.4 of espresso manual v 2.1, >>parallelization issue of pw.x, apply also for the cp.x module. >> >> > >they mostly apply to cp.x as well. Of course there is no k-kpoint >parallelization in cp.x. I am not sure about the status of NEB image >parallelization in cp.x. > > > >> ecutwfc = 30.0, >> ecutrho = 180.0, >> >> > >25 and 100 Ry for C, N, H should be enough > > > >>A test CPMD run with cp.x takes about 50 hours of total cpu >>(16 procs on IBM SP4 at CINECA, all PE of the same node) >>for 100 steps [...]. The question is if this numbers sounds >>correct to you, for this system size >> >> > >1800 s/time step seems to me way too large for a system like >yours. You can find reference CPU times on a SP3 here: >http://www.nest.sns.it/~giannozz/Papers/JCP_57.pdf >Divide by 2 or 3 to get an estimate for SP4. > >Paolo > > > -- Giacomo Saielli Istituto per la Tecnologia delle Membrane del CNR, Sezione di Padova; Via Marzolo, 1 - 35131 Padova, Italy; Tel: +39-049-8275279; Fax: -5239; http://www.chfi.unipd.it/home/g.saielli/ From mpayami at aeoi.org.ir Tue Oct 26 10:26:26 2004 From: mpayami at aeoi.org.ir (Mahmoud Payami) Date: Tue, 26 Oct 2004 11:56:26 +0330 Subject: [Pw_forum] parallel environment not found Message-ID: <001901c4bb35$7c6cc360$1b6710ac@aeoi.org.ir> Dear PWSCF Users, Before I try to use "./configure", I have installed MPI and run "mpdboot -n " command successfully. So the environment for parallel is ok. Afterwards, I try to use the "configure" command. As is seen at the end it does not detect parallel environment (although it detects all relevant mpicc, mpif77, ...): ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ [mahmoud at condmat1 ESPRESSO]$ ./configure checking build system type... i686-pc-linux-gnu checking architecture... linux32 checking for mpif90... mpif90 checking for Fortran 77 compiler default output file name... a.out checking whether the Fortran 77 compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU Fortran 77 compiler... no checking whether mpif90 accepts -g... yes checking version of mpif90... ifc 7.1 checking for mpif77... mpif77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether mpif77 accepts -g... yes checking for mpicc... mpicc checking whether we are using the GNU C compiler... yes checking whether mpicc accepts -g... yes checking for mpicc option to accept ANSI C... none needed checking version of mpicc... gcc 3.3.3 setting FFLAGS... -Vaxlib -O2 -tpp6 setting F90FLAGS... $(FFLAGS) -nomodule setting CFLAGS... -O3 -fomit-frame-pointer checking how to run the C preprocessor... mpicc -E setting CPP... cpp setting CPPFLAGS... -P -traditional setting LD... mpif90 setting LDFLAGS... -Vaxlib -static setting AR... ar setting ARFLAGS... ruv checking whether Fortran files must be preprocessed... no checking for library containing zggev... no in /usr/local/lib: checking for library containing zggev... no in /opt/intel/mkl70/lib/32: checking for library containing zggev... no in /opt/intel/mkl/mkl61/lib/32: checking for library containing zggev... no in /opt/intel/mkl/lib/32: checking for library containing zggev... no in /opt/intel/mkl61/lib/32: checking for library containing zggev... no in /cineca/lib: checking for library containing zggev... no in /cineca/prod/intel/lib: checking for library containing zggev... no in /usr/local/lib: checking for library containing zggev... no in /usr/local/lib: checking for library containing zggev... no in /usr/local/intel/mkl701/lib/32: checking for library containing zggev... -lmkl_lapack checking for library containing fftwnd... -lfftw checking for library containing mpi_init... no setting LIBS... -lfftw -L/usr/local/intel/mkl701/lib/32 -lmkl_lapack -lmkl_ia32 -lguide -lpthread checking for library containing mpi_init... (cached) no checking for library containing zggev... (cached) -lmkl_lapack checking for library containing fftwnd... (cached) -lfftw checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking fftw.h usability... yes checking fftw.h presence... yes checking for fftw.h... yes setting DFLAGS... -D__LINUX -D__INTEL -D__FFTW setting FDFLAGS... $(DFLAGS) setting RANLIB... echo setting MYLIB... lapack_mkl checking module dependencies... done configure: creating ./config.status config.status: creating make.sys config.status: creating make.rules ----------------------------------------------------------------- PWscf can take advantage of several optimized numerical libraries (essl, fftw, mkl...). This configure script attempts to find them, but may fail if they have been installed in non-standard locations. The following libraries have been found: LIBS= -lfftw -L/usr/local/intel/mkl701/lib/32 -lmkl_lapack -lmkl_ia32 -lguide -lpthread If any libraries are missing, you may specify a list of directories to search and retry, as follows: ./configure LIBDIRS="list of directories, separated by spaces" For more information, read the README.INSTALL file or the PWscf manuals. ----------------------------------------------------------------- ---------------------------------------------- WARNING: parallel environment not detected this program will run in single-processor mode ---------------------------------------------- [mahmoud at condmat1 ESPRESSO]$ +++++++++++++++++++++++++++++++++++++++++++++++++++ Should I do anything more before running "./configure" to make it detect the parallel environment? Any comment is highly appreciated. Best regards, Mahmoud Payami -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20041026/fd3a2251/attachment.htm From mpayami at aeoi.org.ir Tue Oct 26 11:15:36 2004 From: mpayami at aeoi.org.ir (Mahmoud Payami) Date: Tue, 26 Oct 2004 12:45:36 +0330 Subject: [Pw_forum] out-files in parallel execution References: <001901c4bb35$7c6cc360$1b6710ac@aeoi.org.ir> Message-ID: <002f01c4bb3c$5a87d620$1b6710ac@aeoi.org.ir> When I change the TMP_DIR to $HOME/tmp in environmental-variables, the execution does not proceed. However, as I change it to /tmp, the example 1 is done fast ( in parallel?) but the out files (say, si.scf.david.out) contains the following message: -------------- si.scf.david.out can not connect to local mpd (/tmp/mpd2.console-mahmoud); possible causes: 1. no mpd running on this host 2. mpd is running but was started without a "console" (-n option) -------------------------------- I do not know how can I fix this problem. Any comment is highly appreciated. Best regards, Mahmoud Payami -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20041026/7b6c879f/attachment.htm From g.ballabio at cineca.it Tue Oct 26 11:37:15 2004 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Tue, 26 Oct 2004 11:37:15 +0200 (MEST) Subject: [Pw_forum] parallel environment not found In-Reply-To: <001901c4bb35$7c6cc360$1b6710ac@aeoi.org.ir> References: <001901c4bb35$7c6cc360$1b6710ac@aeoi.org.ir> Message-ID: <1098783435.1147.45.camel@localhost.localdomain> On Tue, 2004-10-26 at 10:26, Mahmoud Payami wrote: > Before I try to use "./configure", I have installed MPI and run > "mpdboot -n " command successfully. So the > environment for parallel is ok. I don't know this command, is it enough to say that the MPI environment works? Have you tried compiling and running a simple test program? > Afterwards, I try to use the "configure" command. As is seen at the > end it does not detect parallel environment (although it detects all > relevant mpicc, mpif77, ...): [snip] > checking for library containing mpi_init... no [snip] > ---------------------------------------------- > WARNING: parallel environment not detected > this program will run in single-processor mode > ---------------------------------------------- Could you please post the "config.log" file produced by running configure? This should contain more info on why the check failed. If you want to look at it yourself, search for "mpi_init". Gerardo From afloris at physik.fu-berlin.de Tue Oct 26 12:32:42 2004 From: afloris at physik.fu-berlin.de (Andrea Floris) Date: Tue, 26 Oct 2004 12:32:42 +0200 (CEST) Subject: [Pw_forum] OPTERON 64-bit and Portland pgf90 5.2-4 Message-ID: Dear all, I am trying to run the PWSCF version 2.1 in a OPTERON cluster of 64-bit machines. Following the suggestion of manual, I tried the PORTLAND compiler, version 5.2-4. As other people reported (but with older versions) I was able to compile without problems and run pw.x also without problems. But for phonon calculations ph.x gives me immediately a segmentation fault error. What you suggest? There is a workaround to this problem? Thank yor for your answer, Andrea From mpayami at aeoi.org.ir Tue Oct 26 13:55:32 2004 From: mpayami at aeoi.org.ir (Mahmoud Payami) Date: Tue, 26 Oct 2004 15:25:32 +0330 Subject: [Pw_forum] parallel environment not found References: <001901c4bb35$7c6cc360$1b6710ac@aeoi.org.ir> <1098783435.1147.45.camel@localhost.localdomain> Message-ID: <000f01c4bb52$b2023ce0$1b6710ac@aeoi.org.ir> Hi Gerardo, I searched the file "configure" and found out that if it finds parallel environment, it shoud add some "-D__MPI -D__PARA" somewhere in "make.sys", but these switches are absent in my "make.sys". Is it the origin? What is the cure? Thanks a lot. Mahmoud > > Before I try to use "./configure", I have installed MPI and run > > "mpdboot -n " command successfully. So the > > environment for parallel is ok. > > I don't know this command, is it enough to say that the MPI environment > works? Have you tried compiling and running a simple test program? > > > Afterwards, I try to use the "configure" command. As is seen at the > > end it does not detect parallel environment (although it detects all > > relevant mpicc, mpif77, ...): > [snip] > > checking for library containing mpi_init... no > [snip] > > ---------------------------------------------- > > WARNING: parallel environment not detected > > this program will run in single-processor mode > > ---------------------------------------------- > > Could you please post the "config.log" file produced by running > configure? This should contain more info on why the check failed. If you > want to look at it yourself, search for "mpi_init". > > Gerardo > > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From matteoc at MIT.EDU Tue Oct 26 17:00:22 2004 From: matteoc at MIT.EDU (Matteo Cococcioni) Date: Tue, 26 Oct 2004 11:00:22 -0400 Subject: [Pw_forum] Re: ask your help! In-Reply-To: <20041025101053.EEEE.SONG@cello.t.u-tokyo.ac.jp> References: <20041022160415.53A4.SONG@cello.t.u-tokyo.ac.jp> <001601c4ba28$78a58c70$1a54a8c0@nano> <20041025101053.EEEE.SONG@cello.t.u-tokyo.ac.jp> Message-ID: <1098802822.417e66861e08f@webmail.mit.edu> Dear Yingwen and Aijun I've been making some tests on an opteron machines with the CP code contained in the Espresso package (last release) and found your make.sys very useful to improve the one I had. Thank you. I also found out that with pgi compiler, instead of using acml it is more convenient to use pgi lapack and goto blas which you can download for free from the web. I have attached my make.sys to this message. It's only a small modification to yours (see "LIBS =" part) but the code could run much faster (20-25%). I hope this can help. Matteo Quoting Yingwen Song : > Hi, Aijun > > I am Yingwen Song @ The University of Tokyo. The following are the > contents of make.sys. Remember to change IFLAGS and LIBS as I told you > before. > > Wish you good luck. > > > Yingwen > > --------------------make.sys START------------------------------ > # make.sys. Generated from make.sys.in by configure. > CC = pgcc > CCFLAGS = -O3 -tp k8-64 -fast -Munroll -Mvect=sse > -Mvect=assoc,cachesize:1048576 -Mcache_align -Kieee -Mvect=prefetch $(DFLAGS) > $(IFLAGS) > # See include/defs.h.README for a list of precompilation options > # (possible arguments to -D or -U) and their meaning > DFLAGS = -D__LINUX64 -D__PGI -D__PARA -D__MPI -D__FFTW > -D__USE_INTERNAL_FFTW > IFLAGS = -I. -I../include -I../Modules -I../PW -I../PH > -I/opt/mpich-1.2.5/include > CPP = cpp > CPPFLAGS = -P -traditional $(DFLAGS) $(IFLAGS) > F77 = pgf77 > F90 = pgf90 > FFLAGS = -fast -r8 -O3 -tp k8-64 -Munroll -Mvect=sse > -Mvect=assoc,cachesize:1048576 -Mcache_align -Kieee -Mvect=prefetch > F77FLAGS = $(FFLAGS) $(IFLAGS) > F90FLAGS = $(FFLAGS) $(DFLAGS) $(IFLAGS) > F77FLAGS_NOOPT = -O0 > LD = pgf90 > LDFLAGS = $(LIBOBJS) $(LIBS) > LIBOBJS = ../flib/ptools.a ../flib/flib.a ../clib/clib.a > # LIBS must contain the location of all needed external libraries > LIBS = -lacml -L/opt/mpich-1.2.5/lib -lfmpich -lmpich > #LIBS = -llapack -lblas > # MYLIB can be one of the following (depending on LIBS): > # blas : compile the local copy of blas routines > # lapack : compile the local copy of lapack routines > # blas_and_lapack : all of the above - use this for a quick test > # or if you don't have an optimized blas/lapack library > # lapack_ibm : compile only lapack routines not present in IBM ESSL > # use this together with IBM ESSL > # lapack_t3e : compile only lapack routines not present in T3E scilib > # use this together with T3E scilib > # lapack_mkl : compile only lapack routines not present in Intel MKL > # use this together with Intel MKL > MYLIB = > AR = ar > ARFLAGS = ruv > --------------------make.sys END------------------------------ > > > Hello Yingwen, > > > > Thanks for your timely reply. > > > > I am sorry I couldn't receive the attachment successfully. If possible > could > > you please send to me as mail content or alternative to > aijun_du at hotmail.com > > ? > > > > Many thanks, > > Aijun > > ----- Original Message ----- > > From: "Yingwen Song" > > To: "Aijun Du" > > Cc: > > Sent: Friday, October 22, 2004 5:11 PM > > Subject: Re: ask your help! > > > > > > > WARNING: This e-mail has been altered by mail systems at > > > Information Technology Services at The University of Queensland > > > (www.its.uq.edu.au) > > > Following this paragraph are indications of the actual > > > changes made. > > > > > > A file named > > > > > > make.sys > > > > > > was removed from this email as it constituted a security hazard. > > > > > > It may be a virus. If you require this file, please contact > > > the sender and arrange an alternate means of receiving it. > > > For example ask the sender to resend it within > > > a non self-extracting archive. > > > > > > More information can be found at: > > > > > > http://www.uq.edu.au/uqnet/virus.html > > > > > > > > > > > > > -------------------------------------------------------------------------------- > > > > > > > Hi, Aijun > > > > > > I am Yingwen Song @ The University of Tokyo. The MPI version of make.sys > > > is attached. I am using MPICH 1.2.5. Please modify > > > "-I/opt/mpich-1.2.5/include" > > > in IFLAGS and > > > "-L/opt/mpich-1.2.5/lib" > > > in LIBS > > > > > > to point to your own MPI path. > > > > > > Good luck. > > > > > > > > >> Dear Dr. Song, > > >> > > >> I am working in the University of Queensland and also using pwscf for my > > > >> research work. I find your email address from PWSCF email list. I knew > > >> you have succeeded in compiling and running PWSCF on AMD opetron64 using > > > >> pgf90. Have you tried MPI version? Could you send me the Make.sys(MPI) > to > > >> me? > > >> > > >> I have compiled pwscf on my new AMD opteron64 machine. My test on a big > > > >> system met some problems and stopped. But for small system it is okay. > > >> > > >> Many thanks, > > >> Regards, > > >> Aijun > > > > > > -------------------------- > > > Yingwen Song, Ph.D. > > > The University of Tokyo > > > Email:song at cello.t.u-tokyo.ac.jp > > > Homepage:http://cello.t.u-tokyo.ac.jp/~song/ > > > Tel/Fax: 03-5841-1286 > > > > > > > > -------------------------- > Yingwen Song, Ph.D. > The University of Tokyo > Email:song at cello.t.u-tokyo.ac.jp > Homepage:http://cello.t.u-tokyo.ac.jp/~song/ > Tel/Fax: 03-5841-1286 > > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > -------------- next part -------------- A non-text attachment was scrubbed... Name: make.sys_opt_pgi_ser_goto_lap Type: application/octet-stream Size: 2125 bytes Desc: not available Url : /pipermail/attachments/20041026/cb8922ba/attachment.obj From aaron at nemo.physics.ncsu.edu Tue Oct 26 14:54:13 2004 From: aaron at nemo.physics.ncsu.edu (aaron at nemo.physics.ncsu.edu) Date: Tue, 26 Oct 2004 08:54:13 -0400 (EDT) Subject: [Pw_forum] cp.x and lemieux TRU64 Alpha In-Reply-To: <000f01c4bb52$b2023ce0$1b6710ac@aeoi.org.ir> Message-ID: Hi, The problem I'd like to solve is the following: Our cp.x build on the Pittsburg Supercomputing Center alpha cluster Lemieux is failing. The code runs perfectly while we minimize the electronic wavefunction. When we minimize the ionic structure the run fails with the following error: ______________standard out error message_________________________ forrtl: error (72): floating overflow forrtl: error (76): IOT trap signal _________________________________________________________________ In the pipline output the message is as follows: ***************************************************************** <> subroutine rhoofr: total integrated electronic density in g-space = 50.000000 in r-space = 50.000000 total energy = -75.04974 a.u. kinetic energy = 39.40916 a.u. electrostatic energy = -56.31996 a.u. esr = 4.15664 a.u. eself = 61.30307 a.u. pseudopotential energy = -48.85354 a.u. n-l pseudopotential energy = 12.79418 a.u. exchange-correlation energy = -22.07958 a.u. average potential = -0.10767 a.u. exception system: exiting due to multiple internal errors: handler returned invalid disposition exception dispatch or unwind stuck in infinite loop ***************************************************************** We have isolated the failure to the subroutine ortho. It performs roughly five iterations and the error occurs. Is any forum member running CPV/cp.x on the psc machines or similar architecture? I'm attaching the make.sys for inspection. We have reduced the optimizations with no change in the result. Also we used both old and new methods of configure. Thanks in advance for any advice you can provide, Aaron -------------- next part -------------- OSHOME=/usr/users/0/georgea/AiMDF90 # # System-dependent definitions for HP/COMPAQ alpha parallel machines # (contributed by Guido Roma). Edit according to your needs # # Use fft routines from the dxml or cxml library: # CPPFLAGS = -D__ALPHA -D__PARA -D__MPI -DDXML -I$(OSHOME)/include # Use precompiled fftw library (version <= 2.1.5, NOT v.3!) # # In this case, specify also how to load the fftw library (FFTW_LIB) # and the path to the fftw.h include file (FFTW_INC_DIR). Example: # FFTW_LIB=-L/usr/local/src/fftw-2.1.3/fftw/.libs -lfftw # FFTW_INC_DIR=/usr/local/src/fftw-2.1.3/fftw # CPPFLAGS = -D__ALPHA -D__PARA -D__MPI -D__FFTW \ # -I$(OSHOME)/include -I$(FFTW_INC_DIR) # Use the local copy of fftw # CPPFLAGS = -D__ALPHA -D__PARA -D__MPI -D__FFTW -D__USE_INTERNAL_FFTW \ -I$(OSHOME)/include -I./ # # Fortran compiler: # F90 = f90 F77 = f90 CC = cc # # Fortran options: # FFLAGS = -O -fpe0 -real_size 64 -align dcommons -align records # Flags for FPMD # FFLAGS = -double_size 64 -fpconstant -real_size 64 -fast \ # -math_library fast -tune ev68 # F77FLAGS = $(FFLAGS) F90FLAGS = $(FFLAGS) -free -cpp $(CPPFLAGS) CCFLAGS = -O $(CPPFLAGS) # # This is needed to tell the compiler where modules are # MODULEFLAG= -I$(OSHOME)/Modules -I$(OSHOME)/PW -I$(OSHOME)/PH # # Libraries (mpi + cxml + fftw) : # LIBS = -lfmpi -lpmpi -lmpi -lelan -lcxml $(FFTW_LIB) # # Loader: # LD=$(F90) LDFLAGS = $(OSHOME)/flib/ptools.a $(OSHOME)/flib/flib.a $(OSHOME)/clib/clib.a $(LIBS) AR = ar ARFLAGS = rv From giannozz at nest.sns.it Tue Oct 26 17:24:11 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 26 Oct 2004 17:24:11 +0200 Subject: [Pw_forum] cp.x and lemieux TRU64 Alpha In-Reply-To: References: Message-ID: <200410261724.11517.giannozz@nest.sns.it> On Tuesday 26 October 2004 14:54, aaron at nemo.physics.ncsu.edu wrote: > We have isolated the failure to the subroutine ortho does the failure occur in one of the first steps after a restart? the iterative orthonormalization is notoriously unstable if psi(t+dt) and psi(t) differ too much. Try to reduce the time step, maybe just for the first few steps. 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 yonasb at yahoo.com Tue Oct 26 17:40:56 2004 From: yonasb at yahoo.com (Yonas Abraham) Date: Tue, 26 Oct 2004 08:40:56 -0700 (PDT) Subject: [Pw_forum] cp.x and lemieux TRU64 Alpha In-Reply-To: <200410261724.11517.giannozz@nest.sns.it> Message-ID: <20041026154056.72211.qmail@web60807.mail.yahoo.com> Hi Paolo, It looks like the 'bug' is machine dependent. we took the same input parameter identical source code and run it in PGI compiler both 32 and 64 bit versions and intel on 32 bit machines and worked just fine. even though small perturbation in the machine accuracy difference can create instability, i would expect the difference would be bigger between 32 and 64 bits. here is the snapshot of the otho diff. diff= 2.58117779926850 iter= 1 diff= 6.73012657805981 iter= 2 ......///.... diff= 5.958041775915444E+117 iter= 10 diff= 1.644433412630960E+235 iter= 11 then it crushes. we have tried different dt values and didn't help. any help would be appreciated --- Paolo Giannozzi wrote: > On Tuesday 26 October 2004 14:54, > aaron at nemo.physics.ncsu.edu wrote: > > > We have isolated the failure to the subroutine > ortho > > does the failure occur in one of the first steps > after a > restart? the iterative orthonormalization is > notoriously > unstable if psi(t+dt) and psi(t) differ too much. > Try to > reduce the time step, maybe just for the first few > steps. > > Paolo > > -- > Paolo Giannozzi e-mail: > giannozz at nest.sns.it > Scuola Normale Superiore Phone: +39/050-509876, > Fax:-563513 > Piazza dei Cavalieri 7 I-56126 Pisa, Italy > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From silviu at Princeton.EDU Tue Oct 26 17:56:30 2004 From: silviu at Princeton.EDU (Silviu Zilberman) Date: Tue, 26 Oct 2004 11:56:30 -0400 Subject: [Pw_forum] cp.x and lemieux TRU64 Alpha In-Reply-To: <20041026154056.72211.qmail@web60807.mail.yahoo.com> References: <20041026154056.72211.qmail@web60807.mail.yahoo.com> Message-ID: <417E73AE.8060106@Princeton.EDU> Hi, Maybe you try using steepest descent for some number of steps, and then move back to the 'ortho'? Silviu. Yonas Abraham wrote: >Hi Paolo, >It looks like the 'bug' is machine dependent. we took >the same input parameter identical source code and run >it in PGI compiler both 32 and 64 bit versions and >intel on 32 bit machines and worked just fine. even >though small perturbation in the machine accuracy >difference can create instability, i would expect the >difference would be bigger between 32 and 64 bits. >here is the snapshot of the otho diff. > > diff= 2.58117779926850 iter= 1 > diff= 6.73012657805981 iter= 2 > ......///.... > diff= 5.958041775915444E+117 iter= 10 > diff= 1.644433412630960E+235 iter= 11 > >then it crushes. > >we have tried different dt values and didn't help. > >any help would be appreciated > > >--- Paolo Giannozzi wrote: > > > >>On Tuesday 26 October 2004 14:54, >>aaron at nemo.physics.ncsu.edu wrote: >> >> >> >>>We have isolated the failure to the subroutine >>> >>> >>ortho >> >>does the failure occur in one of the first steps >>after a >>restart? the iterative orthonormalization is >>notoriously >>unstable if psi(t+dt) and psi(t) differ too much. >>Try to >>reduce the time step, maybe just for the first few >>steps. >> >>Paolo >> >>-- >>Paolo Giannozzi e-mail: >>giannozz at nest.sns.it >>Scuola Normale Superiore Phone: +39/050-509876, >>Fax:-563513 >>Piazza dei Cavalieri 7 I-56126 Pisa, Italy >>_______________________________________________ >>Pw_forum mailing list >>Pw_forum at pwscf.org >>http://www.democritos.it/mailman/listinfo/pw_forum >> >> >> > > > >__________________________________ >Do you Yahoo!? >Yahoo! Mail Address AutoComplete - You start. We finish. >http://promotions.yahoo.com/new_mail >_______________________________________________ >Pw_forum mailing list >Pw_forum at pwscf.org >http://www.democritos.it/mailman/listinfo/pw_forum > > -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Zilberman Silviu 213 Frick Laboratory, Department of Chemistry, Princeton University Princeton, NJ 08544, USA phone: 609-258-1834 fax: 609-258-6746 silviu at Princeton.EDU %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From mpayami at aeoi.org.ir Tue Oct 26 18:21:55 2004 From: mpayami at aeoi.org.ir (Mahmoud Payami) Date: Tue, 26 Oct 2004 19:51:55 +0330 Subject: [Pw_forum] parallel environment not found References: <001901c4bb35$7c6cc360$1b6710ac@aeoi.org.ir> <1098783435.1147.45.camel@localhost.localdomain> <000f01c4bb52$b2023ce0$1b6710ac@aeoi.org.ir> Message-ID: <003f01c4bb77$e8d8ef50$1b6710ac@aeoi.org.ir> Dear All, When I use "./configure" it complains "no parallel environment detected", and in the file "make.sys" the following two lines: DFLAGS=-D__LINUX -D__INTEL -D__FFTW LDFLAGS=-Vaxlib -static $(LIBOBJS) $(LIBS) However, when I use "./configure --enable-shared", it detects the parallel environment, and in the file "make.sys" the following two lines: DFLAGS=-D__LINUX -D__INTEL -D__MPI -D__PARA -D__FFTW LDFLAGS=-Vaxlib $(LIBOBJS) $(LIBS). I change the two lines in "make.sys" as: DFLAGS=-D__LINUX -D__INTEL -D__MPI -D__PARA -D__FFTW LDFLAGS=-Vaxlib -static $(LIBOBJS) $(LIBS) and execute "makedeps.sh". Then using "make all", proceeds successfully up to "pwtools" which thanks to Paolo's comment I know the cure. Now trying to run example01, the computer sleeps and the only nonempty file in /results is si.scf.daviv.out which contains: ============================= Program PWSCF v.2.1 starts ... Today is 26Oct2004 at 20:33:25 Parallel version (MPI) Number of processors in use: 10 R & G space division: nprocp = 10 Ultrasoft (Vanderbilt) Pseudopotentials Current dimensions of program pwscf are: ntypx =10 npk =40000 lmax = 3 nchix = 6 ndmx = 2000 nbrx =14 nqfx = 8 ==================================== Someone please help me to find the way out. Thanks in advance. Mahmoud Payami From giannozz at nest.sns.it Tue Oct 26 18:40:02 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Tue, 26 Oct 2004 18:40:02 +0200 Subject: [Pw_forum] cp.x and lemieux TRU64 Alpha In-Reply-To: <20041026154056.72211.qmail@web60807.mail.yahoo.com> References: <20041026154056.72211.qmail@web60807.mail.yahoo.com> Message-ID: <200410261840.02866.giannozz@nest.sns.it> On Tuesday 26 October 2004 17:40, Yonas Abraham wrote: > we took the same input parameter identical source code > and run it in PGI compiler both 32 and 64 bit versions and > intel on 32 bit machines and worked just fine [...] > here is the snapshot of the ortho diff. > > diff= 2.58117779926850 iter= 1 > diff= 6.73012657805981 iter= 2 1) check for un-initialized variables, with the appropriate compiler flag, if any 2) restart from the same file on two different machines (both 64-bit: it is possible in principle, in practise I don't know), compare what ortho does in the two cases 3) if you cannot restart from the same file, try anyway to track what ortho does in two calculations as similar as possible on different machines 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 afloris at physik.fu-berlin.de Tue Oct 26 19:12:09 2004 From: afloris at physik.fu-berlin.de (Andrea Floris) Date: Tue, 26 Oct 2004 19:12:09 +0200 (CEST) Subject: [Pw_forum] Re: OPTERON 64-bit and Portland pgf90 5.2-4 In-Reply-To: <20041026150301.8542.95944.Mailman@democritos.sissa.it> References: <20041026150301.8542.95944.Mailman@democritos.sissa.it> Message-ID: I answer myself:), hoping that it can be useful for somebody. The ./configure put in make.sys as compilation flags: FFLAGS = -fast -r8 $(IFLAGS) where -fast == -O2 -Munroll=c:1 -Mnoframe -Mlre I changed the optimization level to -01, that is, substituting: FFLAGS = -fast -r8 $(IFLAGS) with: FFLAGS = -O1 -Mnoframe -Mlre -r8 $(IFLAGS) and ph.x does not give any more segmentation fault errors. If anyone has another solution, maybe preserving the optimization level -02, please let me know.. Thanks, Andrea On Tue, 26 Oct 2004 pw_forum-request at pwscf.org wrote: > > Message: 5 > Date: Tue, 26 Oct 2004 12:32:42 +0200 (CEST) > From: Andrea Floris > To: pw_forum at pwscf.org > Subject: [Pw_forum] OPTERON 64-bit and Portland pgf90 5.2-4 > Reply-To: pw_forum at pwscf.org > > Dear all, I am trying to run the PWSCF version 2.1 in a OPTERON > cluster of 64-bit > machines. Following the suggestion of manual, I tried the PORTLAND > compiler, version 5.2-4. As other people reported (but with older > versions) I was able to > compile without problems and run pw.x also without problems. But for > phonon calculations ph.x gives me immediately a segmentation fault error. > What you suggest? There is a workaround to this problem? > > Thank yor for your answer, > > Andrea > From yonasb at yahoo.com Tue Oct 26 20:34:21 2004 From: yonasb at yahoo.com (Yonas Abraham) Date: Tue, 26 Oct 2004 11:34:21 -0700 (PDT) Subject: [Pw_forum] cp.x and lemieux TRU64 Alpha In-Reply-To: <200410261840.02866.giannozz@nest.sns.it> Message-ID: <20041026183421.44879.qmail@web60802.mail.yahoo.com> Hi, I did a comparison b/n the two 64 bits. Actually, when we look in detail to the diff in log file, even the PGI 64 bit version blows out, but strangling, it adjusted it self with a different guess, I guess. here is the log for the PGI 64 bit. diff= 2.498089579263851 iter= 1 diff= 6.083014579370730 iter= 2 diff= 20.35737489304835 iter= 3 diff= 129.7643878903619 iter= 4 diff= 3621.400080136234 iter= 5 diff= 4616116.523432171 iter= 6 diff= 12739856780499.26 iter= 7 diff= 1.2524752110924165E+026 iter= 8 diff= 1.2478638673171860E+052 iter= 9 diff= 1.2250435300965247E+104 iter= 10 diff= 1.1771833447890517E+208 iter= 11 diff= inf iter= 12 diff= 1.752692656206230 iter= 13 diff= 0.2853517316994355 iter= 14 diff= 0.1048934415556536 iter= 15 diff= 4.4504330932978231E-002 iter= 16 in the case of alpha TRU64 version, after Iter=11, it crushed and stop but the case of PGI it resets itself once it reached inf. how is this happen? is there any switch that controls this? --- Paolo Giannozzi wrote: > On Tuesday 26 October 2004 17:40, Yonas Abraham > wrote: > > > we took the same input parameter identical source > code > > and run it in PGI compiler both 32 and 64 bit > versions and > > intel on 32 bit machines and worked just fine > [...] > > here is the snapshot of the ortho diff. > > > > diff= 2.58117779926850 iter= > 1 > > diff= 6.73012657805981 iter= > 2 > > 1) check for un-initialized variables, with the > appropriate compiler > flag, if any > 2) restart from the same file on two different > machines (both 64-bit: > it is possible in principle, in practise I don't > know), compare what > ortho does in the two cases > 3) if you cannot restart from the same file, try > anyway to track > what ortho does in two calculations as similar as > possible on > different machines > > 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 > _______________________________________________ > __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From marzari at MIT.EDU Tue Oct 26 21:01:36 2004 From: marzari at MIT.EDU (Nicola Marzari) Date: Tue, 26 Oct 2004 15:01:36 -0400 Subject: [Pw_forum] Performance of ESPRESSO CP on Pentium, Nocona, Opteron Message-ID: <417E9F10.5040301@mit.edu> Dear All, we have been doing performance tests on several platforms for the past few years - these standards tests and results could be useful for the community at large, and so we've put them on a small web page: http://nnn.mit.edu/ESPRESSO/CP90_tests/ In particular, we are intrigued by the fact that we cannot seem to get a CPU performance on Opteron platforms anywhere near the Intel. While Opterons do very well in terms of memory bus speed, our best Opteron performance (1 CPU of a 250, 2.4 GHz) is still 75% slower than a Nocona (1 CPU, 3.2 GHz, 1 MB cache), and 43% slower than a PIV (1 CPU, 3.2 GHz, 512 KB cache). We'd be very happy to keep collecting CPU timings for any of the two tests listed above (AgI_small.j and AgI_large.j) - please follow as closely as possible the instructions on the details needed on CPUs and compiilers. Ultimately these numbers would make their way to the official pages... 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 konstantin_kudin at yahoo.com Wed Oct 27 00:32:15 2004 From: konstantin_kudin at yahoo.com (Konstantin Kudin) Date: Tue, 26 Oct 2004 15:32:15 -0700 (PDT) Subject: [Pw_forum] cp.x and lemieux TRU64 Alpha In-Reply-To: <20041026183421.44879.qmail@web60802.mail.yahoo.com> Message-ID: <20041026223215.85804.qmail@web52003.mail.yahoo.com> It seems that since two 64-bit versions (Alpha and x86-64) blow up almost identically under otherwise vastly different environments, there is a good indication that the bug is due to the code itself. The size of Real*8 arrays is not affected by 32/64 bits. Then there could be some integer misallocation if somewhere the 4-byte integer is hardcoded for 32 bits but becomes 8 bytes under 64-bits and overwrites something else. If some variables/arrays are accessed before being initialized, one could set all Real*8 to 'NaN' via compiler flags, and see if the code fails. SGI compilers were especially user friendly with respect to crashes, and could easily tell where the crash happened by using "dbx corefile; where". SGI is also a 64-bit machine, and should fail similarly to Alpha if the code itself contains a bug. Kostya --- Yonas Abraham wrote: > Hi, > > I did a comparison b/n the two 64 bits. Actually, when > we look in detail to the diff in log file, even the > PGI 64 bit version blows out, but strangling, it > adjusted it self with a different guess, I guess. here > is the log for the PGI 64 bit. > > diff= 2.498089579263851 iter= > 1 > diff= 6.083014579370730 iter= > 2 > diff= 20.35737489304835 iter= > 3 > diff= 129.7643878903619 iter= > 4 > diff= 3621.400080136234 iter= > 5 > diff= 4616116.523432171 iter= > 6 > diff= 12739856780499.26 iter= > 7 > diff= 1.2524752110924165E+026 iter= > 8 > diff= 1.2478638673171860E+052 iter= > 9 > diff= 1.2250435300965247E+104 iter= > 10 > diff= 1.1771833447890517E+208 iter= > 11 > diff= inf iter= > 12 > diff= 1.752692656206230 iter= > 13 > diff= 0.2853517316994355 iter= > 14 > diff= 0.1048934415556536 iter= > 15 > diff= 4.4504330932978231E-002 iter= > 16 > > > in the case of alpha TRU64 version, after Iter=11, it > crushed and stop but the case of PGI it resets itself > once it reached inf. > > how is this happen? is there any switch that controls > this? > > > > --- Paolo Giannozzi wrote: > > > On Tuesday 26 October 2004 17:40, Yonas Abraham > > wrote: > > > > > we took the same input parameter identical source > > code > > > and run it in PGI compiler both 32 and 64 bit > > versions and > > > intel on 32 bit machines and worked just fine > > [...] > > > here is the snapshot of the ortho diff. > > > > > > diff= 2.58117779926850 iter= > > 1 > > > diff= 6.73012657805981 iter= > > 2 > > > > 1) check for un-initialized variables, with the > > appropriate compiler > > flag, if any > > 2) restart from the same file on two different > > machines (both 64-bit: > > it is possible in principle, in practise I don't > > know), compare what > > ortho does in the two cases > > 3) if you cannot restart from the same file, try > > anyway to track > > what ortho does in two calculations as similar as > > possible on > > different machines > > > > 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 > > _______________________________________________ > > > > > > __________________________________ > Do you Yahoo!? > Read only the mail you want - Yahoo! Mail SpamGuard. > http://promotions.yahoo.com/new_mail > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From song at cello.t.u-tokyo.ac.jp Wed Oct 27 03:18:33 2004 From: song at cello.t.u-tokyo.ac.jp (Yingwen Song) Date: Wed, 27 Oct 2004 10:18:33 +0900 Subject: [Pw_forum] Re: ask your help! In-Reply-To: <1098802822.417e66861e08f@webmail.mit.edu> References: <20041025101053.EEEE.SONG@cello.t.u-tokyo.ac.jp> <1098802822.417e66861e08f@webmail.mit.edu> Message-ID: <20041027101348.EA64.SONG@cello.t.u-tokyo.ac.jp> Dear Matteo: I am Yingwen @ The University of Tokyo. Thanks a lot for your information. Actually, I am interested in performance instead of physics. Best wishes. Yingwen > > Dear Yingwen and Aijun > > I've been making some tests on an opteron machines with the CP code contained > in > the Espresso package (last release) and found your make.sys very useful to > improve the one I had. Thank you. > > I also found out that with pgi compiler, instead of using acml it is more > convenient to use pgi lapack and goto blas which you can download for free from > the web. I have attached my make.sys to this message. > > It's only a small modification to yours (see "LIBS =" part) but the code could > run much faster > (20-25%). > > I hope this can help. > > Matteo > > > Quoting Yingwen Song : > > > Hi, Aijun > > > > I am Yingwen Song @ The University of Tokyo. The following are the > > contents of make.sys. Remember to change IFLAGS and LIBS as I told you > > before. > > > > Wish you good luck. > > > > > > Yingwen > > > > --------------------make.sys START------------------------------ > > # make.sys. Generated from make.sys.in by configure. > > CC = pgcc > > CCFLAGS = -O3 -tp k8-64 -fast -Munroll -Mvect=sse > > -Mvect=assoc,cachesize:1048576 -Mcache_align -Kieee -Mvect=prefetch $(DFLAGS) > > $(IFLAGS) > > # See include/defs.h.README for a list of precompilation options > > # (possible arguments to -D or -U) and their meaning > > DFLAGS = -D__LINUX64 -D__PGI -D__PARA -D__MPI -D__FFTW > > -D__USE_INTERNAL_FFTW > > IFLAGS = -I. -I../include -I../Modules -I../PW -I../PH > > -I/opt/mpich-1.2.5/include > > CPP = cpp > > CPPFLAGS = -P -traditional $(DFLAGS) $(IFLAGS) > > F77 = pgf77 > > F90 = pgf90 > > FFLAGS = -fast -r8 -O3 -tp k8-64 -Munroll -Mvect=sse > > -Mvect=assoc,cachesize:1048576 -Mcache_align -Kieee -Mvect=prefetch > > F77FLAGS = $(FFLAGS) $(IFLAGS) > > F90FLAGS = $(FFLAGS) $(DFLAGS) $(IFLAGS) > > F77FLAGS_NOOPT = -O0 > > LD = pgf90 > > LDFLAGS = $(LIBOBJS) $(LIBS) > > LIBOBJS = ../flib/ptools.a ../flib/flib.a ../clib/clib.a > > # LIBS must contain the location of all needed external libraries > > LIBS = -lacml -L/opt/mpich-1.2.5/lib -lfmpich -lmpich > > #LIBS = -llapack -lblas > > # MYLIB can be one of the following (depending on LIBS): > > # blas : compile the local copy of blas routines > > # lapack : compile the local copy of lapack routines > > # blas_and_lapack : all of the above - use this for a quick test > > # or if you don't have an optimized blas/lapack library > > # lapack_ibm : compile only lapack routines not present in IBM ESSL > > # use this together with IBM ESSL > > # lapack_t3e : compile only lapack routines not present in T3E scilib > > # use this together with T3E scilib > > # lapack_mkl : compile only lapack routines not present in Intel MKL > > # use this together with Intel MKL > > MYLIB = > > AR = ar > > ARFLAGS = ruv > > --------------------make.sys END------------------------------ > > > > > Hello Yingwen, > > > > > > Thanks for your timely reply. > > > > > > I am sorry I couldn't receive the attachment successfully. If possible > > could > > > you please send to me as mail content or alternative to > > aijun_du at hotmail.com > > > ? > > > > > > Many thanks, > > > Aijun > > > ----- Original Message ----- > > > From: "Yingwen Song" > > > To: "Aijun Du" > > > Cc: > > > Sent: Friday, October 22, 2004 5:11 PM > > > Subject: Re: ask your help! > > > > > > > > > > WARNING: This e-mail has been altered by mail systems at > > > > Information Technology Services at The University of Queensland > > > > (www.its.uq.edu.au) > > > > Following this paragraph are indications of the actual > > > > changes made. > > > > > > > > A file named > > > > > > > > make.sys > > > > > > > > was removed from this email as it constituted a security hazard. > > > > > > > > It may be a virus. If you require this file, please contact > > > > the sender and arrange an alternate means of receiving it. > > > > For example ask the sender to resend it within > > > > a non self-extracting archive. > > > > > > > > More information can be found at: > > > > > > > > http://www.uq.edu.au/uqnet/virus.html > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------------------- > > > > > > > > > > Hi, Aijun > > > > > > > > I am Yingwen Song @ The University of Tokyo. The MPI version of make.sys > > > > is attached. I am using MPICH 1.2.5. Please modify > > > > "-I/opt/mpich-1.2.5/include" > > > > in IFLAGS and > > > > "-L/opt/mpich-1.2.5/lib" > > > > in LIBS > > > > > > > > to point to your own MPI path. > > > > > > > > Good luck. > > > > > > > > > > > >> Dear Dr. Song, > > > >> > > > >> I am working in the University of Queensland and also using pwscf for my > > > > > >> research work. I find your email address from PWSCF email list. I knew > > > >> you have succeeded in compiling and running PWSCF on AMD opetron64 using > > > > > >> pgf90. Have you tried MPI version? Could you send me the Make.sys(MPI) > > to > > > >> me? > > > >> > > > >> I have compiled pwscf on my new AMD opteron64 machine. My test on a big > > > > > >> system met some problems and stopped. But for small system it is okay. > > > >> > > > >> Many thanks, > > > >> Regards, > > > >> Aijun > > > > > > > > -------------------------- > > > > Yingwen Song, Ph.D. > > > > The University of Tokyo > > > > Email:song at cello.t.u-tokyo.ac.jp > > > > Homepage:http://cello.t.u-tokyo.ac.jp/~song/ > > > > Tel/Fax: 03-5841-1286 > > > > > > > > > > > > -------------------------- > > Yingwen Song, Ph.D. > > The University of Tokyo > > Email:song at cello.t.u-tokyo.ac.jp > > Homepage:http://cello.t.u-tokyo.ac.jp/~song/ > > Tel/Fax: 03-5841-1286 > > > > > > _______________________________________________ > > Pw_forum mailing list > > Pw_forum at pwscf.org > > http://www.democritos.it/mailman/listinfo/pw_forum > > > > > -------------------------- Yingwen Song, Ph.D. The University of Tokyo Email:song at cello.t.u-tokyo.ac.jp Homepage:http://cello.t.u-tokyo.ac.jp/~song/ Tel/Fax: 03-5841-1286 From mpayami at aeoi.org.ir Tue Oct 26 13:48:42 2004 From: mpayami at aeoi.org.ir (Mahmoud Payami) Date: Tue, 26 Oct 2004 15:18:42 +0330 Subject: [Pw_forum] parallel environment not found References: <001901c4bb35$7c6cc360$1b6710ac@aeoi.org.ir> <1098783435.1147.45.camel@localhost.localdomain> Message-ID: <000701c4bb51$be329e70$1b6710ac@aeoi.org.ir> Hi Gerardo! In the version (MPICH2) which I am using, there is no "mpi_init" commant but instead "mpdboot". I have also run an example which work fine using the command "mpiexec -n 20 cpi" which calls the hosts listed in the file "mpd.hosts" for totally 20 executions. I think since the configure does not find the special "mpi_init" command, it sets the compiling and linking switches appropriate for single processor. If it is so, please let me know how to set them in the "make.sys" appropriately. Best regards, Mahmoud Here is the log-file: =========================================================== This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by PWscf configure 2.1, which was generated by GNU Autoconf 2.59. Invocation command line was $ ./configure ## --------- ## ## Platform. ## ## --------- ## hostname = condmat1.ctpm.aeoi.org uname -m = i686 uname -r = 2.6.5-1.358smp uname -s = Linux uname -v = #1 SMP Sat May 8 09:25:36 EDT 2004 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = i686 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/bin PATH: /usr/local/ActiveTcl/bin PATH: /home/nis/SHARED_FOLDER/ESPRESSO/PWgui-2.1 PATH: /home/nis/SHARED_FOLDER/XCrySDen-B1.0bin-static PATH: /usr/local/intel/compiler70/ia32/bin PATH: /usr/local/bin PATH: /usr/local/ActiveTcl/bin PATH: /home/nis/SHARED_FOLDER/ESPRESSO/PWgui-2.1 PATH: /home/nis/SHARED_FOLDER/XCrySDen-B1.0bin-static PATH: /usr/local/intel/compiler70/ia32/bin PATH: /usr/kerberos/bin PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/X11R6/bin PATH: /home/nis/SHARED_FOLDER/XCrySDen-B1.0bin-static/scripts PATH: /home/nis/SHARED_FOLDER/XCrySDen-B1.0bin-static/util PATH: /home/nis/SHARED_FOLDER/WIEN2k.04.10 PATH: . PATH: /home/nis/mahmoud/bin PATH: /home/nis/SHARED_FOLDER/XCrySDen-B1.0bin-static/scripts PATH: /home/nis/SHARED_FOLDER/XCrySDen-B1.0bin-static/util PATH: /home/nis/SHARED_FOLDER/WIEN2k.04.10 PATH: . ## ----------- ## ## Core tests. ## ## ----------- ## configure:1377: checking build system type configure:1395: result: i686-pc-linux-gnu configure:1542: checking for mpif90 configure:1558: found /usr/local/bin/mpif90 configure:1568: result: mpif90 configure:1583: checking for Fortran 77 compiler version configure:1586: mpif90 --version &5 ifc: Command line warning: ignoring unknown option '-fversion' /usr/lib/crt1.o(.text+0x18): In function `_start': : undefined reference to `main' configure:1589: $? = 1 configure:1591: mpif90 -v &5 mpif90 for ld \ /usr/lib/crt1.o \ /usr/lib/crti.o \ /usr/local/intel/compiler70/ia32/lib/crtxi.o \ -dynamic-linker \ /lib/ld-linux.so.2 \ -u \ ___get_intrinsics \ -o \ a.out \ -rpath \ /usr/local/intel/compiler70/ia32/lib \ -L \ /usr/local/lib \ -lmpichf90 \ -lmpich \ -Qy \ -L/usr/local/intel/compiler70/ia32/lib \ -L/usr/lib \ -Bstatic \ -lintrins \ -lIEPCF90 \ -lF90 \ -lintrins \ -limf \ -Bdynamic \ -lm \ -Bstatic \ -lirc \ -Bdynamic \ -lcxa \ -Bstatic \ -lunwind \ -Bdynamic \ -lc \ /usr/local/intel/compiler70/ia32/lib/crtxn.o \ /usr/lib/crtn.o /usr/lib/crt1.o(.text+0x18): In function `_start': : undefined reference to `main' configure:1594: $? = 1 configure:1596: mpif90 -V &5 Intel(R) Fortran Compiler for 32-bit applications, Version 7.1 Build 20040713Z Copyright (C) 1985-2004 Intel Corporation. All rights reserved. FOR NON-COMMERCIAL USE ONLY /usr/lib/crt1.o(.text+0x18): In function `_start': : undefined reference to `main' GNU ld version 2.15.90.0.3 20040415 Supported emulations: elf_i386 i386linux configure:1599: $? = 1 configure:1613: checking for Fortran 77 compiler default output file name configure:1616: mpif90 conftest.f >&5 program MAIN 3 Lines Compiled configure:1619: $? = 0 configure:1665: result: a.out configure:1670: checking whether the Fortran 77 compiler works configure:1676: ./a.out configure:1679: $? = 0 configure:1696: result: yes configure:1703: checking whether we are cross compiling configure:1705: result: no configure:1708: checking for suffix of executables configure:1710: mpif90 -o conftest conftest.f >&5 program MAIN 3 Lines Compiled configure:1713: $? = 0 configure:1738: result: configure:1744: checking for suffix of object files configure:1755: mpif90 -c conftest.f >&5 program MAIN 3 Lines Compiled configure:1758: $? = 0 configure:1780: result: o configure:1788: checking whether we are using the GNU Fortran 77 compiler configure:1802: mpif90 -c conftest.F >&5 program MAIN choke me ^ Error 7 at (3:conftest.F) : incomplete statement 1 Error compilation aborted for conftest.F (code 1) configure:1808: $? = 1 configure: failed program was: | program main | #ifndef __GNUC__ | choke me | #endif | | end configure:1833: result: no configure:1839: checking whether mpif90 accepts -g configure:1851: mpif90 -c -g conftest.f >&5 program MAIN 3 Lines Compiled configure:1857: $? = 0 configure:1860: test -z || test ! -s conftest.err configure:1863: $? = 0 configure:1866: test -s conftest.o configure:1869: $? = 0 configure:1881: result: yes configure:2075: checking for mpif77 configure:2091: found /usr/local/bin/mpif77 configure:2101: result: mpif77 configure:2116: checking for Fortran 77 compiler version configure:2119: mpif77 --version &5 GNU Fortran (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7) Copyright (C) 2002 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING or type the command `info -f g77 Copying'. configure:2122: $? = 0 configure:2124: mpif77 -v &5 mpif77 for Driving: g77 -I/usr/local/include -L/usr/local/lib -v -lmpich -lfrtbegin -lg2c -lm -s hared-libgcc Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwi nd-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-li nux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crt1.o /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crti.o /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/crtbegin.o -L/usr/local/lib -L/usr/ lib/gcc-lib/i386-redhat-linux/3.3.3 -L/usr/lib/gcc-lib/i386-redhat-linux/3.3 .3/../../.. -lmpich -lfrtbegin -lg2c -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/crtend.o /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crtn.o /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/libfrtbegin.a(frtbegin.o)(.text+0x3 2): In function `main': : undefined reference to `MAIN__' collect2: ld returned 1 exit status configure:2127: $? = 1 configure:2129: mpif77 -V &5 g77: `-V' must come at the start of the command line configure:2132: $? = 1 configure:2140: checking whether we are using the GNU Fortran 77 compiler configure:2154: mpif77 -c -g conftest.F >&5 configure:2160: $? = 0 configure:2163: test -z || test ! -s conftest.err configure:2166: $? = 0 configure:2169: test -s conftest.o configure:2172: $? = 0 configure:2185: result: yes configure:2191: checking whether mpif77 accepts -g configure:2203: mpif77 -c -g conftest.f >&5 configure:2209: $? = 0 configure:2212: test -z || test ! -s conftest.err configure:2215: $? = 0 configure:2218: test -s conftest.o configure:2221: $? = 0 configure:2233: result: yes configure:2314: checking for mpicc configure:2330: found /usr/local/bin/mpicc configure:2340: result: mpicc configure:2361: checking for C compiler version configure:2364: mpicc --version &5 gcc (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2367: $? = 0 configure:2369: mpicc -v &5 mpicc for Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwi nd-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-li nux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crt1.o /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crti.o /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/crtbegin.o -L/usr/local/lib -L/usr/ lib/gcc-lib/i386-redhat-linux/3.3.3 -L/usr/lib/gcc-lib/i386-redhat-linux/3.3 .3/../../.. -lmpich -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as- needed -lgcc_s --no-as-needed /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/crtend.o /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crtn.o /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crt1.o(.text+0x18): In function `_start': : undefined reference to `main' collect2: ld returned 1 exit status configure:2372: $? = 1 configure:2374: mpicc -V &5 gcc: `-V' must come at the start of the command line configure:2377: $? = 1 configure:2380: checking whether we are using the GNU C compiler configure:2404: mpicc -c conftest.c >&5 configure:2410: $? = 0 configure:2413: test -z || test ! -s conftest.err configure:2416: $? = 0 configure:2419: test -s conftest.o configure:2422: $? = 0 configure:2435: result: yes configure:2441: checking whether mpicc accepts -g configure:2462: mpicc -c -g conftest.c >&5 configure:2468: $? = 0 configure:2471: test -z || test ! -s conftest.err configure:2474: $? = 0 configure:2477: test -s conftest.o configure:2480: $? = 0 configure:2491: result: yes configure:2508: checking for mpicc option to accept ANSI C configure:2578: mpicc -c -g -O2 conftest.c >&5 configure:2584: $? = 0 configure:2587: test -z || test ! -s conftest.err configure:2590: $? = 0 configure:2593: test -s conftest.o configure:2596: $? = 0 configure:2614: result: none needed configure:2632: mpicc -c -g -O2 conftest.c >&5 conftest.c:2: error: syntax error before "me" configure:2638: $? = 1 configure: failed program was: | #ifndef __cplusplus | choke me | #endif configure:3038: checking how to run the C preprocessor configure:3073: mpicc -E conftest.c configure:3079: $? = 0 configure:3111: mpicc -E conftest.c conftest.c:9:28: ac_nonexistent.h: No such file or directory configure:3117: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "PWscf" | #define PACKAGE_TARNAME "pwscf" | #define PACKAGE_VERSION "2.1" | #define PACKAGE_STRING "PWscf 2.1" | #define PACKAGE_BUGREPORT "" | /* end confdefs.h. */ | #include configure:3156: result: mpicc -E configure:3180: mpicc -E conftest.c configure:3186: $? = 0 configure:3218: mpicc -E conftest.c conftest.c:9:28: ac_nonexistent.h: No such file or directory configure:3224: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "PWscf" | #define PACKAGE_TARNAME "pwscf" | #define PACKAGE_VERSION "2.1" | #define PACKAGE_STRING "PWscf 2.1" | #define PACKAGE_BUGREPORT "" | /* end confdefs.h. */ | #include configure:3511: checking for library containing zggev configure:3524: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static conftest.f >&5 program MAIN 3 Lines Compiled /tmp/ifc6rICL5.o(.text+0x1c): In function `main': : undefined reference to `zggev_' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb8): In function `libi_exit': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xc4): In function `libi_exit': : undefined reference to `pthread_equal' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x23): In function `f_claim_mutex': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x33): In function `f_exitthread': : undefined reference to `pthread_exit' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x53): In function `f_release_mutex': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(f90init.o)(.text+0x1b): In function `f90_init': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x9b): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0xb3): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x125): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x13d): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0xd): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0x25): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x2f): In function `_eh_get_lock': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x42): In function `.B1.2': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x63): In function `_eh_release_lock': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x76): In function `.B2.2': : undefined reference to `pthread_mutex_unlock' configure:3530: $? = 1 configure: failed program was: | program main | call zggev | end configure:3561: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static conftest.f -lmkl_lapack -lmkl_ia32 -lguide -lpthread >&5 program MAIN 3 Lines Compiled ld: cannot find -lmkl_lapack configure:3567: $? = 1 configure: failed program was: | program main | call zggev | end configure:3594: result: no configure:3511: checking for library containing zggev configure:3524: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/usr/local/lib conftest.f >&5 program MAIN 3 Lines Compiled /tmp/ifcfbTiNa.o(.text+0x1c): In function `main': : undefined reference to `zggev_' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb8): In function `libi_exit': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xc4): In function `libi_exit': : undefined reference to `pthread_equal' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x23): In function `f_claim_mutex': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x33): In function `f_exitthread': : undefined reference to `pthread_exit' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x53): In function `f_release_mutex': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(f90init.o)(.text+0x1b): In function `f90_init': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x9b): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0xb3): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x125): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x13d): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0xd): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0x25): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x2f): In function `_eh_get_lock': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x42): In function `.B1.2': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x63): In function `_eh_release_lock': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x76): In function `.B2.2': : undefined reference to `pthread_mutex_unlock' configure:3530: $? = 1 configure: failed program was: | program main | call zggev | end configure:3561: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/usr/local/lib conftest.f -lmkl_lapack -lmkl_ia32 -lguide -lpthread >&5 program MAIN 3 Lines Compiled ld: cannot find -lmkl_lapack configure:3567: $? = 1 configure: failed program was: | program main | call zggev | end configure:3594: result: no configure:3511: checking for library containing zggev configure:3524: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/opt/intel/mkl70/lib /32 conftest.f >&5 program MAIN 3 Lines Compiled /tmp/ifcFHkdCr.o(.text+0x1c): In function `main': : undefined reference to `zggev_' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb8): In function `libi_exit': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xc4): In function `libi_exit': : undefined reference to `pthread_equal' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x23): In function `f_claim_mutex': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x33): In function `f_exitthread': : undefined reference to `pthread_exit' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x53): In function `f_release_mutex': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(f90init.o)(.text+0x1b): In function `f90_init': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x9b): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0xb3): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x125): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x13d): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0xd): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0x25): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x2f): In function `_eh_get_lock': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x42): In function `.B1.2': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x63): In function `_eh_release_lock': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x76): In function `.B2.2': : undefined reference to `pthread_mutex_unlock' configure:3530: $? = 1 configure: failed program was: | program main | call zggev | end configure:3561: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/opt/intel/mkl70/lib /32 conftest.f -lmkl_lapack -lmkl_ia32 -lguide -lpthread >&5 program MAIN 3 Lines Compiled ld: cannot find -lmkl_lapack configure:3567: $? = 1 configure: failed program was: | program main | call zggev | end configure:3594: result: no configure:3511: checking for library containing zggev configure:3524: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/opt/intel/mkl/mkl61 /lib/32 conftest.f >&5 program MAIN 3 Lines Compiled /tmp/ifcRMbhKK.o(.text+0x1c): In function `main': : undefined reference to `zggev_' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb8): In function `libi_exit': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xc4): In function `libi_exit': : undefined reference to `pthread_equal' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x23): In function `f_claim_mutex': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x33): In function `f_exitthread': : undefined reference to `pthread_exit' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x53): In function `f_release_mutex': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(f90init.o)(.text+0x1b): In function `f90_init': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x9b): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0xb3): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x125): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x13d): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0xd): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0x25): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x2f): In function `_eh_get_lock': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x42): In function `.B1.2': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x63): In function `_eh_release_lock': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x76): In function `.B2.2': : undefined reference to `pthread_mutex_unlock' configure:3530: $? = 1 configure: failed program was: | program main | call zggev | end configure:3561: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/opt/intel/mkl/mkl61 /lib/32 conftest.f -lmkl_lapack -lmkl_ia32 -lguide -lpthread >&5 program MAIN 3 Lines Compiled ld: cannot find -lmkl_lapack configure:3567: $? = 1 configure: failed program was: | program main | call zggev | end configure:3594: result: no configure:3511: checking for library containing zggev configure:3524: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/opt/intel/mkl/lib/3 2 conftest.f >&5 program MAIN 3 Lines Compiled /tmp/ifcRxrn01.o(.text+0x1c): In function `main': : undefined reference to `zggev_' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb8): In function `libi_exit': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xc4): In function `libi_exit': : undefined reference to `pthread_equal' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x23): In function `f_claim_mutex': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x33): In function `f_exitthread': : undefined reference to `pthread_exit' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x53): In function `f_release_mutex': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(f90init.o)(.text+0x1b): In function `f90_init': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x9b): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0xb3): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x125): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x13d): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0xd): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0x25): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x2f): In function `_eh_get_lock': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x42): In function `.B1.2': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x63): In function `_eh_release_lock': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x76): In function `.B2.2': : undefined reference to `pthread_mutex_unlock' configure:3530: $? = 1 configure: failed program was: | program main | call zggev | end configure:3561: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/opt/intel/mkl/lib/3 2 conftest.f -lmkl_lapack -lmkl_ia32 -lguide -lpthread >&5 program MAIN 3 Lines Compiled ld: cannot find -lmkl_lapack configure:3567: $? = 1 configure: failed program was: | program main | call zggev | end configure:3594: result: no configure:3511: checking for library containing zggev configure:3524: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/opt/intel/mkl61/lib /32 conftest.f >&5 program MAIN 3 Lines Compiled /tmp/ifcGABqa7.o(.text+0x1c): In function `main': : undefined reference to `zggev_' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb8): In function `libi_exit': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xc4): In function `libi_exit': : undefined reference to `pthread_equal' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x23): In function `f_claim_mutex': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x33): In function `f_exitthread': : undefined reference to `pthread_exit' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x53): In function `f_release_mutex': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(f90init.o)(.text+0x1b): In function `f90_init': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x9b): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0xb3): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x125): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x13d): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0xd): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0x25): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x2f): In function `_eh_get_lock': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x42): In function `.B1.2': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x63): In function `_eh_release_lock': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x76): In function `.B2.2': : undefined reference to `pthread_mutex_unlock' configure:3530: $? = 1 configure: failed program was: | program main | call zggev | end configure:3561: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/opt/intel/mkl61/lib /32 conftest.f -lmkl_lapack -lmkl_ia32 -lguide -lpthread >&5 program MAIN 3 Lines Compiled ld: cannot find -lmkl_lapack configure:3567: $? = 1 configure: failed program was: | program main | call zggev | end configure:3594: result: no configure:3511: checking for library containing zggev configure:3524: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/cineca/lib conftest.f >&5 program MAIN 3 Lines Compiled /tmp/ifc89Xabo.o(.text+0x1c): In function `main': : undefined reference to `zggev_' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb8): In function `libi_exit': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xc4): In function `libi_exit': : undefined reference to `pthread_equal' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x23): In function `f_claim_mutex': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x33): In function `f_exitthread': : undefined reference to `pthread_exit' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x53): In function `f_release_mutex': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(f90init.o)(.text+0x1b): In function `f90_init': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x9b): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0xb3): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x125): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x13d): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0xd): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0x25): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x2f): In function `_eh_get_lock': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x42): In function `.B1.2': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x63): In function `_eh_release_lock': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x76): In function `.B2.2': : undefined reference to `pthread_mutex_unlock' configure:3530: $? = 1 configure: failed program was: | program main | call zggev | end configure:3561: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/cineca/lib conftest.f -lmkl_lapack -lmkl_ia32 -lguide -lpthread >&5 program MAIN 3 Lines Compiled ld: cannot find -lmkl_lapack configure:3567: $? = 1 configure: failed program was: | program main | call zggev | end configure:3594: result: no configure:3511: checking for library containing zggev configure:3524: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/cineca/prod/intel/l ib conftest.f >&5 program MAIN 3 Lines Compiled /tmp/ifcQBGZbF.o(.text+0x1c): In function `main': : undefined reference to `zggev_' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb8): In function `libi_exit': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xc4): In function `libi_exit': : undefined reference to `pthread_equal' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x23): In function `f_claim_mutex': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x33): In function `f_exitthread': : undefined reference to `pthread_exit' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x53): In function `f_release_mutex': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(f90init.o)(.text+0x1b): In function `f90_init': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x9b): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0xb3): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x125): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x13d): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0xd): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0x25): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x2f): In function `_eh_get_lock': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x42): In function `.B1.2': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x63): In function `_eh_release_lock': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x76): In function `.B2.2': : undefined reference to `pthread_mutex_unlock' configure:3530: $? = 1 configure: failed program was: | program main | call zggev | end configure:3561: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/cineca/prod/intel/l ib conftest.f -lmkl_lapack -lmkl_ia32 -lguide -lpthread >&5 program MAIN 3 Lines Compiled ld: cannot find -lmkl_lapack configure:3567: $? = 1 configure: failed program was: | program main | call zggev | end configure:3594: result: no configure:3511: checking for library containing zggev configure:3524: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/usr/local/lib conftest.f >&5 program MAIN 3 Lines Compiled /tmp/ifcQsxwtW.o(.text+0x1c): In function `main': : undefined reference to `zggev_' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb8): In function `libi_exit': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xc4): In function `libi_exit': : undefined reference to `pthread_equal' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x23): In function `f_claim_mutex': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x33): In function `f_exitthread': : undefined reference to `pthread_exit' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x53): In function `f_release_mutex': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(f90init.o)(.text+0x1b): In function `f90_init': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x9b): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0xb3): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x125): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x13d): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0xd): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0x25): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x2f): In function `_eh_get_lock': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x42): In function `.B1.2': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x63): In function `_eh_release_lock': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x76): In function `.B2.2': : undefined reference to `pthread_mutex_unlock' configure:3530: $? = 1 configure: failed program was: | program main | call zggev | end configure:3561: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/usr/local/lib conftest.f -lmkl_lapack -lmkl_ia32 -lguide -lpthread >&5 program MAIN 3 Lines Compiled ld: cannot find -lmkl_lapack configure:3567: $? = 1 configure: failed program was: | program main | call zggev | end configure:3594: result: no configure:3511: checking for library containing zggev configure:3524: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/usr/local/lib conftest.f >&5 program MAIN 3 Lines Compiled /tmp/ifclJ5Nm6.o(.text+0x1c): In function `main': : undefined reference to `zggev_' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb8): In function `libi_exit': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xc4): In function `libi_exit': : undefined reference to `pthread_equal' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x23): In function `f_claim_mutex': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x33): In function `f_exitthread': : undefined reference to `pthread_exit' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x53): In function `f_release_mutex': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(f90init.o)(.text+0x1b): In function `f90_init': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x9b): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0xb3): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x125): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x13d): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0xd): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0x25): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x2f): In function `_eh_get_lock': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x42): In function `.B1.2': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x63): In function `_eh_release_lock': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x76): In function `.B2.2': : undefined reference to `pthread_mutex_unlock' configure:3530: $? = 1 configure: failed program was: | program main | call zggev | end configure:3561: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/usr/local/lib conftest.f -lmkl_lapack -lmkl_ia32 -lguide -lpthread >&5 program MAIN 3 Lines Compiled ld: cannot find -lmkl_lapack configure:3567: $? = 1 configure: failed program was: | program main | call zggev | end configure:3594: result: no configure:3511: checking for library containing zggev configure:3524: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/usr/local/intel/mkl 701/lib/32 conftest.f >&5 program MAIN 3 Lines Compiled /tmp/ifcnh0wln.o(.text+0x1c): In function `main': : undefined reference to `zggev_' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb8): In function `libi_exit': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xc4): In function `libi_exit': : undefined reference to `pthread_equal' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x23): In function `f_claim_mutex': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x33): In function `f_exitthread': : undefined reference to `pthread_exit' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x53): In function `f_release_mutex': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(f90init.o)(.text+0x1b): In function `f90_init': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x9b): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0xb3): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x125): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x13d): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0xd): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0x25): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x2f): In function `_eh_get_lock': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x42): In function `.B1.2': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x63): In function `_eh_release_lock': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x76): In function `.B2.2': : undefined reference to `pthread_mutex_unlock' configure:3530: $? = 1 configure: failed program was: | program main | call zggev | end configure:3561: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static -L/usr/local/intel/mkl 701/lib/32 conftest.f -lmkl_lapack -lmkl_ia32 -lguide -lpthread >&5 program MAIN 3 Lines Compiled configure:3567: $? = 0 configure:3570: test -z || test ! -s conftest.err configure:3573: $? = 0 configure:3576: test -s conftest configure:3579: $? = 0 configure:3594: result: -lmkl_lapack configure:4398: checking for library containing fftwnd configure:4428: mpicc -o conftest -O3 -fomit-frame-pointer -O3 -fomit-frame-pointer conftest.c -L/usr/local/intel/mkl701/lib/32 -lmkl_lapack -lmkl_ia32 -lguide -lpthread >&5 /tmp/ccqx9EHX.o(.text+0xa): In function `main': : undefined reference to `fftwnd' collect2: ld returned 1 exit status configure:4434: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "PWscf" | #define PACKAGE_TARNAME "pwscf" | #define PACKAGE_VERSION "2.1" | #define PACKAGE_STRING "PWscf 2.1" | #define PACKAGE_BUGREPORT "" | /* end confdefs.h. */ | | /* Override any gcc2 internal prototype to avoid an error. */ | #ifdef __cplusplus | extern "C" | #endif | /* We use char because int might match the return type of a gcc2 | builtin and then its argument prototype would still apply. */ | char fftwnd (); | int | main () | { | fftwnd (); | ; | return 0; | } configure:4482: mpicc -o conftest -O3 -fomit-frame-pointer -O3 -fomit-frame-pointer conftest.c -lfftw -lm -L/usr/local/intel/mkl701/lib/32 -lmkl_lapack -lmkl_ia 32 -lguide -lpthread >&5 configure:4488: $? = 0 configure:4491: test -z || test ! -s conftest.err configure:4494: $? = 0 configure:4497: test -s conftest configure:4500: $? = 0 configure:4515: result: -lfftw configure:4880: checking for library containing mpi_init configure:4893: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static conftest.f -lfftw -L/usr/local/intel/mkl701/lib/32 -lmkl_lapack -lmkl_ia32 -lguide -lpthread >&5 program MAIN 3 Lines Compiled /usr/local/lib/libmpich.a(simple_pmi.o)(.text+0x18dd): In function `PMII_Connect_to_pm': : warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb8): In function `libi_exit': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xc4): In function `libi_exit': : undefined reference to `pthread_equal' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x23): In function `f_claim_mutex': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x33): In function `f_exitthread': : undefined reference to `pthread_exit' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x53): In function `f_release_mutex': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(f90init.o)(.text+0x1b): In function `f90_init': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x9b): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0xb3): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x125): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x13d): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0xd): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0x25): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x2f): In function `_eh_get_lock': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x42): In function `.B1.2': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x63): In function `_eh_release_lock': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x76): In function `.B2.2': : undefined reference to `pthread_mutex_unlock' configure:4899: $? = 1 configure: failed program was: | program main | call mpi_init | end configure:4930: mpif90 -o conftest -Vaxlib -O2 -tpp6 -nomodule -Vaxlib -static nftest.f -lmpi -lfftw -L/usr/local/intel/mkl701/lib/32 -lmkl_lapack -lmkl_ ia32 -lguide -lpthread >&5 program MAIN 3 Lines Compiled /usr/local/lib/libmpich.a(simple_pmi.o)(.text+0x18dd): In function `PMII_Connect_to_pm': : warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xb8): In function `libi_exit': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(fstop.o)(.text+0xc4): In function `libi_exit': : undefined reference to `pthread_equal' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x23): In function `f_claim_mutex': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x33): In function `f_exitthread': : undefined reference to `pthread_exit' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(threadsafe.o)(.text+0x53): In function `f_release_mutex': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libIEPCF90.a(f90init.o)(.text+0x1b): In function `f90_init': : undefined reference to `pthread_self' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x9b): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0xb3): In function `std::set_unexpected(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x125): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(exception.o)(.text+0x13d): In function `std::set_terminate(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0xd): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libcxa.a(newhandler.o)(.text+0x25): In function `std::set_new_handler(void (*)())': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x2f): In function `_eh_get_lock': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x42): In function `.B1.2': : undefined reference to `pthread_mutex_lock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x63): In function `_eh_release_lock': : undefined reference to `pthread_mutex_unlock' /usr/local/intel/compiler70/ia32/lib/libunwind.a(ptn_ix86.o)(.text+0x76): In function `.B2.2': : undefined reference to `pthread_mutex_unlock' configure:4936: $? = 1 configure: failed program was: | program main | call mpi_init | end configure:4963: result: no configure:4981: checking for library containing mpi_init configure:5064: result: no configure:5075: checking for library containing zggev configure:5158: result: -lmkl_lapack configure:5365: checking for library containing fftwnd configure:5482: result: -lfftw configure:5519: checking for egrep configure:5529: result: grep -E configure:5534: checking for ANSI C header files configure:5559: mpicc -c -O3 -fomit-frame-pointer -O3 -fomit-frame-pointer conftest.c >&5 configure:5565: $? = 0 configure:5568: test -z || test ! -s conftest.err configure:5571: $? = 0 configure:5574: test -s conftest.o configure:5577: $? = 0 configure:5663: mpicc -o conftest -O3 -fomit-frame-pointer -O3 -fomit-frame-pointer conftest.c -lfftw -L/usr/local/intel/mkl701/lib/32 -lmkl_lapack -lmkl_ia32 -lguide -lpthread >&5 configure:5666: $? = 0 configure:5668: ./conftest configure:5671: $? = 0 configure:5686: result: yes configure:5710: checking for sys/types.h configure:5726: mpicc -c -O3 -fomit-frame-pointer -O3 -fomit-frame-pointer conftest.c >&5 configure:5732: $? = 0 configure:5735: test -z || test ! -s conftest.err configure:5738: $? = 0 configure:5741: test -s conftest.o configure:5744: $? = 0 configure:5755: result: yes configure:5710: checking for sys/stat.h configure:5726: mpicc -c -O3 -fomit-frame-pointer -O3 -fomit-frame-pointer conftest.c >&5 configure:5732: $? = 0 configure:5735: test -z || test ! -s conftest.err configure:5738: $? = 0 configure:5741: test -s conftest.o configure:5744: $? = 0 configure:5755: result: yes configure:5710: checking for stdlib.h configure:5726: mpicc -c -O3 -fomit-frame-pointer -O3 -fomit-frame-pointer conftest.c >&5 configure:5732: $? = 0 configure:5735: test -z || test ! -s conftest.err configure:5738: $? = 0 configure:5741: test -s conftest.o configure:5744: $? = 0 configure:5755: result: yes configure:5710: checking for string.h configure:5726: mpicc -c -O3 -fomit-frame-pointer -O3 -fomit-frame-pointer conftest.c >&5 configure:5732: $? = 0 configure:5735: test -z || test ! -s conftest.err configure:5738: $? = 0 configure:5741: test -s conftest.o configure:5744: $? = 0 configure:5755: result: yes configure:5710: checking for memory.h configure:5726: mpicc -c -O3 -fomit-frame-pointer -O3 -fomit-frame-pointer conftest.c >&5 configure:5732: $? = 0 configure:5735: test -z || test ! -s conftest.err configure:5738: $? = 0 configure:5741: test -s conftest.o configure:5744: $? = 0 configure:5755: result: yes configure:5710: checking for strings.h configure:5726: mpicc -c -O3 -fomit-frame-pointer -O3 -fomit-frame-pointer conftest.c >&5 configure:5732: $? = 0 configure:5735: test -z || test ! -s conftest.err configure:5738: $? = 0 configure:5741: test -s conftest.o configure:5744: $? = 0 configure:5755: result: yes configure:5710: checking for inttypes.h configure:5726: mpicc -c -O3 -fomit-frame-pointer -O3 -fomit-frame-pointer conftest.c >&5 configure:5732: $? = 0 configure:5735: test -z || test ! -s conftest.err configure:5738: $? = 0 configure:5741: test -s conftest.o configure:5744: $? = 0 configure:5755: result: yes configure:5710: checking for stdint.h configure:5726: mpicc -c -O3 -fomit-frame-pointer -O3 -fomit-frame-pointer conftest.c >&5 configure:5732: $? = 0 configure:5735: test -z || test ! -s conftest.err configure:5738: $? = 0 configure:5741: test -s conftest.o configure:5744: $? = 0 configure:5755: result: yes configure:5710: checking for unistd.h configure:5726: mpicc -c -O3 -fomit-frame-pointer -O3 -fomit-frame-pointer conftest.c >&5 configure:5732: $? = 0 configure:5735: test -z || test ! -s conftest.err configure:5738: $? = 0 configure:5741: test -s conftest.o configure:5744: $? = 0 configure:5755: result: yes configure:5777: checking fftw.h usability configure:5789: mpicc -c -O3 -fomit-frame-pointer -O3 -fomit-frame-pointer conftest.c >&5 configure:5795: $? = 0 configure:5798: test -z || test ! -s conftest.err configure:5801: $? = 0 configure:5804: test -s conftest.o configure:5807: $? = 0 configure:5817: result: yes configure:5821: checking fftw.h presence configure:5831: mpicc -E -O3 -fomit-frame-pointer conftest.c configure:5837: $? = 0 configure:5857: result: yes configure:5892: checking for fftw.h configure:5899: result: yes configure:6113: creating ./config.status ## ---------------------- ## ## Running config.status. ## ## ---------------------- ## This file was extended by PWscf config.status 2.1, which was generated by GNU Autoconf 2.59. Invocation command line was CONFIG_FILES = CONFIG_HEADERS = CONFIG_LINKS = CONFIG_COMMANDS = $ ./config.status on condmat1.ctpm.aeoi.org config.status:701: creating make.sys config.status:701: creating make.rules ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=i686-pc-linux-gnu ac_cv_build_alias=i686-pc-linux-gnu ac_cv_c_compiler_gnu=yes ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_F77_set= ac_cv_env_F77_value= ac_cv_env_FFLAGS_set= ac_cv_env_FFLAGS_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_exeext= ac_cv_f77_compiler_gnu=yes ac_cv_header_fftw_h=yes ac_cv_header_inttypes_h=yes ac_cv_header_memory_h=yes ac_cv_header_stdc=yes ac_cv_header_stdint_h=yes ac_cv_header_stdlib_h=yes ac_cv_header_string_h=yes ac_cv_header_strings_h=yes ac_cv_header_sys_stat_h=yes ac_cv_header_sys_types_h=yes ac_cv_header_unistd_h=yes ac_cv_objext=o ac_cv_prog_CPP='mpicc -E' ac_cv_prog_ac_ct_CC=mpicc ac_cv_prog_ac_ct_F77=mpif77 ac_cv_prog_cc_g=yes ac_cv_prog_cc_stdc= ac_cv_prog_egrep='grep -E' ac_cv_prog_f77_g=yes ac_cv_search_fftwnd=-lfftw ac_cv_search_mpi_init=no ac_cv_search_zggev=-lmkl_lapack ## ----------------- ## ## Output variables. ## ## ----------------- ## CC='mpicc' CFLAGS='-O3 -fomit-frame-pointer ' CPP='mpicc -E' CPPFLAGS='-O3 -fomit-frame-pointer ' DEFS='-DPACKAGE_NAME=\"PWscf\" -DPACKAGE_TARNAME=\"pwscf\" -DPACKAGE_VERSION =\"2.1\" -DPACKAGE_STRING=\"PWscf\ 2.1\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_ SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ST RINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 ' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='grep -E' EXEEXT='' F77='mpif90' FFLAGS='-Vaxlib -O2 -tpp6 -nomodule' LDFLAGS='' LIBOBJS='' LIBS=' -lfftw -L/usr/local/intel/mkl701/lib/32 -lmkl_lapack -lmkl_ia32 -lgui de -lpthread ' LTLIBOBJS='' OBJEXT='o' PACKAGE_BUGREPORT='' PACKAGE_NAME='PWscf' PACKAGE_STRING='PWscf 2.1' PACKAGE_TARNAME='pwscf' PACKAGE_VERSION='2.1' PATH_SEPARATOR=':' SHELL='/bin/sh' ac_ct_CC='mpicc' ac_ct_F77='mpif77' ar='ar' arflags='ruv' bindir='${exec_prefix}/bin' build='i686-pc-linux-gnu' build_alias='' build_cpu='i686' build_os='linux-gnu' build_vendor='pc' cc='mpicc' cflags='-O3 -fomit-frame-pointer' cpp='cpp' cppflags='-P -traditional' datadir='${prefix}/share' dflags='-D__LINUX -D__INTEL -D__FFTW' exec_prefix='${prefix}' f77='mpif77' f90='mpif90' f90flags='$(FFLAGS) -nomodule' f90rule='$(F90) $(F90FLAGS) $(MODULEFLAG) -c $<' fdflags='$(DFLAGS)' fflags='-Vaxlib -O2 -tpp6' fflags_noopt='-O0' host_alias='' ifftw='' includedir='${prefix}/include' infodir='${prefix}/info' ld='mpif90' ldflags='-Vaxlib -static' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' libs=' -lfftw -L/usr/local/intel/mkl701/lib/32 -lmkl_lapack -lmkl_ia32 -lgui de -lpthread ' localstatedir='${prefix}/var' mandir='${prefix}/man' mylib='lapack_mkl' oldincludedir='/usr/include' pre_fdflags='-fpp ' prefix='/usr/local' program_transform_name='s,x,x,' ranlib='echo' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target_alias='' ## ----------- ## ## confdefs.h. ## ## ----------- ## #define HAVE_INTTYPES_H 1 #define HAVE_MEMORY_H 1 #define HAVE_STDINT_H 1 #define HAVE_STDLIB_H 1 #define HAVE_STRINGS_H 1 #define HAVE_STRING_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_UNISTD_H 1 #define PACKAGE_BUGREPORT "" #define PACKAGE_NAME "PWscf" #define PACKAGE_STRING "PWscf 2.1" #define PACKAGE_TARNAME "pwscf" #define PACKAGE_VERSION "2.1" #define STDC_HEADERS 1 configure: exit 0 ============================================ > On Tue, 2004-10-26 at 10:26, Mahmoud Payami wrote: > > Before I try to use "./configure", I have installed MPI and run > > "mpdboot -n " command successfully. So the > > environment for parallel is ok. > > I don't know this command, is it enough to say that the MPI environment > works? Have you tried compiling and running a simple test program? > > > Afterwards, I try to use the "configure" command. As is seen at the > > end it does not detect parallel environment (although it detects all > > relevant mpicc, mpif77, ...): > [snip] > > checking for library containing mpi_init... no > [snip] > > ---------------------------------------------- > > WARNING: parallel environment not detected > > this program will run in single-processor mode > > ---------------------------------------------- > > Could you please post the "config.log" file produced by running > configure? This should contain more info on why the check failed. If you > want to look at it yourself, search for "mpi_init". > > Gerardo > > > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From giannozz at nest.sns.it Wed Oct 27 09:13:58 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 27 Oct 2004 09:13:58 +0200 Subject: [Pw_forum] Re: OPTERON 64-bit and Portland pgf90 5.2-4 In-Reply-To: References: <20041026150301.8542.95944.Mailman@democritos.sissa.it> Message-ID: <200410270913.58437.giannozz@nest.sns.it> On Tuesday 26 October 2004 19:12, Andrea Floris wrote: > I changed the optimization level to -01 [...] and ph.x does not give any > more segmentation fault errors. If anyone has another solution, maybe > preserving the optimization level -02, please let me know.. typically, problems with optimization are localised in a single routine. If you find out which one, you can compile that routine with -O1 and the rest with -O2. Not exactly a smart solution but better than nothing. 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 Oct 27 09:15:02 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 27 Oct 2004 09:15:02 +0200 Subject: [Pw_forum] parallel environment not found In-Reply-To: <003f01c4bb77$e8d8ef50$1b6710ac@aeoi.org.ir> References: <001901c4bb35$7c6cc360$1b6710ac@aeoi.org.ir> <000f01c4bb52$b2023ce0$1b6710ac@aeoi.org.ir> <003f01c4bb77$e8d8ef50$1b6710ac@aeoi.org.ir> Message-ID: <200410270915.02297.giannozz@nest.sns.it> On Tuesday 26 October 2004 18:21, Mahmoud Payami wrote: > Now trying to run example01, the computer sleeps and the only > nonempty file in /results is si.scf.dav.out [...] check first with just one processor. Try to run a single job interactively (with the output on the terminal, not on a file). Check if input redirection works (sometimes it doesn't with MPI libraries that are not properly configured) 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 g.ballabio at cineca.it Wed Oct 27 11:18:54 2004 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Wed, 27 Oct 2004 11:18:54 +0200 (MEST) Subject: [Pw_forum] parallel environment not found In-Reply-To: <000701c4bb51$be329e70$1b6710ac@aeoi.org.ir> References: <001901c4bb35$7c6cc360$1b6710ac@aeoi.org.ir> <1098783435.1147.45.camel@localhost.localdomain> <000701c4bb51$be329e70$1b6710ac@aeoi.org.ir> Message-ID: <1098868733.13642.29.camel@localhost.localdomain> On Tue, 2004-10-26 at 13:48, Mahmoud Payami wrote: > In the version (MPICH2) which I am using, there is no "mpi_init" commant but > instead "mpdboot". Mpi_init isn't a command. It is a subroutine call, that must be present in every version of MPI. By looking at config.log, it seems that the problem is with the Intel compiler version 7 and static linking. I've already seen that before. Reconfiguring with "configure --enable-shared" should work. Gerardo From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Wed Oct 27 16:36:46 2004 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Wed, 27 Oct 2004 16:36:46 +0200 (CEST) Subject: [Pw_forum] Performance of ESPRESSO CP on Pentium, Nocona, Opteron In-Reply-To: <417E9F10.5040301@mit.edu> Message-ID: On Tue, 26 Oct 2004, Nicola Marzari wrote: nicola, [...] NM> In particular, we are intrigued by the fact that we cannot seem NM> to get a CPU performance on Opteron platforms anywhere near the NM> Intel. While Opterons do very well in terms of memory bus speed, NM> our best Opteron performance (1 CPU of a 250, 2.4 GHz) is still 75% NM> slower than a Nocona (1 CPU, 3.2 GHz, 1 MB cache), and 43% slower NM> than a PIV (1 CPU, 3.2 GHz, 512 KB cache). indeed this seems odd, but did you run the serial benchmarks with OMP_NUM_THREADS=1 set? intel's MKL does automatically use OpenMP parallelization, with the number of cpu's available if OMP_NUM_THREADS is not in the environment. for example with the small example this seems likely, if one compares the Nocona 1+0 run with the 1+1 and the parallel run there is a large performance degradation with two serial jobs, but the mpi job is only a bit faster than the serial one. on the opteron, the timings of the 1+0 and the 1+1 are almost identical. it would be really interesting to see how well this compares to a parallel run using both cpus. you may also want to try the x86_64 atlas from my homepage, i have run the small example on two of our athlon 64 machines (both 2.0GHz but with different cache sizes, for details see attachments) and get: 10it 5it diff 2.0GHz/1MB: 19:14 11:02 8:12 2.0GHz/512kB: 25:44 14:26 11:18 where the faster one (and this is one of the very first generation athlon64 cpus, btw) is pretty close to your best 2.4GHz opteron result. comparing with the newer cpu with the same clock but half the cache, it also seems, that the larger cache seems pretty important here. best regards, axel NM> NM> We'd be very happy to keep collecting CPU timings for any of the NM> two tests listed above (AgI_small.j and AgI_large.j) - please follow NM> as closely as possible the instructions on the details needed on NM> CPUs and compiilers. Ultimately these numbers would make their way NM> to the official pages... NM> NM> nicola NM> NM> NM> --------------------------------------------------------------------- NM> Prof Nicola Marzari Department of Materials Science and Engineering NM> 13-5066 MIT 77 Massachusetts Avenue Cambridge MA 02139-4307 USA NM> tel 617.4522758 fax 617.2586534 marzari at mit.edu http://nnn.mit.edu NM> NM> _______________________________________________ NM> Pw_forum mailing list NM> Pw_forum at pwscf.org NM> http://www.democritos.it/mailman/listinfo/pw_forum NM> NM> -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= If you make something idiot-proof, the universe creates a better idiot. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Report-magicslim.txt Url: /pipermail/attachments/20041027/417f266f/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Report-fatsdomino.txt Url: /pipermail/attachments/20041027/417f266f/attachment-0001.txt From mpayami at aeoi.org.ir Wed Oct 27 18:12:46 2004 From: mpayami at aeoi.org.ir (Mahmoud Payami) Date: Wed, 27 Oct 2004 19:42:46 +0330 Subject: [Pw_forum] parallel environment not found References: <001901c4bb35$7c6cc360$1b6710ac@aeoi.org.ir> <000f01c4bb52$b2023ce0$1b6710ac@aeoi.org.ir> <003f01c4bb77$e8d8ef50$1b6710ac@aeoi.org.ir> <200410270915.02297.giannozz@nest.sns.it> Message-ID: <001901c4bc3f$cc37b160$1b6710ac@aeoi.org.ir> Dear Paolo, Thank you very much for your comment. When I run interactively using an in-file on a single processor, the result is: the same lines when one uses pw.x; including the following message: **Address Error** For information I inform that as you (before)and Gerardo(now) suggested, I have configured with "--enable-shared". Best regards, Mahmoud > On Tuesday 26 October 2004 18:21, Mahmoud Payami wrote: > > > Now trying to run example01, the computer sleeps and the only > > nonempty file in /results is si.scf.dav.out [...] > > check first with just one processor. Try to run a single job interactively > (with the output on the terminal, not on a file). Check if input redirection > works (sometimes it doesn't with MPI libraries that are not properly > configured) > > P. > -- > Paolo Giannozzi e-mail: giannozz at nest.sns.it > Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 > Piazza dei Cavalieri 7 I-56126 Pisa, Italy > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > > From afloris at physik.fu-berlin.de Wed Oct 27 19:03:31 2004 From: afloris at physik.fu-berlin.de (Andrea Floris) Date: Wed, 27 Oct 2004 19:03:31 +0200 (CEST) Subject: [Pw_forum] Re: OPTERON 64-bit and Portland pgf90 5.2-4 Message-ID: Thank you Paolo for your suggestion. The "incriminated" routine in my case was: PH/dvqpsi_us_only.f90 I compiled only that routine with optimization level -O1, the rest with -O2. The phonon calculation resulted 20% faster than with a general compilation with -O1. Andrea From ceresoli at physics.rutgers.edu Wed Oct 27 18:12:40 2004 From: ceresoli at physics.rutgers.edu (Davide Ceresoli) Date: Wed, 27 Oct 2004 12:12:40 -0400 Subject: [Pw_forum] espresso + pgi-5.2-4 Message-ID: <417FC8F8.2000606@physics.rutgers.edu> Dear all, I'm trying to compile ESPRESSO 2.1 on a cluster of PC, using portland compiler 5.2-4 (the latest release) and I get a compiler error: mpif90_gm -fast -r8 -I. -I../include -I../Modules -I../PW -I../PH -D__LINUX -D__PGI -D__MPI -D__PARA -D__FFTW -D__USE_INTERNAL_FFTW -c cell_base.F90 -o cell_base.o pgf90-Fatal-/opt/pgi/linux86/5.2/bin/p3/pgf901 TERMINATED by signal 11 Arguments to /opt/pgi/linux86/5.2/bin/p3/pgf901 /opt/pgi/linux86/5.2/bin/p3/pgf901 cell_base.F90 -opt 2 -terse 1 -inform warn -nohpf -nostatic -x 119 0x100000 -x 15 2 -x 49 0x400004 -x 51 0x20 -x 57 0x4c -x 58 0x10000 -x 124 0x1000 -x 57 0x10000 -x 58 0x8031040 -x 48 3328 -stdinc /opt/pgi/linux86/5.2/include:/usr/local/include:/usr/lib/gcc-lib/i486-suse-linux/3.3/include:/usr/lib/gcc-lib/i486-suse-linux/3.3/include:/usr/include -def unix -def __unix -def __unix__ -def linux -def __linux -def __linux__ -def __inline__= -def i386 -def __i386 -def __i386__ -def __NO_MATH_INLINES -def linux86 -def __THROW= -idir . -idir ../include -idir ../Modules -idir ../PW -idir ../PH -idir /opt/mpich_gm/include/f90base -def __LINUX -def __PGI -def __MPI -def __PARA -def __FFTW -def __USE_INTERNAL_FFTW -vect 48 -x 124 0x8 -output Neither -O1, -O0 helps... pgi-5.2-2, pgi-5.2-4 all of them fail. Only the old pgi-4.0-2 succeeds. What's so nasty about cell_base.f90? Does anybody ever succeded in compiling ESPRESSO with portland 5.2? Regards, Davide -- +-------------------------------------------------------+ | Davide Ceresoli | | Dept. of Physics and Astronomy, Rutgers University | | 136 Frelinghuysen Road | | Piscataway, NJ 08854-8019 USA | | Telephone: 732-445-8299 Fax: 732-445-4343 | | Homepage: http://www.physics.rutgers.edu/~ceresoli | +-------------------------------------------------------+ From giannozz at nest.sns.it Wed Oct 27 19:48:56 2004 From: giannozz at nest.sns.it (Paolo Giannozzi) Date: Wed, 27 Oct 2004 19:48:56 +0200 Subject: [Pw_forum] espresso + pgi-5.2-4 In-Reply-To: <417FC8F8.2000606@physics.rutgers.edu> References: <417FC8F8.2000606@physics.rutgers.edu> Message-ID: <200410271948.56750.giannozz@nest.sns.it> On Wednesday 27 October 2004 18:12, Davide Ceresoli wrote: > I'm trying to compile ESPRESSO 2.1 on a cluster of PC, using portland > compiler 5.2-4 (the latest release) and I get a compiler error: > [...] > TERMINATED by signal 11 - not enough memory for compilation? - lousy compiler? - defective RAM? - a linear combination of the above? > What's so nasty about cell_base.f90? nothing, apart from an unitialized variable :-). After line 505 add: dt2 = delt * delt 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 degironc at sissa.it Thu Oct 28 00:28:46 2004 From: degironc at sissa.it (Stefano de Gironcoli) Date: Thu, 28 Oct 2004 00:28:46 +0200 (CEST) Subject: [Pw_forum] Problem in Variable-cell In-Reply-To: References: Message-ID: On Thu, 21 Oct 2004, Varadharajan Srinivasan wrote: Are you sure you are giving the atomic positions in crystal coordinates in the scf run ? Stefano de Gironcoli > Dear users, > > I have been performing some variable-cell relaxation calculations using > PWSCF on PbTiO3 and I come across an interesting problem. After having > relaxed the unit cell I take the relaxed structure and perform an scf > calculation on it to obtain again the forces, stress and energy that > vc-relax gives me anyway. (I made sure that I chose the structure > corresponding to the final energy and forces, ie. the structure reported > before the final estimate) However, I obtain very different answers. The > variable-cell gives me : > > ###################################################################################### > new lattice vectors (alat unit) : ..........(input alat = 7.3627 (a.u.)) > 0.999624836 0.000000001 0.000000000 > 0.000000001 0.999624847 0.000000000 > 0.000000000 0.000000000 1.081152570 > new unit-cell volume = 431.1954 (a.u.)^3 > new positions in cryst coord > Ti 0.499999997 0.500000003 0.535979348 > O 0.499999997 0.500000004 0.112901652 > O 0.499999997 0.000000004 0.614268219 > O -0.000000003 0.500000004 0.614268218 > Pb -0.000000002 0.000000003 0.004230374 > > ! total energy = -332.37904437 ryd > estimated scf accuracy < 0.00000000 ryd > > convergence has been achieved > > Forces acting on atoms (Ry/au): > > atom 1 type 1 force = 0.00000000 0.00000000 -0.00000063 > atom 2 type 2 force = 0.00000000 0.00000000 -0.00000168 > atom 3 type 2 force = 0.00000000 0.00000000 -0.00000253 > atom 4 type 2 force = 0.00000000 0.00000000 -0.00000253 > atom 5 type 3 force = 0.00000000 0.00000000 0.00000738 > > Total force = 0.000008 Total SCF correction = 0.000008 > > > entering subroutine stress ... > > total stress (ryd/bohr**3) (kbar) P= 0.01 > 0.00000008 0.00000000 0.00000000 0.01 0.00 0.00 > 0.00000000 0.00000008 0.00000000 0.00 0.01 0.00 > 0.00000000 0.00000000 0.00000002 0.00 0.00 0.00 > > > Parrinello-Rahman Damped Dynamics: convergence achieved, Efinal= -332.37904437 > ####################################################################################### > > While from the corresponding structure the scf calculation gives me : > > ####################################################################################### > ibrav= 6, celldm(1) =7.359938, celldm(3)=1.081558 > Ti 0.499999997 0.500000003 0.535979348 > O 0.499999997 0.500000004 0.112901652 > O 0.499999997 0.000000004 0.614268219 > O -0.000000003 0.500000004 0.614268218 > Pb -0.000000002 0.000000003 0.004230374 > > ! total energy = -332.94499390 ryd > estimated scf accuracy < 0.00000000 ryd > > band energy sum = -12.68025211 ryd > one-electron contribution = -93.34743263 ryd > hartree contribution = 73.14958559 ryd > xc contribution = -50.45891514 ryd > ewald contribution = -262.28823173 ryd > > convergence has been achieved > > Forces acting on atoms (Ry/au): > > atom 1 type 1 force = 0.00000000 0.00000000 -0.00108980 > atom 2 type 2 force = 0.00000000 0.00000000 0.00054152 > atom 3 type 2 force = 0.00000000 0.00000000 0.00008334 > atom 4 type 2 force = 0.00000000 0.00000000 0.00008334 > atom 5 type 3 force = 0.00000000 0.00000000 0.00038160 > > Total force = 0.001281 Total SCF correction = 0.000005 > > > entering subroutine stress ... > > total stress (ryd/bohr**3) (kbar) P= -288.66 > -0.00195487 0.00000000 0.00000000 -287.57 0.00 0.00 > 0.00000000 -0.00195487 0.00000000 0.00 -287.57 0.00 > 0.00000000 0.00000000 -0.00197707 0.00 0.00 -290.84 > ############################################################################## > > > Not only is the total energy very different but also the forces and the > stress. I used a ecutwfc=40., ecutrho=240. in both calculations (and > ecfixed=35. Ry in variable-cell) to be consistent in the cutoff energies. > > Is this discrepencancy to be expected or am I doing something wrong? > I would greatly appreciate any help/suggestions. > > Thanks, > Vardha. > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > From whzhang at ustc.edu Thu Oct 28 03:43:25 2004 From: whzhang at ustc.edu (whzhang) Date: Thu, 28 Oct 2004 09:43:25 +0800 Subject: [Pw_forum] about NEB Message-ID: <20041028014131.C49CC112706@democritos.sissa.it> hi everyone: I'd like to do a NEB calculation,and then i wrote an input file but it didn't work. I don't know how to do now. Could somebody help me to check the input file? thanks a lot I have deleted the coordinates of images for the words limitation. &CONTROL title = 'nial' , calculation = 'neb' , restart_mode = 'from_scratch' , outdir = '/home/bsc/whzhang/PWSCF/work/water-NiAl/NEB' , pseudo_dir = '/home/bsc/whzhang/PWSCF/work/water-NiAl/NEB' , prefix = nial , disk_io = 'high' , verbosity = 'high' , nstep = 500 , tstress = .false. , tprnfor = .false. , tefield = .false. , / &SYSTEM ibrav = 8, A = 8.1684 , B = 5.776 , C = 36.7578 , cosAB = 0 , cosAC = 0 , cosBC = 0 , nat = 43, ntyp = 4, ecutwfc = 20 , ecutrho = 80 , / &ELECTRONS electron_maxstep = 100, startingpot = 'atomic' , startingwfc = 'atomic' , mixing_mode = 'plain' , mixing_beta = 0.3 , mixing_ndim = 8, diagonalization = 'david' , diago_david_ndim = 4, / &IONS ion_dynamics = 'damp' , upscale = 10 , num_of_images = 8 , first_last_opt = .true. , minimization_scheme = 'quick-min' , reset_vel = .false. , CI_scheme = 'highest-TS' , k_max = 0.1 , k_min = 0.1 , / ATOMIC_SPECIES Ni 58.70000 Ni.pbe-nd-rrkjus.UPF Al 26.98150 Al.pbe-n-van.UPF O 15.99940 O.pbe-rrkjus.UPF H 1.00790 H.pbe-rrkjus.UPF ATOMIC_POSITIONS angstrom first_image intermediate_image intermediate_image intermediate_image intermediate_image intermediate_image intermediate_image last_image K_POINTS automatic 4 6 1 1 1 1 then the information of output Program PWSCF v.2.0.1 starts ... Today is 27Oct2004 at 23:14:39 Parallel version (MPI) Number of processors in use: 8 R & G space division: nprocp = 8 Ultrasoft (Vanderbilt) Pseudopotentials Current dimensions of program pwscf are: ntypx =10 npk =40000 lmax = 3 nchix = 6 ndim = 2000 nbrx = 8 nqfm = 8 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from read_namelists : error # 979 reading namelist ions %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... yours ????????whzhang ????????whzhang at ustc.edu ??????????2004-10-27 ????????whzhang ????????whzhang at ustc.edu ??????????2004-10-28 -------------- next part -------------- A non-text attachment was scrubbed... Name: fox.gif Type: image/gif Size: 9519 bytes Desc: not available Url : /pipermail/attachments/20041028/4ab7f649/attachment.gif From adrainzhou at yahoo.com.cn Thu Oct 28 04:36:06 2004 From: adrainzhou at yahoo.com.cn (Adrain Zhou) Date: Thu, 28 Oct 2004 10:36:06 +0800 (CST) Subject: [Pw_forum] problem on Writing file! Message-ID: <20041028023606.65660.qmail@web15804.mail.cnb.yahoo.com> Dear all, I have compiled PWSCF on intel Xeon cluster using LAM/MPI, intel fotran 8.0 and MKL LIB. I met a problems for running a small test for Carbon. The program stopped on keep Writing file C.pun for program phonon, no further output for CPU time but the code is still running. Any comments are highly appreciated. Many thanks. Regards, Adrain --------------------------------- Do You Yahoo!? 150??MP3???????????? ??????????????????? 1G??1000??????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20041028/4d48294e/attachment.htm From daniele.falcomer at unipd.it Thu Oct 28 09:16:31 2004 From: daniele.falcomer at unipd.it (Daniele Falcomer) Date: Thu, 28 Oct 2004 09:16:31 +0200 Subject: [Pw_forum] about NEB In-Reply-To: <20041028014131.C49CC112706@democritos.sissa.it> References: <20041028014131.C49CC112706@democritos.sissa.it> Message-ID: Dear whzhang, for me you have not to insert the coordinates of intermediate images. These images are automatically created by the program. Your Daniele -- ################################## Daniele Falcomer Universita' di Padova Via Loredan 4 35131 Padova, Italy Phone: 0039-049-8275202 Fax: 0039-049-8275161 ################################## From sbraccia at sissa.it Thu Oct 28 09:40:10 2004 From: sbraccia at sissa.it (carlo sbraccia) Date: Thu, 28 Oct 2004 09:40:10 +0200 Subject: [Pw_forum] about NEB In-Reply-To: References: <20041028014131.C49CC112706@democritos.sissa.it> Message-ID: <1098949210.2997.14.camel@dhpc-5-18.sissa.it> Dear Whzhang, Daniele is right, you did not specify the atomic positions, for the first and for the last image of the path. Intermediate images are optional, but if you specify the "intermediate_image" keyword, then you must write the coordinates :-) Anyway there are other errors (those signaled by the error message): ion_dynamics and upscale are variables that can be used only in the case of calculation="relax". In the case of calculation="neb" they are not needed. carlo On Thu, 2004-10-28 at 09:16, Daniele Falcomer wrote: > Dear whzhang, > for me you have not to insert the coordinates of intermediate images. > These images are automatically created by the program. > Your > Daniele From rjxiao at blem.ac.cn Thu Oct 28 15:51:59 2004 From: rjxiao at blem.ac.cn (rjxiao) Date: Thu, 28 Oct 2004 21:51:59 +0800 Subject: [Pw_forum] a question about LDA+U Message-ID: <20041028215159.40e46e7a@server.blem.ac.cn> Dear Matteo Cococcioni, I did what you have told me.It does work!But directly inserting the old version of the ns_adj routine in the new code will lead an error.There are four lines which should be changed. --------- f(m1,m2) = nsnew(na,mins,m1,m2)---->f(m1,m2) = nsnew(m1,m2,mins,na) f(m1,m2) = nsnew(na,majs,m1,m2)---->f(m1,m2) = nsnew(m1,m2,mins,na) nsnew(na,adjs,i,j) = dreal(temp)---->nsnew(i,j,adjs,na) = dreal(temp) nsnew(na,adjs,j,i) = nsnew(na,adjs,i,j)---->nsnew(j,i,adjs,na) = nsnew(i,j,adjs,na) -------------- Maybe the two versions use different order of parameters in the function nsnew. By the way, I compare the ns_adj.f90 file in espresso2.1 with the earlier version(such as pwscf2.0.4 and pwscf2.0),I can not find any difference.And the espresso2.1 can not give an energy gap in calculation of Fe2O2.So,maybe this file should also be inserted to the espresso2.1 package. I still believe that my coordination is not wrong.When it is shown in xcrysden,it can give the same picture as your coordination.And it gives the same result in the calculation as yours.I check these two kinds of coordinations carefully.I found that we put the cell with different orientation in the space and put the origin in different site of the cell.In your model, the Fe1(0,0,0) is the at the center of the cell,while in mine,the Fe1(0,0,0) is the atom on the peak of the hexahedron. I am really thank you for your work.I think LDA+U is a very interesting and useful method. Best regards, Sincerely, Ruijuan Xiao Institute of Physics, Chinese Academy of Sciences From mpayami at aeoi.org.ir Thu Oct 28 16:54:35 2004 From: mpayami at aeoi.org.ir (Mahmoud Payami) Date: Thu, 28 Oct 2004 18:24:35 +0330 Subject: [Pw_forum] mpi Message-ID: <003a01c4bcfe$0a45fb10$1b6710ac@aeoi.org.ir> Dear Paolo, I tried to do the compiling job with mpich-2.0.711(which is compiled by ifc8.1. After installing mpi, I used ./configure for espresso which could detect the parallel environment and "make all" worked well. However, trying to run pw.x on single or multi processors, I get unknown error. Could you please let me know which "mpi" ( from where) and "ifc" give the desired results. Thanks in advace. Best regards, Mahmoud -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20041028/27048b09/attachment.htm From g.ballabio at cineca.it Thu Oct 28 17:16:13 2004 From: g.ballabio at cineca.it (Gerardo Ballabio) Date: Thu, 28 Oct 2004 17:16:13 +0200 (MEST) Subject: [Pw_forum] mpi In-Reply-To: <003a01c4bcfe$0a45fb10$1b6710ac@aeoi.org.ir> References: <003a01c4bcfe$0a45fb10$1b6710ac@aeoi.org.ir> Message-ID: <1098976573.9790.49.camel@localhost.localdomain> On Thu, 2004-10-28 at 16:54, Mahmoud Payami wrote: > I tried to do the compiling job with mpich-2.0.711(which is compiled > by ifc8.1. After installing mpi, I used ./configure > for espresso which could detect the parallel environment and "make > all" worked well. However, trying to run pw.x on single or multi > processors, I get unknown error. > Could you please let me know which "mpi" ( from where) and "ifc" give > the desired results. ESPRESSO should work with any version of MPI and Intel compiler. I haven't tried mpich 2 personally, but I have tried Intel compiler version 8.1 and it definitely works. To see if your problem is actually MPI-related, try disabling MPI with "configure --disable-parallel", which produces serial versions of the executables. Do these run or not? If not, do you get the same error or a different one? Also, are you sure that your input file is correct? The ESPRESSO distribution contains a large number of examples. Have you tried to run them? (Instructions are in the examples/README file.) Finally, please be more specific about what kind of error you are obtaining. It might be a known issue. (Have you read the "troubleshooting" section of the manual?) Gerardo From rjxiao at blem.ac.cn Thu Oct 28 17:10:58 2004 From: rjxiao at blem.ac.cn (rjxiao) Date: Thu, 28 Oct 2004 23:10:58 +0800 Subject: [Pw_forum] a question about LDA+U In-Reply-To: <20041028215159.40e46e7a@server.blem.ac.cn> Message-ID: <20041028231058.3a439c7c@server.blem.ac.cn> Dear Matteo Cococcioni I still have another question. It is about the routine tabd.In tabd.f90, the occ_loc of Mn,Fe,Ni,Cu are 5.0,6.0,8.0 and 10.0 respectively which are their number of d electrons.But why the occ_loc of Co is 9.0 which seems that two of 4s electrons are also included?Is it an error? Or If it should be 9.0,why? Best regards, Sincerely, Ruijuan Xiao Institute of Physics, Chinese Academy of Sciences From rjxiao at blem.ac.cn Thu Oct 28 17:13:36 2004 From: rjxiao at blem.ac.cn (rjxiao) Date: Thu, 28 Oct 2004 23:13:36 +0800 Subject: [Pw_forum] a question about LDA+U Message-ID: <20041028231336.da7aea55@server.blem.ac.cn> Dear Matteo Cococcioni I still have another question. It is about the routine tabd. In file tabd.f90, the occ_loc of Mn,Fe,Ni,Cu are 5.0,6.0,8.0 and 10.0 respectively which are their numbers of d electrons.But why the occ_loc of Co is 9.0 which seems that two of 4s electrons are also included?Is it an error? Or If it should be 9.0,why? Best regards, Sincerely, Ruijuan Xiao Institute of Physics, Chinese Academy of Sciences From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Thu Oct 28 17:21:20 2004 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Thu, 28 Oct 2004 17:21:20 +0200 (CEST) Subject: [Pw_forum] mpi In-Reply-To: <003a01c4bcfe$0a45fb10$1b6710ac@aeoi.org.ir> Message-ID: On Thu, 28 Oct 2004, Mahmoud Payami wrote: MP> Dear Paolo, MP> dear mahmoud, espresso 2.1 compiles (and runs) nicely with several mpi packages. for user level, tcp/ip based mpi libraries, most problems (after successful compilation) fall into two categories: a) the mpi tools are not able to log into the compute nodes without a password, b) you have a faulty network (bad driver or hardware). i always found MPICH somewhat lacking in helping the user to figure out, what has been going wrong. you'll only notice failures of type a) only when the parallel infractructure is accessed for the first time, which may be somewhat after you have started your parallel job, and thus i keep recommending LAM-MPI instead. here you can use the lamboot command and a hostfile to initialize the parallel environment, and thus see if you can really log into alle nodes automatically without a password, then (optionally) test it with the tping command and then finally run your parallel job with mpirun. lam-mpi does support reading input files from stdin, btw. if you want to save some time compiling the lam-mpi package, you can downloads suitable for many linux c and fortran compiles from: http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/cpmd-linux.html#mpi to use ifort (8.1) you need to run configure like this: F90=mpiifort F77=mpiifort CC=mpiicc ./configure if you want/have to use gcc instead of icc as c-compiler use: F90=mpiifort F77=mpiifort CC=mpicc ./configure i'd also recommend to replace the -static in the linker line of the resulting make.sys file with -static-libcxa. good luck, axel. MP> I tried to do the compiling job with mpich-2.0.711(which is compiled MP> by ifc8.1. After installing mpi, I used ./configure for espresso which MP> could detect the parallel environment and "make all" worked well. MP> However, trying to run pw.x on single or multi processors, I get MP> unknown error. Could you please let me know which "mpi" ( from where) MP> and "ifc" give the desired results. MP> Thanks in advace. MP> Best regards, MP> Mahmoud MP> -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From whzhang at ustc.edu Wed Oct 27 17:13:50 2004 From: whzhang at ustc.edu (whzhang) Date: Wed, 27 Oct 2004 23:13:50 +0800 Subject: [Pw_forum] about NEB Message-ID: <20041027154516.DCCB0112706@democritos.sissa.it> hello everyone: I'd like to do a NEB calculation,and then i wrote an input file but it didn't work. I don't know how to do now. Could somebody help me to check the input file? thanks a lot &CONTROL title = 'nial' , calculation = 'neb' , restart_mode = 'from_scratch' , outdir = '/home/bsc/whzhang/PWSCF/work/water-NiAl/NEB' , pseudo_dir = '/home/bsc/whzhang/PWSCF/work/water-NiAl/NEB' , prefix = nial , disk_io = 'high' , verbosity = 'high' , nstep = 500 , tstress = .false. , tprnfor = .false. , tefield = .false. , / &SYSTEM ibrav = 8, A = 8.1684 , B = 5.776 , C = 36.7578 , cosAB = 0 , cosAC = 0 , cosBC = 0 , nat = 43, ntyp = 4, ecutwfc = 20 , ecutrho = 80 , / &ELECTRONS electron_maxstep = 100, startingpot = 'atomic' , startingwfc = 'atomic' , mixing_mode = 'plain' , mixing_beta = 0.3 , mixing_ndim = 8, diagonalization = 'david' , diago_david_ndim = 4, / &IONS ion_dynamics = 'damp' , upscale = 10 , num_of_images = 8 , first_last_opt = .true. , minimization_scheme = 'quick-min' , reset_vel = .false. , CI_scheme = 'highest-TS' , k_max = 0.1 , k_min = 0.1 , / ATOMIC_SPECIES Ni 58.70000 Ni.pbe-nd-rrkjus.UPF Al 26.98150 Al.pbe-n-van.UPF O 15.99940 O.pbe-rrkjus.UPF H 1.00790 H.pbe-rrkjus.UPF ATOMIC_POSITIONS angstrom first_image O 0.000000000 0.000000000 16.000000000 H -0.768990000 0.595120000 16.000000000 H 0.768990000 0.595120000 16.000000000 Ni 2.042100000 1.444000000 8.037578863 Ni 2.042100000 4.332000000 8.037578863 Ni 6.126300000 1.444000000 8.037578863 Ni 6.126300000 4.332000000 8.037578863 Ni -0.000000000 1.444000000 6.112486792 Ni -0.000000000 4.332000000 6.112486792 Ni 4.084200000 1.444000000 6.112486792 Ni 4.084200000 4.332000000 6.112486792 Ni 2.042100000 1.444000000 4.084200000 Ni 2.042100000 4.332000000 4.084200000 Ni 6.126300000 1.444000000 4.084200000 Ni 6.126300000 4.332000000 4.084200000 Ni -0.000000000 1.444000000 2.055913208 Ni -0.000000000 4.332000000 2.055913208 Ni 4.084200000 1.444000000 2.055913208 Ni 4.084200000 4.332000000 2.055913208 Ni 2.042100000 1.444000000 0.130821137 Ni 2.042100000 4.332000000 0.130821137 Ni 6.126300000 1.444000000 0.130821137 Ni 6.126300000 4.332000000 0.130821137 Al -0.000000000 0.000000000 8.256808189 Al -0.000000000 2.888000000 8.256808189 Al 4.084200000 0.000000000 8.256808189 Al 4.084200000 2.888000000 8.256808189 Al 2.042100000 0.000000000 6.114151797 Al 2.042100000 2.888000000 6.114151797 Al 6.126300000 0.000000000 6.114151797 Al 6.126300000 2.888000000 6.114151797 Al -0.000000000 0.000000000 4.084200000 Al -0.000000000 2.888000000 4.084200000 Al 4.084200000 0.000000000 4.084200000 Al 4.084200000 2.888000000 4.084200000 Al 2.042100000 0.000000000 2.054248203 Al 2.042100000 2.888000000 2.054248203 Al 6.126300000 0.000000000 2.054248203 Al 6.126300000 2.888000000 2.054248203 Al -0.000000000 0.000000000 -0.088408189 Al -0.000000000 2.888000000 -0.088408189 Al 4.084200000 0.000000000 -0.088408189 Al 4.084200000 2.888000000 -0.088408189 intermediate_image O 0.000000000 0.000000000 15.000000000 H -0.768990000 0.595120000 15.000000000 H 0.768990000 0.595120000 15.000000000 Ni 2.042100000 1.444000000 8.037578863 Ni 2.042100000 4.332000000 8.037578863 Ni 6.126300000 1.444000000 8.037578863 Ni 6.126300000 4.332000000 8.037578863 Ni -0.000000000 1.444000000 6.112486792 Ni -0.000000000 4.332000000 6.112486792 Ni 4.084200000 1.444000000 6.112486792 Ni 4.084200000 4.332000000 6.112486792 Ni 2.042100000 1.444000000 4.084200000 Ni 2.042100000 4.332000000 4.084200000 Ni 6.126300000 1.444000000 4.084200000 Ni 6.126300000 4.332000000 4.084200000 Ni -0.000000000 1.444000000 2.055913208 Ni -0.000000000 4.332000000 2.055913208 Ni 4.084200000 1.444000000 2.055913208 Ni 4.084200000 4.332000000 2.055913208 Ni 2.042100000 1.444000000 0.130821137 Ni 2.042100000 4.332000000 0.130821137 Ni 6.126300000 1.444000000 0.130821137 Ni 6.126300000 4.332000000 0.130821137 Al -0.000000000 0.000000000 8.256808189 Al -0.000000000 2.888000000 8.256808189 Al 4.084200000 0.000000000 8.256808189 Al 4.084200000 2.888000000 8.256808189 Al 2.042100000 0.000000000 6.114151797 Al 2.042100000 2.888000000 6.114151797 Al 6.126300000 0.000000000 6.114151797 Al 6.126300000 2.888000000 6.114151797 Al -0.000000000 0.000000000 4.084200000 Al -0.000000000 2.888000000 4.084200000 Al 4.084200000 0.000000000 4.084200000 Al 4.084200000 2.888000000 4.084200000 Al 2.042100000 0.000000000 2.054248203 Al 2.042100000 2.888000000 2.054248203 Al 6.126300000 0.000000000 2.054248203 Al 6.126300000 2.888000000 2.054248203 Al -0.000000000 0.000000000 -0.088408189 Al -0.000000000 2.888000000 -0.088408189 Al 4.084200000 0.000000000 -0.088408189 Al 4.084200000 2.888000000 -0.088408189 intermediate_image O 0.000000000 0.000000000 14.000000000 H -0.768990000 0.595120000 14.000000000 H 0.768990000 0.595120000 14.000000000 Ni 2.042100000 1.444000000 8.037578863 Ni 2.042100000 4.332000000 8.037578863 Ni 6.126300000 1.444000000 8.037578863 Ni 6.126300000 4.332000000 8.037578863 Ni -0.000000000 1.444000000 6.112486792 Ni -0.000000000 4.332000000 6.112486792 Ni 4.084200000 1.444000000 6.112486792 Ni 4.084200000 4.332000000 6.112486792 Ni 2.042100000 1.444000000 4.084200000 Ni 2.042100000 4.332000000 4.084200000 Ni 6.126300000 1.444000000 4.084200000 Ni 6.126300000 4.332000000 4.084200000 Ni -0.000000000 1.444000000 2.055913208 Ni -0.000000000 4.332000000 2.055913208 Ni 4.084200000 1.444000000 2.055913208 Ni 4.084200000 4.332000000 2.055913208 Ni 2.042100000 1.444000000 0.130821137 Ni 2.042100000 4.332000000 0.130821137 Ni 6.126300000 1.444000000 0.130821137 Ni 6.126300000 4.332000000 0.130821137 Al -0.000000000 0.000000000 8.256808189 Al -0.000000000 2.888000000 8.256808189 Al 4.084200000 0.000000000 8.256808189 Al 4.084200000 2.888000000 8.256808189 Al 2.042100000 0.000000000 6.114151797 Al 2.042100000 2.888000000 6.114151797 Al 6.126300000 0.000000000 6.114151797 Al 6.126300000 2.888000000 6.114151797 Al -0.000000000 0.000000000 4.084200000 Al -0.000000000 2.888000000 4.084200000 Al 4.084200000 0.000000000 4.084200000 Al 4.084200000 2.888000000 4.084200000 Al 2.042100000 0.000000000 2.054248203 Al 2.042100000 2.888000000 2.054248203 Al 6.126300000 0.000000000 2.054248203 Al 6.126300000 2.888000000 2.054248203 Al -0.000000000 0.000000000 -0.088408189 Al -0.000000000 2.888000000 -0.088408189 Al 4.084200000 0.000000000 -0.088408189 Al 4.084200000 2.888000000 -0.088408189 intermediate_image O 0.000000000 0.000000000 13.000000000 H -0.768990000 0.595120000 13.000000000 H 0.768990000 0.595120000 13.000000000 Ni 2.042100000 1.444000000 8.037578863 Ni 2.042100000 4.332000000 8.037578863 Ni 6.126300000 1.444000000 8.037578863 Ni 6.126300000 4.332000000 8.037578863 Ni -0.000000000 1.444000000 6.112486792 Ni -0.000000000 4.332000000 6.112486792 Ni 4.084200000 1.444000000 6.112486792 Ni 4.084200000 4.332000000 6.112486792 Ni 2.042100000 1.444000000 4.084200000 Ni 2.042100000 4.332000000 4.084200000 Ni 6.126300000 1.444000000 4.084200000 Ni 6.126300000 4.332000000 4.084200000 Ni -0.000000000 1.444000000 2.055913208 Ni -0.000000000 4.332000000 2.055913208 Ni 4.084200000 1.444000000 2.055913208 Ni 4.084200000 4.332000000 2.055913208 Ni 2.042100000 1.444000000 0.130821137 Ni 2.042100000 4.332000000 0.130821137 Ni 6.126300000 1.444000000 0.130821137 Ni 6.126300000 4.332000000 0.130821137 Al -0.000000000 0.000000000 8.256808189 Al -0.000000000 2.888000000 8.256808189 Al 4.084200000 0.000000000 8.256808189 Al 4.084200000 2.888000000 8.256808189 Al 2.042100000 0.000000000 6.114151797 Al 2.042100000 2.888000000 6.114151797 Al 6.126300000 0.000000000 6.114151797 Al 6.126300000 2.888000000 6.114151797 Al -0.000000000 0.000000000 4.084200000 Al -0.000000000 2.888000000 4.084200000 Al 4.084200000 0.000000000 4.084200000 Al 4.084200000 2.888000000 4.084200000 Al 2.042100000 0.000000000 2.054248203 Al 2.042100000 2.888000000 2.054248203 Al 6.126300000 0.000000000 2.054248203 Al 6.126300000 2.888000000 2.054248203 Al -0.000000000 0.000000000 -0.088408189 Al -0.000000000 2.888000000 -0.088408189 Al 4.084200000 0.000000000 -0.088408189 Al 4.084200000 2.888000000 -0.088408189 intermediate_image O 0.000000000 0.000000000 12.000000000 H -0.768990000 0.595120000 12.000000000 H 0.768990000 0.595120000 12.000000000 Ni 2.042100000 1.444000000 8.037578863 Ni 2.042100000 4.332000000 8.037578863 Ni 6.126300000 1.444000000 8.037578863 Ni 6.126300000 4.332000000 8.037578863 Ni -0.000000000 1.444000000 6.112486792 Ni -0.000000000 4.332000000 6.112486792 Ni 4.084200000 1.444000000 6.112486792 Ni 4.084200000 4.332000000 6.112486792 Ni 2.042100000 1.444000000 4.084200000 Ni 2.042100000 4.332000000 4.084200000 Ni 6.126300000 1.444000000 4.084200000 Ni 6.126300000 4.332000000 4.084200000 Ni -0.000000000 1.444000000 2.055913208 Ni -0.000000000 4.332000000 2.055913208 Ni 4.084200000 1.444000000 2.055913208 Ni 4.084200000 4.332000000 2.055913208 Ni 2.042100000 1.444000000 0.130821137 Ni 2.042100000 4.332000000 0.130821137 Ni 6.126300000 1.444000000 0.130821137 Ni 6.126300000 4.332000000 0.130821137 Al -0.000000000 0.000000000 8.256808189 Al -0.000000000 2.888000000 8.256808189 Al 4.084200000 0.000000000 8.256808189 Al 4.084200000 2.888000000 8.256808189 Al 2.042100000 0.000000000 6.114151797 Al 2.042100000 2.888000000 6.114151797 Al 6.126300000 0.000000000 6.114151797 Al 6.126300000 2.888000000 6.114151797 Al -0.000000000 0.000000000 4.084200000 Al -0.000000000 2.888000000 4.084200000 Al 4.084200000 0.000000000 4.084200000 Al 4.084200000 2.888000000 4.084200000 Al 2.042100000 0.000000000 2.054248203 Al 2.042100000 2.888000000 2.054248203 Al 6.126300000 0.000000000 2.054248203 Al 6.126300000 2.888000000 2.054248203 Al -0.000000000 0.000000000 -0.088408189 Al -0.000000000 2.888000000 -0.088408189 Al 4.084200000 0.000000000 -0.088408189 Al 4.084200000 2.888000000 -0.088408189 intermediate_image O 0.000000000 0.000000000 11.5000000000 H -0.768990000 0.595120000 11.5000000000 H 0.768990000 0.595120000 11.5000000000 Ni 2.042100000 1.444000000 8.037578863 Ni 2.042100000 4.332000000 8.037578863 Ni 6.126300000 1.444000000 8.037578863 Ni 6.126300000 4.332000000 8.037578863 Ni -0.000000000 1.444000000 6.112486792 Ni -0.000000000 4.332000000 6.112486792 Ni 4.084200000 1.444000000 6.112486792 Ni 4.084200000 4.332000000 6.112486792 Ni 2.042100000 1.444000000 4.084200000 Ni 2.042100000 4.332000000 4.084200000 Ni 6.126300000 1.444000000 4.084200000 Ni 6.126300000 4.332000000 4.084200000 Ni -0.000000000 1.444000000 2.055913208 Ni -0.000000000 4.332000000 2.055913208 Ni 4.084200000 1.444000000 2.055913208 Ni 4.084200000 4.332000000 2.055913208 Ni 2.042100000 1.444000000 0.130821137 Ni 2.042100000 4.332000000 0.130821137 Ni 6.126300000 1.444000000 0.130821137 Ni 6.126300000 4.332000000 0.130821137 Al -0.000000000 0.000000000 8.256808189 Al -0.000000000 2.888000000 8.256808189 Al 4.084200000 0.000000000 8.256808189 Al 4.084200000 2.888000000 8.256808189 Al 2.042100000 0.000000000 6.114151797 Al 2.042100000 2.888000000 6.114151797 Al 6.126300000 0.000000000 6.114151797 Al 6.126300000 2.888000000 6.114151797 Al -0.000000000 0.000000000 4.084200000 Al -0.000000000 2.888000000 4.084200000 Al 4.084200000 0.000000000 4.084200000 Al 4.084200000 2.888000000 4.084200000 Al 2.042100000 0.000000000 2.054248203 Al 2.042100000 2.888000000 2.054248203 Al 6.126300000 0.000000000 2.054248203 Al 6.126300000 2.888000000 2.054248203 Al -0.000000000 0.000000000 -0.088408189 Al -0.000000000 2.888000000 -0.088408189 Al 4.084200000 0.000000000 -0.088408189 Al 4.084200000 2.888000000 -0.088408189 intermediate_image O 0.000000000 0.000000000 11.000000000 H -0.768990000 0.595120000 11.000000000 H 0.768990000 0.595120000 11.000000000 Ni 2.042100000 1.444000000 8.037578863 Ni 2.042100000 4.332000000 8.037578863 Ni 6.126300000 1.444000000 8.037578863 Ni 6.126300000 4.332000000 8.037578863 Ni -0.000000000 1.444000000 6.112486792 Ni -0.000000000 4.332000000 6.112486792 Ni 4.084200000 1.444000000 6.112486792 Ni 4.084200000 4.332000000 6.112486792 Ni 2.042100000 1.444000000 4.084200000 Ni 2.042100000 4.332000000 4.084200000 Ni 6.126300000 1.444000000 4.084200000 Ni 6.126300000 4.332000000 4.084200000 Ni -0.000000000 1.444000000 2.055913208 Ni -0.000000000 4.332000000 2.055913208 Ni 4.084200000 1.444000000 2.055913208 Ni 4.084200000 4.332000000 2.055913208 Ni 2.042100000 1.444000000 0.130821137 Ni 2.042100000 4.332000000 0.130821137 Ni 6.126300000 1.444000000 0.130821137 Ni 6.126300000 4.332000000 0.130821137 Al -0.000000000 0.000000000 8.256808189 Al -0.000000000 2.888000000 8.256808189 Al 4.084200000 0.000000000 8.256808189 Al 4.084200000 2.888000000 8.256808189 Al 2.042100000 0.000000000 6.114151797 Al 2.042100000 2.888000000 6.114151797 Al 6.126300000 0.000000000 6.114151797 Al 6.126300000 2.888000000 6.114151797 Al -0.000000000 0.000000000 4.084200000 Al -0.000000000 2.888000000 4.084200000 Al 4.084200000 0.000000000 4.084200000 Al 4.084200000 2.888000000 4.084200000 Al 2.042100000 0.000000000 2.054248203 Al 2.042100000 2.888000000 2.054248203 Al 6.126300000 0.000000000 2.054248203 Al 6.126300000 2.888000000 2.054248203 Al -0.000000000 0.000000000 -0.088408189 Al -0.000000000 2.888000000 -0.088408189 Al 4.084200000 0.000000000 -0.088408189 Al 4.084200000 2.888000000 -0.088408189 last_image O 0.000000000 0.000000000 10.000000000 H -0.768990000 0.595120000 10.000000000 H 0.768990000 0.595120000 10.000000000 Ni 2.042100000 1.444000000 8.037578863 Ni 2.042100000 4.332000000 8.037578863 Ni 6.126300000 1.444000000 8.037578863 Ni 6.126300000 4.332000000 8.037578863 Ni -0.000000000 1.444000000 6.112486792 Ni -0.000000000 4.332000000 6.112486792 Ni 4.084200000 1.444000000 6.112486792 Ni 4.084200000 4.332000000 6.112486792 Ni 2.042100000 1.444000000 4.084200000 Ni 2.042100000 4.332000000 4.084200000 Ni 6.126300000 1.444000000 4.084200000 Ni 6.126300000 4.332000000 4.084200000 Ni -0.000000000 1.444000000 2.055913208 Ni -0.000000000 4.332000000 2.055913208 Ni 4.084200000 1.444000000 2.055913208 Ni 4.084200000 4.332000000 2.055913208 Ni 2.042100000 1.444000000 0.130821137 Ni 2.042100000 4.332000000 0.130821137 Ni 6.126300000 1.444000000 0.130821137 Ni 6.126300000 4.332000000 0.130821137 Al -0.000000000 0.000000000 8.256808189 Al -0.000000000 2.888000000 8.256808189 Al 4.084200000 0.000000000 8.256808189 Al 4.084200000 2.888000000 8.256808189 Al 2.042100000 0.000000000 6.114151797 Al 2.042100000 2.888000000 6.114151797 Al 6.126300000 0.000000000 6.114151797 Al 6.126300000 2.888000000 6.114151797 Al -0.000000000 0.000000000 4.084200000 Al -0.000000000 2.888000000 4.084200000 Al 4.084200000 0.000000000 4.084200000 Al 4.084200000 2.888000000 4.084200000 Al 2.042100000 0.000000000 2.054248203 Al 2.042100000 2.888000000 2.054248203 Al 6.126300000 0.000000000 2.054248203 Al 6.126300000 2.888000000 2.054248203 Al -0.000000000 0.000000000 -0.088408189 Al -0.000000000 2.888000000 -0.088408189 Al 4.084200000 0.000000000 -0.088408189 Al 4.084200000 2.888000000 -0.088408189 K_POINTS automatic 4 6 1 1 1 1 then the information of output Program PWSCF v.2.0.1 starts ... Today is 27Oct2004 at 23:14:39 Parallel version (MPI) Number of processors in use: 8 R & G space division: nprocp = 8 Ultrasoft (Vanderbilt) Pseudopotentials Current dimensions of program pwscf are: ntypx =10 npk =40000 lmax = 3 nchix = 6 ndim = 2000 nbrx = 8 nqfm = 8 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% from read_namelists : error # 979 reading namelist ions %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... yours ????????whzhang ????????whzhang at ustc.edu ??????????2004-10-27 -------------- next part -------------- A non-text attachment was scrubbed... Name: fox.gif Type: image/gif Size: 9519 bytes Desc: not available Url : /pipermail/attachments/20041027/8c7960fb/attachment.gif From mpayami at aeoi.org.ir Fri Oct 29 12:18:22 2004 From: mpayami at aeoi.org.ir (Mahmoud Payami) Date: Fri, 29 Oct 2004 13:48:22 +0330 Subject: [Pw_forum] parallel environment not found References: <001901c4bb35$7c6cc360$1b6710ac@aeoi.org.ir> <000f01c4bb52$b2023ce0$1b6710ac@aeoi.org.ir> <003f01c4bb77$e8d8ef50$1b6710ac@aeoi.org.ir> <200410270915.02297.giannozz@nest.sns.it> Message-ID: <000901c4bda0$9ea7f180$1b6710ac@aeoi.org.ir> Dears Paolo, Alex, Gerardo, Many thanks to all your advices. I used the system ifc7.1.044+icc7.1.042+mkl61. To install mpich2, I followed the steps: CC=icc CXX=icc FC=ifc export CC CXX FC ./configure --enable-f90 make make install then, for espresso, I used: ./configure --enable-shared added -static-libcxa in make.sys make all it compiled successfully. The example01 run successfully on a single processor but fails when I assign values for PARA_PREFIX and PARA_POSTFIX. But I used the instruction on page 37 of UG: mpiexec -n 10 ../../../bin/pw.x -npool 5 -in si.scf.david.in > si.scf.david.out It worked!! It does not become clear for me why my previous experience continuously failed. Once again I thank you. Best regards Mahmoud > On Tuesday 26 October 2004 18:21, Mahmoud Payami wrote: > > > Now trying to run example01, the computer sleeps and the only > > nonempty file in /results is si.scf.dav.out [...] > > check first with just one processor. Try to run a single job interactively > (with the output on the terminal, not on a file). Check if input redirection > works (sometimes it doesn't with MPI libraries that are not properly > configured) > > P. > -- > Paolo Giannozzi e-mail: giannozz at nest.sns.it > Scuola Normale Superiore Phone: +39/050-509876, Fax:-563513 > Piazza dei Cavalieri 7 I-56126 Pisa, Italy > _______________________________________________ > Pw_forum mailing list > Pw_forum at pwscf.org > http://www.democritos.it/mailman/listinfo/pw_forum > > From degironc at sissa.it Sun Oct 31 18:37:08 2004 From: degironc at sissa.it (Stefano de Gironcoli) Date: Sun, 31 Oct 2004 18:37:08 +0100 (CET) Subject: [Pw_forum] a question about LDA+U In-Reply-To: <1098560548.417ab424eb25f@webmail.mit.edu> References: <20041024002157.ce5c9d42@server.blem.ac.cn> <1098560548.417ab424eb25f@webmail.mit.edu> Message-ID: Dear Ruijuan Xiao I'm including an example of LDA+U calculation with pw.x . It works with the current release of ESPRESSO package (at least on my pc) and will be included among the examples (example 25) from now on. There is a README file that discusses some details and peculiarities of LDA+U calculations. best regards, Stefano de Gironcoli -------------- next part -------------- A non-text attachment was scrubbed... Name: LDA+Uexample.tgz Type: application/x-gzip Size: 54289 bytes Desc: Url : /pipermail/attachments/20041031/c6786401/attachment.bin