[Wien] mbj of Diamond
This is getting stranger and stranger. So the "print" in itself does not cause the crash, nor do any of the values that are to be printed. That only leaves the tau, ir and iint of the "if" clause. What happens if you try to print those ? tau is probably harmless, as it appears in several comparisons before the one on line 46/47, iint has little chance to get corrupted as well, but maybe we enter brl() with an invalid "ir" parameter. (rho is above 10.d0, so the two preceding "if" statements could be decided without checking ir, so this will be the first time that ir is used). -- 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 of Diamond
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_falsch iint=iint+1 endif and the result is: tau= 15534.6272805818 tauw= 15534.6272805818 iint= 0 forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLineSource 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_falsch iint=iint+1 endif and the result is: forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLineSource 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_falsc 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_falsc h isphere=1 endif The result is: forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PCRoutineLineSource 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 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: Monday, October 25, 2010 1:48 AM >To: wien at zeus.theochem.tuwien.ac.at >Subject: *** SPAM *** [5.7] [Wien] mbj of Diamond > >This is getting stranger and stranger. So the "print" in itself does not >cause the crash, nor do any of the values that are to be printed. >That only leaves the tau, ir and iint of the "if" clause. >What happens if you try to print those ? tau is probably harmless, as >it appears in several comparisons before the one on line 46/47, iint has >little chance to get corrupted as well, but maybe we enter brl() with an >invalid "ir" parameter. (rho is above 10.d0, so the two preceding "if" >statements could be decided without checking ir, so this will be the >first time that ir is used). >-- >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
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
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_falsch > iint=iint+1 > endif > > and the result is: > > tau= 15534.6272805818 tauw= 15534.6272805818 iint= 0 > forrtl: severe (174): SIGSEGV, segmentation fault occurred > Image PCRoutineLineSource > > 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_falsch > iint=iint+1 > endif > > and the result is: > forrtl: severe (174): SIGSEGV, segmentation fault occurred > Image PCRoutineLineSource > > 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_falsc > 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_falsc > h > isphere=1 > endif > > The result is: > forrtl: severe (174): SIGSEGV, segmentation fault occurred > Image PCRoutineLineSource > > 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 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: Monday, October 25, 2010 1:48 AM >> To: wien at zeus.theochem.tuwien.ac.at >> Subject: *** SPAM *** [5.7] [Wien] mbj of Diamond >> >> This is getting stranger and stranger. So the "print" in itself does not >> cause the crash, nor do any of the values that are to be printed. >> That only leaves the tau, ir and iint of the "if" clause. >> What happens if you try to print those ? tau is probably harmless, as >> it appears in several comparisons before the one on line 46/47, iint has >> little chance to get corrupted as well, but maybe we enter brl() with an >> invalid "ir" parameter. (rho is above 10.d0, so the two preceding "if" >> statements could be decided without checking ir, so this will be the >> first time that ir is used). >> -- >> 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 mailing list > Wien at zeus.theochem.tuwien.ac.at > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien --
[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')
4/gcc/x86_64-suse-linux/4.1.2/../../../../lib64/crti.o > /usr/lib64/gcc/x86_64-suse-linux/4.1.2/crtbegin.o > /opt/intel//fce/10.1.015/lib/for_main.o 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 -lguide -lpthread -lmkl_em64t > -lmkl_core -lmkl_sequential -liomp5 -lmkl_lapack -lguide -lifport > -lifcore -limf -lsvml -lm -lipgo -lintlc -lc -lgcc_s -lgcc -lirc_s > -ldl -lc /usr/lib64/gcc/x86_64-suse-linux/4.1.2/crtend.o > /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib64/crtn.o > /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib64/libdl.a(dlsym.o): > In function `dlsym': > (.text+0x5): undefined reference to `__dlsym' > rm /tmp/ifortYTJCRSlibgcc > > rm /tmp/ifortqK1kBAgnudirs > > rm /tmp/ifortvgIp5Ztxt > > rm /tmp/ifortYZdtPHtxt > > rm /tmp/ifortG56wzplst > > rm /tmp/ifortfWfBj7sdata > > rm /tmp/ifortmztF3Oscript > > rm /tmp/ipo_ifortqevmli.o > > rm /tmp/ifortcn9JNwgas > > rm /tmp/ifortdzFyyeas_.s > > rm /tmp/ifortNx4njWld_v > > rm /tmp/ifortEtmJ4Dldashv > > rm /tmp/ifortd2cHQlgnudirs > > rm /tmp/ifortotVAD3arg > = > > So as we can see, there are 2 main commands - fortcom and ld (paths > with double slashes '//' seem to be work correctly). I tried to run > them manually in $WIENROOT/SRC_lapw0 directory. The first one > completed successfully, but the second command failed. Surprisingly, > that when I removed *-ldl* flag (which finds 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 :+9
[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)
[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 >>> >pri
[Wien] MAE of Co hcp
__ >>Wien mailing list >>Wien at zeus.theochem.tuwien.ac.at > 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.at <mailto:blaha at >> theochem.tuwien.ac.at> >>WWW: http://info.tuwien.ac.at/theochem/ >> >> -- >>___ >>Wien mailing list >>Wien at zeus.theochem.tuwien.ac.at > 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 <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-bou
[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] necessary modification to brj.f90
Dear Mohammad, There were two problems on the mbj potential. One was originating from a large rho in the MT spheres at the nucleus of heavy elements , which had been fixed before: http://zeus.theochem.tuwien.ac.at/pipermail/wien/2010-June/013213.html The other recent problem originated form from a small rho in the interstitial region for a system with very week van der Waals interactions among light elements. This problem has been also fixed: http://zeus.theochem.tuwien.ac.at/pipermail/wien/2010-October/013808.html Please, find the attachment as the brj.f subroutine, which is compatible with current version of the code, v10.1. Good luck, 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 /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From: wien-boun...@zeus.theochem.tuwien.ac.at [mailto:wien-bounces at zeus.theochem.tuwien.ac.at] On Behalf Of Mohamad Monazam Sent: Monday, October 25, 2010 5:58 PM To: wien at zeus.theochem.tuwien.ac.at Subject: [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/365969f0/attachment.htm> -- next part -- A non-text attachment was scrubbed... Name: brj.f Type: application/octet-stream Size: 3650 bytes Desc: not available URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20101025/365969f0/attachment.dll>
[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 wrote: From: Gerhard Fecher Subject: Re: [Wien] spin orbit calculation (problem with Wien2k_10) To: "A Mailing list for WIEN2k users" 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]" im Auftrag von "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 To: A Mailing list for WIEN2k users 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.so<http://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 wrote: From: Peter Blaha Subject: Re: [Wien] spin orbit calculation To: "A Mailing list for WIEN2k users" 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 Cottenier? >> wrote: >> >> From: Stefaan Cottenier >> 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>
