[Wien] Compilation issues for lapw0 v.13 on Mac OS X (request for code review)

[Kevin Jorissen]

Hi Martin,

thanks for your comments.

* 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.

[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.]

* 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 :).

* 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 ...


Cheers,

Kevin



On Sat, Aug 16, 2014 at 4:07 AM, Martin Kroeker <
martin at ruby.chemie.uni-freiburg.de> wrote:

> As far as I know (and in my experience), passing in a work array that is
> somewhat larger than needed is perfectly legal and should not cause any
> problems. On the other hand, uninitialized variables entering a computation
> are a very serious matter and would explain the intermittent NaNs you are
> seeing. So I would expect the single correction to dergl_spline to fix
> the NaNs and crashes.
> (Ideally, one would have to run a full SCF calculation under valgrind or a
> similar runtime access checker to weed out these things in the code, but
> the
> time and memory requirements could be too much for a weekend project).
>
> Your other changes might still be useful to make the code more readable,
> but I would like to suggest that they be applied separately IF the
> developers
> use any form of revision control system rather than just short term memory
> to keep track of development.
>
> Just my two cents..
> --
> Dr. Martin Kroeker            martin at ruby.chemie.uni-freiburg.de
> c/o Prof.Dr. Caroline Roehr
> Institut fuer Anorganische und Analytische Chemie der Universitaet Freiburg
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20140816/a691e95a/attachment.htm>