<div dir="ltr">OK, The problem is that I don't think I can change this easily as far as the cluster is concerned. I obtain access to petsc by loading the petsc module, and even if I have a few choices, I don't see any debug builds...<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-14 17:26 GMT+09:00 Dave May <span dir="ltr"><<a href="mailto:dave.mayhem23@gmail.com" target="_blank">dave.mayhem23@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br><br>On Monday, 14 December 2015, Timothée Nicolas <<a>timothee.nicolas@gmail.com</a>> wrote:<br></span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hum, OK. I use FORTRAN by the way. Is your comment still valid ? </div><div></div></div></blockquote><div><br></div></span><div>No. Fortran compilers init variables to zero.</div><div>In this case, I would run a debug build on your OSX machine through valgrind and make sure it is clean. </div><div><br></div><div>Other obvious thing<span></span> to check what happens if use exactly the same petsc builds on both machines. I see 3.6.1 and 3.6.0 are being used. </div><div><br></div>For all this type of checking, I would definitely use debug builds on both machines. Your cluster build is using the highest level of optimization...<div class="HOEnZb"><div class="h5"><br><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I'll check anyway, but I thought I had been careful about this sort of things. <br><br>Also, I thought the problem on Mac OS X may have been due to the fact I used the version with debugging on, so I rerun configure with --with-debugging=no, which did not change anything.<br><br></div><div>Thx<br></div><div><br></div>Timothee<br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-14 17:04 GMT+09:00 Dave May <span dir="ltr"><<a>dave.mayhem23@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One suggestion is you have some uninitialized variables in your pcshell. Despite your arch being called "debug", your configure options indicate you have turned debugging off.<div><br></div><div>C standard doesn't prescribe how uninit variables should be treated - the behavior is labelled as undefined. As a result, different compilers on different archs with the same optimization flags can and will treat uninit variables differently. I find OSX c compilers tend to set them to zero.</div><div><br></div><div>I suggest compiling a debug build on both machines and trying your test again. Also, consider running the debug builds through valgrind. </div><div><br></div><div>Thanks,</div><div>  Dave </div><div><div><div><br>On Monday, 14 December 2015, Timothée Nicolas <<a>timothee.nicolas@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div>Hi,<br><br></div>I have noticed I have a VERY big difference in behaviour between two machines in my problem, solved with SNES. I can't explain it, because I have tested my operators which give the same result. I also checked that the vectors fed to the SNES are the same. The problem happens only with my shell preconditioner. When I don't use it, and simply solve using -snes_mf, I don't see anymore than the usual 3-4 changing digits at the end of the residuals. However, when I use my pcshell, the results are completely different between the two machines.<br><br></div>I have attached output_SuperComputer.txt and output_DesktopComputer.txt, which correspond to the output from the exact same code and options (and of course same input data file !). More precisely<br><br></div>output_SuperComputer.txt : output on a supercomputer called Helios, sorry I don't know the exact specs.<br></div>In this case, the SNES norms are reduced successively:<br>0 SNES Function norm 4.867111712420e-03<br>1 SNES Function norm 5.632325929998e-08<br>2 SNES Function norm 7.427800084502e-15<br><br>output_DesktopComputer.txt : output on a Mac OS X Yosemite 3.4 GHz Intel Core i5 16GB 1600 MHz DDr3. (the same happens on an other laptop with Mac OS X Mavericks). <br></div><div>In this case, I obtain the following for the SNES norms,<br><div>while in the other, I obtain <br>0 SNES Function norm 4.867111713544e-03<br>1 SNES Function norm 1.560094052222e-03<br>2 SNES Function norm 1.552118650943e-03<br></div>3 SNES Function norm 1.552106297094e-03<br>4 SNES Function norm 1.552106277949e-03<br>which I can't explain, because otherwise the KSP residual (with the same operator, which I checked) behave well.<br></div><div><br></div>As you can see, the first time the preconditioner is applied (DB_, DP_, Drho_ and PS_ solves), the two outputs coincide (except for the few last digits, up to 9 actually, which is more than I would expect), and everything starts to diverge at the first print of the main KSP (the one stemming from the SNES) residual norms.<br><br></div>Do you have an idea what may cause such a strange behaviour ?<br><br></div>Best<br><br></div>Timothee<br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>
</blockquote>
</div></div></blockquote></div><br></div>