[Wien] core states in spin-polarized calculations and the open-core method

[Peter Blaha]

Hi,

You are absolutely right, the way we treat core-states in spin-polarized 
calculations is "wrong", as we do two separate calculations in the 
spin-up and dn potential, respectively.  This leads to 4 eigenvalues of 
p,d or f states, all of them get "half occupation", which is not correct.

However, a couple of comments below:

i) Long time ago this was cross-checked for Fe using a 
fully-relativistic KKR code.

  ( Solid State Commun. *79*, 121 (1991) )

If I remember correctly, the differences were negligible, at least for 
the quantities of interest there.

ii) Spin-orbit + spin-polarization has always a problem in DFT, as one 
uses commonly a "spin-averaged" potential to evaluate the Spin-Orbit 
term, which is certainly also an approximation. If you want, we average 
in a different way.

iii) Yes, for open-core with different occupations this is an additional 
approximation. However, note that open-core calculations always have a 
fairly large core-leakage. Distributing a couple of percent of 4f charge 
as constant in the interstitial (or renormalizing this inside the 
sphere) is a MUCH larger approximation anyway and in addition dependent 
on RMT.

I would not trust total energy differences of different open-core 
calculations too much, but mainly because of different amounts of charge 
leakage. The problem is anyway, that one cannot compare total energies 
with different number of core electrons (this is true even for semicore 
s-electrons which do not have SO effects, but the total energy is not 
the same if treated as core or valence.

I've used open-core for bandstructures only (and with fixed 4f number).

iii) Of course, open-core is "computational convenient" since the input 
is "trivial" and the calculations converge easily. But you can also use 
the FSM method + GGA+U to select a certain magnetic moment (and thus 
roughly the number of 4f states).  And yes, surprisingly the U value for 
4f should not be one too large. For such heavy systems it is also often 
not justified to use an "effective" U, but should use U and J 
individually. In addition, note that with ONE U, but different starting 
situations, one may run into different metastable solutions, so one may 
need to search for the lowest energy state.

Best regards

Peter Blaha


Am 17.07.2023 um 13:51 schrieb Jindrich Kolorenc:
> Dear Wien2k developers and users,
>
> I would be grateful for your opinion, clarification or pointers to
> literature about core states in Wien2k or LAPW in general. My
> message is a bit long, I am sorry for that.
>
> It seems to me that there is some inconsistency in the way Wien2k
> treats the core states in spin-polarized calculations. As far as I
> understand it, LCORE is run twice, once for spin-up potential and
> once for spin-down potential. In each of these runs, the core states
> are full (up and dn occupied). Then, I suppose, the up charge density
> is set to 1/2 of the LCORE charge run for the up potential and dn
> charge density is set to 1/2 of the LCORE charge run for the dn
> potential. That is different than running a core solver once, each spin
> channel feeling its own potential, which would seem to me as a more
> "rigorous" strategy (but one could not use the same quantum numbers
> for the core states as LCORE does).
>
> I suppose that different approaches to the core states have some effect
> also on the total-energy expression, since it contains sum of
> eigenvalues (I suppose since mixer reads them from case.scf). In
> Wien2k, there are two eigenvalues for each core state for
> spin-polarized calculations. I checked Elk, and if I understand its
> output correctly, it lists only one eigenvalue for each core state for
> spin-polarized calculations. That probably means, that Elk runs one
> core calculation for an averaged potential (though I did not
> investigate Elk in detail to know for sure).
>
> Do you know about any book or paper where different strategies would
> be discussed and/or tested/compared? My LAPW reference, the David
> Singh's book, does not appear to touch this.
>
> It may well be that for full core states all this is usually
> negligible, but I am more concerned about consequences for the
> open-core approximation for 4f states (which is where I actually
> noticed this "issue")
>
>    http://www.wien2k.at/reg_user/faq/open_core.html
>
> The FAQ entry does not mention spin-polarized calculations, but runsp
> does look for case.inc[up,dn] and it will use them if they exist. Then,
> fully spin-polarized polarized f^7 state is calculated as 1/2 (I
> suppose) of f^14 state, for instance. That is likely a good
> approximation for Eu^2+ charge density (full shell vs full subshell),
> but the eigenvalues/total energy are less obvious. And accuracy of
> approximating fully spin-polarized f^6 with 1/2 of spin-restricted f^12
> is even less obvious even for the charge density.
>
> I see that the FAQ entry says that one should use LDA+U instead of open
> core, but it has its own set of problems when applied to localized 4f
> too. And open core has one attractive feature for me - it gives an
> easy way to do calculations with constrained number of 4f electrons. Do
> you think it is meaningful to compare total energies for such
> calculations with different number of 4f electrons (charge-neutral
> cells, electrons shuffled between 4f and valence s,p,d).
>
> Any comments welcome.
>
> Best regards,
> Jindrich
>
>
>
>
>
> _______________________________________________
> 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

-- 
-----------------------------------------------------------------------
Peter Blaha,  Inst. f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-158801165300
Email:peter.blaha at tuwien.ac.at           
WWW:http://www.imc.tuwien.ac.at       WIEN2k:http://www.wien2k.at
-------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20230717/94c7f752/attachment.htm>