[Wien] lapw1 crash with SECLIT - Error in Cholesky

[Laurence Marks]

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.ondracka at 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.ondracka at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20141010/cc25d63c/attachment-0001.html>