<div dir="auto"><div>I can see that there are some emails on this.</div><div dir="auto"><br></div><div dir="auto">With such a small limit very, very simple problems should run fine, but don't expect anything else to work unless you can find a way to redo your kernel.</div><div><br></div><div data-smartmail="gmail_signature">---<br>Professor Laurence Marks (Laurie)<br><a href="http://www.numis.northwestern.edu">www.numis.northwestern.edu</a><br><a href="https://scholar.google.com/citations?user=zmHhI9gAAAAJ&hl=en">https://scholar.google.com/citations?user=zmHhI9gAAAAJ&hl=en</a><br>"Research is to see what everybody else has seen, and to think what nobody else has thought" Albert Szent-Györgyi</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 24, 2024, 18:21 Yichen Zhang <<a href="mailto:zycforphysics@gmail.com">zycforphysics@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear all,<br>
<br>
Thank you for all the previous help and suggestions! I have solved the problem of wien2k running on Apple Silicon Mac. The following notes can be useful for future users who would like to run wien2k on Apple silicon Mac.<br>
<br>
The hanging at lapw0 is due to a stack memory issue. However, the difficult thing is that Apple silicon Mac will ignore the “ulimit -s unlimited” command you add in the root shell rc file. That’s why it seems not straightforward to debug this problem.<br>
<br>
For the newer version of Apple silicon Mac, there is a hard limit for the static memory which is around 65 MB. Apple doesn’t allow you to change that, so “ulimit -s unlimited” doesn’t work, when we thought it would naturally work when we configured it in root rc. If one lists “ulimit -a”, the stack limit is unchanged after ulimit -s unlimited, or with any number of ulimit -s that is larger than the number restricted by Apple. <br>
<br>
Furthermore, if one wants to force lifting this hard limit, Apple will tell you “System integrity security engaged”. Then none of your apps can be opened anymore. It kinds of triggered some Apple system security alert … This was what happened on my laptop. Luckily, by rebooting your computer, the system can return back to normal. So it is advised never to brutally overwrite the static hard limit in newer versions of Apple silicon Mac.<br>
<br>
The solution to this for WIEN2k is to add the option of -fmax-stack-var-size=4096 in gfortran compilation option. The default value for this option is 32 KB (-fmax-stack-var-size=32768 in the unit of byte) when compiling. With this default value and the number of variables engaged in normal wien2k calculations, the static memory used is very likely to exceed 65 MB (set by Apple) quickly at the lapw0 stage. And in my case, I believe it hits the cap when calling subroutine XCPOT1, so that’s why XCPOT1 gets called, never executes, and hangs there. Therefore, I set it to 4096 bytes (4 KB), so that variables exceeding this limit will be handled by heap memory.<br>
<br>
It is possible that the value of -fmax-stack-var-size needs to be further reduced depending on what calculations are to be carried out. But at least for the TiC tutorial SCF, 4096 is enough to restrict the static memory below the Apple hard limit. <br>
<br>
Best regards<br>
Yichen</blockquote></div>