<div dir="ltr">Dear all,<div><br></div><div>Jianxin Zhu and I have done a little work on a problem he discovered running WIEN2k v. 13 on Mac OS X for a medium size calculation (matrix size ~3800; 40 ineq atoms).  </div><div>
<br></div><div>ISSUE:</div><div>In this calculation, the &quot;mixer&quot; program crashes with a runtime error (it prints &quot;Illegal Instruction&quot; on my computer) during the SCF loop.</div><div><br></div><div>This problem does not occur with WIEN2k v. 12.  It also does not occur for smaller testcases.  We have only tested ifort.</div>
<div><br></div><div>SOLUTION:</div><div>We can solve the situation by adding &quot;-heap-arrays&quot; to the compiler options for the mixer program:</div><div>1.  edit SRC_mixer/Makefile : add &quot;-heap-arrays&quot; to &quot;FOPT&quot;.</div>
<div>2. in SRC_mixer directory, do &quot;make&quot;</div><div>3. &quot;cp mixer ..&quot;</div><div>As far as we currently know, it is only needed in mixer.  (No need to use siteconfig and recompile the entire WIEN2k installation.)  This compiler option just tells the compiler to put arrays on the memory &quot;heap&quot; rather than the &quot;stack&quot;.</div>
<div><br></div><div>TECHNICAL DETAILS:</div><div>Possibly the situation could be avoided entirely by a slight recoding.  Mac and Linux have slightly different rules for how to use memory, for the different types of arrays (dynamically or statically allocated, array temporaries ...).  It seems that the issue happens when qmix8 calls NormS (a routine that didn&#39;t exist in WIEN2k_12) : a debugging statement right before &quot;call norms&quot; is executed, but a debugging statement in the first line of &quot;subroutine norms&quot; is not executed.  (I&#39;m no expert in memory issues, so I&#39;m trying to report as phenomenologically as possible.)  The objects in this function call are ca. 1,500,000 x 2 size in my test, or ~20MB each.  My hunch is that the first dimension would grow with number of atoms, whereas the second dimension will grow with the number of SCF iterations.  Perhaps just changing the definition/allocation of the arrays in the function call can quickly solve the issue without need for custom compilation options!</div>
<div><br></div><div><br></div><div>I don&#39;t know that we will have time for further analysis, so we wanted to submit our report as is.  If anyone would like to test this calculation themselves, please ping Jianxin for files.  Thanks everyone :).</div>
<div><br></div><div><br></div><div>Cheers,</div><div><br></div><div>Jian Xin</div><div>Kevin</div><div><br></div><div><br></div><div><br></div><div><br></div></div>