<p>Sorry, but I agree with Peter & I am 99.9% certain that this is not a bug in the mixer. The way to test this is (with ifort) to use -ftrapuv ; the arrays are not set in mixer.F but elsewhere within some complicated subroutines. This flag forces a fault if an undefined variable is used.</p>
<p>---------------------------<br>
Professor Laurence Marks<br>
Department of Materials Science and Engineering<br>
Northwestern University<br>
<a href="http://www.numis.northwestern.edu">www.numis.northwestern.edu</a> 1-847-491-3996<br>
"Research is to see what everybody else has seen, and to think what nobody else has thought"<br>
Albert Szent-Gyorgi<br>
</p>
<div class="gmail_quote">On Oct 10, 2013 7:23 AM, "Pavel Ondračka" <<a href="mailto:pavel.ondracka@email.cz">pavel.ondracka@email.cz</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Peter Blaha píše v Čt 10. 10. 2013 v 12:22 +0200:<br>
> I'm not very familiar with valgrid, but all those reports seem not<br>
> relevant to me.<br>
> It seems to complain about all allocated arrays, which are not set to<br>
> zero globally. But this does NOT mean that one uses uninitialized<br>
> variables or assumes that the compiler sets them to zero.<br>
Valgrind doesn't complain about uninitialized variables in general. Just<br>
when they are used in such way that they can alter the flow of the<br>
program or generally alter the externally-visible behavior.<br>
<br>
I'll take the problem from mixer as an example, because contrary to the<br>
rest of the problems, here I'm 99% sure it is a real bug.<br>
<br>
The complex array ROKMIX in mixer.F, is only partially initialized. The<br>
real part of the complex number is initialized somewhere (don't know<br>
exactly where, since I haven't tracked it that much), however the<br>
imaginary part is not. You can check this by setting the imaginary part<br>
to some specific value right after the allocation, and then set a<br>
breakpoint or print its value at line<br>
mixer.F:1504 if(abs(ROKMIX(J,I)).gt.1D-12)then<br>
and you will see, it has the same value as set before, so it wasn't<br>
written anywhere.<br>
And now basically if real part of ROKMIX(J,I) is lower than 1D-12 we<br>
would randomly fail or pass the if test, depending on what stuff is<br>
written in the corresponding uninitialized memory.<br>
<br>
><br>
> PS: I don't have a variable "WS" in dergl.f<br>
> WS=0.0D0 in dergl.f<br>
My mistake, this should have been RW<br>
><br>
> We can verify this also with ifort by setting -C in the flags, and in<br>
> fact doing so would result in an error in f7splt due to the mistake you<br>
> mentioned before.<br>
><br>
> So the only problem was in f7splt.f and that should be fixed as<br>
> previously mentioned.<br>
Well, this is not what valgrind does. Valgrind doesn't do static code<br>
analysis as compilers do during compilation, but it replaces calls to<br>
malloc and similar at runtime with his own versions and tracks the used<br>
memory at runtime.<br>
<br>
To be more specific, I'll try to explain on my previous example why I<br>
think it can't be discovered by the ifort checking.<br>
Although ifort probably can track, that imaginary part of ROKMIX(J,I) is<br>
uninitialized at that point, it has no way of knowing if return value of<br>
abs(ROKMIX(J,I)) actually depends on the uninitialized value or not,<br>
because abs function has not been linked at that point.<br>
<br>
><br>
> (PS: I was wrong with my first reply that you need ISPLIT=15 (this<br>
> relates to an older version). The present if statement is intentional,<br>
> but still, no result from f7splt will be used (except for ISPLIT=15).<br>
Thanks, this explains it.<br>
<br>
I'm very grateful and I appreciate it very much, that you are looking<br>
into this, even though this is not a problem at your platform.<br>
Thanks again.<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>
</blockquote></div>