<div dir="ltr">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.<div><br></div><div>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.)</div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 10, 2014 at 4:03 AM, Pavel Ondracka <span dir="ltr"><<a href="mailto:pavel.ondracka@email.cz" target="_blank">pavel.ondracka@email.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 2014-10-09 at 08:02 -0500, Laurence Marks wrote:<br>
> I am not sure what exactly you are trying to do. It looks like you<br>
> have some approximation to a Si doped amorphous TiO2 structure. The<br>
> BVS looks reasonable, so this may have come from some other code.<br>
<br>
Yeah, the structure was produced by simulated annealing done by other<br>
code and I want to calculate band gap and optical constants with Wien2k<br>
using mBJ. At the moment I'm just trying to converge the case with LDA<br>
before I initialize mBJ.<br>
<br>
><br>
> One thing odd is the RMT for Si of 1.44 which may very well lead to<br>
> problems. This is actually close to what setrmt is giving. I think<br>
> there may be a bug here in setrmt, Peter can say more. The small Si<br>
> RMT is why you are losing core electrons.<br>
><br>
><br>
> One thing you can do is (after at least one pass) do "x RMTCheck".<br>
> This will show the magnitude of the discontinuity at the RMT. I have<br>
> seen that the discontinuities of different types of atoms should be<br>
> roughly the same, and I suspect that in your case they are not.<br>
><br>
Looking at the output of x RMTCheck (attached) the Si atom doesn't seem<br>
to stand out too much, but I don't have any idea what "roughly the same"<br>
means in this case. Can you have a look please? At the moment I have a<br>
converged LDA case with the Si RMT = 1.44 and ecut -10.2 (no warnings)<br>
and I'm wondering if I can continue with mBJ or rather restart with<br>
different RMTs and higher ecut (e.g. -7.2).<br>
><br>
> Without running your case myself, I would want to use<br>
><br>
><br>
> cp case.struct Hold.struct<br>
> setrmt case -a Ti:1.7,Si:1.6,O:1.4 ; cp *set* *.struct<br>
><br>
><br>
> case is the name and the initial cp is because sometimes setrmt can be<br>
> slightly buggy and get confused about decimal points.<br>
><br>
><br>
> This initialized for me without warning with -ecut -7.2 and only the<br>
> Si 2p as semicore not the 2s as well.<br>
<br>
After playing with this a little bit more it seems that the old scheme<br>
in setrmt is actually giving better results in my case:<br>
<br>
new: O:1.57 Ti:1.74 Si:1.44<br>
old: O:1.56 Ti:1.76 Si:1.56<br>
<br>
The O and Ti RMTs are quite similar so I have no idea why the Si RMT is<br>
so much lower with the new scheme.<br>
BTW with the old scheme I can get no warning also with only 2p states.<br>
><br>
> N.B., you may want to increase nband at the bottom of case.in1c to<br>
> something like 480 or 512, increase emin to 2.5, only use one k-point<br>
> and for LDA with these RMTs I suspect that a RKMAX of 6 is fine.<br>
<br>
Did you meant increase emax to 2.5?<br>
<br>
Anyway this is really helpful, thank you very much.<br>
><br>
><br>
> On Thu, Oct 9, 2014 at 7:01 AM, Pavel Ondracka<br>
> <<a href="mailto:pavel.ondracka@email.cz">pavel.ondracka@email.cz</a>> wrote:<br>
>         On Thu, 2014-10-09 at 06:23 -0500, Laurence Marks wrote:<br>
>         > Why are you using P1? You have made everything much slower<br>
>         and less<br>
>         > efficient.<br>
>         ><br>
>         > Beyond this it is hard to guess.<br>
>         ><br>
>         Well, P1 is what I get during the initialization with sgrup.<br>
><br>
>         In the meantime I managed to get it running by removing -it<br>
>         switch (two<br>
>         successful iterations so far), so will see if it actually<br>
>         stays working.<br>
><br>
>         Best regards<br>
>         Pavel Ondračka<br>
><br>
>         > __________________________<br>
>         > Professor Laurence Marks<br>
>         > Department of Materials Science and Engineering<br>
>         > Northwestern University<br>
>         > <a href="http://www.numis.northwestern.edu" target="_blank">www.numis.northwestern.edu</a><br>
>         > <a href="http://MURI4D.numis.northwestern.edu" target="_blank">MURI4D.numis.northwestern.edu</a><br>
>         > Co-Editor, Acta Cryst A<br>
>         > "Research is to see what everybody else has seen, and to<br>
>         think what<br>
>         > nobody else has thought"<br>
>         > Albert Szent-Gyorgi<br>
>         ><br>
>         > Dear Wien2k mailing list,<br>
>         ><br>
>         > I have a problem with crash in parallel lapw1. It crash with<br>
>         SECLIT -<br>
>         > Error in Cholesky output in stderr. Looking at tail of<br>
>         corresponding<br>
>         > case.output1_2 I see:<br>
>         ><br>
>         > Time for los      (hamilt, cpu/wall) :          0.8<br>
>          5.6<br>
>         > Time for alm         (hns) :          4.2<br>
>         > Time for vector      (hns) :         14.8<br>
>         > Time for vector2     (hns) :         14.0<br>
>         > Time for VxV         (hns) :        211.3<br>
>         > Wall Time for VxV    (hns) :          2.8<br>
>         >  reading Afacts          -1  0.000000000000000E+000<br>
>         > :seclit:  estimate of singular value, factor:   0.6527E+00<br>
>         0.1000E-14<br>
>         > :seclit:  min(sproj(ne+1:2ne))   0.3110E-02<br>
>         >  WARNING: INFO (Cholesky) =          679<br>
>         ><br>
>         > I found some suggestions for Cholesky errors here:<br>
>         > <a href="http://www.mail-archive.com/wien%" target="_blank">http://www.mail-archive.com/wien%</a><br>
>         > <a href="http://40zeus.theochem.tuwien.ac.at/msg02400.html" target="_blank">40zeus.theochem.tuwien.ac.at/msg02400.html</a><br>
>         > however I'm quite sure my struct is OK, RKmax is default 7<br>
>         (which<br>
>         > should<br>
>         > be reasonable for compound with Si Ti and O) and neither can<br>
>         I spot<br>
>         > any<br>
>         > problems in my in1 file.<br>
>         ><br>
>         > This happens in second scf cycle. I'm using a LDA potential<br>
>         and<br>
>         > everything was initialized to the default in init_lapw<br>
>         (except for<br>
>         > energy seperation between core/valence which was set to<br>
>         -10.2 because<br>
>         > some Si core electrons were leaking out of MT sphere, and<br>
>         reduced<br>
>         > number<br>
>         > of k-points).<br>
>         ><br>
>         > I'm attaching my struct and in1 files. Any ideas?<br>
>         ><br>
>         > Best regards<br>
>         > Pavel Ondračka<br>
>         ><br>
>         > _______________________________________________<br>
>         > Wien mailing list<br>
>         > <a href="mailto:Wien@zeus.theochem.tuwien.ac.at">Wien@zeus.theochem.tuwien.ac.at</a><br>
>         > <a href="http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien" target="_blank">http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien</a><br>
>         > SEARCH the MAILING-LIST at:<br>
>         <a href="http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html" target="_blank">http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html</a><br>
><br>
><br>
>         _______________________________________________<br>
>         Wien mailing list<br>
>         <a href="mailto:Wien@zeus.theochem.tuwien.ac.at">Wien@zeus.theochem.tuwien.ac.at</a><br>
>         <a href="http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien" target="_blank">http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien</a><br>
>         SEARCH the MAILING-LIST at:<br>
>         <a href="http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html" target="_blank">http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Professor Laurence Marks<br>
> Department of Materials Science and Engineering<br>
> Northwestern University<br>
> <a href="http://www.numis.northwestern.edu" target="_blank">www.numis.northwestern.edu</a><br>
> Corrosion in 4D: <a href="http://MURI4D.numis.northwestern.edu" target="_blank">MURI4D.numis.northwestern.edu</a><br>
> Co-Editor, Acta Cryst A<br>
> "Research is to see what everybody else has seen, and to think what<br>
> nobody else has thought"<br>
> Albert Szent-Gyorgi<br>
> _______________________________________________<br>
> Wien mailing list<br>
> <a href="mailto:Wien@zeus.theochem.tuwien.ac.at">Wien@zeus.theochem.tuwien.ac.at</a><br>
> <a href="http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien" target="_blank">http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien</a><br>
> SEARCH the MAILING-LIST at:  <a href="http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html" target="_blank">http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html</a><br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Professor Laurence Marks<br>Department of Materials Science and Engineering<br>Northwestern University<br><a href="http://www.numis.northwestern.edu" target="_blank">www.numis.northwestern.edu</a><div>Corrosion in 4D: <a href="http://MURI4D.numis.northwestern.edu" target="_blank">MURI4D.numis.northwestern.edu</a><br>Co-Editor, Acta Cryst A<br>"Research is to see what everybody else has seen, and to think what nobody else has thought"<br>Albert Szent-Gyorgi</div></div>
</div>