<div dir="ltr">We have three problems here (at least).<div><br></div><div>1) I use PETSc's random vectors to compute an eigen estimate.</div><div><br></div><div>2) I use srand() to mix up the graph ordering for the MIS.</div><div><br></div><div>I could write a hash function like thing that takes the global ID and generates a (bad) random number.  These random number do not have to be high quality so this should be fine.  This should fix these two problems.  The convergence rates will still vary with different number of processors but it should otherwise be determinant.</div><div><br></div><div><div>3) And a related problem, we do not reuse the eignenestimages in Cheby that I campute.</div></div><div><br></div><div>Maybe I'm missing something, but we seemed to have lost this when we moved the eigen estimator for Cheby out of GAMG.  Can we attach the eigen estimates is some universally defined way, have everyone that computes eigen estimates (of the diagonally preconditioned operator) attach it, and have Cheby check for it?</div><div><br></div><div>Mark</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 8, 2015 at 4:40 PM, Andrs, David <span dir="ltr"><<a href="mailto:david.andrs@inl.gov" target="_blank">david.andrs@inl.gov</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"><span class=""><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:arial,sans-serif">On Sat, Aug 8, 2015 at 2:29 PM, Barry Smith </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span><span style="font-family:arial,sans-serif"> wrote:</span><br></div></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  Mark,<br>
<br>
    So GAMG uses random numbers in the implementation, this means identical runs on machines with different random number generates can produce noticeable different convergence histories. This means that the "no change" tests in the nightly tests indicate change (i.e. a problem) when this perhaps not a problem. So it is impossible to trust the results of the tests.<br>
<br>
   Is there anything we can do to alleviate this problem? Are the random number usage fundamental to the algorithm? Should we distribute with PETSc a "random number generator" that will generate the same results on all systems (if that is even possible?)?<br></blockquote><div><br></div></span><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">​We had a similar problem in MOOSE where tests using RNG were returning slightly different results. We ended up using <a href="http://www.cs.hmc.edu/~geoff/mtwist.html" target="_blank">mtwist</a>, however, the author now recommends to use <a href="http://www.pcg-random.org" target="_blank">PCG</a>.</div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">​Hope that helps,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">--</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">David​</div><br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  Thanks<br>
<br>
  Barry<br>
<br>
<br>
Note that on the same machine if you run the same program twice with our default system provided "random number generator" you will get the same result, this is an issue with running on different kinds of machines and getting different results.<br>
<br>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div>