Re: [Wien] lapw0 hang with mbj calculation for slab
Switch to PBE for one iteration. Increase IFFTfactor from 2 to 4 in case.in0 (and, most likely, reduce RKMAX) Am 18.10.2013 05:55, schrieb alpa dashora: Dear Prof. Blaha and Wien2k users, I am trying to run mbj calculation for MoS2 10 layer slab. After few cycles lapw0 hanged. I have seen the earlier posts discussed on the same topics. I have used the vxclm2.f file as provided by Prof. Blaha and removed case.in0_grr file. I have also increased the Rmt*Kmax up to 9 but still I am not able to solve my problem. Please suggest any other solution for this error or any other method to calculate the correct band gap. Thanks in advance. With kind regards, -- Alpa Dashora ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- - Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pbl...@theochem.tuwien.ac.at - ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] lapw0 hang with mbj calculation for slab
Hi, Most likely the problem is due to the Newton iteration procedure in brj.f which does not stop. Replace this subroutine by the one that I attached (it is based on an analytical representation of the solution). By the way, it is nonsense to calculate the average of grad rho/rho when there is vacuum. So, fix the value of c to the one obtained for the bulk. F. Tran On Fri, 18 Oct 2013, alpa dashora wrote: Dear Prof. Blaha and Wien2k users, I am trying to run mbj calculation for MoS2 10 layer slab. After few cycles lapw0 hanged. I have seen the earlier posts discussed on the same topics. I have used the vxclm2.f file as provided by Prof. Blaha and removed case.in0_grr file. I have also increased the Rmt*Kmax up to 9 but still I am not able to solve my problem. Please suggest any other solution for this error or any other method to calculate the correct band gap. Thanks in advance. With kind regards, -- Alpa Dashora 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). !E. Proynov, Z. Gan, and J. Kong, Chem. Phys. Lett. 455, 103 (2008). use xcparam implicit real*8(a-h,o-z) real*8 :: a(1:3), b(0:5), c(0:5), d(0:5), e(0:5), yp(0:5) save iint,isphere data iint/0/,isphere/0/ pi = 4d0*atan(1d0) vxbrj = 0d0 if (rho .gt. 1d-18) then tautf = (3d0/10d0)*(3d0*pi**2)**(2d0/3d0)*(2d0*rho)**(5d0/3d0) tauw = 0.125d0*grho*grho*2.d0/rho if (tau.lt.tauw) then tau_falsch=tau tau=tauw endif 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_falsch isphere=1 endif 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 a(1) = 1.5255251812009530d0 a(2) = 0.4576575543602858d0 a(3) = 0.4292036732051034d0 c(0) = 0.7566445420735584d0 c(1) = -2.6363977871370960d0 c(2) = 5.4745159964232880d0 c(3) = -12.657308127108290d0 c(4) = 4.1250584725121360d0 c(5) = -30.425133957163840d0 b(0) = 0.4771976183772063d0 b(1) = -1.7799813494556270d0 b(2) = 3.8433841862302150d0 b(3) = -9.5912050880518490d0 b(4) = 2.1730180285916720d0 b(5) = -30.425133851603660d0 d(0) =0.4435009886795587d0 d(1) =0.58128653604457910d0 d(2) = 66.742764515940610d0 d(3) = 434.26780897229770d0 d(4) = 824.7765766052239000d0 d(5) = 1657.9652731582120d0 e(0) =0.3347285060926091d0 e(1) =0.47917931023971350d0 e(2) = 62.392268338574240d0 e(3) = 463.14816427938120d0 e(4) = 785.2360350104029000d0 e(5) = 1657.96296822327300d0 dd = tau - 0.25d0*grho**2/rho q = (g2rho - 1.6d0*dd)/6d0 if (abs(q) .gt. 1d-18) then y = (2d0/3d0)*pi**(2d0/3d0)*rho**(5d0/3d0)/q do i=0, 5 yp(i) = y**i enddo if (y .le. 0d0) then g = -atan(a(1)*y + a(2)) + a(3) p1 = sum(c(0:5)*yp(0:5)) p2 = sum(b(0:5)*yp(0:5)) elseif (y .gt. 0d0) then z = 2.085749716493756d0*y g = log(sqrt(1d0 + 1d0/z**2) + 1d0/z) + 2d0 p1 = sum(d(0:5)*yp(0:5)) p2 = sum(e(0:5)*yp(0:5)) endif if (abs(p2) .gt. 1d-18) then x = g*p1/p2 if (abs(x) .gt. 1d-18) then vxbrj = -2d0*pi**(1d0/3d0)*rho**(1d0/3d0)*exp(x/3d0)/x*(1d0 - exp(-x) - 0.5d0*x*exp(-x)) if (tau .ge. 0d0) then vxbrj = xcconst*vxbrj + (3d0*xcconst-2d0)*sqrt(5d0/12d0)/pi*sqrt(tau/rho) else vxbrj = xcconst*vxbrj - (3d0*xcconst-2d0)*sqrt(5d0/12d0)/pi*sqrt(abs(tau/rho)) endif endif endif endif endif return end ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] installation issues
Dear users and developers We are having problems with two of our systems, and couldn't figure out what is wrong. Even after checking the mailing list. 1- We couldn't plot our output using rhoplot, For example, when we try electron density plots for TiC, there was no visual. However, it works in some of our systems under the same condition. 2- When I try to copy/upload the original case struct file into a new directory for supercell calculations I got this msg Can't locate CGI.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /home/mohammed/WIEN2K/SRC_w2web/htdocs/util/upload2.pl line 3. BEGIN failed--compilation aborted at /home/mohammed/WIEN2K/SRC_w2web/htdocs/util/upload2.pl line 3. However, it works on one of our system. If there are any info that anybody may need to assist we will be grateful to provide. With best regards Mohammed lawal universiti Technologi Malaysia___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] installation issues
1- Is gnuplot installed on the non-working systems? Of note, it could be installed with sudo apt-get install gnuplot on older Ubuntu versions. However, I believe you have to use now sudo apt-get install gnuplot gnuplot-x11 on recent Ubuntu versions, since it seems that they decided to remove gnuplot-x11 as a dependency of gnuplot. 2- You likely need to install a missing Perl module. For example, for Fedora: https://ask.fedoraproject.org/question/8330/where-is-perl-module-cgipm-installed/ Since we don't know what operating systems you are using, you can search the Internet or your OS support (manual, forum, etc) on how to install these for your systems. On 10/18/2013 12:27 AM, Lawal Mohammed wrote: Dear users and developers We are having problems with two of our systems, and couldn't figure out what is wrong. Even after checking the mailing list. 1- We couldn't plot our output using rhoplot, For example, when we try electron density plots for TiC, there was no visual. However, it works in some of our systems under the same condition. 2- When I try to copy/upload the original case struct file into a new directory for supercell calculations I got this msg Can't locate CGI.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /home/mohammed/WIEN2K/SRC_w2web/htdocs/util/upload2.pl line 3. BEGIN failed--compilation aborted at /home/mohammed/WIEN2K/SRC_w2web/htdocs/util/upload2.pl line 3. However, it works on one of our system. If there are any info that anybody may need to assist we will be grateful to provide. With best regards Mohammed lawal universiti Technologi Malaysia ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Intel(R) Xeon(R) CPU X5550 @ 2.67GHz vs Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
First, thank Peter. I should have described my problem thoroughly. :RKM : MATRIX SIZE 9190LOs:1944 RKM= 4.88 WEIGHT= 2.00 PGR The reduced RKM is 4.88. The reduced matrix size is 9190 which is about 2/5 of the full matrix. So that explains a lot. I'm using P1 symmetry. Therefore, the complex veion of lapw1, lapw2 are used. Compared with LDA calculations, LSDA almost doubles lapw1 and lapw2. I'm using P1 symmetry. Therefore, symmetry cannot reduce the number of stars (i.e. planes waves) in the interstitial region or the number of spherical harmonics inside the muffin-tin sphere. I guess that's why my job takes so long. And moreover, I'm only using k-point parallel without mpi. Oxygen is the smallest atom in the unit cell. Reducing RKMAX to 6.5 is what I'm going to do first. One of the clusters to which I have access has 8 cores per node and 8GB memory per node. Given the constraint of memory, I wonder how to improve the core usage when calculating compounds with large unit cells. For the compound I'm currently working on, I request one core per node and 8 nodes(=nkp) per job. So 7*8=56 cores are wasted while running my job. I'm in dire need of help. Yundi On Oct 17, 2013, at 10:58 PM, Peter Blaha pbl...@theochem.tuwien.ac.at wrote: You still did not tell us the matrix size for the truncated RKmax, but yes, the scaling is probably ok. (scaling goes with n^3; i.e. in case of of matrix size 12000 and 24000 we expect almost a factor of 8 !!! in cpu time. It also explaines the memory You also did not tell us if you have inversion or not. One of my real cases with NMAT= 21500 takes 400 sec on 64 cores (mpi), so one could estimate something like 2 sec on a single core, which comes to the right order of magnitude compared to your case. And: you may have 72 inequivalent atoms, but you did not tell us how many atoms in total you have. The total number of atoms is the important info !! Probably you can reduce RKMAX (you did not tell us which atom has RMT=1.65 (probably O ??) and most likely you should use mpi AND iterative diagonalization. As I said, a case with 72 atoms (or whatever you have) can run in minutes on a reasonable cluster and with a proper optimized setup (not just the defaults). Am 17.10.2013 18:05, schrieb Yundi Quan: Thanks a lot. On cluster A, RKM was automatically reduced to 4.88 while on cluster B RKM was kept at 7. I didn't expect this, though I was aware that WIEN2k would automatically reduce RKM in some cases. But is it reasonable for an iteration to run for eight hours with the following parameters? Minimum sphere size: 1.65000 Bohr. Total k-mesh : 8 Gmax : 12 :RKM : MATRIX SIZE23486LOs:1944 RKM= 7.00 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE23486LOs:1944 RKM= 7.00 WEIGHT= 2.00 PGR: On Thu, Oct 17, 2013 at 8:54 AM, Peter Blaha pbl...@theochem.tuwien.ac.at mailto:pbl...@theochem.tuwien.ac.at wrote: The Xeon X5550 processor is a 4 core processor and your cluster may have combined a few of them on one node (2-4 ?) Anyway, 14 cores are not really possible ?? Have you done more than just looking on the total time ? Is the machines file the same on both clusters ? Such a machines file does NOT use mpi. One guess in case you really use mpi on cluster B (with a different .machines file): In the sequential run (A) the basis set is limited by NMATMAX, in the mpi-parallel run it is not (or it is scaled up by sqrt(N-core)). So it could be that run A has a MUCH smaller RKMAX than run (B). Check grep :RKM case.scf of the two runs. What are the real matrix sizes Alternatively, NMATMAX could be chosen differently on the two machines since somebody else installed WIEN2k. Please compare carefully the resulting case.output1_1 files and eventually send the RELEVANT PARTS OF THEM. In any case, a 72 atom cell should NOT take 2 h / iteration (or even 8 ??). What are your sphere sizes ???, what gives :RKM in case.scf ??? At least one can set OMP_NUM_THREAD=2 or 4 and speed up the code by a factor of almost 2. (You should see in the dayfile something close to 200 % instead of ~100% c1208-ib(1) 26558.265u 17.956s 7:34:14.39 97.5%0+0k 0+0io 0pf+0w In essence: A matrix size of 1 (real, with inversion) lapw1 should take in the order of 10 min (no mpi, maybe with OMP_NUM_THREAD=2) On 10/17/2013 04:33 PM, Yundi Quan wrote: Thanks for your reply. a). both machines are set up in a way that once a node is assigned to a job, it cannot be assigned to another. b). The .machines file looks like this 1:node1 1:node2 1:node3 1:node4 1:node5 1:node6 1:node7 1:node8 granularity:1 extrafine:1 lapw2_vector_split:1 I've been trying to avoid using mpi
Re: [Wien] Intel(R) Xeon(R) CPU X5550 @ 2.67GHz vs Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
As was mentioned before, such a big case needs mpi in order to run efficiently. As a quick small improvement set the OMP_NUM_THREAD variable to 2 or 4. This should give a speedup of about 2 and in the dayfile you should see that not 905% of the cpu was used, but 180% or so. On 10/18/2013 10:51 AM, Yundi Quan wrote: First, thank Peter. I should have described my problem thoroughly. :RKM : MATRIX SIZE 9190LOs:1944 RKM= 4.88 WEIGHT= 2.00 PGR The reduced RKM is 4.88. The reduced matrix size is 9190 which is about 2/5 of the full matrix. So that explains a lot. I'm using P1 symmetry. Therefore, the complex veion of lapw1, lapw2 are used. Compared with LDA calculations, LSDA almost doubles lapw1 and lapw2. I'm using P1 symmetry. Therefore, symmetry cannot reduce the number of stars (i.e. planes waves) in the interstitial region or the number of spherical harmonics inside the muffin-tin sphere. I guess that's why my job takes so long. And moreover, I'm only using k-point parallel without mpi. Oxygen is the smallest atom in the unit cell. Reducing RKMAX to 6.5 is what I'm going to do first. One of the clusters to which I have access has 8 cores per node and 8GB memory per node. Given the constraint of memory, I wonder how to improve the core usage when calculating compounds with large unit cells. For the compound I'm currently working on, I request one core per node and 8 nodes(=nkp) per job. So 7*8=56 cores are wasted while running my job. I'm in dire need of help. Yundi On Oct 17, 2013, at 10:58 PM, Peter Blaha pbl...@theochem.tuwien.ac.at wrote: You still did not tell us the matrix size for the truncated RKmax, but yes, the scaling is probably ok. (scaling goes with n^3; i.e. in case of of matrix size 12000 and 24000 we expect almost a factor of 8 !!! in cpu time. It also explaines the memory You also did not tell us if you have inversion or not. One of my real cases with NMAT= 21500 takes 400 sec on 64 cores (mpi), so one could estimate something like 2 sec on a single core, which comes to the right order of magnitude compared to your case. And: you may have 72 inequivalent atoms, but you did not tell us how many atoms in total you have. The total number of atoms is the important info !! Probably you can reduce RKMAX (you did not tell us which atom has RMT=1.65 (probably O ??) and most likely you should use mpi AND iterative diagonalization. As I said, a case with 72 atoms (or whatever you have) can run in minutes on a reasonable cluster and with a proper optimized setup (not just the defaults). Am 17.10.2013 18:05, schrieb Yundi Quan: Thanks a lot. On cluster A, RKM was automatically reduced to 4.88 while on cluster B RKM was kept at 7. I didn't expect this, though I was aware that WIEN2k would automatically reduce RKM in some cases. But is it reasonable for an iteration to run for eight hours with the following parameters? Minimum sphere size: 1.65000 Bohr. Total k-mesh : 8 Gmax : 12 :RKM : MATRIX SIZE23486LOs:1944 RKM= 7.00 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE23486LOs:1944 RKM= 7.00 WEIGHT= 2.00 PGR: On Thu, Oct 17, 2013 at 8:54 AM, Peter Blaha pbl...@theochem.tuwien.ac.at mailto:pbl...@theochem.tuwien.ac.at wrote: The Xeon X5550 processor is a 4 core processor and your cluster may have combined a few of them on one node (2-4 ?) Anyway, 14 cores are not really possible ?? Have you done more than just looking on the total time ? Is the machines file the same on both clusters ? Such a machines file does NOT use mpi. One guess in case you really use mpi on cluster B (with a different .machines file): In the sequential run (A) the basis set is limited by NMATMAX, in the mpi-parallel run it is not (or it is scaled up by sqrt(N-core)). So it could be that run A has a MUCH smaller RKMAX than run (B). Check grep :RKM case.scf of the two runs. What are the real matrix sizes Alternatively, NMATMAX could be chosen differently on the two machines since somebody else installed WIEN2k. Please compare carefully the resulting case.output1_1 files and eventually send the RELEVANT PARTS OF THEM. In any case, a 72 atom cell should NOT take 2 h / iteration (or even 8 ??). What are your sphere sizes ???, what gives :RKM in case.scf ??? At least one can set OMP_NUM_THREAD=2 or 4 and speed up the code by a factor of almost 2. (You should see in the dayfile something close to 200 % instead of ~100% c1208-ib(1) 26558.265u 17.956s 7:34:14.39 97.5%0+0k 0+0io 0pf+0w In essence: A matrix size of 1 (real, with inversion) lapw1 should take in the order of 10 min (no mpi, maybe with OMP_NUM_THREAD=2) On 10/17/2013 04:33 PM, Yundi Quan wrote: Thanks for your reply. a). both machines are set up in a way that once a node is assigned to a job, it cannot be assigned to another. b). The .machines file
Re: [Wien] lapw0 hang with mbj calculation for slab
Dear Prof. Blaha, Thanks for reply. I am unable to understand the reply. In only one iteration FFT factor should be 4 or for complete mbj cycle it should be same or again changed to 2. Should I remove case.in0_grr file? Please clear it. With regards, On Fri, Oct 18, 2013 at 11:30 AM, Peter Blaha pbl...@theochem.tuwien.ac.atwrote: Switch to PBE for one iteration. Increase IFFTfactor from 2 to 4 in case.in0 (and, most likely, reduce RKMAX) Am 18.10.2013 05:55, schrieb alpa dashora: Dear Prof. Blaha and Wien2k users, I am trying to run mbj calculation for MoS2 10 layer slab. After few cycles lapw0 hanged. I have seen the earlier posts discussed on the same topics. I have used the vxclm2.f file as provided by Prof. Blaha and removed case.in0_grr file. I have also increased the Rmt*Kmax up to 9 but still I am not able to solve my problem. Please suggest any other solution for this error or any other method to calculate the correct band gap. Thanks in advance. With kind regards, -- Alpa Dashora __**_ Wien mailing list w...@zeus.theochem.tuwien.ac.**at Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/** w...@zeus.theochem.tuwien.ac.**at/index.htmlhttp://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- --**--- Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pbl...@theochem.tuwien.ac.at --**--- __**_ Wien mailing list w...@zeus.theochem.tuwien.ac.**at Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wienhttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/** w...@zeus.theochem.tuwien.ac.**at/index.htmlhttp://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- Alpa Dashora ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] lapw0 hang with mbj calculation for slab
For mBJ it is ALWAYS a good idea to use a larger IFFTfactor (complete cycle). For a surface, case.in0_grr should not be present. However, you need a file case.grr (normally prepared when case.in0_grr is present). This file (or the corresponding avrg [(grad rho)/rho] value) should be taken from a corresponding bulk calculation. On 10/18/2013 12:37 PM, alpa dashora wrote: Dear Prof. Blaha, Thanks for reply. I am unable to understand the reply. In only one iteration FFT factor should be 4 or for complete mbj cycle it should be same or again changed to 2. Should I remove case.in0_grr file? Please clear it. With regards, On Fri, Oct 18, 2013 at 11:30 AM, Peter Blaha pbl...@theochem.tuwien.ac.at mailto:pbl...@theochem.tuwien.ac.at wrote: Switch to PBE for one iteration. Increase IFFTfactor from 2 to 4 in case.in0 (and, most likely, reduce RKMAX) Am 18.10.2013 05:55, schrieb alpa dashora: Dear Prof. Blaha and Wien2k users, I am trying to run mbj calculation for MoS2 10 layer slab. After few cycles lapw0 hanged. I have seen the earlier posts discussed on the same topics. I have used the vxclm2.f file as provided by Prof. Blaha and removed case.in0_grr file. I have also increased the Rmt*Kmax up to 9 but still I am not able to solve my problem. Please suggest any other solution for this error or any other method to calculate the correct band gap. Thanks in advance. With kind regards, -- Alpa Dashora _ Wien mailing list w...@zeus.theochem.tuwien.ac.__at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.__ac.at/mailman/listinfo/wien http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/__wien@zeus.theochem.tuwien.ac.__at/index.html http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- --__--- Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pbl...@theochem.tuwien.ac.at mailto:pbl...@theochem.tuwien.ac.at --__--- _ Wien mailing list w...@zeus.theochem.tuwien.ac.__at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.__ac.at/mailman/listinfo/wien http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/__wien@zeus.theochem.tuwien.ac.__at/index.html http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- Alpa Dashora ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] installation issues
Thank you so much Prof. Peter Blaha, Abo Gavin, ... The link you provided help. The issues are now resolved using two commands 1) yum install gnutplot gnuplot-x11 2) yum install perl-CGI in fedora 16 and18. Another issue, in this regard, I got this error /home/mohammed/WIEN2K/lapw0: error while loading shared libraries: libmkl_intel_lp64.so: cannot open shared object file: No such file or directory stop error while running scf, Chakrabarti Shamik suggested that it is because the path for the file (libmkl_intel_lp64.so) is not properly given during compilation of wien2k (during userconfig_lapw). If that is the case, can anybody please tell me how to set the path for that file properly. Thanking you all in advance for your response. Best regards. On Friday, October 18, 2013 3:30 PM, Gavin Abo gs...@crimson.ua.edu wrote: 1- Is gnuplot installed on the non-working systems? Of note, it could be installed with sudo apt-get install gnuplot on older Ubuntu versions. However, I believe you have to use now sudo apt-get install gnuplot gnuplot-x11 on recent Ubuntu versions, since it seems that they decided to remove gnuplot-x11 as a dependency of gnuplot. 2- You likely need to install a missing Perl module. For example, for Fedora: https://ask.fedoraproject.org/question/8330/where-is-perl-module-cgipm-installed/ Since we don't know what operating systems you are using, you can search the Internet or your OS support (manual, forum, etc) on how to install these for your systems. On 10/18/2013 12:27 AM, Lawal Mohammed wrote: Dear users and developers We are having problems with two of our systems, and couldn't figure out what is wrong. Even after checking the mailing list. 1- We couldn't plot our output using rhoplot, For example, when we try electron density plots for TiC, there was no visual. However, it works in some of our systems under the same condition. 2- When I try to copy/upload the original case struct file into a new directory for supercell calculations I got this msg Can't locate CGI.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /home/mohammed/WIEN2K/SRC_w2web/htdocs/util/upload2.pl line 3. BEGIN failed--compilation aborted at /home/mohammed/WIEN2K/SRC_w2web/htdocs/util/upload2.pl line 3. However, it works on one of our system. If there are any info that anybody may need to assist we will be grateful to provide. With best regards Mohammed lawal universiti Technologi Malaysia ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] lapw0 hang with mbj calculation for slab
Can you please remove my name (my email address= n...@uaeu.ac.ae) from your mailing List. Please do. I would appreciate that very much. Thanks! ** Dr. Nacir Tit Professor of Computational Physics Physics Department UAE University Al-Ain United Arab Emirates Tel: +971 3 7136 326 Fax: +971 3 7671 291 Email: n...@uaeu.ac.ae ** From: wien-boun...@zeus.theochem.tuwien.ac.at [wien-boun...@zeus.theochem.tuwien.ac.at] on behalf of Peter Blaha [pbl...@theochem.tuwien.ac.at] Sent: Friday, October 18, 2013 3:36 PM To: A Mailing list for WIEN2k users Subject: Re: [Wien] lapw0 hang with mbj calculation for slab For mBJ it is ALWAYS a good idea to use a larger IFFTfactor (complete cycle). For a surface, case.in0_grr should not be present. However, you need a file case.grr (normally prepared when case.in0_grr is present). This file (or the corresponding avrg [(grad rho)/rho] value) should be taken from a corresponding bulk calculation. On 10/18/2013 12:37 PM, alpa dashora wrote: Dear Prof. Blaha, Thanks for reply. I am unable to understand the reply. In only one iteration FFT factor should be 4 or for complete mbj cycle it should be same or again changed to 2. Should I remove case.in0_grr file? Please clear it. With regards, On Fri, Oct 18, 2013 at 11:30 AM, Peter Blaha pbl...@theochem.tuwien.ac.at mailto:pbl...@theochem.tuwien.ac.at wrote: Switch to PBE for one iteration. Increase IFFTfactor from 2 to 4 in case.in0 (and, most likely, reduce RKMAX) Am 18.10.2013 05:55, schrieb alpa dashora: Dear Prof. Blaha and Wien2k users, I am trying to run mbj calculation for MoS2 10 layer slab. After few cycles lapw0 hanged. I have seen the earlier posts discussed on the same topics. I have used the vxclm2.f file as provided by Prof. Blaha and removed case.in0_grr file. I have also increased the Rmt*Kmax up to 9 but still I am not able to solve my problem. Please suggest any other solution for this error or any other method to calculate the correct band gap. Thanks in advance. With kind regards, -- Alpa Dashora _ Wien mailing list w...@zeus.theochem.tuwien.ac.__at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.__ac.at/mailman/listinfo/wien http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/__wien@zeus.theochem.tuwien.ac.__at/index.html http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- --__--- Peter Blaha Inst. Materials Chemistry, TU Vienna Getreidemarkt 9, A-1060 Vienna, Austria Tel: +43-1-5880115671 Fax: +43-1-5880115698 email: pbl...@theochem.tuwien.ac.at mailto:pbl...@theochem.tuwien.ac.at --__--- _ Wien mailing list w...@zeus.theochem.tuwien.ac.__at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.__ac.at/mailman/listinfo/wien http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/__wien@zeus.theochem.tuwien.ac.__at/index.html http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- Alpa Dashora ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html -- P.Blaha -- Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna Phone: +43-1-58801-165300 FAX: +43-1-58801-165982 Email: bl...@theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/ -- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] hyperfine field question in ORB package for the aluminum
Dear Prof. Blaha It works very well after TEMP broadening is turned on. Thanks for your suggestion. 2013/10/15 Peter Blaha pbl...@theochem.tuwien.ac.at Hi, I guess I never suggested B=1 T, but anyway, what you should check is if the calculated HFF vary linear with the applied field. I could imagine that with such calculations where you should have some artificial degeneracy of the 4 Al atoms, the TETRA method makes some small problem. In any case, it looks already fairly similar. Have you ever tried TEMP (with a small broadening ??, so that you do not destroy the magnetic shift). In addition, I suggest to increase the IFFT factor in case.in0 to 4 or 6, so that aliasing problems are reduced. Otherwise I would need to check this out myself. On 10/15/2013 06:25 PM, Jing-Han Chen wrote: Dear Prof. Blaha and other wien2k users: (I posted a similar message yesterday, apologies in case this appears as a repeat; the first message has not appeared on the list, perhaps reflected due to included images.) Regarding tests of the hyperfine fields in aluminum metal, we had thought about the issue of insufficient k-points, however we thought we had a handle on this issue. In a 9 T field, a rough calculation shows that the thin spin-polarized shell at Ef represents about 1/3000 of the BZ volume for fcc-Al. We ran a script gradually increasing the number of k-points, with a result (shown in http://people.physics.tamu.**edu/jhchen/points.pnghttp://people.physics.tamu.edu/jhchen/points.png) that the HFF settles down within about 20% of the expected value for 10,000 k-points in B=9T, with fluctuations dying down to the order of 10% and less in the range 30,000 - 80,000 k-points. We also ran a test for linearity in B at a setting of 10,000 k-points, and the results appeared to be quite linear up to 100 T (shown in http://people.physics.tamu.**edu/jhchen/field.pnghttp://people.physics.tamu.edu/jhchen/field.png ). We ran the test treating fcc-Al as simple cubic with 4 sites in order to be sure we understood how the field is applied in ORB, and expected if anything better convergence since the expanded cell gives a greater k-point density. However the results seem strange: with several k-point settings we found that in general, the HFF approached the expected value for fcc-Al after a relatively small number of iterations, yet without quite converging, and finally the HFF values diverged, with one or more going large and negative. We had not tried as many variations as for fcc since the results are much slower to obtain converged HFF. Following the suggestion of Prof. Blaha after our last posting we tried increasing to very large field and k-point values, and did finally get convergence (more than 10 last iterations of HFF is the same) for a setting of 10 k-points and 1 T, yielding 4 reasonably close positive values as in the following: -- :HFF001: 143.345 0.000 0.572 143.917 (KGAUSS) :HFF002: 143.344 0.000 0.572 143.916 (KGAUSS) :HFF003: 144.427 0.000 0.583 145.010 (KGAUSS) :HFF004: 143.344 0.000 0.572 143.916 (KGAUSS) -- However we are concerned that the HFF values are still not identical, whereas at 10,000 T the spin-polarized shell at Ef represents a significant fraction of the BZ, and the spin energy is quite large. We expected this to be more than enough k-points for random sampling of the shell at Ef. For this reason, and in particular in light of the strange behavior in which the HFF values almost converge before diverging to widely separated values, is it possible that there might be some other issue that we are overlooking? Any suggestions would be appreciated. 2013/10/7 Peter Blaha pbl...@theochem.tuwien.ac.at mailto:pblaha@theochem.**tuwien.ac.at pbl...@theochem.tuwien.ac.at The hyperfine field for a metal is coming mainly from the contact term due to the induced spin-polarization by the magnetic field. You should notice, that a field of 9 T is (for theoretical calculations) an extremely small field, causing a very small spin-splitting of the states near EF, which causes the HFF. I suppose all you see is numerical noise. Since only the states at EF are of interest (the field can only reoccupy states within a few mRy (or less) around EF), you need to converge your calculation with respect to: a) the k-mesh (test MUCH larger meshes (1, 5 10 k or more) b) the magnetic field (increase it and test fields up to 1000 T), You are not interested in the absolute number, but in ppm, i.e. the relative induced field. c) The angular momentum component of the hFF introduced by case.vorbup/dn is NOT correct. I would even suggest that you put l=0 to minimize the effect (or use-orbc with case.vorbup/dn ,
