<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Hello Lyudmila,</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
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.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
For now, I'll calculate my isomer shifts by an additional scf-cycle with the 3s as core, as a temporary work-around.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Thanks,<br>
Stefaan</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Van:</b> Wien <wien-bounces@zeus.theochem.tuwien.ac.at> namens Lyudmila <lyuka17@gmail.com><br>
<b>Verzonden:</b> zondag 6 april 2025 14:31<br>
<b>Aan:</b> wien@zeus.theochem.tuwien.ac.at <wien@zeus.theochem.tuwien.ac.at><br>
<b>Onderwerp:</b> Re: [Wien] different :RTO values</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">04.04.2025 19:24, Stefaan Cottenier via Wien wrote:<br>
> I'm puzzled by an observation which I could boil down to the following <br>
> two simple test cases:<br>
Dear Stefaan,<br>
<br>
Yes, this looks a puzzle.<br>
Usual values in my systems are 15308-15309, the second 15259.503192 <br>
looks wrong.<br>
I usually take 3s level into the core when choosing E=-6Ry.<br>
When I have taken 3s as valence I also had the like strangeness.<br>
If I put 3s into core the result is usual (self consistent calculations):<br>
test1 val3s :RTO001: 1 192.948473 15115.793018 15308.741492<br>
test2 val3s :RTO001: 1 144.699393 15116.823666 15261.523059<br>
test1 core3s :RTO001: 1 6.263063 15302.654746 15308.917809<br>
test2 core3s :RTO001: 1 5.097620 15303.863569 15308.961190<br>
<br>
So, when 3s is in core the result looks normal. Do not know why this <br>
happens...<br>
<br>
Best wishes<br>
Lyudmila<br>
<br>
-- <br>
Lyudmila Dobysheva<br>
------------------<br>
<a href="http://ftiudm.ru/content/view/25/103/lang,english/">https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fftiudm.ru%2Fcontent%2Fview%2F25%2F103%2Flang%2Cenglish%2F&data=05%7C02%7CStefaan.Cottenier%40ugent.be%7Ca09a6b7c0b8541803d5508dd7506ff38%7Cd7811cdeecef496c8f91a1786241b99c%7C1%7C0%7C638795395156685718%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OBRCCCr6Qy46hTLNd7lxGmFFz71WdCJARWNnDv0t4h4%3D&reserved=0</a><br>
Institute of Physics and Technology,<br>
Udmurt Federal Research Center, Ural Br. of Rus.Ac.Sci.<br>
426000 Izhevsk Kirov str. 132<br>
Russia<br>
---<br>
Tel. +7 (34I2)72-87-79 (office), +7 (9I2)OI9-795O (home)<br>
Skype: lyuka18 (office), lyuka17 (home)<br>
E-mail: lyuka17@mail.ru (office), lyuka17@gmail.com (home)<br>
<br>
> For the two attached structure files, do:<br>
><br>
> init_lapw -prec 0 -ecut -11 -sp<br>
> runsp -i 1<br>
> grep :RTO001 case.scf<br>
><br>
> For test1, this gives:<br>
><br>
> :RTO001: 1 192.208707 0.000000 15115.811643 15308.020350<br>
><br>
> For test2, the result is:<br>
><br>
> :RTO001: 1 143.691518 0.000000 15115.811674 15259.503192<br>
><br>
> This is in the very first iteration, not self-consistent. But these <br>
> numbers will not change significantly when going to selfconsistency.<br>
><br>
> You see that the valence contribution to :RTO is very different for <br>
> both cases, in spite of this being for the same element, with the same <br>
> R0 value, the same radial grid, the same RMT, the same initialization,...<br>
><br>
> I've done several different cases with similar structures, most of <br>
> them end up like test2, but a few behave as in test1. I guess I'm <br>
> overlooking something simple, but I don't see why these are different...<br>
><br>
> Any suggestion? (or maybe a check whether you get similar results with <br>
> this test, to exclude it is an issue of the compute facility?)<br>
><br>
> Thanks,<br>
> Stefaan<br>
><br>
> _______________________________________________<br>
> Wien mailing list<br>
> Wien@zeus.theochem.tuwien.ac.at<br>
> <a href="http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien">https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fzeus.theochem.tuwien.ac.at%2Fmailman%2Flistinfo%2Fwien&data=05%7C02%7CStefaan.Cottenier%40ugent.be%7Ca09a6b7c0b8541803d5508dd7506ff38%7Cd7811cdeecef496c8f91a1786241b99c%7C1%7C0%7C638795395156702295%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IjFMIy6FrkF0qXhhgsBlbxgK1bjxhD%2BwVPFU86ySoQ4%3D&reserved=0</a><br>
> SEARCH the MAILING-LIST at: <br>
> <a href="http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html">
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mail-archive.com%2Fwien%40zeus.theochem.tuwien.ac.at%2Findex.html&data=05%7C02%7CStefaan.Cottenier%40ugent.be%7Ca09a6b7c0b8541803d5508dd7506ff38%7Cd7811cdeecef496c8f91a1786241b99c%7C1%7C0%7C638795395156716674%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3KehHfpA5e15ZbL6Kb0VSjc9YPYg2F7b0ZwWQLACtKw%3D&reserved=0</a><br>
<br>
<br>
_______________________________________________<br>
Wien mailing list<br>
Wien@zeus.theochem.tuwien.ac.at<br>
<a href="http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien">https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fzeus.theochem.tuwien.ac.at%2Fmailman%2Flistinfo%2Fwien&data=05%7C02%7CStefaan.Cottenier%40ugent.be%7Ca09a6b7c0b8541803d5508dd7506ff38%7Cd7811cdeecef496c8f91a1786241b99c%7C1%7C0%7C638795395156729850%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EAwTkjw%2B%2B%2BmMsJhA%2FgPhRtJYSThZBGtwKW8JVfml9JI%3D&reserved=0</a><br>
SEARCH the MAILING-LIST at: <a href="http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html">
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mail-archive.com%2Fwien%40zeus.theochem.tuwien.ac.at%2Findex.html&data=05%7C02%7CStefaan.Cottenier%40ugent.be%7Ca09a6b7c0b8541803d5508dd7506ff38%7Cd7811cdeecef496c8f91a1786241b99c%7C1%7C0%7C638795395156742411%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OddCovvQz2HydTxnooIeHuo%2BZT8hvQSVT8Qnnb0ovow%3D&reserved=0</a><br>
</div>
</span></font></div>
</body>
</html>