> On Aug 28, 2015, at 6:52 AM, Matthew Knepley <knep...@gmail.com> wrote: > > On Fri, Aug 28, 2015 at 6:02 AM, Mark Adams <mfad...@lbl.gov> wrote: > Is there a good way to get a deterministic rand wrt number of processors? > Seeding rand for each entry, with its global ID would work I assume.
What "global idea"? Even with something simple like DMDA the "global idea" of a variable depends on the number of processes, similarly if one is doing any kind of partitioner on the unknowns the ordering changes with the number of processors. Barry > > > If drand48 is just one line then why not just copy it tweak it as desired? > > I did. Its in next. > > Matt > > Cheby is otherwise deterministic, with a deterministic PC, and we have > equation numbers to make this work. Eigen estimates are a real pain and the > source of a lot of time consuming AMG errors. It would be nice to have it > not depend in any way on processor count. > > On Thu, Aug 27, 2015 at 10:12 PM, Barry Smith <bsm...@mcs.anl.gov> wrote: > > > On Aug 27, 2015, at 5:35 PM, Jed Brown <j...@jedbrown.org> wrote: > > > > Barry Smith <bsm...@mcs.anl.gov> writes: > >> This is the default behavior if one just creates a PetscRandom and uses > >> it, so don't be going and setting seeds inside GAMG or Chebyshev. > > > > Yikes, you are right all three of our current random number generators > have global state! What a mess. We should remove all them completely and we > can complement Matt's by adding in a more modern version of Sprng that does > not use global state. (Stupid Sprng fucks changed to C++) > > Barry > > > You're right (my mistake), but the consequences are dangerous if the > > user is holding a PetscRandom across calls to GAMG (or anything that > > creates new PetscRandom instances). The reason is that merely creating > > a PetscRandom reseeds the global PRNG. (What moron thought a global > > seed was a good idea?) Seems to me we should avoid drand48 always so we > > don't disrupt the user's source of randomness (leading to really > > confusing incorrect results). We could use the non-disastrous > > drand48_r, but it's a GNU extension so we'd need an alternative anyway. > > > > If Matt changes "rander48" to the rand48_r (or erand48_r) interface, > > then we'd be okay. This would also remove the internal variables that > > Matt forget to make static. > > > > > > -- > What most experimenters take for granted before they begin their experiments > is infinitely more interesting than any results to which their experiments > lead. > -- Norbert Wiener
