<div dir="ltr">Another update to this thread.<div><br></div><div>First, Jianxin Zhu did some more tests and here are the findings:</div><div><br></div><div><br></div><div><span style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">###############################################################</span><br>
</div><div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">I have a few items to share ---</div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
A) ---</div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">I compared the total energy from running with version 13.1 and version 12.1 on my two mac osx boxes (with the same condition). The values of the total energy are respectively,</div>
<div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><div>:ENE : ********** TOTAL ENERGY IN Ry = -244362.69826119</div>
<div>:ENE : ********** TOTAL ENERGY IN Ry = -244362.69826094</div><div>:ENE : ********** TOTAL ENERGY IN Ry = -244362.69826095</div></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
:ENE : ********** TOTAL ENERGY IN Ry = -244362.69826079</div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">with version 13.1,</div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
and</div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><div>:ENE : ********** TOTAL ENERGY IN Ry = -244362.69576023</div><div>:ENE : ********** TOTAL ENERGY IN Ry = -244362.69576000</div>
<div>:ENE : ********** TOTAL ENERGY IN Ry = -244362.69576000</div></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">:ENE : ********** TOTAL ENERGY IN Ry = -244362.69576001</div>
<div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">with version 12.1</div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
I have also compared the values of total energy from running with the same version 13.1 on my linux cluster (there without the option -heap–arrays in the compilation).</div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
:ENE : ********** TOTAL ENERGY IN Ry = -244362.69827763</div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><div>:ENE : ********** TOTAL ENERGY IN Ry = -244362.69827704</div><div>:ENE : ********** TOTAL ENERGY IN Ry = -244362.69827626</div>
<div>:ENE : ********** TOTAL ENERGY IN Ry = -244362.69827588</div></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
[I am using the following convergence criterion for benchmark ---</div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"> run_lapw -ec 0.000001 -i 40 -NI –p]</div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
<br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">B) ---</div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">Without the use of the option, -heap-arrays, if you can print out those matrices before the subroutine call NormS in qmix8.F, you should be able to see some part of the matrices (I have no time to identify which of them) has NAN.</div>
<div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">C) --- </div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
I also compared the W2kutils.c in version 12.1 and that in version 13.1. </div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
The following lines </div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><div>#ifdef __APPLE__</div><div> limit.rlim_cur = limit.rlim_max ; /* RLIM_INFINITY */</div>
<div>#else</div><div> limit.rlim_cur = RLIM_INFINITY ;</div><div>#endif</div></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
are in version 13.1; while</div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"> /* Set to the maximum we can */</div>
<div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"> limit.rlim_cur = limit.rlim_max; /* limit.rlim_max; RLIM_INFINITY;*/ </div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
<br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">Are in version 12.1, which I put in a few years ago. </div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
In the assumption that if #ifdef __APPLE__ is automatically active, there is really no difference to cause the problem we currently have. </div></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
<br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><br></div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">###############################################################</div>
<div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">Second, I add the following comments:</div><div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px"><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">
* seeing NaN sounds pretty serious</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">* I'm a bit mystified by this W2kutils stuff. I don't think that "APPLE" is activated by siteconfig in any way?? Should I add something like "-DAPPLE" to the FOPT in my Makefiles?</div>
<div><br></div><div><br></div><div><br></div><div><br></div><div>Cheers,</div><div><br></div><div><br></div><div>Kevin</div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 31, 2014 at 11:23 PM, Laurence Marks <span dir="ltr"><<a href="mailto:L-marks@northwestern.edu" target="_blank">L-marks@northwestern.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Dear Kevin,</p>
<p dir="ltr">No problem with your email. All large codes have bugs, and sometimes I write sloppy code. I do try and keep mixer as free of bugs as I can since I wrote the multisecant algorithms.</p>
<p dir="ltr">Listing the W2kutils issue - good idea, hint to Peter.</p>
<p dir="ltr">___________________________</p><div class=""><br>
Professor Laurence Marks<br>
Department of Materials Science and Engineering<br>
Northwestern University<br></div>
www.numis.northwestern.edu1-847-491-3996<div class=""><br>
Co-Editor, Acta Cryst A<br>
"Research is to see what everybody else has seen, and to think what nobody else has thought"<br>
Albert Szent-Gyorgi</div><p></p>
<div class="gmail_quote"><div class="">On Sep 1, 2014 1:13 AM, "Kevin Jorissen" <<a href="mailto:kevinjorissenpdx@gmail.com" target="_blank">kevinjorissenpdx@gmail.com</a>> wrote:<br type="attribution"></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div dir="ltr"><div class="">Hi Laurence,
<div><br>
</div>
<div>thanks for your comments. </div>
<div><br>
</div>
<div>I hope I didn't call the issue we observed a code bug -- I meant to use unsensational language and avoid assumptions. For sure this could be a problem on the Mac side or in ifort (we all know these exist). I haven't edited the W2kutils. But didn't we
fix the Mac problems with that file a few years ago? In any case, I'm not using MPI and stacksize is set to unlimited in my shell startup file, so I doubt this is the culprit. Or could the W2kutils somehow override my shell startup configuration?</div>
<div><br>
</div>
<div>It's probably not urgent since we have a remedy that will do for now. If you can think of any tests you'd like to see done on Mac, let us know.</div>
<div><br>
</div>
<div>By the way, this W2kutils thing is ***NOT*** on the list of known issues and bugs on the WIEN2k website. It would be very, very valuable and time-saving if that list could be updated to reflect the knowledge inside the experts' heads.</div>
<div><br>
</div>
</div><div>Cheers,</div>
<div><br>
</div>
<div>Kevin</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote"><div class="">On Sun, Aug 31, 2014 at 10:47 PM, Laurence Marks <span dir="ltr">
<<a href="mailto:L-marks@northwestern.edu" target="_blank">L-marks@northwestern.edu</a>></span> wrote:<br>
</div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I am currently at a conference in Montenegro, so don't have enough time to check properly. While this could be a code bug, I suspect an OS bug connected to the known problem in W2kutils for Mac of setting the stack size. Do you have this commented
out?
<div><br>
</div>
<div>To expand, the reason W2kutils sets the stack size is because this was a very common problem (look at the mail list some years ago for ulimit), some sys_admins were setting it too low and openmpi was not by default passing ulimit values. If it is not large
enough problems occur. The argument you are using <span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:12.800000190734863px">-heap-arrays puts arrays onto disc (it is similar to the Fortran save command). This is slower, although this does
not matter much in mixer.</span></div>
<div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:12.800000190734863px"><br>
</span></div>
<div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:12.800000190734863px">Unless you can identify something specific, I am not sure what I can do as I have no access to Mac. Maybe run mixer using ddd (or gdb) ? As one caveat, with this
type of issue sometimes it does not show up at the source.</span></div>
<div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:12.800000190734863px"><br>
</span></div>
<div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:12.800000190734863px">N.B. mixer is a bit of a memory hog, and sometime I should try and clean up some of the arrays. Unfortunately this is hard with code that is changing.</span></div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
<div>On Sun, Aug 31, 2014 at 6:30 PM, Kevin Jorissen <span dir="ltr"><<a href="mailto:kevinjorissenpdx@gmail.com" target="_blank">kevinjorissenpdx@gmail.com</a>></span> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
<div dir="ltr">Thanks, Martin, for sharing some advanced ideas.
<div><br>
</div>
<div>I spent a few minutes trying to find out more, throwing a diagnostic compile line at the problem :
<div>
<p style="margin:0px;font-size:11px;font-family:Menlo">-gen-interfaces -warn interfaces -fp-stack-check -g -traceback -check arg_temp_created -check bounds </p>
</div>
<div>trying to catch anything potentially suspicious. The problem with most codes I've worked on is that you typically catch a bunch of unrelated things that obscure the analysis :). In this case, e.g., the argument F to TrustStep (called before the NormS
mentioned earlier) is an allocated array on one side and implicit on the other, and that offends the compile options above. I don't have much time for analysis right now - maybe the mixer developers will immediately spot what's going on in my earlier e-mail.
"check bounds" or "check all" by themselves don't give any runtime diagnostics, so I'm guessing we're not overstepping array bounds explicitly.</div>
<div><br>
</div>
<div>If you have a more specific idea for a test, I or maybe Jianxin can try to run it for you. I guess a basic one would be to just do the run_lapw calculation on Linux vs. Mac (with -heap-arrays) and see if the results are identical.</div>
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>Kevin</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
<div>On Sun, Aug 31, 2014 at 4:29 PM, Martin Kroeker <span dir="ltr"><<a href="mailto:martin@ruby.chemie.uni-freiburg.de" target="_blank">martin@ruby.chemie.uni-freiburg.de</a>></span> wrote:<br>
</div>
<div>
<div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This might warrant closer scrutiny - was it reproducible with any odd<br>
tutorial problem, or does it require a particular case or type of<br>
calculation ?<br>
The "illegal instruction" abort signals that data was somehow spilling<br>
over into the memory ranges holding the executable code. Now I would not<br>
expect a "simple" heap-stack-collision (from an array that is simply too<br>
big to put on the stack with impunity) to occur on any modern system<br>
except perhaps severely constrained embedded ones. At worst, the abort<br>
should have been accompanied by a "segmentation fault" message as the<br>
attempt to overwrite the running program got caught. So other possible<br>
explanations could be that the code tries to store more array elements<br>
than the array was designed to hold, or that the indexes into the array<br>
are miscalculated (overflowing or not clamped to positive values).<br>
Moving data to the heap may have just changed the location of the<br>
inadvertently overwritten memory to ranges where the effects are more<br>
subtle (unrelated data) or not noticable (lucky hit on unused memory).<span><font color="#888888"><br>
<span><font color="#888888">--<br>
Dr. Martin Kroeker <a href="mailto:martin@ruby.chemie.uni-freiburg.de" target="_blank">
martin@ruby.chemie.uni-freiburg.de</a><br>
c/o Prof.Dr. Caroline Roehr<br>
Institut fuer Anorganische und Analytische Chemie der Universitaet Freiburg<br>
<br>
_______________________________________________<br>
Wien mailing list<br>
<a href="mailto:Wien@zeus.theochem.tuwien.ac.at" target="_blank">Wien@zeus.theochem.tuwien.ac.at</a><br>
<a href="http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien" target="_blank">http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien</a><br>
SEARCH the MAILING-LIST at: <a href="http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html" target="_blank">
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html</a><br>
</font></span></font></span></blockquote>
</div>
</div>
</div>
<br>
<span><font color="#888888"></font></span></div>
<span><font color="#888888"></font></span></div>
<span><font color="#888888"></font></span></blockquote>
</div>
<span><font color="#888888"><br>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">Professor Laurence Marks<br>
Department of Materials Science and Engineering<br>
Northwestern University<br>
<a href="http://www.numis.northwestern.edu" target="_blank">www.numis.northwestern.edu</a>
<div>Corrosion in 4D: <a href="http://MURI4D.numis.northwestern.edu" target="_blank">
MURI4D.numis.northwestern.edu</a><br>
Co-Editor, Acta Cryst A<br>
"Research is to see what everybody else has seen, and to think what nobody else has thought"<br>
Albert Szent-Gyorgi</div>
</div>
</font></span></div>
<br>
_______________________________________________<br>
Wien mailing list<br>
<a href="mailto:Wien@zeus.theochem.tuwien.ac.at" target="_blank">Wien@zeus.theochem.tuwien.ac.at</a><br>
<a href="http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien" target="_blank">http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien</a><br>
SEARCH the MAILING-LIST at: <a href="http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html" target="_blank">
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html</a><br>
<br>
</blockquote>
</div></div></div>
<br>
</div>
</div>
</blockquote></div>
<br>_______________________________________________<br>
Wien mailing list<br>
<a href="mailto:Wien@zeus.theochem.tuwien.ac.at">Wien@zeus.theochem.tuwien.ac.at</a><br>
<a href="http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien" target="_blank">http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien</a><br>
SEARCH the MAILING-LIST at: <a href="http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html" target="_blank">http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html</a><br>
<br></blockquote></div><br></div>