[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] Gd5Si4 calculations freeze
The scf1 files look absolutely ok. However, previously you reported: the calculations freeze; now you report a: forrtl: severe (174): SIGSEGV, segmentation fault occurred Stack trace terminated abnormally. without any further debugging output. (Did you compile with -traceback ??) I'd suggest tocheck compilation run x kgen and use fewer k-points for debugging start another scf cycle and ckeck if the problem happens again. maybe a problem with an overloaded NFS-filesystem ? -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-15671 FAX: +43-1-58801-15698 Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ --
[Wien] WIEN2k_10.1 compilation problem (undefined reference to `__dlsym')
libdl.so/a), lapw0 was generated without any problems. Although the exec was built, I don't know if it's correct or no. Is libdl library necessary for all WIEN2k executables? Or maybe linker cache isn't correct? Any ideas? Thanks, - Maxim 23.10.2010 12:35, Peter Blaha ?: To fix it I sourced mklvarsem64t.sh, so the $INCLUDE variable became Did you also source the corresponding file for the ifort compiler ? Am 22.10.2010 11:39, schrieb Maxim Rakitin: Dear WIEN2k experts, I tried to compile WIEN2k_10.1 on the cluster of my university (SuSE linux, Xeon 53XX processors), but I got an error during the process: usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib64/libdl.a(dlsym.o): In function `dlsym': (.text+0x5): undefined reference to `__dlsym' Here is a part of the compilation log of lapw0 (serial version): icc -c W2kutils.c ifort -FR -w -mp1 -prec-div -pad -ip -DINTEL_VML -O3 -xP -c W2kinit.F ifort -o lapw0 cputim.o modules.o reallocate.o ainv.o am05_xscss.o b88.o blyp.o brj.o charg2.o charg3.o charge.o chfac.o chslv.o corgga.o corpbe_revtpss.o corpbe_tpss.o cub_xc_back.o corlsd.o dfxhpbe.o dfxrevtpss.o dfxtpss.o drho.o dylm.o efg.o energy.o epot1.o eramps.o errclr.o errflg.o ev92.o ev92ex.o exch.o exch17.o fftw_para.o fithi.o fxhpbe.o fx_revtpss.o fx_tpss.o gbass.o gcor.o gea.o geaex.o getff1.o getfft.o gpoint.o gpointm.o grans.o gtfnam.o hcth.o ifflim.o kcis.o lapw0.o latgen.o multfc.o multsu.o outerr.o pbea.o pbem.o pbe1.o pbe2.o pbesol.o poissn.o potfac.o pwxad4.o pwxad5.o qranf.o readstruct.o rean0.o rean1.o rean3.o rean4.o rhopw.o rotate.o rotdef.o rpbe.o setff0.o setff1.o setfft.o setff2.o seval.o sevald.o sevaldd.o sevali.o sevalin.o sicpbe.o sicpbe_revtpss.o sicpbe_tpss.o sogga.o sphbes.o spline.o srolyl.o stern.o sumfac.o suml.o th1.o th2.o vpw91.o vresp.o vs98.o vxc15.o vxc16.o vxc17.o vxc24.o vxc26.o vxclm2.o vxcpw2.o vxi35.o vxi35a.o wc05.o workf1.o xcener.o xcpot.o xcpot1.o xcpot3.o ykav.o ylm.o zfft3d.o W2kutils.o W2kinit.o -FR -w -mp1 -prec-div -pad -ip -DINTEL_VML -O3 -xP -L/opt/intel/mkl/10.0.3.020/lib/em64t -lguide -lpthread -L/opt/intel/mkl/10.0.3.020/lib/em64t -lmkl_em64t -lmkl_core -lmkl_sequential -liomp5 -lmkl_lapack -lguide -lpthread It seems to me that the problem is connected with new routines W2k*, because when I compile the package without $INCLUDE wariable, I got the following error: fortcom: Error: W2kinit.F, line 28: Cannot open include file 'mkl_vml.fi' include 'mkl_vml.fi' ---^ To fix it I sourced mklvarsem64t.sh, so the $INCLUDE variable became available. But this produced the error in the beginning of this mail. I tried different combinations of input parameters (FOPT, FPOPT, etc), but this didn't help. FYI, in the previous versions of WIEN2k I haven't met such kind of problems. Could anyboby please help me to find where the problem came from? I really appreciate any help and advice. If you need additional information on my compilation options or cluster details, please let me know. Thanks a lot. -- Best regards, Maxim Rakitin Postgraduate student South Ural State University, 76 Lenin av., Chelyabinsk, Russia, 454080 Email:rms85 at physics.susu.ac.ru Web:http://www.susu.ac.ru ___ 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/20101025/23308328/attachment.htm
[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 at
[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] MAE of Co hcp
at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Bin Shao, Ph.D. Candidate College of Information Technical Science, Nankai University 94 Weijin Rd. Nankai Dist. Tianjin 300071, China Email: binshao1118 at gmail.com mailto:binshao1118 at gmail.com ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-15671 FAX: +43-1-58801-15698 Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien -- Bin Shao, Ph.D. Candidate College of Information Technical Science, Nankai University 94 Weijin Rd. Nankai Dist. Tianjin 300071, China Email: binshao1118 at gmail.com -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20101025/8752bbeb/attachment.htm
[Wien] *** SPAM *** [5.7] Re: mbj of Diamond
Dear Peter and Martin, Now, this is the end of evening here, and the time is apt to report to the mailinglist. The speed problem was due to our system. I am very pleased, to inform you that the mbj is now running at third cycles (up to now) on our case with no problem. We are eagerly waiting for the final result. Here, we are deeply thankful to Peter Blaha and Martin Kroker for their valuable contributions to this work. 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 Saeid Jalali Sent: Monday, October 25, 2010 1:42 PM To: 'A Mailing list for WIEN2k users' Subject: *** SPAM *** [5.7] Re: [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] necessary modification to brj.f90
Dear Saeid, What exactly needed to be changed in the brj.f90 to fixed the problem in mbj calculation. I had problem with mbj in parallel mode, you already reported, with my case and I hope this fixes it up. best regards, mohammad -- next part -- An HTML attachment was scrubbed... URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20101025/905d4205/attachment.htm
[Wien] spin orbit calculation (problem with Wien2k_10)
Thank you Dr Stefan in my calculation I tried NX=0 and delete NX1 then every thing is well thank you --- On Sun, 10/24/10, Gerhard Fecher fecher at uni-mainz.de wrote: From: Gerhard Fecher fec...@uni-mainz.de Subject: Re: [Wien] spin orbit calculation (problem with Wien2k_10) To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Date: Sunday, October 24, 2010, 11:26 PM why don't you give? numbers but NX or NX1 in youre .inso file ? 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;Mahmoud Farout [mq2021 at yahoo.com] Gesendet: Sonntag, 24. Oktober 2010 19:07 Bis: A Mailing list for WIEN2k users Betreff: Re: [Wien] spin orbit calculation (problem with Wien2k_10) every thing going well All Thanks to Dr Stefan and to any body like to help others From: Mahmoud Farout mq2...@yahoo.com To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Sent: Sun, October 24, 2010 5:49:37 PM Subject: Re: [Wien] spin orbit calculation (problem with Wien2k_10) I tried the Wien2k 10 the same error I face ???stop error lapwso? ? ? ? ? ???0804AE01? Unknown? ? ? ? ? ? ???Unknown? Unknown libc.sohttp://libc.so.6? ? ? ? ? 00B496D5? Unknown? ? ? ? ? ? ???Unknown? Unknown lapwso? ? ? ? ? ???0804AEF1? Unknown? ? ? ? ? ? ???Unknown? Unknown lapwso? ? ? ? ? ???08067847? Unknown? ? ? ? ? ? ???Unknown? Unknown lapwso? ? ? ? ? ???08062281? Unknown? ? ? ? ? ? ???Unknown? Unknown lapwso? ? ? ? ? ???080A023F? Unknown? ? ? ? ? ? ???Unknown? Unknown lapwso? ? ? ? ? ???080A1DAD? Unknown? ? ? ? ? ? ???Unknown? Unknown lapwso? ? ? ? ? ???0808CD8B? Unknown? ? ? ? ? ? ???Unknown? Unknown lapwso? ? ? ? ? ???0808D407? Unknown? ? ? ? ? ? ???Unknown? Unknown lapwso? ? ? ? ? ???080B7CEF? Unknown? ? ? ? ? ? ???Unknown? Unknown lapwso? ? ? ? ? ???080F6DD5? Unknown? ? ? ? ? ? ???Unknown? Unknown lapwso? ? ? ? ? ???080F7FDD? Unknown? ? ? ? ? ? ???Unknown? Unknown Image? ? ? ? ? ? ? PC? ? ? ? Routine ? ? ???Line? ? ? ? Source forrtl: severe (64): input conversion error, unit 5, file /root/WIEN2k/wien10_test/test2/test2.inso LAPW1 END LAPW1 END LAPW0 END the file is in attachments I just work with FCC structure so I make the direction of magnetization in the plane? 1? 1???1 my structure is FeN? ???FCC???it is a test of spin orbit calculation I fail till now , this is my first test --- On Sat, 10/23/10, Peter Blaha pblaha at theochem.tuwien.ac.at wrote: From: Peter Blaha pbl...@theochem.tuwien.ac.at Subject: Re: [Wien] spin orbit calculation To: A Mailing list for WIEN2k users wien at zeus.theochem.tuwien.ac.at Date: Saturday, October 23, 2010, 8:38 AM What about reading the UG ? The new version WIEN2k_10? has a initso, which does it for you automatically. Am 23.10.2010 08:36, schrieb Mahmoud Farout: in the file *.inso 1? ? 1? ???1? magnetization direction NX? ? number of atoms .. NX1? . NX , NX1 must be edited? If yes , help me, what are their format? Numbers or what? I am trying -so calculation first time using FeN ,FCC crystal On Fri Oct 22nd, 2010 10:00 PM IST Mahmoud Farout wrote: thank you but I don't understand you what did you mean by typo?? --- On Fri, 10/22/10, Stefaan CottenierStefaan.Cottenier at UGent.be? wrote: From: Stefaan CottenierStefaan.Cottenier at UGent.be Subject: Re: [Wien] WIEN(Spin orbit calculation) To: wien at zeus.theochem.tuwien.ac.at Date: Friday, October 22, 2010, 9:05 PM forrtl :severe(64) : input conversion error , unit 5, file ./root/./test_so.inso 'input conversion error' : probably a typo in case.inso ? Stefaan ___ 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 -- Peter Blaha Inst.Materials Chemistry TU Vienna Getreidemarkt 9 A-1060 Vienna Austria +43-1-5880115671 ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien ___ Wien 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/20101025/9cbf7565/attachment.htm
