[Wien] error in compilation
Dear Developers and Users, Recently we purchased a DELL power edge T620 server . We have installed Ubuntu 12.04LS OS and for the ifort and mkl we used Composer_xe_2013.2.146 options used: Compiler options: -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML - LD_LIBRARY_PATH=/opt/intel/composer_xe_2013.2.146/mkl/lib/intel64 R_LIB (LAPACK+BLAS):-lmkl_lapack95_lp64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lpthread we tried to install Wien2k_12.1 version and we are getting the following errors, which is attached herewith. kindly suggest how to rectify the errors. Thanking you in advance * Dr M.Rajagopalan Emeritus Scientist (CSIR) Crystal Growth Center20 6th Main Road Anna University Chromepet Chennai 600 025 Chennai 600 044 Phone # 22213023 (R) 22359208 (O) Mobile 9445125709 * -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130315/1d219b60/attachment.htm> -- next part -- A non-text attachment was scrubbed... Name: compilation errors Type: application/octet-stream Size: 3142 bytes Desc: not available URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130315/1d219b60/attachment.dll>
[Wien] error in compilation
Try the following shown below. On 3/15/2013 1:01 AM, Mathrubutham Rajagopalan wrote: > Dear Developers and Users, > > Recently we purchased a DELL power edge T620 server . > We have installed Ubuntu 12.04LS OS and for the ifort and mkl we used > Composer_xe_2013.2.146 > options used: > Compiler options: -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML - > LD_LIBRARY_PATH=/opt/intel/composer_xe_2013.2.146/mkl/lib/intel64-I/opt/intel/composer_xe_2013.2.146/mkl/include > R_LIB (LAPACK+BLAS):-lmkl_lapack95_lp64 -lmkl_intel_lp64 > -lmkl_intel_thread -lmkl_core -openmp -lpthread > we tried to install Wien2k_12.1 version and we are getting the > following errors, which is attached herewith. > kindly suggest how to rectify the errors. > Thanking you in advance > > */ > Dr M.Rajagopalan > Emeritus Scientist (CSIR) > Crystal Growth Center20 6th Main Road > Anna University Chromepet > Chennai 600 025 Chennai 600 044 > Phone # 22213023 (R) > 22359208 (O) > Mobile 9445125709 > > /* -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130315/a726b5b5/attachment.htm>
[Wien] Nonlinear optics using WIEN2k
Thanks From: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at zeus.theochem.tuwien.ac.at] on behalf of Gavin Abo [gs...@crimson.ua.edu] Sent: Thursday, March 14, 2013 4:50 PM To: A Mailing list for WIEN2k users Subject: Re: [Wien] Nonlinear optics using WIEN2k There is an EXCITiNG at WIEN2k package, I think you have to contact Dr. C. Ambrosch-Draxl to get it: http://amadm.unileoben.ac.at/codes_wien2k.html There also seems to be a NLO package, but you would have to contact Dr. B. Olejnik: http://www.wien2k.at/events/ws2003/downloads/ws2003_olejnik.pdf On 3/11/2013 1:22 PM, Choudhary,Kamal wrote: Hi Is there any tool available to calculate nonlinear optical properties using WIEN2k? Best Regards Kamal Choudhary -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130315/b9179eac/attachment.htm>
[Wien] SCF crash, XLF IBM
4:05:53 CET 2013> (x) nn Fri Mar 15 14:06:03 CET 2013> (x) sgroup Fri Mar 15 14:06:14 CET 2013> (x) symmetry Fri Mar 15 14:06:33 CET 2013> (x) lstart Fri Mar 15 14:07:24 CET 2013> (x) kgen Fri Mar 15 14:07:34 CET 2013> (x) dstart -c > (run_lapw) options: -NI -ec 0.0001 Fri Mar 15 14:10:53 CET 2013> (x) lapw0 Fri Mar 15 14:11:04 CET 2013> (x) lapw1 -c Fri Mar 15 14:11:06 CET 2013> (x) lapw2 -c == case.struct (initialized with default parameters and 10 inequivalent k-points) InP F LATTICE,NONEQUIV.ATOMS: 2216_F-43m MODE OF CALC=RELA unit=ang 11.23584 11.23584 11.23584 90.0 90.0 90.0 ATOM 1: X=0. Y=0. Z=0. MULT= 1 ISPLIT= 2 In NPT= 781 R0=0.1000 RMT= 2.5 Z: 49.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 2: X=0.2500 Y=0.2500 Z=0.2500 MULT= 1 ISPLIT= 2 P NPT= 781 R0=0.0001 RMT= 2.12 Z: 15.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 24 NUMBER OF SYMMETRY OPERATIONS 1 0 0 0. 0-1 0 0. 0 0-1 0. 1 1 0 0 0. 0 0-1 0. 0-1 0 0. 2 0 1 0 0. -1 0 0 0. 0 0-1 0. 3 0 0 1 0. -1 0 0 0. 0-1 0 0. 4 0 1 0 0. 0 0-1 0. -1 0 0 0. 5 0 0 1 0. 0-1 0 0. -1 0 0 0. 6 0-1 0 0. 1 0 0 0. 0 0-1 0. 7 0 0-1 0. 1 0 0 0. 0-1 0 0. 8 -1 0 0 0. 0 1 0 0. 0 0-1 0. 9 -1 0 0 0. 0 0 1 0. 0-1 0 0. 10 0-1 0 0. 0 0-1 0. 1 0 0 0. 11 0 0-1 0. 0-1 0 0. 1 0 0 0. 12 0 0 1 0. 0 1 0 0. 1 0 0 0. 13 0 1 0 0. 0 0 1 0. 1 0 0 0. 14 -1 0 0 0. 0 0-1 0. 0 1 0 0. 15 -1 0 0 0. 0-1 0 0. 0 0 1 0. 16 0 0 1 0. 1 0 0 0. 0 1 0 0. 17 0 1 0 0. 1 0 0 0. 0 0 1 0. 18 0 0-1 0. 0 1 0 0. -1 0 0 0. 19 0-1 0 0. 0 0 1 0. -1 0 0 0. 20 0 0-1 0. -1 0 0 0. 0 1 0 0. 21 0-1 0 0. -1 0 0 0. 0 0 1 0. 22 1 0 0 0. 0 0 1 0. 0 1 0 0.0000 23 1 0 0 0. 0 1 0 0. 0 0 1 0. 24 -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130315/0191ba04/attachment.htm>
[Wien] SCF crash, XLF IBM
Peter may have some ideas but I suspect that you need to tell us what they changed in the source code. That is very dangerous. On Fri, Mar 15, 2013 at 11:27 AM, Luis Ogando wrote: > Dear WIEN2k community, > >I am trying to use WIEN2k 12.1 in the "Spanish Supercomputing Network" > (RES), more specifically, the TIRANT machine at Valencia University (PowerPC > processors and XLF compiler). The guys from RES had a hard work to compile > WIEN2k (I believe mainly due to XLF) and now, we are facing a problem when > trying to calculate a simple example, namely, InP in the zinc blend phase in > sequential mode. >The initialization goes fine, but when I start the SCF cycle, I get: > > STOP LAPW0 END > STOP LAPW1 END > "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base input > found the invalid digit '.' in the input file. The program will recover by > assuming a zero in its place. > "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base input > found the invalid digit 'E' in the input file. The program will recover by > assuming a zero in its place. > "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base input > found the invalid digit '-' in the input file. The program will recover by > assuming a zero in its place. > "fermi_tmp_.F", line 516: 1525-096 A data item processed during an integer > read is too large. The program will recover by assigning the data item the > value 2147483647. > "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base input > found the invalid digit '-' in the input file. The program will recover by > assuming a zero in its place. > "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base input > found the invalid digit '.' in the input file. The program will recover by > assuming a zero in its place. > "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base input > found the invalid digit 'E' in the input file. The program will recover by > assuming a zero in its place. > "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base input > found the invalid digit '-' in the input file. The program will recover by > assuming a zero in its place. > >People from RES had to change the source code in order to get a > successful compilation, but I do not believe that this is the cause of our > problems. >I have searched the mailing list without any help and I would really > appreciate if someone could give us any hint. >Below, I show some information that I believe may be relevant, but if you > need any other information, please, ask. >Many thanks in advance, > Luis Ogando > > == > > Processor: IBM PowrPC 970+ > Compilers: XLC 11.1 and XLF 13.1 > MPI: MPICH-MX 1.2.7 (the problem occurs in the sequential version, parallel > version not yet tested) > == > Compilation options for sequential version: > O Compiler options:-qfree=f90 -O5 -qstrict -q64 > -qextname=flush -qdpc > L Linker Flags:$(FOPT) -L../SRC_lib -lpthread > -L/gpfs/apps/GOTO2/64 -L/gpfs/apps/SCALAPACK-GOTO2/2.0.2 > -L/opt/ibmcmp/xlf/13.1/lib64 -lxl -lxlf90 -lxlfmath > P Preprocessor flags '-WF,-DParallel' > R R_LIB (LAPACK+BLAS): -lgoto2 > == > Compilation options for parallel version (again, the problem occurs in the > sequential version, parallel version not yet tested) > RP RP_LIB(SCALAPACK+PBLAS): -L/gpfs/apps/SCALAPACK-GOTO2/2.0.2 > -L/gpfs/apps/GOTO2/64 -L/gpfs/apps/FFTW/3.3/64/double-xlf/lib > -L/opt/osshpc/mpich-mx/64/lib/ -lgoto2 -lscalapack -lmpich -lfftw3_mpi > -lfftw3 > FP FPOPT(par.comp.options): -qfree=f90 -O5 -qstrict -q64 > -WF,-DFFTW3 -qextname=flush > MP MPIRUN command: mpirun -np _NP_ -machinefile _HOSTS_ > _EXEC_ > > == > case.dayfile: > Calculating InPzb in /gpfs/home_apps/home/vlc54/vlc54925/Wien/InP/InPzb > on s01c2b11 with PID 17405 > using WIEN2k_12.1 (Release 22/7/2012) in /gpfs/home_apps/apps/WIEN2K/12.1 > > > start (Fri Mar 15 14:10:53 CET 2013) with lapw0 (40/99 to go) > > cycle 1 (Fri Mar 15 14:10:53 CET 2013) (40/99 to go) > >> lapw0 (14:10:53) 10.373u 0.274s 0:10.90 97.6% 0+0k 0+0io 1pf+0w >> lapw1 -c (14:11:04) 1.489u 0.117s 0:01.67 95.2% 0+0k 0+0io 0pf+0w >> lapw2-c (14:11:06) Segmentation fault > 0.064u 0.033s 0:00.15 60.0% 0+0k 0+0io 0pf+0w > error: command /gpfs/home_apps/apps/WIEN2K/12.1/lapw2c lapw2.def failed > >> stop error > =
[Wien] SCF crash, XLF IBM
_mpi > > -lfftw3 > > FP FPOPT(par.comp.options): -qfree=f90 -O5 -qstrict -q64 > > -WF,-DFFTW3 -qextname=flush > > MP MPIRUN command: mpirun -np _NP_ -machinefile _HOSTS_ > > _EXEC_ > > > > > == > > case.dayfile: > > Calculating InPzb in /gpfs/home_apps/home/vlc54/vlc54925/Wien/InP/InPzb > > on s01c2b11 with PID 17405 > > using WIEN2k_12.1 (Release 22/7/2012) in /gpfs/home_apps/apps/WIEN2K/12.1 > > > > > > start (Fri Mar 15 14:10:53 CET 2013) with lapw0 (40/99 to go) > > > > cycle 1 (Fri Mar 15 14:10:53 CET 2013) (40/99 to go) > > > >> lapw0 (14:10:53) 10.373u 0.274s 0:10.90 97.6% 0+0k 0+0io 1pf+0w > >> lapw1 -c (14:11:04) 1.489u 0.117s 0:01.67 95.2% 0+0k 0+0io 0pf+0w > >> lapw2-c (14:11:06) Segmentation fault > > 0.064u 0.033s 0:00.15 60.0% 0+0k 0+0io 0pf+0w > > error: command /gpfs/home_apps/apps/WIEN2K/12.1/lapw2c lapw2.def > failed > > > >> stop error > > > == > > > > :log > >> (init_lapw) options: > > Fri Mar 15 14:05:44 CET 2013> (x_lapw) nn -f InPzb > > Fri Mar 15 14:05:53 CET 2013> (x) nn > > Fri Mar 15 14:06:03 CET 2013> (x) sgroup > > Fri Mar 15 14:06:14 CET 2013> (x) symmetry > > Fri Mar 15 14:06:33 CET 2013> (x) lstart > > Fri Mar 15 14:07:24 CET 2013> (x) kgen > > Fri Mar 15 14:07:34 CET 2013> (x) dstart -c > >> (run_lapw) options: -NI -ec 0.0001 > > Fri Mar 15 14:10:53 CET 2013> (x) lapw0 > > Fri Mar 15 14:11:04 CET 2013> (x) lapw1 -c > > Fri Mar 15 14:11:06 CET 2013> (x) lapw2 -c > > > == > > > > case.struct (initialized with default parameters and 10 inequivalent > > k-points) > > > > InP > > F LATTICE,NONEQUIV.ATOMS: 2216_F-43m > > MODE OF CALC=RELA unit=ang > > 11.23584 11.23584 11.23584 90.0 90.0 90.0 > > ATOM 1: X=0. Y=0. Z=0. > > MULT= 1 ISPLIT= 2 > > In NPT= 781 R0=0.1000 RMT= 2.5 Z: 49.0 > > LOCAL ROT MATRIX:1.000 0.000 0.000 > > 0.000 1.000 0.000 > > 0.000 0.000 1.000 > > ATOM 2: X=0.2500 Y=0.2500 Z=0.2500 > > MULT= 1 ISPLIT= 2 > > P NPT= 781 R0=0.0001 RMT= 2.12 Z: 15.0 > > LOCAL ROT MATRIX:1.000 0.000 0.000 > > 0.000 1.000 0.000 > > 0.000 0.000 1.000 > > 24 NUMBER OF SYMMETRY OPERATIONS > > 1 0 0 0. > > 0-1 0 0. > > 0 0-1 0. > >1 > > 1 0 0 0. > > 0 0-1 0. > > 0-1 0 0. > >2 > > 0 1 0 0. > > -1 0 0 0. > > 0 0-1 0. > >3 > > 0 0 1 0. > > -1 0 0 0. > > 0-1 0 0. > >4 > > 0 1 0 0. > > 0 0-1 0. > > -1 0 0 0. > >5 > > 0 0 1 0. > > 0-1 0 0. > > -1 0 0 0. > >6 > > 0-1 0 0. > > 1 0 0 0. > > 0 0-1 0. > >7 > > 0 0-1 0. > > 1 0 0 0. > > 0-1 0 0. > >8 > > -1 0 0 0. > > 0 1 0 0. > > 0 0-1 0. > >9 > > -1 0 0 0. > > 0 0 1 0. > > 0-1 0 0. > > 10 > > 0-1 0 0. > > 0 0-1 0. > > 1 0 0 0. > > 11 > > 0 0-1 0. > > 0-1 0 0. > > 1 0 0 0. > > 12 > > 0 0 1 0. > > 0 1 0 0. > > 1 0 0 0. > > 13 > > 0 1 0 0. > > 0 0 1 0. > > 1 0 0 0. > > 14 > > -1 0 0 0. > > 0 0-1 0. > > 0 1 0 0. > > 15 > > -1 0 0 0. > > 0-1 0 0. > > 0 0 1 0. > > 16 > > 0 0 1 0. > > 1 0 0 0. > > 0 1 0 0. > > 17 > > 0 1 0 0. > > 1 0 0 0. > > 0 0 1 0. > > 18 > > 0 0-1 0. > > 0 1 0 0. > > -1 0 0 0. > > 19 > > 0-1 0 0. > > 0 0 1 0. > > -1 0 0 0. > > 20 > > 0 0-1 0. > > -1 0 0 0. > > 0 1 0 0. > > 21 > > 0-1 0 0. > > -1 0 0 0. > > 0 0 1 0. > > 22 > > 1 0 0 0. > > 0 0 1 0. > > 0 1 0 0. > > 23 > > 1 0 0 0. > > 0 1 0 0. > > 0 0 1 0. > > 24 > > > > > > -- > Professor Laurence Marks > Department of Materials Science and Engineering > Northwestern University > www.numis.northwestern.edu 1-847-491-3996 > "Research is to see what everybody else has seen, and to think what > nobody else has thought" > Albert Szent-Gyorgi > ___ > Wien mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien > -- next part -- An HTML attachment was scrubbed... URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130315/433f0e82/attachment-0001.htm>
[Wien] SCF crash, XLF IBM
Hard to tell what could cause the problem. Hopefully, the code changes did not introduce something odd. My suspicion is the xlf compiler, because: line 516 in SRC_lapw2/fermi.F is: 14 READ(ITAP,*) NUM,E1 and it is reading from a filecase.energy A valid case.energy file looks like: a) Header lines for each atom in your cell like: 198.98000200.3 0.3 0.3 0.3 0.3 0.3 0.3 0.3000 0 0.3 0.3 0.3 0.3 0.0 -1.02000 0.3999.0999.0 0.3997.0999.0999.0999. 0999.0999.0999.0 b) the coordinates of a k-point and number of bands, 1.2500E-01 4.545454545455E-02 8.7500E-01 4 4423 330 4.0 c) number of bands (330) lines with num, E 1 -1.76431887534161 2 -1.76416068726848 3 -1.76381815817653 4 -1.76374388956472 5 -1.76356590139222 ... Since these lines are written format free, they may also contain: 4 5.506360437936372E-002 Reading these lines, the program seems to crash. So either it does not read properly some header lines, or it has problems to convert a number like 5.506360437936372E-002 with a "*"-format into a real number. Just put a print statement after line 516 into the code and compare the output with case.energy. Am 15.03.2013 17:27, schrieb Luis Ogando: > Dear WIEN2k community, > > I am trying to use WIEN2k 12.1 in the "Spanish Supercomputing Network" > (RES), more specifically, the TIRANT machine at Valencia University (PowerPC > processors and XLF > compiler). The guys from RES had a hard work to compile WIEN2k (I believe > mainly due to XLF) and now, we are facing a problem when trying to calculate > a simple example, > namely, InP in the zinc blend phase in sequential mode. > The initialization goes fine, but when I start the SCF cycle, I get: > > STOP LAPW0 END > STOP LAPW1 END > "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base input > found the invalid digit '.' in the input file. The program will recover by > assuming a zero in > its place. > "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base input > found the invalid digit 'E' in the input file. The program will recover by > assuming a zero in > its place. > "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base input > found the invalid digit '-' in the input file. The program will recover by > assuming a zero in > its place. > "fermi_tmp_.F", line 516: 1525-096 A data item processed during an integer > read is too large. The program will recover by assigning the data item the > value 2147483647 > . > "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base input > found the invalid digit '-' in the input file. The program will recover by > assuming a zero in > its place. > "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base input > found the invalid digit '.' in the input file. The program will recover by > assuming a zero in > its place. > "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base input > found the invalid digit 'E' in the input file. The program will recover by > assuming a zero in > its place. > "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal base input > found the invalid digit '-' in the input file. The program will recover by > assuming a zero in > its place. > > People from RES had to change the source code in order to get a > successful compilation, but I do not believe that this is the cause of our > problems. > I have searched the mailing list without any help and I would really > appreciate if someone could give us any hint. > Below, I show some information that I believe may be relevant, but if you > need any other information, please, ask. > Many thanks in advance, > Luis Ogando > > == > > Processor: IBM PowrPC 970+ > Compilers: XLC 11.1 and XLF 13.1 > MPI: MPICH-MX 1.2.7 (the problem occurs in the sequential version, parallel > version not yet tested) > == > Compilation options for sequential version: > O Compiler options:-qfree=f90 -O5 -qstrict -q64 > -qextname=flush -qdpc > L Linker Flags:$(FOPT) -L../SRC_lib -lpthread > -L/gpfs/apps/GOTO2/64 -L/gpfs/apps/SCALAPACK-GOTO2/2.0.2 > -L/opt/ibmcmp/xlf/13.1/lib64 -lxl -lxlf90 -lxlfmath > P Preprocessor flags '-WF,-DParallel' > R R_LIB (LAPACK+BLAS): -lgoto2 > == > Compilation options for parallel version (again, the problem occurs in t
