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: [email protected] WIEN2k: http://www.wien2k.at
WWW: http://www.imc.tuwien.ac.at
-------------------------------------------------------------------------
_______________________________________________
Wien mailing list
[email protected]
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/[email protected]/index.html
