[Wien] runsp_lapw following afm_lapw
This is only because runafm is not guaranteed to be always correct (not yet detected bugs etc.). To be safe, you should therefor continue afterwards with a few iterations using runsp. If runafm was correct for your case, nothing will change. If there was a bug (or if the material wants to be ferrimagnetic rather than antiferromagnetic) you will see changes. Stefaan Wenmei wrote: Dear Wien2k users, recently, I have done some AFM calculations, but I have somewhat confused by the recommedation below from the Wien2k userguide It is recommended that you save your work(lapw_save) and check the results by continuing with a regular runsp_lapw. If nothing changes(E-tot and other properties),then you are ok. why E-tot and other properties should not change by continuting a regular runsp_lapw? if it is truely so, will it be conclude that the final converged result has dependence of the initial given condition, not uniquely determined??? Any suggestion will be greatly appreciated! Best regards, Iphyboy ??? http://cn.mail.yahoo.com/gc/index.html?entry=5souce=mail_mailletter_tagline ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
[Wien] :WARNING you might have inconsistent Forces/Energies
Dear All, I have made additional calculations now and found that more than 10% of the cases I have problem to relax atom positions using PORT option. This can not be changed by various computational parameters I have tried (see my previous email). If one change from PORT to NEW1 for the troubled cases one can able to optimize atom positions with wien2k. It appears that PORT is not an efficient scheme to optimize atom positions for complex systems. But, I don't know howmuch one can gain computationally by using PORT instead of NEWT or NEW1. Best regards Ravi
[Wien] Lapw1 error
Dear Wein2k Users: I am installing Wien version 8 on a machine: Intel Core 2 Dou Proc with Intel motherboard with operating system openSuse 10.3 x86-64, Intel Fortran compiler (ifort)10.1.008 and Intel math Kernel lib 10.0.1.014. I am finished compiling without errors, but when I started to run TiC (example) I got following error: --- LAPW0 END *** glibc detected *** /home/devil/WIEN2k_08/lapw1: double free or corruption (!prev): 0x010a5ed0 *** === Backtrace: = /lib64/libc.so.6[0x2ac91912e21d] /lib64/libc.so.6(cfree+0x76)[0x2ac91912ff76] /home/devil/WIEN2k_08/lapw1[0x9c5801] /home/devil/WIEN2k_08/lapw1[0x46eb82] /home/devil/WIEN2k_08/lapw1[0x418b79] /home/devil/WIEN2k_08/lapw1[0x448441] /home/devil/WIEN2k_08/lapw1(realloc+0x1aa)[0x40c322] /lib64/libc.so.6(__libc_start_main+0xf4)[0x2ac9190ddb54] /home/devil/WIEN2k_08/lapw1(realloc+0xf1)[0x40c269] === Memory map: 0040-00abe000 r-xp 08:03 999719 /home/devil/WIEN2k_08/lapw1 00cbe000-00cbf000 r-xp 006be000 08:03 999719 /home/devil/WIEN2k_08/lapw1 00cbf000-00cdb000 rwxp 006bf000 08:03 999719 /home/devil/WIEN2k_08/lapw1 00cdb000-01554000 rwxp 00cdb000 00:00 0 [heap] 4000-40001000 ---p 4000 00:00 0 40001000-40011000 rwxp 40001000 00:00 0 40011000-40012000 ---p 40011000 00:00 0 40012000-4040a000 rwxp 40012000 00:00 0 2c00-2c321000 rwxp 2c00 00:00 0 2c321000-2aaab000 ---p 2c321000 00:00 0 2ac9188cd000-2ac9188e9000 r-xp 08:02 6033890 /lib64/ld-2.6.1.so 2ac9188e9000-2ac9188ea000 rwxp 2ac9188e9000 00:00 0 2ac918904000-2ac918a75000 rwxp 2ac918904000 00:00 0 2ac918ae8000-2ac918aea000 rwxp 0001b000 08:02 6033890 /lib64/ld-2.6.1.so 2ac918aea000-2ac918aff000 r-xp 08:02 6033923 /lib64/libpthread-2.6.1.so 2ac918aff000-2ac918cff000 ---p 00015000 08:02 6033923 /lib64/libpthread-2.6.1.so 2ac918cff000-2ac918d01000 rwxp 00015000 08:02 6033923 /lib64/libpthread-2.6.1.so 2ac918d01000-2ac918d05000 rwxp 2ac918d01000 00:00 0 2ac918d05000-2ac918d62000 r-xp 08:02 4435079 /opt/intel/fce/10.1.008/lib/libguide.so 2ac918d62000-2ac918e61000 ---p 0005d000 08:02 4435079 /opt/intel/fce/10.1.008/lib/libguide.so 2ac918e61000-2ac918e66000 rwxp 0005c000 08:02 4435079 /opt/intel/fce/10.1.008/lib/libguide.so 2ac918e66000-2ac918e6c000 rwxp 2ac918e66000 00:00 0 2ac918e6c000-2ac918ebe000 r-xp 08:02 6033905 /lib64/libm-2.6.1.so 2ac918ebe000-2ac9190bd000 ---p 00052000 08:02 6033905 /lib64/libm-2.6.1.so 2ac9190bd000-2ac9190bf000 rwxp 00051000 08:02 6033905 /lib64/libm-2.6.1.so 2ac9190bf000-2ac9190c rwxp 2ac9190bf000 00:00 0 2ac9190c-2ac9191fc000 r-xp 08:02 6033897 /lib64/libc-2.6.1.so 2ac9191fc000-2ac9193fc000 ---p 0013c000 08:02 6033897 /lib64/libc-2.6.1.so 2ac9193fc000-2ac9193ff000 r-xp 0013c000 08:02 6033897 /lib64/libc-2.6.1.so 2ac9193ff000-2ac919401000 rwxp 0013f000 08:02 6033897 /lib64/libc-2.6.1.so 2ac919401000-2ac919406000 rwxp 2ac919401000 00:00 0 2ac919406000-2ac919413000 r-xp 08:02 6033975 /lib64/libgcc_s.so.1 2ac919413000-2ac919612000 ---p d000 08:02 6033975 /lib64/libgcc_s.so.1 2ac919612000-2ac919614000 rwxp c000 08:02 6033975 /lib64/libgcc_s.so.1 2ac919614000-2ac919616000 r-xp 08:02 6033903 /lib64/libdl-2.6.1.so 2ac919616000-2ac919816000 ---p 2000 08:02 6033903 /lib64/libdl-2.6.1.so 2ac919816000-2ac919818000 rwxp 2000 08:02 6033903 /lib64/libdl-2.6.1.so 2ac919818000-2ac91981a000 rwxp 2ac919818000 00:00 0 7fff921b6000-7fff921dd000 rwxp 7fff921b6000 00:00 0 [stack] ff60-ff601000 r-xp 00:00 0 [vdso] stop error -- any suggestions? D.Vingurt -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20080213/85cf2b0e/attachment.html
[Wien] Error in case.in0 (H-mode)
Dear Dr. Blaha; In the UG, section 7, lapw0 (page 81), in format of case.in0, line 3 is IPRINT, H-mod, FFTopt, LUSE. When I try to use HYBR mod, there is *error* in *lapw0.* case.in0### TOT 18(5...CA-LDA, 13...PBE-GGA, 11...WC-GGA) R2V HYBR IFFT 8 (R2V) 0 0 02.00min IFFT-parameters, enhancement factor # According to UG, section 4.5.7, for B3PW91 it is needed to use functional 18 in case.in0, and mode = HYBR and fraction = 0.2 in case.ineece. What is my mistake for using B3PW91? -- H. Abbaszadeh Magnetic Research Laboratory (MRL) Sharif University of Technology (SUT) Tehran, IRAN Mobile: +98(914)4132419 e-mail: abbaszadeh at physics.sharif.edu -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20080213/10cdf95e/attachment.html
