[Wien] different :RTO values

Sun Apr 6 18:47:37 CEST 2025

The correct calculation occurs with cubic structure (test1), and wrong 
with rhombohedral...

06.04.2025 19:39, Stefaan Cottenier via Wien wrote:
> Hmm.... The automatic initialization by -prec 0 was meant for a quick 
> test only. It is the lowest level of precision, and indeed gives a 
> lower basis set size.
>
> As your comparison with Rkm 6.5 shows, it is indeed the core/valence 
> of 3s that gives the change in :RTO, and the basis set size will 
> hardly matter for this.
>
> The difference in :ENE is probably because the 3s when being core 
> electrons are treated fully relativistically, whereas they are 
> scalar-relativistic when taken to be valence electrons.
>
> My conclusion remains that it is the core/valence choice of Fe-3s 
> alone that leads to the big change in :RTO, and it remains to be 
> understood why in my initial test case these two different crystals 
> lead to a :RTO that has once a value close to that 15309 (similar to 
> 3s as core), and once close to 15261 (similar to 2s as valence), 
> although in both of my cases the -ecut 11 has assigned the Fe-3s to be 
> valence electrons.
>
> Stefaan
> ------------------------------------------------------------------------
> *Van:* Wien <wien-bounces at zeus.theochem.tuwien.ac.at> namens Lyudmila 
> <lyuka17 at gmail.com>
> *Verzonden:* zondag 6 april 2025 18:25
> *Aan:* wien at zeus.theochem.tuwien.ac.at <wien at zeus.theochem.tuwien.ac.at>
> *Onderwerp:* Re: [Wien] different :RTO values
> 06.04.2025 18:23, Stefaan Cottenier via Wien wrote:
> > Thanks for checking, and for this additional observation. Agreed, with
> > "-ecut -6" it works as usual, but with "-ecut -11" it doesn't. I
> > hadn't suspect this as a possible reason. And although I would expect
> > that :RTO should be well-defined for either choice, it may be that it
> > isn't (maybe it can't handle a 3s and 4s as valence simultaneously?).
> > Or it could be a bug.
> > For now, I'll calculate my isomer shifts by an additional scf-cycle
> > with the 3s as core, as a temporary work-around.
> I don't know how automatic initialization works, but do pay attention:
> for these two cases
> init_lapw -prec 0 -ecut -11 -sp
> have put different Rkmax (5.5 and 6.5), in my installation at least.
>
> But with both Rkm=6.5 there is still a difference
>     Rkm=6.5                 :MMTOT:          :ENE :RTO001
> test2-core3s-cc0001  13.50740  -18395.45013356  15308.962923
> test2-val3s-cc0001    13.61144  -18392.30987127 15261.536598
> I'd say, rather large difference in ENE. Maybe it is necessary to
> increase Rkm?
>
> I've tried even to take clm from core3s calculation (correct) and to
> continue with val3s,
> This has given the same difference in RTO.
>
> 04.04.2025 19:24, Stefaan Cottenier via Wien wrote:
> > > I'm puzzled by an observation which I could boil down to the following
> > > two simple test cases:
> > Dear Stefaan,
> >
> > Yes, this looks a puzzle.
> > Usual values in my systems are 15308-15309, the second 15259.503192
> > looks wrong.
> > I usually take 3s level into the core when choosing E=-6Ry.
> > When I have taken 3s as valence I also had the like strangeness.
> > If I put 3s into core the result is usual (self consistent 
> calculations):
> > test1 val3s   :RTO001:   1    192.948473  15115.793018 15308.741492
> > test2 val3s   :RTO001:   1    144.699393  15116.823666 15261.523059
> > test1 core3s :RTO001:   1        6.263063  15302.654746 15308.917809
> > test2 core3s :RTO001:   1        5.097620  15303.863569 15308.961190
> >
> > So, when 3s is in core the result looks normal. Do not know why this
> > happens...
> >
> > Best wishes
> > Lyudmila
> > Lyudmila Dobysheva
> > ------------------
> >
> > > For the two attached structure files, do:
> > >
> > > init_lapw -prec 0 -ecut -11 -sp
> > > runsp -i 1
> > > grep :RTO001 case.scf
> > >
> > > For test1, this gives:
> > >
> > > :RTO001:   1      192.208707        0.000000  15115.811643 
>  15308.020350
> > >
> > > For test2, the result is:
> > >
> > > :RTO001:   1      143.691518        0.000000  15115.811674 
>  15259.503192
> > >
> > > This is in the very first iteration, not self-consistent. But these
> > > numbers will not change significantly when going to selfconsistency.
> > >
> > > You see that the valence contribution to :RTO is very different for
> > > both cases, in spite of this being for the same element, with the same
> > > R0 value, the same radial grid, the same RMT, the same
> > initialization,...
> > >
> > > I've done several different cases with similar structures, most of
> > > them end up like test2, but a few behave as in test1. I guess I'm
> > > overlooking something simple, but I don't see why these are 
> different...
> > >
> > > Any suggestion? (or maybe a check whether you get similar results with
> > > this test, to exclude it is an issue of the compute facility?)
> > >
> > > Thanks,
> > > Stefaan

-- 
Lyudmila Dobysheva
------------------
http://ftiudm.ru/content/view/25/103/lang,english/
Institute of Physics and Technology,
Udmurt Federal Research Center, Ural Br. of Rus.Ac.Sci.
426000 Izhevsk Kirov str. 132
Russia
---
Tel. +7 (34I2)72-87-79 (office), +7 (9I2)OI9-795O (home)
Skype: lyuka18 (office), lyuka17 (home)
E-mail: lyuka17 at mail.ru (office), lyuka17 at gmail.com (home)