[Wien] AMD or intel CPU
Intel I7 cpus are SIGNIFICANTLY faster than AMD. Make sure it is an I7 (not I5,..), because they have the fastest memory access and run best with Lapack/Blas (because of the mkl-library) which is very important. At the moment Intel offers: i7-3820 300$, 130W, 4 cores, 3.6/3.8GHz, 10MB cache, 4 memory channels and 51.2 GB/s bandwidth i7-3930K 600$, 130W, 6 cores, 3.2/3.8 12, as above i7-3770K 340$, 77W, 4 cores, 3.5/3.9 , 8MB , 2 memory channels 25.6 GB/s !!! So I would go clearly for a i7-3820 (or if you have more money) for a i7-3930K processor. The last one (3770K) is produced in the newest technology (power saving), but I guess its memory bus is much slower! Am 27.06.2012 13:53, schrieb ali ghafari: Dear Profs. Blaha and users We want to buy new computer for Wien2k calculation. The question is which kind of platforms (AMD or inlet) are suitable for Wien2k package? Best Regards Ali ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Peter Blaha Inst.Materials Chemistry TU Vienna Getreidemarkt 9 A-1060 Vienna Austria +43-1-5880115671
[Wien] lapw2.def failed ???
It's difficult always to stop at the final cycle manually. The second method also does not help. On Mon, Jun 25, 2012 at 7:59 PM, susanta mohanta susanta.phy at gmail.comwrote: thanks to both Lyudmila Dobysheva and Gavin Abo for your suggestions. I am trying these fixes. with regards susanta On Mon, Jun 25, 2012 at 6:11 PM, Gavin Abo gsabo at crimson.ua.edu wrote: Did you apply the fix to $WIENROOT/SRC_lapw2/l2main.f? You might try and see if it resolves the error. The fix was described at: http://zeus.theochem.tuwien.ac.at/pipermail/wien/2012-May/017010.html On 6/24/2012 11:12 PM, susanta mohanta wrote: Dear Prof. P. Blaha and wien2k users, we are facing a strange kind of problem in 3*3*3 (2*2*2 case also)supercell calculation of antiferromagnetic Cr. The system shows an error like this stop error error: command /home/mishra/wien2k/lapw2 uplapw2.def failed 2.808u 0.184s 0:02.00 149.0% 0+0k 0+968io 0pf+0w 0.775463595415941754.996137720228755.043014519304 lapw2 -up(23:58:22) WARNING: EF not accurate, new emin,emax,NE-min,NE-max 0.775463587848595 lapw1 -dn (23:57:00) 336.505u 3.180s 1:21.52 416.6% 0+0k 0+166840io 0pf+0w lapw1 -up (23:55:40) 338.905u 3.136s 1:19.75 428.8% 0+0k 0+166816io 0pf+0w :FORCE convergence: 1 1 0 XCO 0 XCO 0 XCO 0 XCO 0 XCO 0 XCO 0 XCO 0 XCO lapw0(23:55:12) 27.109u 0.240s 0:27.37 99.8% 0+0k 0+7400io 0pf+0w cycle 54 (Sun Jun 24 23:55:12 IST 2012) (347/46 to go) :CHARGE convergence: 1 0.001 -.736 :ENERGY convergence: 1 0.0001 .9145 mixer(23:55:11) 1.240u 0.144s 0:00.56 246.4% 0+0k 0+14680io 0pf+0w lcore -dn(23:55:11) 0.036u 0.008s 0:00.04 75.0% 0+0k 0+856io 0pf+0w lcore -up(23:55:11) 0.036u 0.008s 0:00.04 75.0% 0+0k 0+856io 0pf+0w 61.439u 1.900s 0:16.99 372.7%0+0k 0+4488io 0pf+0w 0.775465728942304754.996318253305755.043195022568 lapw2 -dn(23:54:54) WARNING: EF not accurate, new emin,emax,NE-min,NE-max 0.775465721374979 62.315u 2.016s 0:16.99 378.5%0+0k 0+4488io 0pf+0w 0.775465728942304754.996318253305755.043195022568 lapw2 -up(23:54:37) WARNING: EF not accurate, new emin,emax,NE-min,NE-max 0.775465721374979 lapw1 -dn (23:53:17) 334.468u 3.092s 1:19.74 423.3% 0+0k 0+166824io 0pf+0w lapw1 -up (23:51:57) 337.681u 2.816s 1:19.95 425.8% 0+0k 0+166832io 0pf+0w lapw0(23:51:30) 27.117u 0.260s 0:27.40 99.8% 0+0k 0+7400io 0pf+0w cycle 53 (Sun Jun 24 23:51:30 IST 2012) (348/47 to go) Though the system seems to be converging completely, the error comes at the last cycle. The problem is only seen in the latest version of wien2k, there is no problem in the older version, even those had published. I have attached the struct file. My IFORT version is 11.1.072. We are unable to figure out the reason behind it ? The shown case shows EF not accurate warnig, but even if the warning is not there the problem arises at the end as shown. we have played with various input parameters like RMT, RKMAX, but problem still persists. Any suggestions will be helpful. Thank you and kind regards Susanta ___ Wien mailing listWien at zeus.theochem.tuwien.ac.athttp://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 -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120628/244e57a2/attachment.htm
[Wien] AMD or intel CPU
Prof.Blaha Is there possibility to purchase wien2k through a vendor, as we have procurement problems (like placing order on you) to purchase directly through you.If yes, can we get for the same price as we are govt. labs please help us in this regard thanking you, ** *B.VENKATARAMUDU * Scientist *Defence Metallurgical Research Lab (DMRL)* Kanchanbagh ,Hyderabad-58 *Mob:09490381127* *Off:040-24586368* *** -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120628/c9f38ed1/attachment.htm
[Wien] AMD or intel CPU
Dear Prof. Blaha Thank you very much for your professional advice. for optimize system does it matter which operating system we use or not? for example Debian is better or Ubuntu? Best Regards Ali From: Peter Blaha pblaha at theochem.tuwien.ac.at To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Sent: Thursday, June 28, 2012 8:44 AM Subject: Re: [Wien] AMD or intel CPU Intel I7 cpus are SIGNIFICANTLY faster than AMD. Make sure it is an I7 (not I5,..), because they have the fastest memory access and run best with Lapack/Blas (because of the mkl-library) which is very important. At the moment Intel offers: i7-3820? 300$, 130W, 4 cores, 3.6/3.8GHz, 10MB cache, 4 memory channels ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? and 51.2 GB/s bandwidth i7-3930K 600$, 130W, 6 cores, 3.2/3.8? ? 12? ? ? ? ,? as above i7-3770K 340$,? 77W, 4 cores, 3.5/3.9? ,? 8MB? ? ? , 2 memory channels ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 25.6 GB/s !!! So I would go clearly for a i7-3820? (or if you have more money) for a i7-3930K processor. The last one (3770K) is produced in the newest technology (power saving), but I guess its memory bus is much slower! Am 27.06.2012 13:53, schrieb ali ghafari: Dear Profs. Blaha and users We want to buy new computer for Wien2k calculation. The question is which kind of platforms (AMD or inlet) are suitable for Wien2k package? Best Regards Ali ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- 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 -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120628/bd791716/attachment.htm
[Wien] AMD or intel CPU
Use the Linux version which you know best, so that you are able to configure your Linux properly and install all necessary tools. Am 28.06.2012 10:20, schrieb ali ghafari: Dear Prof. Blaha Thank you very much for your professional advice. for optimize system does it matter which operating system we use or not? for example Debian is better or Ubuntu? Best Regards Ali *From:* Peter Blaha pblaha at theochem.tuwien.ac.at *To:* A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at *Sent:* Thursday, June 28, 2012 8:44 AM *Subject:* Re: [Wien] AMD or intel CPU Intel I7 cpus are SIGNIFICANTLY faster than AMD. Make sure it is an I7 (not I5,..), because they have the fastest memory access and run best with Lapack/Blas (because of the mkl-library) which is very important. At the moment Intel offers: i7-3820 300$, 130W, 4 cores, 3.6/3.8GHz, 10MB cache, 4 memory channels and 51.2 GB/s bandwidth i7-3930K 600$, 130W, 6 cores, 3.2/3.812, as above i7-3770K 340$, 77W, 4 cores, 3.5/3.9 , 8MB , 2 memory channels 25.6 GB/s !!! So I would go clearly for a i7-3820 (or if you have more money) for a i7-3930K processor. The last one (3770K) is produced in the newest technology (power saving), but I guess its memory bus is much slower! Am 27.06.2012 13:53, schrieb ali ghafari: Dear Profs. Blaha and users We want to buy new computer for Wien2k calculation. The question is which kind of platforms (AMD or inlet) are suitable for Wien2k package? Best Regards Ali ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at mailto:Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- 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 mailto: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 -- Peter Blaha Inst.Materials Chemistry TU Vienna Getreidemarkt 9 A-1060 Vienna Austria +43-1-5880115671
[Wien] Runtime Error
Dear Wien2k Users, I am using Ubuntu operating system with Intel Fortran compiler to compile wien2k. The compilation showed no error; but at the time of running the code I am finding the following error: hup: Command not found. LAPW0 END *** glibc detected *** /home/debojyoti/Software/wien2k/lapw1: munmap_chunk(): invalid pointer: 0x09709f88 *** === Backtrace: = /lib/i386-linux-gnu/libc.so.6(+0x73e42)[0x40de4e42] /lib/i386-linux-gnu/libc.so.6(+0x74525)[0x40de5525] /home/debojyoti/Software/wien2k/lapw1[0x80d04f2] /home/debojyoti/Software/wien2k/lapw1[0x8082d54] /home/debojyoti/Software/wien2k/lapw1[0x80939a5] /home/debojyoti/Software/wien2k/lapw1[0x807ca21] /home/debojyoti/Software/wien2k/lapw1[0x804b0c4] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x40d8a4d3] === Memory map: 08048000-08193000 r-xp 08:06 7744711 /home/debojyoti/Software/wien2k/lapw1 08193000-0819b000 rw-p 0014a000 08:06 7744711 /home/debojyoti/Software/wien2k/lapw1 0819b000-0840b000 rw-p 00:00 0 094de000-097a rw-p 00:00 0 [heap] 4000-4002 r-xp 08:06 7078795/lib/i386-linux-gnu/ ld-2.15.so 4002-40021000 r--p 0001f000 08:06 7078795/lib/i386-linux-gnu/ ld-2.15.so 40021000-40022000 rw-p 0002 08:06 7078795/lib/i386-linux-gnu/ ld-2.15.so 40022000-40023000 r-xp 00:00 0 [vdso] 40023000-40025000 rw-p 00:00 0 40025000-40371000 r-xp 08:06 7350966 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_intel.so 40371000-40378000 rw-p 0034b000 08:06 7350966 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_intel.so 40378000-4037d000 rw-p 00:00 0 4037d000-40529000 r-xp 08:06 7351033 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_sequential.so 40529000-4052d000 rw-p 001ac000 08:06 7351033 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_sequential.so 4052d000-40cff000 r-xp 08:06 7348996 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_core.so 40cff000-40d08000 rw-p 007d2000 08:06 7348996 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_core.so 40d08000-40d13000 rw-p 00:00 0 40d24000-40d4e000 r-xp 08:06 7078847/lib/i386-linux-gnu/ libm-2.15.so 40d4e000-40d4f000 r--p 00029000 08:06 7078847/lib/i386-linux-gnu/ libm-2.15.so 40d4f000-40d5 rw-p 0002a000 08:06 7078847/lib/i386-linux-gnu/ libm-2.15.so 40d5-40d67000 r-xp 08:06 7078895/lib/i386-linux-gnu/ libpthread-2.15.so 40d67000-40d68000 r--p 00016000 08:06 7078895/lib/i386-linux-gnu/ libpthread-2.15.so 40d68000-40d69000 rw-p 00017000 08:06 7078895/lib/i386-linux-gnu/ libpthread-2.15.so 40d69000-40d6b000 rw-p 00:00 0 40d6b000-40d6e000 r-xp 08:06 7078828/lib/i386-linux-gnu/ libdl-2.15.so 40d6e000-40d6f000 r--p 2000 08:06 7078828/lib/i386-linux-gnu/ libdl-2.15.so 40d6f000-40d7 rw-p 3000 08:06 7078828/lib/i386-linux-gnu/ libdl-2.15.so 40d7-40d71000 rw-p 00:00 0 40d71000-40f1 r-xp 08:06 7078815/lib/i386-linux-gnu/ libc-2.15.so 40f1-40f12000 r--p 0019f000 08:06 7078815/lib/i386-linux-gnu/ libc-2.15.so 40f12000-40f13000 rw-p 001a1000 08:06 7078815/lib/i386-linux-gnu/ libc-2.15.so 40f13000-40f16000 rw-p 00:00 0 40f16000-40f32000 r-xp 08:06 7078836 /lib/i386-linux-gnu/libgcc_s.so.1 40f32000-40f33000 r--p 0001b000 08:06 7078836 /lib/i386-linux-gnu/libgcc_s.so.1 40f33000-40f34000 rw-p 0001c000 08:06 7078836 /lib/i386-linux-gnu/libgcc_s.so.1 40f34000-40f35000 rw-p 00:00 0 40f35000-416ac000 r-xp 08:06 7351127 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_vml_p4m3.so 416ac000-416bc000 rw-p 00777000 08:06 7351127 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_vml_p4m3.so 416bc000-416bd000 rw-p 00:00 0 417a6000-4188f000 rw-p 00:00 0 41df3000-433d9000 r-xp 08:06 7350997 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_p4m3.so 433d9000-43447000 rw-p 015e6000 08:06 7350997 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_p4m3.so 43447000-43449000 rw-p 00:00 0 bfd11000-bfd34000 rw-p 00:00 0 [stack] stop error Can anybody tell me where is the error and how to get rid of this problem? Thanks in advenced. --Debojyoti Mukherjee-- -- Scientific Officer - D, Applied Physics Division, Bhabha Atomic Research Center, Mumbai - 400085, India. -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120628/49e6c14f/attachment.htm
[Wien] Is there any relationship between DOS(E_F) and conductivity?
Fast answer: compare Fe and Cu and you have it. The conductivity depends not only on the DOS at Ef but also on the setails of the bandstructure. There is no way to compare whether Sodium, Copper, or Gold are more metallic or not. 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;saeid pourmasoud [sa_pourmasoud2007 at yahoo.com] Gesendet: Donnerstag, 28. Juni 2012 06:45 An: wien at zeus.theochem.tuwien.ac.at Betreff: [Wien] Is there any relationship between DOS(E_F) and conductivity? Dear All, We are working on two different metallic compounds. I have calculated total DOS at Fermi level, DOS(E_F), for these two compounds. Our result shows that the DOS(E_F) of the first compound is larger than the DOS(E_F) of the second compound. Can I conclude from this observation that the first compound is more metallic than the second compound? Can we compare conductivity of these two compounds using their total DOS values at Fermi levels? Can you cite a reference in this respect? Best regards, S. Pourmasoud
[Wien] Problem with wien2k 11
Dear Prof. Blaha, I have installed wien2k11 in my dell core2duo laptop with composer xe 11 update 9 (l_fcompxe_intel64_2011.11.339_1). I can sucessfully run TiC, VC, ScC and similar compounds in fcc structure. But when I tried to calculate ZrO2 in monoclinic structure I got the following error:ZrO2 problem Calculating ZrO2 in /home/james/ZrO2on localhost.localdomain with PID 8700 using WIEN2k_11.1 (Release 14/6/2011) in /home/james/wien2k start (Thu Jun 28 14:24:27 IST 2012) with lapw0 (40/99 to go) cycle 1 (Thu Jun 28 14:24:27 IST 2012) (40/99 to go) lapw0 (14:24:27) 5.979u 0.380s 0:06.37 99.6% 0+0k 0+6320io 0pf+0w lapw1 (14:24:34) Abort (core dumped) 2.369u 0.289s 0:03.73 70.7% 0+0k 1688+5168io 9pf+0w error: command /home/james/wien2k/lapw1 lapw1.def failed stop error In another case I installed wien2k11 in my hp corei3 with composer xe 11.9.2011. In this case even TiC is unable to run. The following message came: LAPW0 ENDforrtl: severe (174): SIGSEGV, segmentation fault occurred stop error Please help me to get me out of these problems. Yours sincerely Jameson Maibam -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120628/1e927e9f/attachment.htm
[Wien] Is there any relationship between DOS(E_F) and conductivity?
Hello S. Pourmasoud, To calculate conductivity (in a bandstructure approach), you also need to know how many electronic states have non-zero momentum in your transport direction (in simple words ...). In other words, you need to calculate the Fermi surface projection on the plane, normal to your transport direction. Therefore, as Gerhard noticed, conductance also depends on details of electronic structure - Fermi surface topology. You can check this ref on how to use this approach to calculate transport properties: Phys. Rev. B 57, 8907 (1998). Vladimir. === Dr. Vladimir Timoshevskii (Timochevski) Department of Physics, McGill University, 3600 rue University, Montreal, QC Canada H3A 2T8 Tel: +1 (514) 396-8935 Fax: +1 (514) 398-8434 === On 06/28/12 05:04, Fecher, Gerhard wrote: Fast answer: compare Fe and Cu and you have it. The conductivity depends not only on the DOS at Ef but also on the setails of the bandstructure. There is no way to compare whether Sodium, Copper, or Gold are more metallic or not. 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 vonquot;saeid pourmasoud [sa_pourmasoud2007 at yahoo.com] Gesendet: Donnerstag, 28. Juni 2012 06:45 An: wien at zeus.theochem.tuwien.ac.at Betreff: [Wien] Is there any relationship between DOS(E_F) and conductivity? Dear All, We are working on two different metallic compounds. I have calculated total DOS at Fermi level, DOS(E_F), for these two compounds. Our result shows that the DOS(E_F) of the first compound is larger than the DOS(E_F) of the second compound. Can I conclude from this observation that the first compound is more metallic than the second compound? Can we compare conductivity of these two compounds using their total DOS values at Fermi levels? Can you cite a reference in this respect? Best regards, S. Pourmasoud ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien --
[Wien] Problem in LDA+U calculation
Thank you for the solution, it is working now. From: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at zeus.theochem.tuwien.ac.at] on behalf of tran at theochem.tuwien.ac.at [t...@theochem.tuwien.ac.at] Sent: Wednesday, June 27, 2012 1:54 PM To: A Mailing list for WIEN2k users Subject: Re: [Wien] Problem in LDA+U calculation I have the same problem and the error message in case.outputorbup is Conflict in atom orb. number: lorb 3 ne ll 2. The reason is that in case.dmatup(dn), the blocks for a given atom are ordered in increasing value of l (even if they are not ordered in case.indmc), while orb thinks that the order is like in case.inorb. I solved the problem by ordering the values of l in case.inorb (don't forget to also order the values of U and J accordingly): 1 2 2 3 2 2 2 3 3 1 2 Then it runs. Another unrelated problem: during init_lapw, lstart complains about the values of R0 in case.struct. You have to regenerate case.struct, such that the values of R0 (they are set automatically) are ok. The values of R0 should never be set manually. On Wed, 27 Jun 2012, Hena Das wrote: @Robert: Yes I used Wien2k orb executables. @Tran: I followed your suggestion and tried to do the same in Wien2k. The same error appeared even in Wien2k. I tried both options : 1 2 3 2 2 2 3 2 1 2 2 3 2 2 2 3 Below are the case.indmc and case.inorb files that I have used: case.indmc -9. Emin cutoff energy 3 number of atoms for which density matrix is calculated 1 2 3 2 index of 1st atom, number of L's, L1 2 2 3 2 dtto for 2nd atom, repeat NATOM times 3 1 2 dtto for 2nd atom, repeat NATOM times 0 0 r-index, (l,s)index case.inorb 1 3 0 nmod, natorb, ipr PRATT 1.0BROYD/PRATT, mixing 1 2 3 2 2 2 3 2 3 1 2 iatom nlorb, lorb 1 nsic 0..AMF, 1..SIC, 2..HFM 0.53 0.07 0.43 0.07U J (Ry) 0.53 0.07 0.43 0.07 0.43 0.07 I hope I am not using any wrong input. Can you please check. Hena From: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at zeus.theochem.tuwien.ac.at] on behalf of tran at theochem.tuwien.ac.at [tran at theochem.tuwien.ac.at] Sent: Wednesday, June 27, 2012 3:22 AM To: wien at zeus.theochem.tuwien.ac.at Subject: Re: [Wien] Problem in LDA+U calculation Dear Hena, Actually, it should work with WIEN2k (I don't know with Wienncm). I have tried myself on NiO with l=1 and 2 on nickel and l=1 on oxygen and it's running properly. The first thing you should do is to try with WIEN2k and see if it works or not. If it works with WIEN2k, but not with Wienncm, it could be that also a c-shell script of Wienncm has to be modified. But just in case, you can also try this: replace 1 2 3 2 2 2 3 2 by 1 2 2 3 2 2 2 3 in case.indmc and case.inorb F. Tran On 25.06.2012 17:45, Hena Das wrote: I am doing a scf calculation for a particular non-collinear spin configuration. A am using LDA+U method. When I use the following case.inorb and case.indmc files: case.inorb 1 3 0 nmod, natorb, ipr PRATT 1.0BROYD/PRATT, mixing 1 1 3 2 1 3 3 1 2 1 nsic 0..AMF, 1..SIC, 2..HFM 0.65 0.07U J (Ry) 0.65 0.07 0.45 0.07 case.indmc -9. Emin cutoff energy 3 number of atoms for which density matrix is calculated 1 1 3 index of 1st atom, number of L's, L1 2 1 3 dtto for 2nd atom, repeat NATOM times 3 1 2 index of 1st atom, number of L's, L1 0 0 r-index, (l,s)index the program executes properly without any error. However when I use the other set of case.inorb and case.indmc files: case.inorb 1 3 0 nmod, natorb, ipr PRATT 1.0BROYD/PRATT, mixing 1 2 3 2 2 2 3 2 3 1 2 1 nsic 0..AMF, 1..SIC, 2..HFM 0.65 0.07 0.45 0.07U J (Ry) 0.65 0.07 0.45 0.07 0.45 0.07 case.indmc -9. Emin cutoff energy 3 number of atoms for which density matrix is calculated 1 2 3 2 index of 1st atom, number of L's, L1 2 2 3 2 dtto for 2nd atom, repeat NATOM times 3 1 2 index of 1st atom, number of L's, L1 0 0 r-index, (l,s)index the program stops by giving the error: error in Vorb. It is not writing case.vorbup/dn files. In the next set I just use U at the d states as well as at the f states for atom 1 and 2. Am I giving any
[Wien] spin and orbital moments
Dear Wien2k developers, I use wien2k version 11.1 to run spin-polarized GGA+U calculations with SO coupling for a molibdenum oxide. The symmetry of the system is the following bleblebles-o calc. M|| 1.00 1.00 -1.00 P 15 2 P- RELA 13.669712 13.669712 13.669712 60.00 60.00 60.00 As you see, I set magnetization axis to 1 1 -1, which should be in terms of (non-orthogonal) lattice vectors. With the help of xcrysden and case.outsymso, I can deduce that this direction corresponds to the 0.577350, 0.816497, 0 direction in terms of the cartesian global coordinate system. When I converge the electron density with (without using any previously converged non-relativistic calculation) runsp_lapw -p -orb -so -dm I get the following data for the first and the last iteration on one of the Mo atoms: 1. iteration: :SPI005: SPIN MOMENT: 0.46560 0.80642 -0.53749 PROJECTION ON M 1.07518 :ORB005: ORBITAL MOMENT: -0.08361 -0.01872 0.02851 PROJECTION ON M -0.06454 :MMI005: MAGNETIC MOMENT IN SPHERE 5=1.86180 last iteration (converged solution): :SPI005: SPIN MOMENT: 0.61653 1.06239 -0.70860 PROJECTION ON M 1.41804 :ORB005: ORBITAL MOMENT: -0.08361 -0.01872 0.02851 PROJECTION ON M -0.06454 :MMI005: MAGNETIC MOMENT IN SPHERE 5=1.43149 Now, I am struggling to understand two things: 1) In which coordinate system are SPI005 and ORB005 given? If they were given in the global cartesian coordinate system, they would be parallel to 0.577350, 0.816497, 0, but they are not. 2) Why for the first iteration MMI005 is not even roughly equal to SPI005 + ORB005? Thank you very much! Kateryna Foyevtsova P.S. When I perform relativistic calculations starting with a preconverged electron density of the non-relativistic solution I get the same final result.
[Wien] Problem in LDA+U calculation
Ok. There was another problem with your case.struct: the RMT of some atoms were too small, leading to core leakage (during init_lapw). Also, with LDA+U it is better to use large RMT because U is applied only inside the sphere. On Thu, 28 Jun 2012, Hena Das wrote: Thank you for the solution, it is working now. From: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at zeus.theochem.tuwien.ac.at] on behalf of tran at theochem.tuwien.ac.at [tran at theochem.tuwien.ac.at] Sent: Wednesday, June 27, 2012 1:54 PM To: A Mailing list for WIEN2k users Subject: Re: [Wien] Problem in LDA+U calculation I have the same problem and the error message in case.outputorbup is Conflict in atom orb. number: lorb 3 ne ll 2. The reason is that in case.dmatup(dn), the blocks for a given atom are ordered in increasing value of l (even if they are not ordered in case.indmc), while orb thinks that the order is like in case.inorb. I solved the problem by ordering the values of l in case.inorb (don't forget to also order the values of U and J accordingly): 1 2 2 3 2 2 2 3 3 1 2 Then it runs. Another unrelated problem: during init_lapw, lstart complains about the values of R0 in case.struct. You have to regenerate case.struct, such that the values of R0 (they are set automatically) are ok. The values of R0 should never be set manually. On Wed, 27 Jun 2012, Hena Das wrote: @Robert: Yes I used Wien2k orb executables. @Tran: I followed your suggestion and tried to do the same in Wien2k. The same error appeared even in Wien2k. I tried both options : 1 2 3 2 2 2 3 2 1 2 2 3 2 2 2 3 Below are the case.indmc and case.inorb files that I have used: case.indmc -9. Emin cutoff energy 3 number of atoms for which density matrix is calculated 1 2 3 2 index of 1st atom, number of L's, L1 2 2 3 2 dtto for 2nd atom, repeat NATOM times 3 1 2 dtto for 2nd atom, repeat NATOM times 0 0 r-index, (l,s)index case.inorb 1 3 0 nmod, natorb, ipr PRATT 1.0BROYD/PRATT, mixing 1 2 3 2 2 2 3 2 3 1 2 iatom nlorb, lorb 1 nsic 0..AMF, 1..SIC, 2..HFM 0.53 0.07 0.43 0.07U J (Ry) 0.53 0.07 0.43 0.07 0.43 0.07 I hope I am not using any wrong input. Can you please check. Hena From: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at zeus.theochem.tuwien.ac.at] on behalf of tran at theochem.tuwien.ac.at [tran at theochem.tuwien.ac.at] Sent: Wednesday, June 27, 2012 3:22 AM To: wien at zeus.theochem.tuwien.ac.at Subject: Re: [Wien] Problem in LDA+U calculation Dear Hena, Actually, it should work with WIEN2k (I don't know with Wienncm). I have tried myself on NiO with l=1 and 2 on nickel and l=1 on oxygen and it's running properly. The first thing you should do is to try with WIEN2k and see if it works or not. If it works with WIEN2k, but not with Wienncm, it could be that also a c-shell script of Wienncm has to be modified. But just in case, you can also try this: replace 1 2 3 2 2 2 3 2 by 1 2 2 3 2 2 2 3 in case.indmc and case.inorb F. Tran On 25.06.2012 17:45, Hena Das wrote: I am doing a scf calculation for a particular non-collinear spin configuration. A am using LDA+U method. When I use the following case.inorb and case.indmc files: case.inorb 1 3 0 nmod, natorb, ipr PRATT 1.0BROYD/PRATT, mixing 1 1 3 2 1 3 3 1 2 1 nsic 0..AMF, 1..SIC, 2..HFM 0.65 0.07U J (Ry) 0.65 0.07 0.45 0.07 case.indmc -9. Emin cutoff energy 3 number of atoms for which density matrix is calculated 1 1 3 index of 1st atom, number of L's, L1 2 1 3 dtto for 2nd atom, repeat NATOM times 3 1 2 index of 1st atom, number of L's, L1 0 0 r-index, (l,s)index the program executes properly without any error. However when I use the other set of case.inorb and case.indmc files: case.inorb 1 3 0 nmod, natorb, ipr PRATT 1.0BROYD/PRATT, mixing 1 2 3 2 2 2 3 2 3 1 2 1 nsic 0..AMF, 1..SIC, 2..HFM 0.65 0.07 0.45 0.07U J (Ry) 0.65 0.07 0.45 0.07 0.45 0.07 case.indmc -9. Emin cutoff energy 3 number of atoms for which density matrix is
[Wien] Problem in LDA+U calculation
Okay...Thanks. From: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at zeus.theochem.tuwien.ac.at] on behalf of tran at theochem.tuwien.ac.at [t...@theochem.tuwien.ac.at] Sent: Thursday, June 28, 2012 11:36 AM To: A Mailing list for WIEN2k users Subject: Re: [Wien] Problem in LDA+U calculation Ok. There was another problem with your case.struct: the RMT of some atoms were too small, leading to core leakage (during init_lapw). Also, with LDA+U it is better to use large RMT because U is applied only inside the sphere. On Thu, 28 Jun 2012, Hena Das wrote: Thank you for the solution, it is working now. From: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at zeus.theochem.tuwien.ac.at] on behalf of tran at theochem.tuwien.ac.at [tran at theochem.tuwien.ac.at] Sent: Wednesday, June 27, 2012 1:54 PM To: A Mailing list for WIEN2k users Subject: Re: [Wien] Problem in LDA+U calculation I have the same problem and the error message in case.outputorbup is Conflict in atom orb. number: lorb 3 ne ll 2. The reason is that in case.dmatup(dn), the blocks for a given atom are ordered in increasing value of l (even if they are not ordered in case.indmc), while orb thinks that the order is like in case.inorb. I solved the problem by ordering the values of l in case.inorb (don't forget to also order the values of U and J accordingly): 1 2 2 3 2 2 2 3 3 1 2 Then it runs. Another unrelated problem: during init_lapw, lstart complains about the values of R0 in case.struct. You have to regenerate case.struct, such that the values of R0 (they are set automatically) are ok. The values of R0 should never be set manually. On Wed, 27 Jun 2012, Hena Das wrote: @Robert: Yes I used Wien2k orb executables. @Tran: I followed your suggestion and tried to do the same in Wien2k. The same error appeared even in Wien2k. I tried both options : 1 2 3 2 2 2 3 2 1 2 2 3 2 2 2 3 Below are the case.indmc and case.inorb files that I have used: case.indmc -9. Emin cutoff energy 3 number of atoms for which density matrix is calculated 1 2 3 2 index of 1st atom, number of L's, L1 2 2 3 2 dtto for 2nd atom, repeat NATOM times 3 1 2 dtto for 2nd atom, repeat NATOM times 0 0 r-index, (l,s)index case.inorb 1 3 0 nmod, natorb, ipr PRATT 1.0BROYD/PRATT, mixing 1 2 3 2 2 2 3 2 3 1 2 iatom nlorb, lorb 1 nsic 0..AMF, 1..SIC, 2..HFM 0.53 0.07 0.43 0.07U J (Ry) 0.53 0.07 0.43 0.07 0.43 0.07 I hope I am not using any wrong input. Can you please check. Hena From: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at zeus.theochem.tuwien.ac.at] on behalf of tran at theochem.tuwien.ac.at [tran at theochem.tuwien.ac.at] Sent: Wednesday, June 27, 2012 3:22 AM To: wien at zeus.theochem.tuwien.ac.at Subject: Re: [Wien] Problem in LDA+U calculation Dear Hena, Actually, it should work with WIEN2k (I don't know with Wienncm). I have tried myself on NiO with l=1 and 2 on nickel and l=1 on oxygen and it's running properly. The first thing you should do is to try with WIEN2k and see if it works or not. If it works with WIEN2k, but not with Wienncm, it could be that also a c-shell script of Wienncm has to be modified. But just in case, you can also try this: replace 1 2 3 2 2 2 3 2 by 1 2 2 3 2 2 2 3 in case.indmc and case.inorb F. Tran On 25.06.2012 17:45, Hena Das wrote: I am doing a scf calculation for a particular non-collinear spin configuration. A am using LDA+U method. When I use the following case.inorb and case.indmc files: case.inorb 1 3 0 nmod, natorb, ipr PRATT 1.0BROYD/PRATT, mixing 1 1 3 2 1 3 3 1 2 1 nsic 0..AMF, 1..SIC, 2..HFM 0.65 0.07U J (Ry) 0.65 0.07 0.45 0.07 case.indmc -9. Emin cutoff energy 3 number of atoms for which density matrix is calculated 1 1 3 index of 1st atom, number of L's, L1 2 1 3 dtto for 2nd atom, repeat NATOM times 3 1 2 index of 1st atom, number of L's, L1 0 0 r-index, (l,s)index the program executes properly without any error. However when I use the other set of case.inorb and case.indmc files: case.inorb 1 3 0 nmod, natorb, ipr PRATT 1.0BROYD/PRATT, mixing
[Wien] optics calculation with spin orbit coupling
Dear Wien2k users and Prof. Blaha I am trying to calculate magneto-optical properties of some 3d transition metal. For this purpose we need to do spin orbit coupling calculation first. For normal optics calculation with spin-polarization option we need to do addjoint_lapw to join case.outputjoint(up/dn) and form case.joint file. Then we proceed with x kram My confusion is do we need to do addjoint_lapw also for spin polarized spin-orbit coupling case since the spins are not independent any more. any clarification will be very helpful. Thanks and regards -- Soumyajyoti Haldar, PhD Student Department of Physics and Astronomy, Materials Theory ?ngstr?m Laboratory, Office ?13235 | Uppsala University Box 516, SE-75120, Uppsala, SWEDEN Phone: (+46) 18 471 5860 Mobile: (+46) 070 0399 394 http://www.physics.uu.se/en/page/soumyajyoti-haldar -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120628/e40dfe9d/attachment.htm
[Wien] Problem with wien2k 11
You have to read the mailing list and search it for such problems. It was addressed several time recently: Most likely (unless you do something else wrong) it is the version of ifort. As far as we know, the last stable release is: composerxe-2011.3.174 More recent versions are all more or less wrong when using the mkl. Am 28.06.2012 16:42, schrieb Jameson Maibam: Dear Prof. Blaha, I have installed wien2k11 in my dell core2duo laptop with composer xe 11 update 9 (l_fcompxe_intel64_2011.11.339_1).I can sucessfully run TiC, VC, ScC and similar compounds in fcc structure. But when I tried to calculate ZrO2 in monoclinic structure I got the following error: ZrO2 problem Calculating ZrO2 in /home/james/ZrO2 on localhost.localdomain with PID 8700 using WIEN2k_11.1 (Release 14/6/2011) in /home/james/wien2k start (Thu Jun 28 14:24:27 IST 2012) with lapw0 (40/99 to go) cycle 1 (Thu Jun 28 14:24:27 IST 2012) (40/99 to go) lapw0 (14:24:27) 5.979u 0.380s 0:06.37 99.6% 0+0k 0+6320io 0pf+0w lapw1 (14:24:34) Abort (core dumped) 2.369u 0.289s 0:03.73 70.7% 0+0k 1688+5168io 9pf+0w error: command /home/james/wien2k/lapw1 lapw1.def failed stop error In another case I installed wien2k11 in my hp corei3 with composer xe 11.9.2011. In this case even TiC is unable to run. The following message came: LAPW0 END forrtl: severe (174): SIGSEGV, segmentation fault occurred stop error Please help me to get me out of these problems. Yours sincerely Jameson Maibam ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Peter Blaha Inst.Materials Chemistry TU Vienna Getreidemarkt 9 A-1060 Vienna Austria +43-1-5880115671
[Wien] Runtime Error
What I just ansfered in a different thread also holds for your problem. Am 28.06.2012 10:46, schrieb Debojyoti Mukherjee: Dear Wien2k Users, I am using Ubuntu operating system with Intel Fortran compiler to compile wien2k. The compilation showed no error; but at the time of running the code I am finding the following error: hup: Command not found. LAPW0 END *** glibc detected *** /home/debojyoti/Software/wien2k/lapw1: munmap_chunk(): invalid pointer: 0x09709f88 *** === Backtrace: = /lib/i386-linux-gnu/libc.so.6(+0x73e42)[0x40de4e42] /lib/i386-linux-gnu/libc.so.6(+0x74525)[0x40de5525] /home/debojyoti/Software/wien2k/lapw1[0x80d04f2] /home/debojyoti/Software/wien2k/lapw1[0x8082d54] /home/debojyoti/Software/wien2k/lapw1[0x80939a5] /home/debojyoti/Software/wien2k/lapw1[0x807ca21] /home/debojyoti/Software/wien2k/lapw1[0x804b0c4] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x40d8a4d3] === Memory map: 08048000-08193000 r-xp 08:06 7744711 /home/debojyoti/Software/wien2k/lapw1 08193000-0819b000 rw-p 0014a000 08:06 7744711 /home/debojyoti/Software/wien2k/lapw1 0819b000-0840b000 rw-p 00:00 0 094de000-097a rw-p 00:00 0 [heap] 4000-4002 r-xp 08:06 7078795 /lib/i386-linux-gnu/ld-2.15.so http://ld-2.15.so 4002-40021000 r--p 0001f000 08:06 7078795 /lib/i386-linux-gnu/ld-2.15.so http://ld-2.15.so 40021000-40022000 rw-p 0002 08:06 7078795 /lib/i386-linux-gnu/ld-2.15.so http://ld-2.15.so 40022000-40023000 r-xp 00:00 0 [vdso] 40023000-40025000 rw-p 00:00 0 40025000-40371000 r-xp 08:06 7350966 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_intel.so 40371000-40378000 rw-p 0034b000 08:06 7350966 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_intel.so 40378000-4037d000 rw-p 00:00 0 4037d000-40529000 r-xp 08:06 7351033 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_sequential.so 40529000-4052d000 rw-p 001ac000 08:06 7351033 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_sequential.so 4052d000-40cff000 r-xp 08:06 7348996 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_core.so 40cff000-40d08000 rw-p 007d2000 08:06 7348996 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_core.so 40d08000-40d13000 rw-p 00:00 0 40d24000-40d4e000 r-xp 08:06 7078847 /lib/i386-linux-gnu/libm-2.15.so http://libm-2.15.so 40d4e000-40d4f000 r--p 00029000 08:06 7078847 /lib/i386-linux-gnu/libm-2.15.so http://libm-2.15.so 40d4f000-40d5 rw-p 0002a000 08:06 7078847 /lib/i386-linux-gnu/libm-2.15.so http://libm-2.15.so 40d5-40d67000 r-xp 08:06 7078895 /lib/i386-linux-gnu/libpthread-2.15.so http://libpthread-2.15.so 40d67000-40d68000 r--p 00016000 08:06 7078895 /lib/i386-linux-gnu/libpthread-2.15.so http://libpthread-2.15.so 40d68000-40d69000 rw-p 00017000 08:06 7078895 /lib/i386-linux-gnu/libpthread-2.15.so http://libpthread-2.15.so 40d69000-40d6b000 rw-p 00:00 0 40d6b000-40d6e000 r-xp 08:06 7078828 /lib/i386-linux-gnu/libdl-2.15.so http://libdl-2.15.so 40d6e000-40d6f000 r--p 2000 08:06 7078828 /lib/i386-linux-gnu/libdl-2.15.so http://libdl-2.15.so 40d6f000-40d7 rw-p 3000 08:06 7078828 /lib/i386-linux-gnu/libdl-2.15.so http://libdl-2.15.so 40d7-40d71000 rw-p 00:00 0 40d71000-40f1 r-xp 08:06 7078815 /lib/i386-linux-gnu/libc-2.15.so http://libc-2.15.so 40f1-40f12000 r--p 0019f000 08:06 7078815 /lib/i386-linux-gnu/libc-2.15.so http://libc-2.15.so 40f12000-40f13000 rw-p 001a1000 08:06 7078815 /lib/i386-linux-gnu/libc-2.15.so http://libc-2.15.so 40f13000-40f16000 rw-p 00:00 0 40f16000-40f32000 r-xp 08:06 7078836 /lib/i386-linux-gnu/libgcc_s.so.1 40f32000-40f33000 r--p 0001b000 08:06 7078836 /lib/i386-linux-gnu/libgcc_s.so.1 40f33000-40f34000 rw-p 0001c000 08:06 7078836 /lib/i386-linux-gnu/libgcc_s.so.1 40f34000-40f35000 rw-p 00:00 0 40f35000-416ac000 r-xp 08:06 7351127 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_vml_p4m3.so 416ac000-416bc000 rw-p 00777000 08:06 7351127 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_vml_p4m3.so 416bc000-416bd000 rw-p 00:00 0 417a6000-4188f000 rw-p 00:00 0 41df3000-433d9000 r-xp 08:06 7350997 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_p4m3.so 433d9000-43447000 rw-p 015e6000 08:06 7350997 /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_p4m3.so 43447000-43449000 rw-p 00:00 0 bfd11000-bfd34000 rw-p 00:00 0 [stack] stop error Can anybody tell me where is the error and how to get rid of this problem? Thanks in advenced. --Debojyoti Mukherjee-- -- Scientific Officer - D, Applied Physics Division, Bhabha Atomic Research Center, Mumbai - 400085, India.
[Wien] optics calculation with spin orbit coupling
No, you don't need addjoint. Am 28.06.2012 19:27, schrieb soumyajyoti haldar: Dear Wien2k users and Prof. Blaha I am trying to calculate magneto-optical properties of some 3d transition metal. For this purpose we need to do spin orbit coupling calculation first. For normal optics calculation with spin-polarization option we need to do addjoint_lapw to join case.outputjoint(up/dn) and form case.joint file. Then we proceed with x kram My confusion is do we need to do addjoint_lapw also for spin polarized spin-orbit coupling case since the spins are not independent any more. any clarification will be very helpful. Thanks and regards -- Soumyajyoti Haldar, PhD Student Department of Physics and Astronomy, Materials Theory ?ngstr?m Laboratory, Office ?13235 | Uppsala University Box 516, SE-75120, Uppsala, SWEDEN Phone: (+46) 18 471 5860 Mobile: (+46) 070 0399 394 http://www.physics.uu.se/en/page/soumyajyoti-haldar ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Peter Blaha Inst.Materials Chemistry TU Vienna Getreidemarkt 9 A-1060 Vienna Austria +43-1-5880115671
[Wien] Fw: Is there any relationship between DOS(E_F) and conductivity?
Hello Dr. Validimir Timoshevskiiand Dr. Gerhard H. Fecher I do really thank you for your nice answers. best regards, Saeid - Forwarded Message - From: Vladimir Timochevski vladi...@physics.mcgill.ca To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Sent: Thursday, June 28, 2012 7:34 PM Subject: Re: [Wien] Is there any relationship between DOS(E_F) and conductivity? Hello S. Pourmasoud, To calculate conductivity (in a bandstructure approach), you also need to know how many electronic states have non-zero momentum in your transport direction (in simple words ...). In other words, you need to calculate the Fermi surface projection on the plane, normal to your transport direction. Therefore, as Gerhard noticed, conductance also depends on details of electronic structure - Fermi surface topology. You can check this ref on how to use this approach to calculate transport properties: Phys. Rev. B 57, 8907 (1998). Vladimir. === Dr. Vladimir Timoshevskii (Timochevski) Department of Physics, McGill University, 3600 rue University, Montreal, QC Canada H3A 2T8 Tel: +1 (514) 396-8935 Fax: +1 (514) 398-8434 === On 06/28/12 05:04, Fecher, Gerhard wrote: Fast answer: compare Fe and Cu and you have it. The conductivity depends not only on the DOS at Ef but also on the setails of the bandstructure. There is no way to compare whether Sodium, Copper, or Gold are more metallic or not. 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 vonquot;saeid pourmasoud [sa_pourmasoud2007 at yahoo.com] Gesendet: Donnerstag, 28. Juni 2012 06:45 An: wien at zeus.theochem.tuwien.ac.at Betreff: [Wien] Is there any relationship between DOS(E_F) and conductivity? Dear All, We are working on two different metallic compounds. I have calculated total DOS at Fermi level, DOS(E_F), for these two compounds. Our result shows that the DOS(E_F) of the first compound is larger than the? DOS(E_F) of the second compound. Can I conclude from this observation that the first compound is more metallic than the second compound? Can we compare conductivity of these two compounds using their total DOS values at Fermi levels? Can you cite a reference in this respect? Best regards, S. Pourmasoud ___ 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 -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120628/2d2916bd/attachment-0001.htm
[Wien] (no subject)
http://www.stanekstanek.pl/tkpofh.html -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120628/86a00038/attachment.htm
[Wien] spin and orbital moments
1) In which coordinate system are SPI005 and ORB005 given? In Appendix C (http://www.wien2k.at/reg_user/textbooks/) of New notes about Hyperfinefield calculations (ps), it mentions that the subroutine /couplx/ (of lapwdm) now calculates matrices of all components of spin and orbital momentum in the crystal coordinate system (sx,sy,sz,lx,ly,lz). Therefore, *I believe the x, y, and z values of SPIxxx and ORBxxx are also in the crystal coordinate system (CCS), while the M values (PROJECTION ON M values) are parallel to the magnetization. * If your good with reading fortan, you can look into the code. I don't full understand what is going on in the code, but I believe the direction to M (in your case: 1 1 -1) specified in case.inso is read in SRC_lapwdm/lapwdm.f. Then, the angles theta and phi between the direction to M and CCS are calculated in SRC_lapwdm/angle.f. Next, the x, y, and z values of SPIxxx and ORBxxx are calculated in the CCS. The x, y, and z values are written to case.outputdm(up/dn) and case.scfdm(up/dn), while a Cartesian to spherical equation [r = sin(theta)*(cos(phi)*x+sin(phi)y)+cos(theta)*z] is used to calculate the radius (M) using the x, y, and z, theta, and phi values before writing to the same output files as performed by SRC_lapwdm/output.f. 2) Why for the first iteration MMI005 is not even roughly equal to SPI005 + ORB005? SPIxxx is the spin moment calculated from selected electrons only (usually d or f). MMIxxx is the sum from all electrons (s, p, d and f states) inside the atomic sphere xxx. ORBxxx is the orbital magnetic moment. So*MMIxxx = SPIxxx + ORBxxx is not necessarily true.* See the reference links below for more information: http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-September/015296.html http://zeus.theochem.tuwien.ac.at/pipermail/wien/2008-April/010820.html http://zeus.theochem.tuwien.ac.at/pipermail/wien/2005-January/004399.html On 6/28/2012 9:18 AM, Kateryna Foyevtsova wrote: Dear Wien2k developers, I use wien2k version 11.1 to run spin-polarized GGA+U calculations with SO coupling for a molibdenum oxide. The symmetry of the system is the following bleblebles-o calc. M|| 1.00 1.00 -1.00 P 15 2 P- RELA 13.669712 13.669712 13.669712 60.00 60.00 60.00 As you see, I set magnetization axis to 1 1 -1, which should be in terms of (non-orthogonal) lattice vectors. With the help of xcrysden and case.outsymso, I can deduce that this direction corresponds to the 0.577350, 0.816497, 0 direction in terms of the cartesian global coordinate system. When I converge the electron density with (without using any previously converged non-relativistic calculation) runsp_lapw -p -orb -so -dm I get the following data for the first and the last iteration on one of the Mo atoms: 1. iteration: :SPI005: SPIN MOMENT: 0.46560 0.80642 -0.53749 PROJECTION ON M 1.07518 :ORB005: ORBITAL MOMENT: -0.08361 -0.01872 0.02851 PROJECTION ON M -0.06454 :MMI005: MAGNETIC MOMENT IN SPHERE 5=1.86180 last iteration (converged solution): :SPI005: SPIN MOMENT: 0.61653 1.06239 -0.70860 PROJECTION ON M 1.41804 :ORB005: ORBITAL MOMENT: -0.08361 -0.01872 0.02851 PROJECTION ON M -0.06454 :MMI005: MAGNETIC MOMENT IN SPHERE 5=1.43149 Now, I am struggling to understand two things: 1) In which coordinate system are SPI005 and ORB005 given? If they were given in the global cartesian coordinate system, they would be parallel to 0.577350, 0.816497, 0, but they are not. 2) Why for the first iteration MMI005 is not even roughly equal to SPI005 + ORB005? Thank you very much! Kateryna Foyevtsova P.S. When I perform relativistic calculations starting with a preconverged electron density of the non-relativistic solution I get the same final result. ___ 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/20120628/8766850e/attachment.htm
