[Wien] 'LOPW' - Plane waves exhausted
Please check your custom klist. When the invalid or wrongly-formatted case.klist exists, the error can be occurred. 2011/2/22 Laurence Marks L-marks at northwestern.edu It is very hard to know exactly what you have done wrong, or it could be something special to your problem. Do you have d and f states in the valence region? You might need to increase RKMAX. 2011/2/21 Volodymyr Svitlyk svitlyk at esrf.fr: Hi all, I have tried to use my custom klist. I have copied my klist into the directory, set TEMP as a Fermi-method with eval = 0.002, then I just skipped the kgen command during the initialize calc. At the lapw1 I got the error 'LOPW' - Plane waves exhausted. I guess something is wrong in the way I feed the klist? Thank you. ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2220 N Campus Drive Northwestern University Evanston, IL 60208, USA Tel: (847) 491-3996 Fax: (847) 491-7820 email: L-marks at northwestern dot edu Web: www.numis.northwestern.edu Chair, Commission on Electron Crystallography of IUCR www.numis.northwestern.edu/ Electron crystallography is the branch of science that uses electron scattering and imaging to study the structure of matter. ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Min Wook OH, Ph. D., Korea Electrotechnology Research Institute (KERI) Tel: 82-55-280-1638 Fax: 82-55-280-1590 E-mail: minwookoh at keri.re.kr -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110223/9553dd02/attachment.htm
[Wien] A problem with icc and wien2k
Dear sir, The line you mentioned for solving the problem of lstart by using ifort(12) + gcc was already included in the insld.f file, at around the line 114 of the file: ... BAR(10)=BAR1 norb=10 ! iex=5 DVC=137.0359895 IF(.NOT.RELA) DVC=1.E30 ! ! ... Then, I am still having problems with lstart in TiC example, even including DVC=137.0359895 at the line 57 IF (NSTOP.EQ.0) GO TO 2 1 CONTINUE JSPIN=2 DVC=137.0359895 ! add this line DSAL=DVC+DVC ... as you suggested in your last email. This is the warning I ve obtained after doing some small modifications to print out additional values: WARNING: R0 for atom1 Z= 22.00 too big, dr1: 0.0001000 NP0= 781 RMTT = 1.57000 (NOTICE THAT dr1=0.000100 is 0.51 in the line 139 of insld.f, so for atoms with Z18 the warning message should appear always, as it occurs for Ti.) forrtl: severe (71): integer divide by zero Image PCRoutineLineSource lstart 080C2149 Unknown Unknown Unknown lstart 0805623C MAIN__136 lstart.f lstart 08049FA4 Unknown Unknown Unknown libc.so.6 4008BBD6 Unknown Unknown Unknown lstart 08049EB1 Unknown Unknown Unknown 0.0u 0.0s 0:00.00 0.0% 0+0k 0+72io 0pf+0w error: command /usr/local/wien2k/lstart lstart.def failed However the problem should be in other place of insld.f I cannot debug properly the lstart program by using the intel compiler, so I would appreciate any support. Sorry, but I cannot access to the messages of Mailing list where this problem was fixed. Thanks anyway, Cesar -Mensaje original- De: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien-bounces at zeus.theochem.tuwien.ac.at] En nombre de Peter Blaha Enviado el: domingo, 20 de febrero de 2011 8:52 Para: A Mailing list for WIEN2k users Asunto: Re: [Wien] A problem with icc and wien2k If I remember correctly, the lstart problem with ifort12 was discussed and solved before. I guess it concernsinsld.f where one must add an initilization of DVC. IF (NSTOP.EQ.0) GO TO 2 1 CONTINUE JSPIN=2 DVC=137.0359895 ! add this line DSAL=DVC+DVC ... Am 19.02.2011 19:27, schrieb EGUCHI Gaku: Hello, I'm also in the same trouble with x lstart even in using ifort (v12)+gcc: SELECT XCPOT: recommended: 13: PBE-GGA (Perdew-Burke-Ernzerhof 96) 5: LSDA 11: WC-GGA (Wu-Cohen 2006) 19: PBEsol-GGA (Perdew etal. 2008) SELECT ENERGY to separate core and valence states: recommended: -6.0 Ry (check how much core charge leaks out of MT-sphere) ALTERNATIVELY: specify charge localization (between 0.97 and 1.0) to select core state forrtl: severe (71): integer divide by zero Image PC Routine Line Source lstart 080C2158 Unknown Unknown Unknown lstart 080561CC MAIN__ 136 lstart.f lstart 08049FA4 Unknown Unknown Unknown libc.so.6 4008DBD6 Unknown Unknown Unknown lstart 08049EB1 Unknown Unknown Unknown 0.008u 0.004s 0:00.01 0.0% 0+0k 0+0io 0pf+0w error: command /home/gaku/WIEN2k/lstart lstart.def failed -- This case I tried with pure sodium crystal and .inst file looks no problem: -- Na Ne 1 3,-1,0.5 N 3,-1,0.5 N END of input (instgen_lapw) -- I also tried with TiC that came across the same problem. For the trouble relating to SRC_vecpratt is removed by changing icc for gcc. I'd very happy if someone knows how to solve the trouble. Best, G. Eguchi (11/02/19 19:13), C?sar de la Fuente wrote: Everything works fine by using gcc instead icc (12.0). Thanks. C?sar -Mensaje original- De: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien-bounces at zeus.theochem.tuwien.ac.at] En nombre de Gerhard Fecher Enviado el: s?bado, 19 de febrero de 2011 10:37 Para: A Mailing list for WIEN2k users Asunto: Re: [Wien] A problem with icc and wien2k As Info: the overoptimization bug is removed since ifort 11.1.070 Ciao Gerhard Dr. Gerhard H. Fecher Institut of Inorganic and Analytical Chemistry Johannes Gutenberg - University 55099 Mainz Von: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at zeus.theochem.tuwien.ac.at]quot; im Auftrag von quot;Laurence Marks [L-marks at northwestern.edu] Gesendet: Freitag, 18. Februar 2011 14:54 Bis: A Mailing list for WIEN2k users Betreff: Re: [Wien] A problem with icc and wien2k I
[Wien] [SPAM?] Re: Counting the numer of electrons / slightly metallic tail crossing EF
Dear Professor Wu and Professor Blaha. I truly appreciate your kind advice. I am truly happy to be confirmed that I could consider this 0.0002 e- deviation from the integer number of electrons as negligible. Thank you. On Fri, Feb 18, 2011 at 5:17 PM, Peter Blaha pblaha at theochem.tuwien.ac.at wrote: When I check TOTAL CORE-CHARGE of Gd after lstart (and scf file), ?TOTAL CORE-CHARGE: ? ? ? ? ? ? ? ? ? 46.00 ?TOTAL CORE-CHARGE INSIDE SPHERE: ? ? 45.29 ?TOTAL CORE-CHARGE OUTSIDE SPHERE: ? ? 0.71 MAGNETIC MOMENT IN SPHERE seems quite reasonable, but I would like to make sure whether this order of charge leakage can be negligible in total energy calculations (with different spin configurations). This is perfectly ok and you don't have to worry. But when I run x tetra to draw the DOS plot, and check outputtdn/up files, the up+dn sum of the NUMBER OF ELECTRONS UP TO EF is about 61 % of the number from :NOE. Even though I exclude the 5S and 5P electrons (10 e-) from counting in :NOE, the number from NUMBER OF ELECTRONS UP TO EF is still smaller. Is it normal to have much smaller (like 2/3) values in outputtdn/up than that of :NOE? Or those two numbers are of different meaning? Probably your Emin (-0.5 )in case.int is not ok and you are truncating some DOS (F 2s ?) 3. When I plot the DOS, with settings in int file as ?-0.500 ? 0.1 ? 0.8 ?0.0005 ? ? #Emin, DE, Emax, Gauss-Broad With such DE you are asking for numerical inaccuracies. Stick to the defaults first or modify them only slighly. For sure Gauss-broadening introduces some small tails above EF which are of course artifacts due to the broadening. this results in slight VBM tail crossing the EF. I expect from the simple electron countings, this system should shows the gap between VBM and CBM, suspecting this is solely due to the Gaussian broadening. (Even though I use the GGA+U scheme, this tail is still there.) So, I checked outputtup/dn file, and I find I have non-integer occupation number in up spin, like 195.9998, at EF and it sustains the decimal value upto the conduction band minimum. The down spin shows exact interger number of electrons up to EF. I would like to know whether the 0.0002 e- deficiency is due to the numerical error (thus can be neglected), or I should check with the band structure to determine the metallicity of the system. When the number from the outputtup/dn file suggests sort of band gap, then could I consider this system as a semi-conductor regardless of the metallic states tail in dos1up/dn files? And, if 0.0002 e- is due to the numerics, is there any way to remove this annoying number? -- Peter Blaha Inst.Materials Chemistry TU Vienna Getreidemarkt 9 A-1060 Vienna Austria +43-1-5880115671 ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] A problem with icc and wien2k
I installed Intel ifort12 (l_fcompxe_2011.1.107) on my machine and started some tests. Yes, when compiling lstart with defaults it crashes with forrtl: severe (71): integer divide by zero Image PCRoutineLineSource lstart 004A0088 Unknown Unknown Unknown Even nicer, -traceback does not give any linenumber information. However, using -O1 (or -C) it works ! FOPT = -FR -O1 -w -DINTEL_VML -traceback It seems that Intel has created another buggy compiler version. PS: If somebody has already played with good compiler/linker options using ifort version 12, I would appreciate if you send me your options. Am 23.02.2011 12:43, schrieb C?sar de la Fuente: Dear sir, The line you mentioned for solving the problem of lstart by using ifort(12) + gcc was already included in the insld.f file, at around the line 114 of the file: ... BAR(10)=BAR1 norb=10 ! iex=5 DVC=137.0359895 IF(.NOT.RELA) DVC=1.E30 ! ! ... Then, I am still having problems with lstart in TiC example, even including DVC=137.0359895 at the line 57 IF (NSTOP.EQ.0) GO TO 2 1 CONTINUE JSPIN=2 DVC=137.0359895 ! add this line DSAL=DVC+DVC ... as you suggested in your last email. This is the warning I ve obtained after doing some small modifications to print out additional values: WARNING: R0 for atom1 Z= 22.00 too big, dr1: 0.0001000 NP0= 781 RMTT = 1.57000 (NOTICE THAT dr1=0.000100 is 0.51 in the line 139 of insld.f, so for atoms with Z18 the warning message should appear always, as it occurs for Ti.) forrtl: severe (71): integer divide by zero Image PCRoutineLineSource lstart 080C2149 Unknown Unknown Unknown lstart 0805623C MAIN__136 lstart.f lstart 08049FA4 Unknown Unknown Unknown libc.so.6 4008BBD6 Unknown Unknown Unknown lstart 08049EB1 Unknown Unknown Unknown 0.0u 0.0s 0:00.00 0.0% 0+0k 0+72io 0pf+0w error: command /usr/local/wien2k/lstart lstart.def failed However the problem should be in other place of insld.f I cannot debug properly the lstart program by using the intel compiler, so I would appreciate any support. Sorry, but I cannot access to the messages of Mailing list where this problem was fixed. Thanks anyway, Cesar -Mensaje original- De: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien-bounces at zeus.theochem.tuwien.ac.at] En nombre de Peter Blaha Enviado el: domingo, 20 de febrero de 2011 8:52 Para: A Mailing list for WIEN2k users Asunto: Re: [Wien] A problem with icc and wien2k If I remember correctly, the lstart problem with ifort12 was discussed and solved before. I guess it concernsinsld.f where one must add an initilization of DVC. IF (NSTOP.EQ.0) GO TO 2 1 CONTINUE JSPIN=2 DVC=137.0359895 ! add this line DSAL=DVC+DVC ... Am 19.02.2011 19:27, schrieb EGUCHI Gaku: Hello, I'm also in the same trouble with x lstart even in using ifort (v12)+gcc: SELECT XCPOT: recommended: 13: PBE-GGA (Perdew-Burke-Ernzerhof 96) 5: LSDA 11: WC-GGA (Wu-Cohen 2006) 19: PBEsol-GGA (Perdew etal. 2008) SELECT ENERGY to separate core and valence states: recommended: -6.0 Ry (check how much core charge leaks out of MT-sphere) ALTERNATIVELY: specify charge localization (between 0.97 and 1.0) to select core state forrtl: severe (71): integer divide by zero Image PC Routine Line Source lstart 080C2158 Unknown Unknown Unknown lstart 080561CC MAIN__ 136 lstart.f lstart 08049FA4 Unknown Unknown Unknown libc.so.6 4008DBD6 Unknown Unknown Unknown lstart 08049EB1 Unknown Unknown Unknown 0.008u 0.004s 0:00.01 0.0% 0+0k 0+0io 0pf+0w error: command /home/gaku/WIEN2k/lstart lstart.def failed -- This case I tried with pure sodium crystal and .inst file looks no problem: -- Na Ne 1 3,-1,0.5 N 3,-1,0.5 N END of input (instgen_lapw) -- I also tried with TiC that came across the same problem. For the trouble relating to SRC_vecpratt is removed by changing icc for gcc. I'd very happy if someone knows how to solve the trouble. Best, G. Eguchi (11/02/19 19:13), C?sar de la Fuente wrote: Everything works fine by using gcc instead icc (12.0). Thanks. C?sar -Mensaje original- De: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien-bounces at zeus.theochem.tuwien.ac.at] En nombre de Gerhard Fecher Enviado el: s?bado, 19 de febrero de 2011 10:37 Para: A Mailing list for WIEN2k users Asunto: Re: [Wien] A problem
[Wien] A problem with icc and wien2k
lstart 08049FA4 Unknown Unknown Unknown libc.so.6 4008BBD6 Unknown Unknown Unknown lstart 08049EB1 Unknown Unknown Unknown 0.0u 0.0s 0:00.03 0.0% 0+0k 8+72io 0pf+0w error: command /usr/local/wien2k/lstart lstart.def failed -- So, the previous compiling warning must be a real error and apparently it affects to icc configuration and specifically to W2kutils.c program. Any idea about how fix the problem by using the icc compiler? I ve sourced all variables compilers. I do not know if it works with other c-compiler but first I would like to use icc. Thanks for any comments. Sincerely, C?sar de la Fuente. ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2220 N Campus Drive Northwestern University Evanston, IL 60208, USA Tel: %28847%29%20491-3996(847) 491-3996 Fax: %28847%29%20491-7820(847) 491-7820 email: L-marks at northwestern dot edu Web: www.numis.northwestern.edu Chair, Commission on Electron Crystallography of IUCR www.numis.northwestern.edu/ Electron crystallography is the branch of science that uses electron scattering and imaging to study the structure of matter. ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: %2B43-1-58801-15671+43-1-58801-15671 FAX: %2B43-1-58801-15698+43-1-58801-15698 Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ 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/20110223/6b08805e/attachment.htm
[Wien] A problem with icc and wien2k
Thank's for this info. So it seems that beside lstart also lapw0 and txspec need to be recompiled with -O1 !!! -- - -- I continued to trace the lstart problem. This compiler version is really stupid: in case.insld.f insert: ... DO 119 I=1,NORB NMAX(I)=NP L=1 J=NQN(I)-NQL(I) IF((J-2*(J/2)).EQ.0) L=-L DQ1(I)=L*NK(I)/IABS(NK(I)) print*,'stupid print to fix ifort12 bug',i! insert this line IF (NUC) 111,119,111 111 IF (NK(I)) 112,119,119 112 DQ1(I)=DQ1(I)*(NK(I)-DFL(I))*DVC/Z 119 CONTINUE This print statement inhibits the overoptimization due to the compiler and one can compile with -O2. (during execution you will get several reminders about the stupidity of the compiler) PS: It does not help to set nk=999 at the beginning of insld.f Am 23.02.2011 16:24, schrieb Eamon McDermott: Dear Prof. Blaha and fellow WIEN2k users, Here are the compiler/linker options I have used with ifort 12 (ifort (IFORT) 12.0.0 20101116) on the Ubuntu 10.04 LTS x86_64 platform (Linux 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 23:42:43 UTC 2011 x86_64 GNU/Linux): FOPT = -g -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -I/opt/intel/mkl/include -O2 LDFLAGS = $(FOPT) -L/opt/intel/mkl/lib/intel64 -pthread R_LIBS = -Wl,--start-group -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -Wl,--end-group -openmp -lpthread You can choose an R_LIBS line appropriate to your architecture (32bit vs 64bit) by using the MKL link line advisor: http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/ I have the following set in my /etc/ld.so.conf.d/intel.conf (this prevents users from needing to run the ifort environment scripts): /opt/intel/mkl/lib/intel64 /opt/intel/lib/intel64 I do a full build with the above flags, then I reduce optimization from -O2 to -O1 and recompile the following tools (which get over-optimized with -O2): lapw0 lstart txspec So far I have had no problems with this setup (although I haven't tried an MPI build using this compiler yet). This is using all the default installation paths for the latest ifort. -- Eamon McDermott M.Sc Student Physics and Engineering Physics University of Saskatchewan eamon.mcdermott at usask.ca mailto:eamon.mcdermott at usask.ca On Wed, Feb 23, 2011 at 8:40 AM, Peter Blaha pblaha at theochem.tuwien.ac.at mailto:pblaha at theochem.tuwien.ac.at wrote: I installed Intel ifort12 (l_fcompxe_2011.1.107) on my machine and started some tests. Yes, when compiling lstart with defaults it crashes with forrtl: severe (71): integer divide by zero Image PCRoutineLineSource lstart 004A0088 Unknown Unknown Unknown Even nicer, -traceback does not give any linenumber information. However, using -O1 (or -C) it works ! FOPT = -FR -O1 -w -DINTEL_VML -traceback It seems that Intel has created another buggy compiler version. PS: If somebody has already played with good compiler/linker options using ifort version 12, I would appreciate if you send me your options. Am 23.02.2011 12:43, schrieb C?sar de la Fuente: Dear sir, The line you mentioned for solving the problem of lstart by using ifort(12) + gcc was already included in the insld.f file, at around the line 114 of the file: ... BAR(10)=BAR1 norb=10 ! iex=5 DVC=137.0359895 IF(.NOT.RELA) DVC=1.E30 ! ! ... Then, I am still having problems with lstart in TiC example, even including DVC=137.0359895 at the line 57 IF (NSTOP.EQ.0) GO TO 2 1 CONTINUE JSPIN=2 DVC=137.0359895 ! add this line DSAL=DVC+DVC ... as you suggested in your last email. This is the warning I ve obtained after doing some small modifications to print out additional values: WARNING: R0 for atom1 Z= 22.00 too big, dr1: 0.0001000 NP0= 781 RMTT = 1.57000 (NOTICE THAT dr1=0.000100 is 0.51 in the line 139 of insld.f, so for atoms with Z18 the warning message should appear always, as it occurs for Ti.) forrtl: severe (71): integer divide by zero Image PCRoutineLineSource lstart 080C2149 Unknown Unknown Unknown lstart 0805623C MAIN__136 lstart.f lstart 08049FA4 Unknown Unknown Unknown libc.so.6 4008BBD6 Unknown Unknown Unknown lstart
[Wien] A problem with icc and wien2k
Hi, Yes you a right. Just compiling lstart with FOPT: -FR -O1 -w -DINTEL_VML -traceback and it works for me too. Thanks you. Is there any problem if I keep the wien2k default ifort options for the rest of executables? Or Should I recompile all programs again with the -FR -O1 -w -DINTEL_VML -traceback? I guess it should not be a problem but I m not sure. Sincerely, Cesar -Mensaje original- De: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien-bounces at zeus.theochem.tuwien.ac.at] En nombre de Peter Blaha Enviado el: mi?rcoles, 23 de febrero de 2011 15:40 Para: A Mailing list for WIEN2k users Asunto: Re: [Wien] A problem with icc and wien2k I installed Intel ifort12 (l_fcompxe_2011.1.107) on my machine and started some tests. Yes, when compiling lstart with defaults it crashes with forrtl: severe (71): integer divide by zero Image PCRoutineLineSource lstart 004A0088 Unknown Unknown Unknown Even nicer, -traceback does not give any linenumber information. However, using -O1 (or -C) it works ! FOPT = -FR -O1 -w -DINTEL_VML -traceback It seems that Intel has created another buggy compiler version. PS: If somebody has already played with good compiler/linker options using ifort version 12, I would appreciate if you send me your options. Am 23.02.2011 12:43, schrieb C?sar de la Fuente: Dear sir, The line you mentioned for solving the problem of lstart by using ifort(12) + gcc was already included in the insld.f file, at around the line 114 of the file: ... BAR(10)=BAR1 norb=10 ! iex=5 DVC=137.0359895 IF(.NOT.RELA) DVC=1.E30 ! ! ... Then, I am still having problems with lstart in TiC example, even including DVC=137.0359895 at the line 57 IF (NSTOP.EQ.0) GO TO 2 1 CONTINUE JSPIN=2 DVC=137.0359895 ! add this line DSAL=DVC+DVC ... as you suggested in your last email. This is the warning I ve obtained after doing some small modifications to print out additional values: WARNING: R0 for atom1 Z= 22.00 too big, dr1: 0.0001000 NP0= 781 RMTT = 1.57000 (NOTICE THAT dr1=0.000100 is 0.51 in the line 139 of insld.f, so for atoms with Z18 the warning message should appear always, as it occurs for Ti.) forrtl: severe (71): integer divide by zero Image PCRoutineLineSource lstart 080C2149 Unknown Unknown Unknown lstart 0805623C MAIN__136 lstart.f lstart 08049FA4 Unknown Unknown Unknown libc.so.6 4008BBD6 Unknown Unknown Unknown lstart 08049EB1 Unknown Unknown Unknown 0.0u 0.0s 0:00.00 0.0% 0+0k 0+72io 0pf+0w error: command /usr/local/wien2k/lstart lstart.def failed However the problem should be in other place of insld.f I cannot debug properly the lstart program by using the intel compiler, so I would appreciate any support. Sorry, but I cannot access to the messages of Mailing list where this problem was fixed. Thanks anyway, Cesar -Mensaje original- De: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien-bounces at zeus.theochem.tuwien.ac.at] En nombre de Peter Blaha Enviado el: domingo, 20 de febrero de 2011 8:52 Para: A Mailing list for WIEN2k users Asunto: Re: [Wien] A problem with icc and wien2k If I remember correctly, the lstart problem with ifort12 was discussed and solved before. I guess it concernsinsld.f where one must add an initilization of DVC. IF (NSTOP.EQ.0) GO TO 2 1 CONTINUE JSPIN=2 DVC=137.0359895 ! add this line DSAL=DVC+DVC ... Am 19.02.2011 19:27, schrieb EGUCHI Gaku: Hello, I'm also in the same trouble with x lstart even in using ifort (v12)+gcc: SELECT XCPOT: recommended: 13: PBE-GGA (Perdew-Burke-Ernzerhof 96) 5: LSDA 11: WC-GGA (Wu-Cohen 2006) 19: PBEsol-GGA (Perdew etal. 2008) SELECT ENERGY to separate core and valence states: recommended: -6.0 Ry (check how much core charge leaks out of MT-sphere) ALTERNATIVELY: specify charge localization (between 0.97 and 1.0) to select core state forrtl: severe (71): integer divide by zero Image PC Routine Line Source lstart 080C2158 Unknown Unknown Unknown lstart 080561CC MAIN__ 136 lstart.f lstart 08049FA4 Unknown Unknown Unknown libc.so.6 4008DBD6 Unknown Unknown Unknown lstart 08049EB1 Unknown Unknown Unknown 0.008u 0.004s 0:00.01 0.0% 0+0k 0+0io 0pf+0w error: command /home/gaku/WIEN2k/lstart lstart.def failed -- This case I tried with pure sodium crystal and .inst file looks no problem: -- Na Ne 1 3,-1,0.5 N 3,-1,0.5 N END of input
[Wien] A problem with icc and wien2k
Hi again, It seems that lcore too in TiC example. start (Wed Feb 23 16:11:44 GMT 2011) with lapw0 (40/99 to go) cycle 1 (Wed Feb 23 16:11:44 GMT 2011) (40/99 to go) lapw0 (16:11:44) 6.1u 0.1s 0:06.41 97.9% 0+0k 6952+424io 13pf+0w lapw1 (16:11:51) 0.7u 0.0s 0:01.12 69.6% 0+0k 9440+632io 42pf+0w lapw2 (16:11:52) 0.2u 0.0s 0:00.33 100.0% 0+0k 0+392io 0pf+0w lcore (16:11:52) 0.0u 0.0s 0:00.00 0.0% 0+0k 0+32io 0pf+0w error: command /usr/local/wien2k/lcore lcore.def failed stop error -Mensaje original- De: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien-bounces at zeus.theochem.tuwien.ac.at] En nombre de Peter Blaha Enviado el: mi?rcoles, 23 de febrero de 2011 16:36 Para: A Mailing list for WIEN2k users Asunto: Re: [Wien] A problem with icc and wien2k Thank's for this info. So it seems that beside lstart also lapw0 and txspec need to be recompiled with -O1 !!! -- - -- I continued to trace the lstart problem. This compiler version is really stupid: in case.insld.f insert: ... DO 119 I=1,NORB NMAX(I)=NP L=1 J=NQN(I)-NQL(I) IF((J-2*(J/2)).EQ.0) L=-L DQ1(I)=L*NK(I)/IABS(NK(I)) print*,'stupid print to fix ifort12 bug',i! insert this line IF (NUC) 111,119,111 111 IF (NK(I)) 112,119,119 112 DQ1(I)=DQ1(I)*(NK(I)-DFL(I))*DVC/Z 119 CONTINUE This print statement inhibits the overoptimization due to the compiler and one can compile with -O2. (during execution you will get several reminders about the stupidity of the compiler) PS: It does not help to set nk=999 at the beginning of insld.f Am 23.02.2011 16:24, schrieb Eamon McDermott: Dear Prof. Blaha and fellow WIEN2k users, Here are the compiler/linker options I have used with ifort 12 (ifort (IFORT) 12.0.0 20101116) on the Ubuntu 10.04 LTS x86_64 platform (Linux 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 23:42:43 UTC 2011 x86_64 GNU/Linux): FOPT = -g -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -I/opt/intel/mkl/include -O2 LDFLAGS = $(FOPT) -L/opt/intel/mkl/lib/intel64 -pthread R_LIBS = -Wl,--start-group -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -Wl,--end-group -openmp -lpthread You can choose an R_LIBS line appropriate to your architecture (32bit vs 64bit) by using the MKL link line advisor: http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/ I have the following set in my /etc/ld.so.conf.d/intel.conf (this prevents users from needing to run the ifort environment scripts): /opt/intel/mkl/lib/intel64 /opt/intel/lib/intel64 I do a full build with the above flags, then I reduce optimization from -O2 to -O1 and recompile the following tools (which get over-optimized with -O2): lapw0 lstart txspec So far I have had no problems with this setup (although I haven't tried an MPI build using this compiler yet). This is using all the default installation paths for the latest ifort. -- Eamon McDermott M.Sc Student Physics and Engineering Physics University of Saskatchewan eamon.mcdermott at usask.ca mailto:eamon.mcdermott at usask.ca On Wed, Feb 23, 2011 at 8:40 AM, Peter Blaha pblaha at theochem.tuwien.ac.at mailto:pblaha at theochem.tuwien.ac.at wrote: I installed Intel ifort12 (l_fcompxe_2011.1.107) on my machine and started some tests. Yes, when compiling lstart with defaults it crashes with forrtl: severe (71): integer divide by zero Image PCRoutineLine Source lstart 004A0088 Unknown Unknown Unknown Even nicer, -traceback does not give any linenumber information. However, using -O1 (or -C) it works ! FOPT = -FR -O1 -w -DINTEL_VML -traceback It seems that Intel has created another buggy compiler version. PS: If somebody has already played with good compiler/linker options using ifort version 12, I would appreciate if you send me your options. Am 23.02.2011 12:43, schrieb C?sar de la Fuente: Dear sir, The line you mentioned for solving the problem of lstart by using ifort(12) + gcc was already included in the insld.f file, at around the line 114 of the file: ... BAR(10)=BAR1 norb=10 ! iex=5 DVC=137.0359895 IF(.NOT.RELA) DVC=1.E30 ! ! ... Then, I am still having problems with lstart in TiC example, even including DVC=137.0359895 at the line 57 IF (NSTOP.EQ.0) GO TO 2 1 CONTINUE JSPIN=2 DVC=137.0359895 ! add this line DSAL=DVC+DVC ... as you suggested in your last email. This is the warning I ve obtained after doing some small
[Wien] A problem with icc and wien2k
Of course, the problem with lcore also disappear when you recompile with -O1. At least now, TiC seems to get closer numbers obtained from previous wien2k and ifort version compilers. Someone should enter in the intel forums and try to get a solution from intel, hopefully for the next ifort compiler versions. Cheers Cesar -Mensaje original- De: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien-bounces at zeus.theochem.tuwien.ac.at] En nombre de C?sar de la Fuente Enviado el: mi?rcoles, 23 de febrero de 2011 17:14 Para: 'A Mailing list for WIEN2k users' Asunto: Re: [Wien] A problem with icc and wien2k Hi again, It seems that lcore too in TiC example. start (Wed Feb 23 16:11:44 GMT 2011) with lapw0 (40/99 to go) cycle 1 (Wed Feb 23 16:11:44 GMT 2011) (40/99 to go) lapw0 (16:11:44) 6.1u 0.1s 0:06.41 97.9% 0+0k 6952+424io 13pf+0w lapw1 (16:11:51) 0.7u 0.0s 0:01.12 69.6% 0+0k 9440+632io 42pf+0w lapw2 (16:11:52) 0.2u 0.0s 0:00.33 100.0% 0+0k 0+392io 0pf+0w lcore (16:11:52) 0.0u 0.0s 0:00.00 0.0% 0+0k 0+32io 0pf+0w error: command /usr/local/wien2k/lcore lcore.def failed stop error -Mensaje original- De: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien-bounces at zeus.theochem.tuwien.ac.at] En nombre de Peter Blaha Enviado el: mi?rcoles, 23 de febrero de 2011 16:36 Para: A Mailing list for WIEN2k users Asunto: Re: [Wien] A problem with icc and wien2k Thank's for this info. So it seems that beside lstart also lapw0 and txspec need to be recompiled with -O1 !!! -- - -- I continued to trace the lstart problem. This compiler version is really stupid: in case.insld.f insert: ... DO 119 I=1,NORB NMAX(I)=NP L=1 J=NQN(I)-NQL(I) IF((J-2*(J/2)).EQ.0) L=-L DQ1(I)=L*NK(I)/IABS(NK(I)) print*,'stupid print to fix ifort12 bug',i! insert this line IF (NUC) 111,119,111 111 IF (NK(I)) 112,119,119 112 DQ1(I)=DQ1(I)*(NK(I)-DFL(I))*DVC/Z 119 CONTINUE This print statement inhibits the overoptimization due to the compiler and one can compile with -O2. (during execution you will get several reminders about the stupidity of the compiler) PS: It does not help to set nk=999 at the beginning of insld.f Am 23.02.2011 16:24, schrieb Eamon McDermott: Dear Prof. Blaha and fellow WIEN2k users, Here are the compiler/linker options I have used with ifort 12 (ifort (IFORT) 12.0.0 20101116) on the Ubuntu 10.04 LTS x86_64 platform (Linux 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 23:42:43 UTC 2011 x86_64 GNU/Linux): FOPT = -g -FR -mp1 -w -prec_div -pc80 -pad -align -DINTEL_VML -I/opt/intel/mkl/include -O2 LDFLAGS = $(FOPT) -L/opt/intel/mkl/lib/intel64 -pthread R_LIBS = -Wl,--start-group -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -Wl,--end-group -openmp -lpthread You can choose an R_LIBS line appropriate to your architecture (32bit vs 64bit) by using the MKL link line advisor: http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/ I have the following set in my /etc/ld.so.conf.d/intel.conf (this prevents users from needing to run the ifort environment scripts): /opt/intel/mkl/lib/intel64 /opt/intel/lib/intel64 I do a full build with the above flags, then I reduce optimization from -O2 to -O1 and recompile the following tools (which get over-optimized with -O2): lapw0 lstart txspec So far I have had no problems with this setup (although I haven't tried an MPI build using this compiler yet). This is using all the default installation paths for the latest ifort. -- Eamon McDermott M.Sc Student Physics and Engineering Physics University of Saskatchewan eamon.mcdermott at usask.ca mailto:eamon.mcdermott at usask.ca On Wed, Feb 23, 2011 at 8:40 AM, Peter Blaha pblaha at theochem.tuwien.ac.at mailto:pblaha at theochem.tuwien.ac.at wrote: I installed Intel ifort12 (l_fcompxe_2011.1.107) on my machine and started some tests. Yes, when compiling lstart with defaults it crashes with forrtl: severe (71): integer divide by zero Image PCRoutineLine Source lstart 004A0088 Unknown Unknown Unknown Even nicer, -traceback does not give any linenumber information. However, using -O1 (or -C) it works ! FOPT = -FR -O1 -w -DINTEL_VML -traceback It seems that Intel has created another buggy compiler version. PS: If somebody has already played with good compiler/linker options using ifort version 12, I would appreciate if you send me your options. Am 23.02.2011 12:43, schrieb C?sar de la Fuente: Dear sir, The line you mentioned for solving the problem of lstart by using ifort(12) + gcc was already included in the insld.f file, at around the line 114 of the file: ...
[Wien] A problem with icc and wien2k
Apparently there is a newer version, 12.0.2 20110112, distributed as l_fcompxe_intel64_2011.2.137 (Jan 26 2011) The release notes state, somewhat obliquely: Update 2 (12.0.2) * Intel? Math Kernel Library updated to 10.3 Update 2 * The way that the Static Security Analysis feature creates data files has changed * Corrections to reported problems On Wed, Feb 23, 2011 at 8:40 AM, Peter Blaha pblaha at theochem.tuwien.ac.at wrote: I installed Intel ifort12 (l_fcompxe_2011.1.107) on my machine and started some tests. Yes, when compiling lstart with defaults it crashes with forrtl: severe (71): integer divide by zero Image ? ? ? ? ? ? ?PC ? ? ? ? ? ? ? ?Routine ? ? ? ? ? ?Line ? ? ? ?Source lstart ? ? ? ? ? ? 004A0088 ?Unknown ? ? ? ? ? ? ? Unknown ?Unknown Even nicer, -traceback does not give any linenumber information. However, using -O1 (or -C) ?it works ! FOPT ? ? = -FR -O1 -w -DINTEL_VML -traceback It seems that Intel has created another buggy compiler version. PS: If somebody has already played with good compiler/linker options using ifort version 12, I would appreciate if you send me your options. Am 23.02.2011 12:43, schrieb C?sar de la Fuente: Dear sir, The line you mentioned for solving the problem of lstart by using ifort(12) + gcc was already included in the insld.f file, at around the line 114 of the file: ... ? ? ? BAR(10)=BAR1 ? ? ? norb=10 ! ? ? ?iex=5 ? ? ? DVC=137.0359895 ? ? ? IF(.NOT.RELA) DVC=1.E30 ! ! ... Then, I am still having problems with lstart in TiC example, even including DVC=137.0359895 at the line 57 ? ? ? ?IF (NSTOP.EQ.0) GO TO 2 ? ?1 ? CONTINUE ? ? ? ?JSPIN=2 ? ? ? ?DVC=137.0359895 ? ? ? ! add this line ? ? ? ?DSAL=DVC+DVC ... as you suggested in your last email. This is the warning I ve obtained after doing some small modifications to print out additional values: WARNING: R0 for atom ? ?1 Z= 22.00 too big, dr1: 0.0001000 NP0= ? 781 RMTT = 1.57000 (NOTICE THAT dr1=0.000100 is ?0.51 in the line 139 of insld.f, so for atoms with Z18 the warning message should appear always, as it occurs for Ti.) forrtl: severe (71): integer divide by zero Image ? ? ? ? ? ? ?PC ? ? ? ?Routine ? ? ? ? ? ?Line ? ? ? ?Source lstart ? ? ? ? ? ? 080C2149 ?Unknown ? ? ? ? ? ? ? Unknown ?Unknown lstart ? ? ? ? ? ? 0805623C ?MAIN__ ? ? ? ? ? ? ? ? ? ?136 ?lstart.f lstart ? ? ? ? ? ? 08049FA4 ?Unknown ? ? ? ? ? ? ? Unknown ?Unknown libc.so.6 ? ? ? ? ?4008BBD6 ?Unknown ? ? ? ? ? ? ? Unknown ?Unknown lstart ? ? ? ? ? ? 08049EB1 ?Unknown ? ? ? ? ? ? ? Unknown ?Unknown 0.0u 0.0s 0:00.00 0.0% 0+0k 0+72io 0pf+0w error: command ? /usr/local/wien2k/lstart lstart.def ? failed However the problem should be in other place of insld.f I cannot debug properly the lstart program by using the intel compiler, so I would appreciate any support. Sorry, but I cannot access to the messages of Mailing list where this problem was fixed. Thanks anyway, Cesar -Mensaje original- De: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien-bounces at zeus.theochem.tuwien.ac.at] En nombre de Peter Blaha Enviado el: domingo, 20 de febrero de 2011 8:52 Para: A Mailing list for WIEN2k users Asunto: Re: [Wien] A problem with icc and wien2k If I remember correctly, the lstart problem with ifort12 was discussed and solved before. I guess it concerns ? ?insld.f ? where one must add an initilization of DVC. ? ? ? ?IF (NSTOP.EQ.0) GO TO 2 ? ?1 ? CONTINUE ? ? ? ?JSPIN=2 ? ? ? ?DVC=137.0359895 ? ? ? ! add this line ? ? ? ?DSAL=DVC+DVC ... Am 19.02.2011 19:27, schrieb EGUCHI Gaku: Hello, I'm also in the same trouble with x lstart even in using ifort (v12)+gcc: SELECT XCPOT: recommended: 13: PBE-GGA (Perdew-Burke-Ernzerhof 96) 5: LSDA 11: WC-GGA (Wu-Cohen 2006) 19: PBEsol-GGA (Perdew etal. 2008) SELECT ENERGY to separate core and valence states: recommended: -6.0 Ry (check how much core charge leaks out of MT-sphere) ALTERNATIVELY: specify charge localization (between 0.97 and 1.0) to select core state forrtl: severe (71): integer divide by zero Image PC Routine Line Source lstart 080C2158 Unknown Unknown Unknown lstart 080561CC MAIN__ 136 lstart.f lstart 08049FA4 Unknown Unknown Unknown libc.so.6 4008DBD6 Unknown Unknown Unknown lstart 08049EB1 Unknown Unknown Unknown 0.008u 0.004s 0:00.01 0.0% 0+0k 0+0io 0pf+0w error: command /home/gaku/WIEN2k/lstart lstart.def failed -- This case I tried with pure sodium crystal and .inst file looks no problem: -- Na Ne 1 3,-1,0.5 N 3,-1,0.5 N END of input (instgen_lapw) -- I also tried with TiC that came across the same problem. For the trouble relating to SRC_vecpratt is removed by changing icc for gcc.
[Wien] A problem with icc and wien2k
-- So, the previous compiling warning must be a real error and apparently it affects to icc configuration and specifically to W2kutils.c program. Any idea about how fix the problem by using the icc compiler? I ve sourced all variables compilers. I do not know if it works with other c-compiler but first I would like to use icc. Thanks for any comments. Sincerely, C?sar de la Fuente. ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2220 N Campus Drive Northwestern University Evanston, IL 60208, USA Tel: (847) 491-3996 Fax: (847) 491-7820 email: L-marks at northwestern dot edu Web: www.numis.northwestern.edu Chair, Commission on Electron Crystallography of IUCR www.numis.northwestern.edu/ Electron crystallography is the branch of science that uses electron scattering and imaging to study the structure of matter. ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-15671 FAX: +43-1-58801-15698 Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2220 N Campus Drive Northwestern University Evanston, IL 60208, USA Tel: (847) 491-3996 Fax: (847) 491-7820 email: L-marks at northwestern dot edu Web: www.numis.northwestern.edu Chair, Commission on Electron Crystallography of IUCR www.numis.northwestern.edu/ Electron crystallography is the branch of science that uses electron scattering and imaging to study the structure of matter. ___ 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/20110223/b73076a4/attachment.htm
[Wien] Wien2k compilation with gfortran compiler
I had the same problem while trying to compile with the gfortran compiler on Ubuntu 10.04, 10.10, and Debian Lenny. When I compile it, I do not get in errors, but I do get warnings like this: --- Warning: Deleted feature: GOTO at (1) jumps to END of construct at (2) --- assign 2021 to iform1 1 Warning: Deleted feature: ASSIGN statement at (1) init.f:264.17: READ(9,iform1) (CLM(I,L,JATOM),I=1,JRJ) --- clmcopy.f:206.29: WRITE(18,IFORM1) (CLMNEW(J,LM2,JATO,1),J=1,JRI(JATO)) 1 Warning: Deleted feature: ASSIGNED variable in FORMAT tag at (1) --- main.frc_tmp_.f:667.20: WRITE(2,IFORM)IEABS,E 1 Warning: Deleted feature: ASSIGNED variable in FORMAT tag at (1) --- I didn't install the goto library and I just used the regular blas and lapack libraries. I got everything to work with our old Intel compilers and mkl libraries, by finding an old libstdc++5 from a previous distribution of Debian. I would especially like to hear the explanation for these errors. Jason Vielma Quoting bobli rekharam swetarekharam at gmail.com: Dear Users I am using Wien2k_10.0. I compiled this in my machines ubuntu 9.04 using gfortran compiler. After compilation I am not getting error in compile.msg. But when i am running 'x tetra' for DOS i am getting following error Segmentation fault 0.090u 0.000s 0:00.09 100.0%0+0k 0+0io 0pf+0w error: command WIEN2k/tetra tetra.def failed and for MBJ( modified Becke John potential) I am getting this error STOP LAPW0 END At line 1653 of file lapw0.F (unit = 11, file = 'CsCaF3.r2v') Fortran runtime error: Constant string in input format (1X,,I10) ^ For compiling the code i am using the copiler option --- R_LIBS = -llapack_lapw -lblas_lapw -lblas -llapack Can you help me to remove this error Swetarekha Ram, Research Scholar, . -- ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] problem in optic
Dear wien2k users and Dr. Blaha
I calculated?electronic and structural properties of BNxP(1-x) with x=0.25
(nitrogen?impurity of BP), without any problem. Now?I am studing about optical
properties of this compound. I?excute (x lapw2 -fermi -p) without problem.?When
I excute (x optic -p)
I face with this error:
?
Commandline: x optic -p
Program input is:
running OPTIC in parallel mode
[1] 32632
[2] 32638
?OPTIC END
[1]? - Done? ( cd $PWD; $t $exe ${def}_${loop}.def; rm
-f .lock_$lockfile[$p] ) ? ...
[3] 32644
?OPTIC END
[2]? - Done? ( cd $PWD; $t $exe ${def}_${loop}.def; rm
-f .lock_$lockfile[$p] ) ? ...
[4] 32654
?OPTIC END
[3]? - Done? ( cd $PWD; $t $exe ${def}_${loop}.def; rm
-f .lock_$lockfile[$p] ) ? ...
[5] 32660
?OPTIC END
?OPTIC END
[5]? + Done? ( cd $PWD; $t $exe ${def}_${loop}.def; rm
-f .lock_$lockfile[$p] ) ? ...
[4]? + Done? ( cd $PWD; $t $exe ${def}_${loop}.def; rm
-f .lock_$lockfile[$p] ) ? ...
?? Summary of opticpara:
?? node3? user=7.796? wallclock=8.17
mv: cannot stat `bn.25p.symop_1': No such file or directory
rm: No match.
cat: bn.25p.symmat_1: No such file or directory
cat: bn.25p.mommat_1: No such file or directory
cat: bn.25p.mat_diag_1: No such file or directory
cat: bn.25p.mme_1: No such file or directory
rm: cannot remove `bn.25p.symmat_1': No such file or directory
rm: cannot remove `bn.25p.mommat_1': No such file or directory
rm: cannot remove `bn.25p.mat_diag_1': No such file or directory
rm: cannot remove `bn.25p.mme_1': No such file or directory
tail: cannot open `bn.25p.symmat_2' for reading: No such file or directory
tail: cannot open `bn.25p.mommat_2' for reading: No such file or directory
tail: cannot open `bn.25p.mat_diag_2' for reading: No such file or directory
tail: cannot open `bn.25p.mme_2' for reading: No such file or directory
rm: cannot remove `bn.25p.symmat_2': No such file or directory
rm: cannot remove `bn.25p.mommat_2': No such file or directory
rm: cannot remove `bn.25p.mat_diag_2': No such file or directory
rm: cannot remove `bn.25p.mme_2': No such file or directory
tail: cannot open `bn.25p.symmat_3' for reading: No such file or directory
tail: cannot open `bn.25p.mommat_3' for reading: No such file or directory
tail: cannot open `bn.25p.mat_diag_3' for reading: No such file or directory
tail: cannot open `bn.25p.mme_3' for reading: No such file or directory
rm: cannot remove `bn.25p.symmat_3': No such file or directory
rm: cannot remove `bn.25p.mommat_3': No such file or directory
rm: cannot remove `bn.25p.mat_diag_3': No such file or directory
rm: cannot remove `bn.25p.mme_3': No such file or directory
tail: cannot open `bn.25p.symmat_4' for reading: No such file or directory
tail: cannot open `bn.25p.mommat_4' for reading: No such file or directory
tail: cannot open `bn.25p.mat_diag_4' for reading: No such file or directory
tail: cannot open `bn.25p.mme_4' for reading: No such file or directory
rm: cannot remove `bn.25p.symmat_4': No such file or directory
rm: cannot remove `bn.25p.mommat_4': No such file or directory
rm: cannot remove `bn.25p.mat_diag_4': No such file or directory
rm: cannot remove `bn.25p.mme_4': No such file or directory
tail: cannot open `bn.25p.symmat_5' for reading: No such file or directory
tail: cannot open `bn.25p.mommat_5' for reading: No such file or directory
tail: cannot open `bn.25p.mat_diag_5' for reading: No such file or directory
tail: cannot open `bn.25p.mme_5' for reading: No such file or directory
rm: cannot remove `bn.25p.symmat_5': No such file or directory
rm: cannot remove `bn.25p.mommat_5': No such file or directory
rm: cannot remove `bn.25p.mat_diag_5': No such file or directory
rm: cannot remove `bn.25p.mme_5': No such file or directory
7.820u 0.216s 0:05.90 136.1%?0+0k 0+0io 0pf+0w
?
Please help me to solve this problem.
Thanks alot!
-- next part --
An HTML attachment was scrubbed...
URL:
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110223/b690e57a/attachment.htm
