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
Re: [Wien] lapw1 crash with SECLIT - Error in Cholesky
Why are you using P1? You have made everything much slower and less efficient. Beyond this it is hard to guess. ___ 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 for energy seperation between core/valence which was set to -10.2 because some Si core electrons were leaking out of MT sphere, and reduced number of k-points). I'm attaching my struct and in1 files. Any ideas? Best regards Pavel Ondračka ___ 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 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 for energy seperation between core/valence which was set to -10.2 because some Si core electrons were leaking out of MT sphere, and reduced number of k-points). I'm attaching my struct and in1 files. Any ideas? Best regards Pavel Ondračka ___ 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
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. 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. 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. 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. 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 for energy seperation between core/valence which was set to -10.2 because some Si core electrons were leaking out of MT sphere, and reduced number of k-points). I'm attaching my struct and in1 files. Any ideas? Best regards Pavel Ondračka ___ 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
Addendum: I should not call it a bug in setrmt. That code does an amazingly good job of estimating good RMTs to use. However, there are times when other RMTs can be better. ___ 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 On Oct 9, 2014 8:02 AM, Laurence Marks l-ma...@northwestern.edu 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. 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. 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. 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. 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 for energy seperation between core/valence which was set to -10.2 because some Si core electrons were leaking out of MT sphere, and reduced number of k-points). I'm attaching my struct and in1 files. Any ideas? Best regards Pavel Ondračka ___ 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
Re: [Wien] lapw1 crash with SECLIT - Error in Cholesky
Yes, clearly the problem is in the iterative diagonalization. It can be that this is connected with the low lying Si 2s orbital. Either run without -it ortry -it -noHns ortry to modify (?increase) Emax in the last line of case.in1 with -it On 10/09/2014 02:01 PM, Pavel Ondracka 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 for energy seperation between core/valence which was set to -10.2 because some Si core electrons were leaking out of MT sphere, and reduced number of k-points). I'm attaching my struct and in1 files. Any ideas? Best regards Pavel Ondračka ___ 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 -- 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
