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

[Laurence Marks]

I can see that there are some emails on this.

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.

---
Professor Laurence Marks (Laurie)
www.numis.northwestern.edu
https://scholar.google.com/citations?user=zmHhI9gAAAAJ&hl=en
"Research is to see what everybody else has seen, and to think what nobody
else has thought" Albert Szent-Györgyi

On Mon, Jun 24, 2024, 18:21 Yichen Zhang <zycforphysics at gmail.com> wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20240624/a36c5a1d/attachment.htm>