[petsc-dev] strangness in Chebyshev estimate of eigenvalues

[Barry Smith]

> On Aug 28, 2015, at 6:52 AM, Matthew Knepley <knepley at gmail.com> wrote:
> 
> On Fri, Aug 28, 2015 at 6:02 AM, Mark Adams <mfadams at 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 <bsmith at mcs.anl.gov> wrote:
> 
> > On Aug 27, 2015, at 5:35 PM, Jed Brown <jed at jedbrown.org> wrote:
> >
> > Barry Smith <bsmith at 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