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@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.bl...@tuwien.ac.at WWW:http://www.imc.tuwien.ac.at WIEN2k:http://www.wien2k.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

Reply via email to