[Wien] lapw0 stuck/drained with seemingly no error message upon launching SCF

[Peter Blaha]

Thank you very much for your report and the "partial" solution.

Unbelievable, what Apple produces ....

Anyway, if it really does not work for bigger cases, you may want to try 
an installation on a virtual machine.

Best regards

Am 25.06.2024 um 01:21 schrieb Yichen Zhang:
> Dear all,
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Best regards
> Yichen

-- 
--------------------------------------------------------------------------
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.blaha at tuwien.ac.at    WIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at
-------------------------------------------------------------------------