Re: [Wien] Xcrysden problem
After installation of xcrysden you must kill w2web (ps -ef |grep w2web and kill the corresponding processes). Then make sure your environment is ok (eventually logout/login) and restart w2web. PS: before starting w2web, the environment variable XCRYSDEN_TOPDIR must be set. Am 10.10.2014 04:51, schrieb bayarr temuujin: Dear Wien2k users, I am new to Wien2k and i am running Wien2k version 13.1 on Ubuntu 14.04. LTS. I have problem with Xcrysden not showing up when i run electron density calculation. The button Calculate density with XCrysden doesnt show up. I have re-installed Xcrysden and XCrysden is working fine. Please help me out. Best regards, Temuujin ___ 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] Installation of 14.1 vs 13.1 using gfortran+gcc
Thank's for the report. gfortran is much more picky than ifort, so non-standard programming gets accepted with ifort, but not with gfortran. A modified Tmaker.f program will be supplied in the next version, where the corresponding read statements are replaced by something like: read(10,'(a)') row READ(row(25:79),*) ai,bi,ci ! write(*,*) ai,bi,ci read(10,'(a)') row READ(row(25:79),*) alpha,beta,gamma read(10,'(a)') row READ(row(20:79),*) xp,yp,zp ... read(10,'(a)') row READ(row(20:79),*) xp,yp,zp ! READ(10,1007) xp,yp,zp On 10/09/2014 03:30 PM, Priyanka Seth wrote: Dear Wien2k users and developers, I have been trying to install the 14.1 version of the code on the machines that I use, but have struggled when using gfortran+gcc while installation on ifort+mkl combination works beautifully. More specifically, I am installing sequentially on Ubuntu 14.04 machines with standard lapack and blas, gfortran and gcc (I have tried both versions 4.8 and 4.9 unsuccessfully). I have chosen the siteconfig_lapw settings as follows: SRC_lapw0: pwxad5.f:22.9: IF(GGA_SWITCH .EQ. .true.) THEN 1 Error: Logicals at (1) must be compared with .eqv. instead of .eq. make[1]: *** [pwxad5.o] Error 1 SRC_Tmaker: rm -f Tmaker.o clean gfortran -c -ffree-form -O2 -ffree-line-length-none Tmaker.f Tmaker.f:485.19: 1007 FORMAT(20X,F,F,F) 1 Error: Nonnegative width required in format string at (1) Tmaker.f:493.19: 1025 FORMAT(24X,F,F,F) 1 Error: Nonnegative width required in format string at (1) Tmaker.f:55.21: READ(10,1025) alpha,beta,gamma 1 Error: FORMAT label 1025 at (1) not defined Tmaker.f:55.21: READ(10,1025) alpha,beta,gamma 1 Error: FORMAT label 1025 at (1) not defined Tmaker.f:249.21: READ(10,1007) xp,yp,zp 1 Error: FORMAT label 1007 at (1) not defined Tmaker.f:1313.20: if(Eqrv(sp,s6(1,k),ndim,.0001)) then 1 Warning: Type mismatch in argument 'a' at (1); passed REAL(8) to REAL(4) Tmaker.f:249.21: READ(10,1007) xp,yp,zp 1 Error: FORMAT label 1007 at (1) not defined make: *** [Tmaker.o] Error 1 Looking into the files with .EQ., it seems that not much has changed between 13.1 and 14.1. I know it is possible to simply replace EQ with EQV, but I am surprised that with the same system setup and compiler, it is a problem for one system and not another. Any ideas why? Many thanks for your help, Priyanka Seth ___ 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.atWIEN2k: http://www.wien2k.at WWW: http://www.imc.tuwien.ac.at/staff/tc_group_e.php -- ___ 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] lapw1 crash with SECLIT - Error in Cholesky
On Thu, 2014-10-09 at 08:02 -0500, Laurence Marks wrote: I am not sure what exactly you are trying to do. It looks like you have some approximation to a Si doped amorphous TiO2 structure. The BVS looks reasonable, so this may have come from some other code. Yeah, the structure was produced by simulated annealing done by other code and I want to calculate band gap and optical constants with Wien2k using mBJ. At the moment I'm just trying to converge the case with LDA before I initialize mBJ. One thing odd is the RMT for Si of 1.44 which may very well lead to problems. This is actually close to what setrmt is giving. I think there may be a bug here in setrmt, Peter can say more. The small Si RMT is why you are losing core electrons. One thing you can do is (after at least one pass) do x RMTCheck. This will show the magnitude of the discontinuity at the RMT. I have seen that the discontinuities of different types of atoms should be roughly the same, and I suspect that in your case they are not. Looking at the output of x RMTCheck (attached) the Si atom doesn't seem to stand out too much, but I don't have any idea what roughly the same means in this case. Can you have a look please? At the moment I have a converged LDA case with the Si RMT = 1.44 and ecut -10.2 (no warnings) and I'm wondering if I can continue with mBJ or rather restart with different RMTs and higher ecut (e.g. -7.2). Without running your case myself, I would want to use cp case.struct Hold.struct setrmt case -a Ti:1.7,Si:1.6,O:1.4 ; cp *set* *.struct case is the name and the initial cp is because sometimes setrmt can be slightly buggy and get confused about decimal points. This initialized for me without warning with -ecut -7.2 and only the Si 2p as semicore not the 2s as well. After playing with this a little bit more it seems that the old scheme in setrmt is actually giving better results in my case: new: O:1.57 Ti:1.74 Si:1.44 old: O:1.56 Ti:1.76 Si:1.56 The O and Ti RMTs are quite similar so I have no idea why the Si RMT is so much lower with the new scheme. BTW with the old scheme I can get no warning also with only 2p states. N.B., you may want to increase nband at the bottom of case.in1c to something like 480 or 512, increase emin to 2.5, only use one k-point and for LDA with these RMTs I suspect that a RKMAX of 6 is fine. Did you meant increase emax to 2.5? Anyway this is really helpful, thank you very much. On Thu, Oct 9, 2014 at 7:01 AM, Pavel Ondracka pavel.ondra...@email.cz wrote: On Thu, 2014-10-09 at 06:23 -0500, Laurence Marks wrote: Why are you using P1? You have made everything much slower and less efficient. Beyond this it is hard to guess. Well, P1 is what I get during the initialization with sgrup. In the meantime I managed to get it running by removing -it switch (two successful iterations so far), so will see if it actually stays working. Best regards Pavel Ondračka __ Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu MURI4D.numis.northwestern.edu Co-Editor, Acta Cryst A Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi Dear Wien2k mailing list, I have a problem with crash in parallel lapw1. It crash with SECLIT - Error in Cholesky output in stderr. Looking at tail of corresponding case.output1_2 I see: Time for los (hamilt, cpu/wall) : 0.8 5.6 Time for alm (hns) : 4.2 Time for vector (hns) : 14.8 Time for vector2 (hns) : 14.0 Time for VxV (hns) :211.3 Wall Time for VxV(hns) : 2.8 reading Afacts -1 0.000E+000 :seclit: estimate of singular value, factor: 0.6527E+00 0.1000E-14 :seclit: min(sproj(ne+1:2ne)) 0.3110E-02 WARNING: INFO (Cholesky) = 679 I found some suggestions for Cholesky errors here: http://www.mail-archive.com/wien% 40zeus.theochem.tuwien.ac.at/msg02400.html however I'm quite sure my struct is OK, RKmax is default 7 (which should be reasonable for compound with Si Ti and O) and neither can I spot any problems in my in1 file. This happens in second scf cycle. I'm using a LDA potential and everything was initialized to the default in init_lapw (except
Re: [Wien] lapw1 crash with SECLIT - Error in Cholesky
I forgot that your case has no inversion symmetry -- you need to use x RMTCheck -c. Please send me that output so I can make educated guesses. If you are using -it then increasing nband and emax can help. The iterative methods use an expansion in terms of the previous eigensolutions, both occupied and some unoccupied. If this expansion is not adequate I am pretty certain one starts to get ghostbands and many other problems. (This is more intuition and experience than any proper math.) I do know that for MSR1a one can often improve things a little by using more solutions, the speed cost is very minor so long and you do not use extreme increases. I also prefer -noHinv, but that is my personal view not a general suggestion. On Fri, Oct 10, 2014 at 4:03 AM, Pavel Ondracka pavel.ondra...@email.cz wrote: On Thu, 2014-10-09 at 08:02 -0500, Laurence Marks wrote: I am not sure what exactly you are trying to do. It looks like you have some approximation to a Si doped amorphous TiO2 structure. The BVS looks reasonable, so this may have come from some other code. Yeah, the structure was produced by simulated annealing done by other code and I want to calculate band gap and optical constants with Wien2k using mBJ. At the moment I'm just trying to converge the case with LDA before I initialize mBJ. One thing odd is the RMT for Si of 1.44 which may very well lead to problems. This is actually close to what setrmt is giving. I think there may be a bug here in setrmt, Peter can say more. The small Si RMT is why you are losing core electrons. One thing you can do is (after at least one pass) do x RMTCheck. This will show the magnitude of the discontinuity at the RMT. I have seen that the discontinuities of different types of atoms should be roughly the same, and I suspect that in your case they are not. Looking at the output of x RMTCheck (attached) the Si atom doesn't seem to stand out too much, but I don't have any idea what roughly the same means in this case. Can you have a look please? At the moment I have a converged LDA case with the Si RMT = 1.44 and ecut -10.2 (no warnings) and I'm wondering if I can continue with mBJ or rather restart with different RMTs and higher ecut (e.g. -7.2). Without running your case myself, I would want to use cp case.struct Hold.struct setrmt case -a Ti:1.7,Si:1.6,O:1.4 ; cp *set* *.struct case is the name and the initial cp is because sometimes setrmt can be slightly buggy and get confused about decimal points. This initialized for me without warning with -ecut -7.2 and only the Si 2p as semicore not the 2s as well. After playing with this a little bit more it seems that the old scheme in setrmt is actually giving better results in my case: new: O:1.57 Ti:1.74 Si:1.44 old: O:1.56 Ti:1.76 Si:1.56 The O and Ti RMTs are quite similar so I have no idea why the Si RMT is so much lower with the new scheme. BTW with the old scheme I can get no warning also with only 2p states. N.B., you may want to increase nband at the bottom of case.in1c to something like 480 or 512, increase emin to 2.5, only use one k-point and for LDA with these RMTs I suspect that a RKMAX of 6 is fine. Did you meant increase emax to 2.5? Anyway this is really helpful, thank you very much. On Thu, Oct 9, 2014 at 7:01 AM, Pavel Ondracka pavel.ondra...@email.cz wrote: On Thu, 2014-10-09 at 06:23 -0500, Laurence Marks wrote: Why are you using P1? You have made everything much slower and less efficient. Beyond this it is hard to guess. Well, P1 is what I get during the initialization with sgrup. In the meantime I managed to get it running by removing -it switch (two successful iterations so far), so will see if it actually stays working. Best regards Pavel Ondračka __ Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu MURI4D.numis.northwestern.edu Co-Editor, Acta Cryst A Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi Dear Wien2k mailing list, I have a problem with crash in parallel lapw1. It crash with SECLIT - Error in Cholesky output in stderr. Looking at tail of corresponding case.output1_2 I see: Time for los (hamilt, cpu/wall) : 0.8 5.6 Time for alm (hns) : 4.2 Time for vector (hns) : 14.8 Time for vector2 (hns) : 14.0 Time for VxV (hns) :211.3 Wall
Re: [Wien] lapw1 crash with SECLIT - Error in Cholesky
Laurence Marks píše v Pá 10. 10. 2014 v 09:03 -0500: I forgot that your case has no inversion symmetry -- you need to use x RMTCheck -c. Please send me that output so I can make educated guesses. x RMTCheck -c output attached. If you are using -it then increasing nband and emax can help. The iterative methods use an expansion in terms of the previous eigensolutions, both occupied and some unoccupied. If this expansion is not adequate I am pretty certain one starts to get ghostbands and many other problems. (This is more intuition and experience than any proper math.) I do know that for MSR1a one can often improve things a little by using more solutions, the speed cost is very minor so long and you do not use extreme increases. I also prefer -noHinv, but that is my personal view not a general suggestion. Atom 1 O| RMT Charge 1.287 Grad 2.661 | Step Charge 0.00397, 0.0 Gradient 0.1141, -0.1141 O Atom 2 O| RMT Charge 1.291 Grad 2.673 | Step Charge 0.00437, 0.0 Gradient 0.1144, -0.1144 O Atom 3 O| RMT Charge 1.312 Grad 2.686 | Step Charge 0.00492, 0.0 Gradient 0.1113, -0.1113 O Atom 4 O| RMT Charge 1.261 Grad 2.634 | Step Charge 0.00654, 0.0 Gradient 0.1102, -0.1102 O Atom 5 O| RMT Charge 1.283 Grad 2.659 | Step Charge 0.00461, 0.0 Gradient 0.1137, -0.1137 O Atom 6 O| RMT Charge 1.258 Grad 2.653 | Step Charge 0.00199, 0.0 Gradient 0.1116, -0.1116 O Atom 7 O| RMT Charge 1.298 Grad 2.655 | Step Charge 0.00656, 0.0 Gradient 0.1158, -0.1158 O Atom 8 O| RMT Charge 1.260 Grad 2.630 | Step Charge 0.00616, 0.0 Gradient 0.1092, -0.1092 O Atom 9 O| RMT Charge 1.275 Grad 2.647 | Step Charge 0.00579, 0.0 Gradient 0.1121, -0.1121 O Atom 10 O| RMT Charge 1.279 Grad 2.654 | Step Charge 0.00568, 0.0 Gradient 0.1145, -0.1145 O Atom 11 O| RMT Charge 1.266 Grad 2.628 | Step Charge 0.00687, 0.0 Gradient 0.1127, -0.1125 O Atom 12 O| RMT Charge 1.268 Grad 2.659 | Step Charge 0.00259, 0.0 Gradient 0.1113, -0.1113 O Atom 13 O| RMT Charge 1.279 Grad 2.666 | Step Charge 0.00305, 0.0 Gradient 0.1133, -0.1133 O Atom 14 O| RMT Charge 1.323 Grad 2.705 | Step Charge 0.00318, 0.0 Gradient 0.1131, -0.1131 O Atom 15 O| RMT Charge 1.289 Grad 2.643 | Step Charge 0.00755, 0.0 Gradient 0.1158, -0.1154 O Atom 16 O| RMT Charge 1.275 Grad 2.662 | Step Charge 0.00435, 0.0 Gradient 0.1133, -0.1133 O Atom 17 O| RMT Charge 1.300 Grad 2.670 | Step Charge 0.00486, 0.0 Gradient 0.1154, -0.1154 O Atom 18 O| RMT Charge 1.283 Grad 2.668 | Step Charge 0.00422, 0.0 Gradient 0.1139, -0.1139 O Atom 19 O| RMT Charge 1.275 Grad 2.661 | Step Charge 0.00395, 0.0 Gradient 0.1127, -0.1127 O Atom 20 O| RMT Charge 1.297 Grad 2.666 | Step Charge 0.00314, 0.0 Gradient 0.1152, -0.1152 O Atom 21 O| RMT Charge 1.286 Grad 2.659 | Step Charge 0.00493, 0.0 Gradient 0.1134, -0.1134 O Atom 22 O| RMT Charge 1.341 Grad 2.723 | Step Charge 0.00295, 0.0 Gradient 0.1125, -0.1125 O Atom 23 O| RMT Charge 1.273 Grad 2.636 | Step Charge 0.00653, 0.0 Gradient 0.1121, -0.1121 O Atom 24 O| RMT Charge 1.285 Grad 2.672 | Step Charge 0.00336, 0.0 Gradient 0.1140, -0.1140 O Atom 25 O| RMT Charge 1.268 Grad 2.634 | Step Charge 0.00673, 0.0 Gradient 0.1137, -0.1130 O Atom 26 O| RMT Charge 1.312 Grad 2.695 | Step Charge 0.00205, 0.0 Gradient 0.1102, -0.1102 O Atom 27 O| RMT Charge 1.292 Grad 2.657 | Step Charge 0.00493, 0.0 Gradient 0.1149, -0.1149 O Atom 28 O| RMT Charge 1.257 Grad 2.622 | Step Charge 0.00719, 0.0 Gradient 0.1109, -0.1104 O Atom 29 O| RMT Charge 1.262 Grad 2.653 | Step Charge 0.00207, 0.0 Gradient 0.1114, -0.1114 O Atom 30 O| RMT Charge 1.265 Grad 2.653 | Step Charge 0.00466, 0.0 Gradient 0.1113, -0.1113 O Atom 31 O| RMT Charge 1.258 Grad 2.646 | Step Charge 0.00242, 0.0 Gradient 0.1106, -0.1106 O Atom 32 O| RMT Charge 1.277 Grad 2.654 | Step Charge 0.00392, 0.0 Gradient 0.1123, -0.1123 O Atom 33 Ti | RMT Charge 1.003 Grad 2.070 | Step Charge 0.01565, 0.0 Gradient 0.1137, -0.1120 Ti Atom 34 Ti | RMT Charge 0.961 Grad 2.094 | Step Charge 0.00946, 0.0 Gradient 0.1093, -0.1090 Ti Atom 35 Ti | RMT Charge 0.963 Grad 2.091 | Step Charge 0.00834, 0.0 Gradient 0.1092, -0.1092 Ti Atom 36 Ti | RMT Charge 0.988 Grad 2.081 | Step Charge 0.00779, 0.0 Gradient 0.1109, -0.1109 Ti Atom 37 Ti | RMT Charge 0.993 Grad 2.080 | Step Charge 0.01081, 0.0 Gradient
Re: [Wien] lapw1 crash with SECLIT - Error in Cholesky
What RMT's? On Fri, Oct 10, 2014 at 11:18 AM, Pavel Ondračka pavel.ondra...@email.cz wrote: Laurence Marks píše v Pá 10. 10. 2014 v 09:03 -0500: I forgot that your case has no inversion symmetry -- you need to use x RMTCheck -c. Please send me that output so I can make educated guesses. x RMTCheck -c output attached. If you are using -it then increasing nband and emax can help. The iterative methods use an expansion in terms of the previous eigensolutions, both occupied and some unoccupied. If this expansion is not adequate I am pretty certain one starts to get ghostbands and many other problems. (This is more intuition and experience than any proper math.) I do know that for MSR1a one can often improve things a little by using more solutions, the speed cost is very minor so long and you do not use extreme increases. I also prefer -noHinv, but that is my personal view not a general suggestion. -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu Corrosion in 4D: MURI4D.numis.northwestern.edu Co-Editor, Acta Cryst A Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi ___ 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] lapw1 crash with SECLIT - Error in Cholesky
Laurence Marks píše v Pá 10. 10. 2014 v 11:23 -0500: What RMT's? This is still with the original RMTs, e.g. the ones which are produced by setrmt new scheme. O:1.57 Ti:1.74 Si:1.44 On Fri, Oct 10, 2014 at 11:18 AM, Pavel Ondračka pavel.ondra...@email.cz wrote: Laurence Marks píše v Pá 10. 10. 2014 v 09:03 -0500: I forgot that your case has no inversion symmetry -- you need to use x RMTCheck -c. Please send me that output so I can make educated guesses. x RMTCheck -c output attached. If you are using -it then increasing nband and emax can help. The iterative methods use an expansion in terms of the previous eigensolutions, both occupied and some unoccupied. If this expansion is not adequate I am pretty certain one starts to get ghostbands and many other problems. (This is more intuition and experience than any proper math.) I do know that for MSR1a one can often improve things a little by using more solutions, the speed cost is very minor so long and you do not use extreme increases. I also prefer -noHinv, but that is my personal view not a general suggestion. -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu Corrosion in 4D: MURI4D.numis.northwestern.edu Co-Editor, Acta Cryst A Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi ___ 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] lapw1 crash with SECLIT - Error in Cholesky
Thanks. I don't see anything obviously problematic. The only way I know to check RMT values is to minimize the energy with a constant RKMAX*min(RMT) (Peter might know a better one). My observation is that is approximately when the last term on the right of the output, the step in the gradient, is roughly the same for different atom types. It should also be not too large. Your value of 0.1 for Ti O looks fine to me, both small enough and suggesting that your RKMAX is big enough. There is a reasonable amount of charge at the RMT for O ( ~1.3) which is to be expected, less for the Ti, again fine. The value for the gradient for Si of 0.576 is slightly surprising to me, I guess most of the Si valence density is outside the RMT except for the 2s (guessing). Without real proof I would be slightly cautious of how the Si is being treated. It is probably fine. On Fri, Oct 10, 2014 at 11:47 AM, Pavel Ondračka pavel.ondra...@email.cz wrote: Laurence Marks píše v Pá 10. 10. 2014 v 11:23 -0500: What RMT's? This is still with the original RMTs, e.g. the ones which are produced by setrmt new scheme. O:1.57 Ti:1.74 Si:1.44 On Fri, Oct 10, 2014 at 11:18 AM, Pavel Ondračka pavel.ondra...@email.cz wrote: Laurence Marks píše v Pá 10. 10. 2014 v 09:03 -0500: I forgot that your case has no inversion symmetry -- you need to use x RMTCheck -c. Please send me that output so I can make educated guesses. x RMTCheck -c output attached. If you are using -it then increasing nband and emax can help. The iterative methods use an expansion in terms of the previous eigensolutions, both occupied and some unoccupied. If this expansion is not adequate I am pretty certain one starts to get ghostbands and many other problems. (This is more intuition and experience than any proper math.) I do know that for MSR1a one can often improve things a little by using more solutions, the speed cost is very minor so long and you do not use extreme increases. I also prefer -noHinv, but that is my personal view not a general suggestion. -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu Corrosion in 4D: MURI4D.numis.northwestern.edu Co-Editor, Acta Cryst A Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi ___ 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 -- Professor Laurence Marks Department of Materials Science and Engineering Northwestern University www.numis.northwestern.edu Corrosion in 4D: MURI4D.numis.northwestern.edu Co-Editor, Acta Cryst A Research is to see what everybody else has seen, and to think what nobody else has thought Albert Szent-Gyorgi ___ 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] lapw1 crash with SECLIT - Error in Cholesky
Laurence Marks píše v Pá 10. 10. 2014 v 11:59 -0500: Thanks. I don't see anything obviously problematic. The only way I know to check RMT values is to minimize the energy with a constant RKMAX*min(RMT) (Peter might know a better one). My observation is that is approximately when the last term on the right of the output, the step in the gradient, is roughly the same for different atom types. It should also be not too large. Your value of 0.1 for Ti O looks fine to me, both small enough and suggesting that your RKMAX is big enough. There is a reasonable amount of charge at the RMT for O ( ~1.3) which is to be expected, less for the Ti, again fine. The value for the gradient for Si of 0.576 is slightly surprising to me, I guess most of the Si valence density is outside the RMT except for the 2s (guessing). Without real proof I would be slightly cautious of how the Si is being treated. It is probably fine. OK, ATM I'm running the calculation again with different RMTs just to be sure and if the both results are consistent, I will continue with mBJ. Thanks a lot for your help. ___ 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
