<div dir="ltr">Hi Martin,<div><br></div><div>thanks for your comments.</div><div><br></div><div>* You're right: fixing only the initialization bug (2 lines of code) is good enough. Just tested running with only that single change: It makes the test finish successfully. Good thinking.</div>
<div><br></div><div>[I made the other code changes first while looking for the source of the problem and they had some effect on code behavior (while the initialization bug was still unfixed) so I included them in my report ... I personally prefer "tighter", cleaner code as it makes it easier to find and fix problems - sometimes array size issues do cause a problem even when they shouldn't. But it looks like they are optional and could be ignored.]</div>
<div><br></div><div>* I think the development model for many scientific projects is "let's put it in now or we'll forget" rather than the nice branched models you read about :).</div><div><br></div><div>
* Valgrind, yeah ... I tried it some years ago and hated it. I found it unwieldy, convoluted, buggy, low signal-to-noise i.e. loads of false positives ... Maybe it's gotten better though, maybe I'm missing out. But I have a feeling it's not for casual users: you have to study Valgrind before it becomes a useful tool. And, like runtime checks (-check all), often harder to use in these big legacy projects that are full of small leaks and errors (that are harmless in the end) and make it hard to get to the issues that matter ...</div>
<div><br></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 Sat, Aug 16, 2014 at 4:07 AM, 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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As far as I know (and in my experience), passing in a work array that is<br>
somewhat larger than needed is perfectly legal and should not cause any<br>
problems. On the other hand, uninitialized variables entering a computation<br>
are a very serious matter and would explain the intermittent NaNs you are<br>
seeing. So I would expect the single correction to dergl_spline to fix<br>
the NaNs and crashes.<br>
(Ideally, one would have to run a full SCF calculation under valgrind or a<br>
similar runtime access checker to weed out these things in the code, but the<br>
time and memory requirements could be too much for a weekend project).<br>
<br>
Your other changes might still be useful to make the code more readable,<br>
but I would like to suggest that they be applied separately IF the developers<br>
use any form of revision control system rather than just short term memory<br>
to keep track of development.<br>
<br>
Just my two cents..<br>
<span class="HOEnZb"><font color="#888888">--<br>
Dr. Martin Kroeker <a href="mailto:martin@ruby.chemie.uni-freiburg.de">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">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></blockquote></div><br></div>