<div dir="ltr">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>Cheers,</div><div><br></div><div>Kevin</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">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>
<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 class="">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 class="">
<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 class="">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 class="h5"><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 class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">
</font></span></blockquote></div><span class="HOEnZb"><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">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>