[Wien] mbj on Diamond
Dear Prof. Klier, You would look for brj.f as a keyword in the mailinglist, where the problem (segmentation fault due to the ir) and its solution were discussed. You would either add ir to all calls in vxclm2.f, or just completely remove the ir from brj.f. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage:http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Kamil Klier Sent: Thursday, November 11, 2010 6:37 AM To: A Mailing list for WIEN2k users Subject: *** SPAM *** [5.8] Re: [Wien] mbj on Diamond Please correct the typo brj.j to brj.f. The query is not affected by this typographic slip. Quoting Kamil Klier kk04 at Lehigh.EDU: Dear Prof. Blaha, Your attached brj.j triggers the following error message after a crash in our CFN-BNL environment: *** LAPW0 END forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLine Source lapw0 0040A79E brj_ 37 brj.f lapw0 0047338D vxclm2_ 534 vxclm2.f lapw0 0047B565 xcpot1_ 365 xcpot1.f lapw0 004393FA MAIN__ 1696 lapw0.F lapw0 00403A1C Unknown Unknown Unknown libc.so.6 00370E01D994 Unknown Unknown Unknown lapw0 00403929 Unknown Unknown Unknown However, the file brj.j_current, which I am now attaching, does not crash in the same runs, although the covergence is very slow. This prompts the questions: Q1: What's wrong with the attached brj.f_current ? Q2: For my curiosity, what does the parameter ir do ? [I have attempted to trace it in vxclm2.f,also attached, where it is referenced, but the calls to BRJ do not include ,ir as you suggest] The runs involved are 128 atom supercells of ZnO with various dopants. The 'regular scf' converges well, the slow convergence occurs in the mBJ runs with option 28 in *in0 and 50 in *in0_grr, even though the PRATT option in *inm is used. I believe I have the latest version of WIEN2k, 10.2. Regards, Kamil Klier Quoting Peter Blaha pblaha at theochem.tuwien.ac.at: Hi, No, use the attached one. Note: it has one more parameter (ir), thus the calling in vxclm2.f should also be modified and ,ir should be added to all calls. Best regards Am 06.11.2010 14:59, schrieb Kamil Klier: Dear Prof. Blaha, Is the brj.f file referred to in this e-mail (attached as brj.f_new) one that should replace any previous brj.f files (for example, attached as brj.f_old)? Regards, Kamil Klier Quoting Peter Blaha pblaha at theochem.tuwien.ac.at: Hi, After I got the struct file, I could verify the problem. As expected, it is again in the SRC_lapw0/brj.f subroutine, where one has to find the root of a function. For strange densities this is numerically non-trivial. The problem at the nucleus of heavy elements was solved before, but here is the problem in the interstitial, when rho is very small and also grad-rho, tau and laplace-rho are sufficiently small. Then the required functions are nearly zero (lt. 10^-6) for a range of x=10-30; but using x=30 produces a V-xc potential of -100 Ry, which is the reason for your Eigenvalues below zero. When such problems occur again, please check also case.output0. The Fourier coefficients of Vxc must converge, i.e. (0 0 0) should be order one, while (0 0 30) should be order 10^-5 . The attached subroutine brj.f should fix these problems (at least your case converges smoothly). Dear All, We are performing the mbj calculations for a carbon based compound. According to the usersguide there are three SCF cycles for mbj calculations: first a regular calculations within LDA/GGA (we use the PBE-GGA here), second one more cycle run_lapw ?NI ?i 1 , and third the mbj run after changing the potential energy functional indxc=28 in case.in0 and index=50 in case.in0_grr. Here we call the regular SCF
[Wien] mbj on Diamond
Dear Prof. Blaha, Your attached brj.j triggers the following error message after a crash in our CFN-BNL environment: *** LAPW0 END forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLineSource lapw0 0040A79E brj_ 37 brj.f lapw0 0047338D vxclm2_ 534 vxclm2.f lapw0 0047B565 xcpot1_ 365 xcpot1.f lapw0 004393FA MAIN__ 1696 lapw0.F lapw0 00403A1C Unknown Unknown Unknown libc.so.6 00370E01D994 Unknown Unknown Unknown lapw0 00403929 Unknown Unknown Unknown However, the file brj.j_current, which I am now attaching, does not crash in the same runs, although the covergence is very slow. This prompts the questions: Q1: What's wrong with the attached brj.f_current ? Q2: For my curiosity, what does the parameter ir do ? [I have attempted to trace it in vxclm2.f,also attached, where it is referenced, but the calls to BRJ do not include ,ir as you suggest] The runs involved are 128 atom supercells of ZnO with various dopants. The 'regular scf' converges well, the slow convergence occurs in the mBJ runs with option 28 in *in0 and 50 in *in0_grr, even though the PRATT option in *inm is used. I believe I have the latest version of WIEN2k, 10.2. Regards, Kamil Klier Quoting Peter Blaha pblaha at theochem.tuwien.ac.at: Hi, No, use the attached one. Note: it has one more parameter (ir), thus the calling in vxclm2.f should also be modified and ,ir should be added to all calls. Best regards Am 06.11.2010 14:59, schrieb Kamil Klier: Dear Prof. Blaha, Is the brj.f file referred to in this e-mail (attached as brj.f_new) one that should replace any previous brj.f files (for example, attached as brj.f_old)? Regards, Kamil Klier Quoting Peter Blaha pblaha at theochem.tuwien.ac.at: Hi, After I got the struct file, I could verify the problem. As expected, it is again in the SRC_lapw0/brj.f subroutine, where one has to find the root of a function. For strange densities this is numerically non-trivial. The problem at the nucleus of heavy elements was solved before, but here is the problem in the interstitial, when rho is very small and also grad-rho, tau and laplace-rho are sufficiently small. Then the required functions are nearly zero (lt. 10^-6) for a range of x=10-30; but using x=30 produces a V-xc potential of -100 Ry, which is the reason for your Eigenvalues below zero. When such problems occur again, please check also case.output0. The Fourier coefficients of Vxc must converge, i.e. (0 0 0) should be order one, while (0 0 30) should be order 10^-5 . The attached subroutine brj.f should fix these problems (at least your case converges smoothly). Dear All, We are performing the mbj calculations for a carbon based compound. According to the usersguide there are three SCF cycles for mbj calculations: first a regular calculations within LDA/GGA (we use the PBE-GGA here), second one more cycle run_lapw ?NI ?i 1 , and third the mbj run after changing the potential energy functional indxc=28 in case.in0 and index=50 in case.in0_grr. Here we call the regular SCF cycles C1.scf, second one-more SCF cycle as C2.scf, and the third the mbj as cycle C3.scf. The first regular cycle and the second run_lapw ?NI ?i 1 are converged smoothly. However, the third mbj cycle is stopped at lapw2 in its second iteration. We analyzed the problem to find the source of the error. The result is given below, where the C2.scf line refers to the last :ITE of the second one more SCF cycle, and the C3.scf refers to the first :ITE of the third mbj run: C2.scf::NTO033: TOTAL CHARGE IN SPHERE 1 = 3.9781366 C3.scf::NTO033: TOTAL CHARGE IN SPHERE 1 = 2.4250427 C2.scf::CTO033: TOTAL CHARGE IN SPHERE 1 = 3.9781254 C3.scf::CTO033: TOTAL CHARGE IN SPHERE 1 = 3.9470631 C2.scf::DIS : CHARGE DISTANCE ( 0.355 for atom 33 spin 1) 0.136 C3.scf::DIS : CHARGE DISTANCE ( 1.8978668 for atom 25 spin 1) 1.5016586 C2.scf::NEC01: NUCLEAR AND ELECTRONIC CHARGE 366.0 365.98257 1.5 C3.scf::NEC01: NUCLEAR AND ELECTRONIC CHARGE 366.0 365.98171 1.5 C2.scf::FER : F E R M I - ENERGY(TETRAH.M.)= 0.21390 C3.scf::FER : F E R M I - ENERGY(TETRAH.M.)= -1.44751 The result clearly shows that there is a jump in :NTO, :DIS, and :FER (But in :CTO) after changing the functional to index=28. -- P.Blaha --
[Wien] mbj on Diamond
Hi, No, use the attached one. Note: it has one more parameter (ir), thus the calling in vxclm2.f should also be modified and ,ir should be added to all calls. Best regards Am 06.11.2010 14:59, schrieb Kamil Klier: Dear Prof. Blaha, Is the brj.f file referred to in this e-mail (attached as brj.f_new) one that should replace any previous brj.f files (for example, attached as brj.f_old)? Regards, Kamil Klier Quoting Peter Blaha pblaha at theochem.tuwien.ac.at: Hi, After I got the struct file, I could verify the problem. As expected, it is again in the SRC_lapw0/brj.f subroutine, where one has to find the root of a function. For strange densities this is numerically non-trivial. The problem at the nucleus of heavy elements was solved before, but here is the problem in the interstitial, when rho is very small and also grad-rho, tau and laplace-rho are sufficiently small. Then the required functions are nearly zero (lt. 10^-6) for a range of x=10-30; but using x=30 produces a V-xc potential of -100 Ry, which is the reason for your Eigenvalues below zero. When such problems occur again, please check also case.output0. The Fourier coefficients of Vxc must converge, i.e. (0 0 0) should be order one, while (0 0 30) should be order 10^-5 . The attached subroutine brj.f should fix these problems (at least your case converges smoothly). Dear All, We are performing the mbj calculations for a carbon based compound. According to the usersguide there are three SCF cycles for mbj calculations: first a regular calculations within LDA/GGA (we use the PBE-GGA here), second one more cycle run_lapw ?NI ?i 1 , and third the mbj run after changing the potential energy functional indxc=28 in case.in0 and index=50 in case.in0_grr. Here we call the regular SCF cycles C1.scf, second one-more SCF cycle as C2.scf, and the third the mbj as cycle C3.scf. The first regular cycle and the second run_lapw ?NI ?i 1 are converged smoothly. However, the third mbj cycle is stopped at lapw2 in its second iteration. We analyzed the problem to find the source of the error. The result is given below, where the C2.scf line refers to the last :ITE of the second one more SCF cycle, and the C3.scf refers to the first :ITE of the third mbj run: C2.scf::NTO033: TOTAL CHARGE IN SPHERE 1 = 3.9781366 C3.scf::NTO033: TOTAL CHARGE IN SPHERE 1 = 2.4250427 C2.scf::CTO033: TOTAL CHARGE IN SPHERE 1 = 3.9781254 C3.scf::CTO033: TOTAL CHARGE IN SPHERE 1 = 3.9470631 C2.scf::DIS : CHARGE DISTANCE ( 0.355 for atom 33 spin 1) 0.136 C3.scf::DIS : CHARGE DISTANCE ( 1.8978668 for atom 25 spin 1) 1.5016586 C2.scf::NEC01: NUCLEAR AND ELECTRONIC CHARGE 366.0 365.98257 1.5 C3.scf::NEC01: NUCLEAR AND ELECTRONIC CHARGE 366.0 365.98171 1.5 C2.scf::FER : F E R M I - ENERGY(TETRAH.M.)= 0.21390 C3.scf::FER : F E R M I - ENERGY(TETRAH.M.)= -1.44751 The result clearly shows that there is a jump in :NTO, :DIS, and :FER (But in :CTO) after changing the functional to index=28. -- 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.at WWW: http://info.tuwien.ac.at/theochem/ -- This message was sent using IMP, the Internet Messaging Program. ___ 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/ -- -- next part -- A non-text attachment was scrubbed... Name: brj.f Type: text/x-fortran Size: 3718 bytes Desc: not available URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20101108/773f9a89/attachment.f
[Wien] mbj on Diamond
I don't quite understand where the seg.faults come from mentioned recently. Anyway, the modified routine I sent out a few days ago is using a wrong bound for tau and thus leads to (slightly) incorrect results for most cases. Please use and test the attached one. Peter Blaha Am 15.10.2010 13:38, schrieb Peter Blaha: Hi, After I got the struct file, I could verify the problem. As expected, it is again in the SRC_lapw0/brj.f subroutine, where one has to find the root of a function. For strange densities this is numerically non-trivial. The problem at the nucleus of heavy elements was solved before, but here is the problem in the interstitial, when rho is very small and also grad-rho, tau and laplace-rho are sufficiently small. Then the required functions are nearly zero (lt. 10^-6) for a range of x=10-30; but using x=30 produces a V-xc potential of -100 Ry, which is the reason for your Eigenvalues below zero. When such problems occur again, please check also case.output0. The Fourier coefficients of Vxc must converge, i.e. (0 0 0) should be order one, while (0 0 30) should be order 10^-5 . The attached subroutine brj.f should fix these problems (at least your case converges smoothly). Dear All, We are performing the mbj calculations for a carbon based compound. According to the usersguide there are three SCF cycles for mbj calculations: first a regular calculations within LDA/GGA (we use the PBE-GGA here), second one more cycle run_lapw ?NI ?i 1 , and third the mbj run after changing the potential energy functional indxc=28 in case.in0 and index=50 in case.in0_grr. Here we call the regular SCF cycles C1.scf, second one-more SCF cycle as C2.scf, and the third the mbj as cycle C3.scf. The first regular cycle and the second run_lapw ?NI ?i 1 are converged smoothly. However, the third mbj cycle is stopped at lapw2 in its second iteration. We analyzed the problem to find the source of the error. The result is given below, where the C2.scf line refers to the last :ITE of the second one more SCF cycle, and the C3.scf refers to the first :ITE of the third mbj run: C2.scf::NTO033: TOTAL CHARGE IN SPHERE 1 = 3.9781366 C3.scf::NTO033: TOTAL CHARGE IN SPHERE 1 = 2.4250427 C2.scf::CTO033: TOTAL CHARGE IN SPHERE 1 = 3.9781254 C3.scf::CTO033: TOTAL CHARGE IN SPHERE 1 = 3.9470631 C2.scf::DIS : CHARGE DISTANCE ( 0.355 for atom 33 spin 1) 0.136 C3.scf::DIS : CHARGE DISTANCE ( 1.8978668 for atom 25 spin 1) 1.5016586 C2.scf::NEC01: NUCLEAR AND ELECTRONIC CHARGE 366.0 365.98257 1.5 C3.scf::NEC01: NUCLEAR AND ELECTRONIC CHARGE 366.0 365.98171 1.5 C2.scf::FER : F E R M I - ENERGY(TETRAH.M.)= 0.21390 C3.scf::FER : F E R M I - ENERGY(TETRAH.M.)= -1.44751 The result clearly shows that there is a jump in :NTO, :DIS, and :FER (But in :CTO) after changing the functional to index=28. ___ 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/ -- -- next part -- A non-text attachment was scrubbed... Name: brj.f Type: text/x-fortran Size: 3718 bytes Desc: not available URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20101025/5c3d464b/attachment.f
[Wien] mbj of Diamond
Dear Peter, Thank you for your reply and valuable comment. I replaced the latest brj.f. This time the segmentation fault occurred at line 103 of the brj.f. As soon as I received your following comment on ir, then I removed all the references to ir from the latest brj.f. I tested the diamond. I am pleased to inform you that the mbj works fine for the diamond now--all my thanks to you and Martin. Then I ran the mbj for our case. However, we have still trouble in running mbj for our cases: This is more than two hours that the lapw0 -grr is running for one of our case. I agree that our system is slow, and I do not have access to fast computer. But our computer could run the lapw0 -grr within 14 minutes employing the original mbj of the current v10.1 on the web for our one of cases. Is the lapw0 trapped in a loop in brj.f? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage:http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Peter Blaha Sent: Monday, October 25, 2010 9:25 AM To: A Mailing list for WIEN2k users Subject: *** SPAM *** [5.7] Re: [Wien] mbj of Diamond Sorry, again. I'm using a new WIEN2k version (not released yet) and the new brj.f is not compatible with the WIENM2k_10.1 version. Simply remove all references to ir (it is used only as guide for printing warnings). Regards Am 25.10.2010 07:09, schrieb Saeid Jalali: Dear Prof. Kroker, I could print the tau, tauw, and iint: print*,'tau=',tau,'tauw=',tauw,'iint=',iint if(tau.eq.tauw .and. ir.gt.900.and.iint.lt.10) then print*,'int:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_fals ch iint=iint+1 endif and the result is: tau= 15534.6272805818 tauw= 15534.6272805818 iint= 0 forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLine Source lapw0 0040ABA9 brj_ 48 brj.f ... Then, I tried to print ir as well: print*,'ir=',ir print*,'tau=',tau,'tauw=',tauw,'iint=',iint if(tau.eq.tauw .and. ir.gt.900.and.iint.lt.10) then print*,'int:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_fals ch iint=iint+1 endif and the result is: forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLine Source lapw0 0040A482 brj_ 36 brj.f The line 36 starts with an if clause: if(tau.eq.tauw .and. rho.lt.10.d0.and.ir.lt.900.and.isphere.eq.0) then print*,'sphere:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_f alsc h isphere=1 endif Then, I tried to print the ir before line 36: print*,'ir=',ir if(tau.eq.tauw .and. rho.lt.10.d0.and.ir.lt.900.and.isphere.eq.0) then print*,'sphere:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_f alsc h isphere=1 endif The result is: forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLine Source lapw0 0040A4D7 brj_ 35 brj.f So the error as you nicely expected comes from the ir. In the last brj.f subroutine the ir was not used: SUBROUTINE BRJ(RHO,GRHO,G2RHO,TAU,VXBRJ) !A. D. Becke and M. R. Roussel, Phys. Rev. A 39, 3761 (1989). !A. D. Becke and E. R. Johnson, J. Chem. Phys. 124, 221101 (2006). But, in the new brj.f subroutine the ir is used: SUBROUTINE BRJ(RHO,GRHO,G2RHO,TAU,VXBRJ,ir) !A. D. Becke and M. R. Roussel, Phys. Rev. A 39, 3761 (1989). !A. D. Becke and E. R. Johnson, J. Chem. Phys. 124, 221101 (2006). Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi
[Wien] mbj of Diamond
lapw0 -grr uses case.in0_grr and this should have option 50 Option 50 does not call subroutine brj Am 25.10.2010 11:30, schrieb Saeid Jalali: Dear Peter, Thank you for your reply and valuable comment. I replaced the latest brj.f. This time the segmentation fault occurred at line 103 of the brj.f. As soon as I received your following comment on ir, then I removed all the references to ir from the latest brj.f. I tested the diamond. I am pleased to inform you that the mbj works fine for the diamond now--all my thanks to you and Martin. Then I ran the mbj for our case. However, we have still trouble in running mbj for our cases: This is more than two hours that the lapw0 -grr is running for one of our case. I agree that our system is slow, and I do not have access to fast computer. But our computer could run the lapw0 -grr within 14 minutes employing the original mbj of the current v10.1 on the web for our one of cases. Is the lapw0 trapped in a loop in brj.f? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage:http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Peter Blaha Sent: Monday, October 25, 2010 9:25 AM To: A Mailing list for WIEN2k users Subject: *** SPAM *** [5.7] Re: [Wien] mbj of Diamond Sorry, again. I'm using a new WIEN2k version (not released yet) and the new brj.f is not compatible with the WIENM2k_10.1 version. Simply remove all references to ir (it is used only as guide for printing warnings). Regards Am 25.10.2010 07:09, schrieb Saeid Jalali: Dear Prof. Kroker, I could print the tau, tauw, and iint: print*,'tau=',tau,'tauw=',tauw,'iint=',iint if(tau.eq.tauw .and. ir.gt.900.and.iint.lt.10) then print*,'int:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_fals ch iint=iint+1 endif and the result is: tau= 15534.6272805818 tauw= 15534.6272805818 iint= 0 forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLine Source lapw0 0040ABA9 brj_ 48 brj.f ... Then, I tried to print ir as well: print*,'ir=',ir print*,'tau=',tau,'tauw=',tauw,'iint=',iint if(tau.eq.tauw .and. ir.gt.900.and.iint.lt.10) then print*,'int:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_fals ch iint=iint+1 endif and the result is: forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLine Source lapw0 0040A482 brj_ 36 brj.f The line 36 starts with an if clause: if(tau.eq.tauw .and. rho.lt.10.d0.and.ir.lt.900.and.isphere.eq.0) then print*,'sphere:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_f alsc h isphere=1 endif Then, I tried to print the ir before line 36: print*,'ir=',ir if(tau.eq.tauw .and. rho.lt.10.d0.and.ir.lt.900.and.isphere.eq.0) then print*,'sphere:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_f alsc h isphere=1 endif The result is: forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLine Source lapw0 0040A4D7 brj_ 35 brj.f So the error as you nicely expected comes from the ir. In the last brj.f subroutine the ir was not used: SUBROUTINE BRJ(RHO,GRHO,G2RHO,TAU,VXBRJ) !A. D. Becke and M. R. Roussel, Phys. Rev. A 39, 3761 (1989). !A. D. Becke and E. R. Johnson, J. Chem. Phys. 124, 221101 (2006). But, in the new brj.f subroutine the ir is used: SUBROUTINE BRJ(RHO,GRHO,G2RHO,TAU,VXBRJ,ir) !A. D. Becke and M. R. Roussel, Phys. Rev. A 39, 3761 (1989). !A. D. Becke and E. R. Johnson, J. Chem. Phys. 124, 221101 (2006). Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office
[Wien] mbj of Diamond
After 2.5 hours the lapw0 -grr has finished its work, and now lapw0 is running. Yes, we set the option to 50 in case.in0_grr: TOT 50(5...CA-LDA, 13...PBE-GGA, 11...WC-GGA) R2V IFFT (R2V) 144 144 1442.00min IFFT-parameters, enhancement factor And to 28 in case.in0 TOT 28(5...CA-LDA, 13...PBE-GGA, 11...WC-GGA) R2V IFFT (R2V) 144 144 1442.00min IFFT-parameters, enhancement factor If option 50 does not call brj, so your changes should not affect the speed. I will reboot our system to make sure about its free ram and swap memories and try again. I will report back the result at the end of this evening. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage:http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Peter Blaha Sent: Monday, October 25, 2010 1:12 PM To: A Mailing list for WIEN2k users Subject: *** SPAM *** [5.7] Re: [Wien] mbj of Diamond lapw0 -grr uses case.in0_grr and this should have option 50 Option 50 does not call subroutine brj Am 25.10.2010 11:30, schrieb Saeid Jalali: Dear Peter, Thank you for your reply and valuable comment. I replaced the latest brj.f. This time the segmentation fault occurred at line 103 of the brj.f. As soon as I received your following comment on ir, then I removed all the references to ir from the latest brj.f. I tested the diamond. I am pleased to inform you that the mbj works fine for the diamond now--all my thanks to you and Martin. Then I ran the mbj for our case. However, we have still trouble in running mbj for our cases: This is more than two hours that the lapw0 -grr is running for one of our case. I agree that our system is slow, and I do not have access to fast computer. But our computer could run the lapw0 -grr within 14 minutes employing the original mbj of the current v10.1 on the web for our one of cases. Is the lapw0 trapped in a loop in brj.f? Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage:http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Peter Blaha Sent: Monday, October 25, 2010 9:25 AM To: A Mailing list for WIEN2k users Subject: *** SPAM *** [5.7] Re: [Wien] mbj of Diamond Sorry, again. I'm using a new WIEN2k version (not released yet) and the new brj.f is not compatible with the WIENM2k_10.1 version. Simply remove all references to ir (it is used only as guide for printing warnings). Regards Am 25.10.2010 07:09, schrieb Saeid Jalali: Dear Prof. Kroker, I could print the tau, tauw, and iint: print*,'tau=',tau,'tauw=',tauw,'iint=',iint if(tau.eq.tauw .and. ir.gt.900.and.iint.lt.10) then print*,'int:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_fals ch iint=iint+1 endif and the result is: tau= 15534.6272805818 tauw= 15534.6272805818 iint= 0 forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLine Source lapw0 0040ABA9 brj_ 48 brj.f ... Then, I tried to print ir as well: print*,'ir=',ir print*,'tau=',tau,'tauw=',tauw,'iint=',iint if(tau.eq.tauw .and. ir.gt.900.and.iint.lt.10) then print*,'int:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_fals ch iint=iint+1 endif and the result is: forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLine Source lapw0
[Wien] mbj of Diamond
Dear Prof. Kroeker, Right before the line 47, where the problem is there, I let be printed values of the rho,tauw,grho,g2rho, tau_falsch quantities, as follows: print*,'int:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_falsch if(tau.eq.tauw .and. ir.gt.900.and.iint.lt.10) then print*,'int:rho,tauw,grho,g2rho',rho,tau,grho,g2rho,'tauwrong=',tau_falsch iint=iint+1 endif The results by running lapw0 are: int:rho,tauw,grho,g2rho 64.238976254813115534.6272805818 1997.92747916902 -24058013.7208862 tauwrong= -4250585.42208186 forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLineSource lapw0 0040ABB9 brj_ 47 brj.f ... As you would see they are nonzero numbers. You may know that the modified Becke-Johnson potential (mbj) potential, PRL 102, 226401 (2009), is a LDA+U-like or Hybrid-like method for treating with sp-compounds. LDA+U and hybride methods are proper for f- and d-compound. Within mbj method we can improve the band gap too. You would see section 4.5.8 of the v10.1 usersguide. Thank you for your friendly and valuable co-operation. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage:http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Martin Kroeker Sent: Sunday, October 24, 2010 3:33 PM To: wien at zeus.theochem.tuwien.ac.at Subject: *** SPAM *** [5.7] [Wien] mbj of Diamond But, again the segmentation fault error occurred at line 47 It was only a wild guess. So either one of the other values that are printed on line 46(47) contains an unprintable value, or - more likely - an array overflowed somewhere else and the memory management breaks down on the next attempt to allocate memory (internally in the print). Further analysis will probably require use of a debugger. (You could try commenting out the print call inside the if block, or separating it into individual print calls for the five variables, just to see if you get any further). -- Dr. Martin Kroekermartin at ruby.chemie.uni-freiburg.de c/o Prof.Dr. Caroline Roehr Institut fuer Anorganische und Analytische Chemie der Universitaet Freiburg ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] mbj on Diamond
Dear Peter, I compared it with the last original brj.f. You really made substantial changes. Thank you very much for your nice effort on brj.f. I recompiled the lapw0 replacing your new brj.f file. But, unfortunately, our case stopped at the first cycle with the following error in lapw0: ?LAPW0 END forrtl: severe (174): SIGSEGV, segmentation fault occurred Image? PC??? Routine??? Line??? Source lapw0? 0040AA28? brj_?? 46? brj.f lapw0? 00479D44? vxclm2_?? 534? vxclm2.f lapw0? 00482859? xcpot1_?? 365? xcpot1.f lapw0? 0043A7D7? MAIN__?? 1696? lapw0.F lapw0? 00403D3C? Unknown?? Unknown? Unknown libc.so.6? 00350A41EB1D? Unknown?? Unknown? Unknown lapw0? 00403C39? Unknown?? Unknown? Unknown We run the mbj for diamond, and found that the problem is not only for our case. It stops with the above error for any other simple cases. I again copied the old brj.f and recompile the lapw0, and fond that it works properly for the diamond and the other simple cases, but for our case. Any comments will be highly appreciated. Thank you again, With my best regards for you, Saeid. --- On Fri, 10/15/10, Peter Blaha pblaha at theochem.tuwien.ac.at wrote: From: Peter Blaha pbl...@theochem.tuwien.ac.at Subject: Re: [Wien] mbj on Diamond To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Date: Friday, October 15, 2010, 4:38 AM Hi, After I got the struct file, I could verify the problem. As expected, it is again in the SRC_lapw0/brj.f subroutine, where one has to find the root of a function. For strange densities this is numerically non-trivial. The problem at the nucleus of heavy elements was solved before, but here is the problem in the interstitial, when rho is very small and also grad-rho, tau and laplace-rho are sufficiently small. Then the required functions are nearly zero (lt. 10^-6) for a range of x=10-30; but using x=30 produces a V-xc potential of -100 Ry, which is the reason for your Eigenvalues below zero. When such problems occur again, please check also case.output0. The Fourier coefficients of Vxc must converge, i.e. (0 0 0) should be order one, while (0 0 30) should be order 10^-5 . The attached subroutine brj.f should fix these problems (at least your case converges smoothly). Dear All, We are performing the mbj calculations for a carbon based compound. According to the usersguide there are three SCF cycles for mbj calculations: first a regular calculations within LDA/GGA (we use the PBE-GGA here),? second one more cycle run_lapw ?NI ?i 1 , and third the mbj run after changing the potential energy functional indxc=28 in case.in0 and index=50 in case.in0_grr. Here we call the regular SCF cycles C1.scf, second one-more SCF cycle as C2.scf, and the third the mbj as cycle C3.scf. The first regular cycle and the second run_lapw ?NI ?i 1 are converged smoothly. However, the third mbj cycle is stopped at lapw2 in its second iteration. We analyzed the problem to find the source of the error. The result is given below, where the C2.scf line refers to the last :ITE of the second one more SCF cycle, and the C3.scf refers to the first :ITE of the third mbj run: C2.scf::NTO033: TOTAL???CHARGE IN SPHERE? 1 =? ? ? ? 3.9781366 C3.scf::NTO033: TOTAL???CHARGE IN SPHERE? 1 =? ? ? ? 2.4250427 C2.scf::CTO033: TOTAL???CHARGE IN SPHERE? 1 =? ? ? ? 3.9781254 C3.scf::CTO033: TOTAL???CHARGE IN SPHERE? 1 =? ? ? ? 3.9470631 C2.scf::DIS? :? CHARGE DISTANCE? ? ???( 0.355 for atom???33 spin 1)? ? ? 0.136 C3.scf::DIS? :? CHARGE DISTANCE? ? ???( 1.8978668 for atom???25 spin 1)? ? ? 1.5016586 C2.scf::NEC01: NUCLEAR AND ELECTRONIC CHARGE? ? 366.0???365.98257? ???1.5 C3.scf::NEC01: NUCLEAR AND ELECTRONIC CHARGE? ? 366.0???365.98171? ???1.5 C2.scf::FER? : F E R M I - ENERGY(TETRAH.M.)=???0.21390 C3.scf::FER? : F E R M I - ENERGY(TETRAH.M.)=? -1.44751 The result clearly shows that there is a jump in :NTO, :DIS, and :FER (But in :CTO) after changing the functional to index=28. -- ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 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.at? ? WWW: http://info.tuwien.ac.at/theochem/ -- -Inline Attachment Follows- ___ 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
[Wien] mbj on Diamond
I am probably not qualified to comment on what brj.f does, but I do notice that the segmentation fault in line 46 occurs on a line that tries to print tau_falsch when no value has ever been assigned to this variable. You could try inserting the line tau_falsch = 0D0 before the IF RHO.GT.1.D-18 block. -- Dr. Martin Kroekermartin at ruby.chemie.uni-freiburg.de c/o Prof.Dr. Caroline Roehr Institut fuer Anorganische und Analytische Chemie der Universitaet Freiburg
[Wien] mbj on Diamond
Hello Martin, I added the line tau_falsch = 0D0 right before the IF (RHO .GT. 1D-18) THEN in the brj.f subroutine as you would see below: SUBROUTINE BRJ(RHO,GRHO,G2RHO,TAU,VXBRJ,ir) !A. D. Becke and M. R. Roussel, Phys. Rev. A 39, 3761 (1989). !A. D. Becke and E. R. Johnson, J. Chem. Phys. 124, 221101 (2006). USE xcparam IMPLICIT REAL*8(A-H,O-Z) SAVE X,iint,isphere DATA X/0D0/,iint/0/,isphere/0/ PI = 4D0*DATAN(1D0) tau_falsch = 0D0 IF (RHO .GT. 1D-18) THEN ... But, again the segmentation fault error occurred at line 47: LAPW0 END forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLineSource lapw0 0040AA2D brj_ 47 brj.f lapw0 00479D34 vxclm2_ 534 vxclm2.f lapw0 00482849 xcpot1_ 365 xcpot1.f lapw0 0043A7C7 MAIN__ 1696 lapw0.F lapw0 00403D3C Unknown Unknown Unknown libc.so.6 00350A41EB1D Unknown Unknown Unknown lapw0 00403C39 Unknown Unknown Unknown The line 47 is exactly the last line, i.e. 46, as I inserted one additional line: if(tau.eq.tauw .and. ir.gt.900.and.iint.lt.10) then Thank you for your very friendly help, like your last valuable contribution on the last 32 and 64 bit problem. Kind regards, Saeid. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No. :+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage:http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -Original Message- From: wien-bounces at zeus.theochem.tuwien.ac.at [mailto:wien- bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Martin Kroeker Sent: Saturday, October 23, 2010 9:39 PM To: wien at zeus.theochem.tuwien.ac.at Subject: *** SPAM *** [5.7] [Wien] mbj on Diamond I am probably not qualified to comment on what brj.f does, but I do notice that the segmentation fault in line 46 occurs on a line that tries to print tau_falsch when no value has ever been assigned to this variable. You could try inserting the line tau_falsch = 0D0 before the IF RHO.GT.1.D-18 block. -- Dr. Martin Kroekermartin at ruby.chemie.uni-freiburg.de c/o Prof.Dr. Caroline Roehr Institut fuer Anorganische und Analytische Chemie der Universitaet Freiburg ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
[Wien] mbj on Diamond
Hi, After I got the struct file, I could verify the problem. As expected, it is again in the SRC_lapw0/brj.f subroutine, where one has to find the root of a function. For strange densities this is numerically non-trivial. The problem at the nucleus of heavy elements was solved before, but here is the problem in the interstitial, when rho is very small and also grad-rho, tau and laplace-rho are sufficiently small. Then the required functions are nearly zero (lt. 10^-6) for a range of x=10-30; but using x=30 produces a V-xc potential of -100 Ry, which is the reason for your Eigenvalues below zero. When such problems occur again, please check also case.output0. The Fourier coefficients of Vxc must converge, i.e. (0 0 0) should be order one, while (0 0 30) should be order 10^-5 . The attached subroutine brj.f should fix these problems (at least your case converges smoothly). Dear All, We are performing the mbj calculations for a carbon based compound. According to the usersguide there are three SCF cycles for mbj calculations: first a regular calculations within LDA/GGA (we use the PBE-GGA here), second one more cycle run_lapw ?NI ?i 1 , and third the mbj run after changing the potential energy functional indxc=28 in case.in0 and index=50 in case.in0_grr. Here we call the regular SCF cycles C1.scf, second one-more SCF cycle as C2.scf, and the third the mbj as cycle C3.scf. The first regular cycle and the second run_lapw ?NI ?i 1 are converged smoothly. However, the third mbj cycle is stopped at lapw2 in its second iteration. We analyzed the problem to find the source of the error. The result is given below, where the C2.scf line refers to the last :ITE of the second one more SCF cycle, and the C3.scf refers to the first :ITE of the third mbj run: C2.scf::NTO033: TOTAL CHARGE IN SPHERE 1 =3.9781366 C3.scf::NTO033: TOTAL CHARGE IN SPHERE 1 =2.4250427 C2.scf::CTO033: TOTAL CHARGE IN SPHERE 1 =3.9781254 C3.scf::CTO033: TOTAL CHARGE IN SPHERE 1 =3.9470631 C2.scf::DIS : CHARGE DISTANCE ( 0.355 for atom 33 spin 1) 0.136 C3.scf::DIS : CHARGE DISTANCE ( 1.8978668 for atom 25 spin 1) 1.5016586 C2.scf::NEC01: NUCLEAR AND ELECTRONIC CHARGE366.0 365.98257 1.5 C3.scf::NEC01: NUCLEAR AND ELECTRONIC CHARGE366.0 365.98171 1.5 C2.scf::FER : F E R M I - ENERGY(TETRAH.M.)= 0.21390 C3.scf::FER : F E R M I - ENERGY(TETRAH.M.)= -1.44751 The result clearly shows that there is a jump in :NTO, :DIS, and :FER (But in :CTO) after changing the functional to index=28. -- 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/ -- -- next part -- A non-text attachment was scrubbed... Name: brj.f Type: text/x-fortran Size: 3680 bytes Desc: not available URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20101015/f8063dbe/attachment.f
[Wien] mbj on Diamond
Yes, the purpose of the GGA calculation is just to produce necessary files and it does not matter which GGA is used and if this calculation is converged or not. On Sat, 9 Oct 2010, Saeid Jalali wrote: We calculated the band gap of diamond (as an example) within the mbj potential functional in two different procedures: In the first procedure, we exactly followed the steps discussed in the usersguide and found significant improvement on the band gap: In the second procedure, we before saving the regular GGA calculation executed the dstart program, i.e., x dstart, and then followed exactly the reaming steps as discussed in the usersguide. The band gap within the second procedure is exactly similar to the first procedure. This shows that (?) the regular calculation is just to produce necessary files and its converged results may not be very important (?) for the remaining mbj calculations. In this case, one may (?} only run the regular GGA calculation for one cycle, which can save efficiently the time for heavy cases. We ran the dstart to reproduce the starting charge density and as a result destroy the converged case.clmsum. In this case, we hope to avoid the jump in :DIS due to the new mbj potential indxc=28 compared to the :DIS in two last cycles of the regular calculations as discussed in my last unregarded contribution (maybe due to not enough information) to the mailing list. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No.:+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage :http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
[Wien] mbj on Diamond
We calculated the band gap of diamond (as an example) within the mbj potential functional in two different procedures: In the first procedure, we exactly followed the steps discussed in the usersguide and found significant improvement on the band gap: In the second procedure, we before saving the regular GGA calculation executed the dstart program, i.e., x dstart, and then followed exactly the reaming steps as discussed in the usersguide. The band gap within the second procedure is exactly similar to the first procedure. This shows that (?) the regular calculation is just to produce necessary files and its converged results may not be very important (?) for the remaining mbj calculations. In this case, one may (?} only run the regular GGA calculation for one cycle, which can save efficiently the time for heavy cases. We ran the dstart to reproduce the starting charge density and as a result destroy the converged case.clmsum. In this case, we hope to avoid the jump in :DIS due to the new mbj potential indxc=28 compared to the :DIS in two last cycles of the regular calculations as discussed in my last unregarded contribution (maybe due to not enough information) to the mailing list. Sincerely yours, S. Jalali /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Saeid Jalali Asadabadi, Department of Physics, Faculty of Science, University of Isfahan (UI), Hezar Gerib Avenue, 81744 Isfahan, Iran. Phones: Dep. of Phys. :+98-0311-793 2435 Office :+98-0311-793 4176 Fax No.:+98-0311-793 2409 E-mail :sjalali at phys.ui.ac.ir :sjalali at sci.ui.ac.ir :sjalali at mailaps.org :saeid.jalali.asadabadi at gmail.com :s_jalali_a at yahoo.com Homepage :http://sci.ui.ac.ir/~sjalali www :http://www.ui.ac.ir /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20101009/f3247c41/attachment.htm
