[petsc-dev] strangness in Chebyshev estimate of eigenvalues

[Barry Smith]

> On May 17, 2016, at 9:25 PM, Jed Brown <jed at jedbrown.org> wrote:
> 
> The relevance is when someone writes their problem matrix to disk and we read it back. Or, for those that use space filling curves to order their dofs (many use them to order elements).

  Jed,

  So are you proposing we have three options KSPChebyshevEstEigSetRHSType() with (1) "use give rhs", (2) "use random rhs", (3) "use hash scheme to produce same right hand side independent of number of processes so long as the ordering stays the same" or are you suggesting just bagging the random? or bagging also the right hand side and always just use the hash scheme? By just using the hash scheme we can remove some current code and options which is always a good thing... if they provide no added value then they should be removed.

   Barry

> 
> On May 17, 2016 6:13:31 PM PDT, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
>  On May 17, 2016, at 7:29 PM, Jed Brown <jed at jedbrown.org> wrote:
>  
>  That is my suggestion and I think you should use it so it's easier to debug.
>  
> 
>    As Jed already noted this approach only works if the ordering remains the same when you change the number of processes which  I submit is almost never true in the "real world". Both with DMDA (except 1d) and DMPLEX and virtually anybodies homegrown mesh system and presumably libMesh and Deal.ii the ordering will change so this goofy little hack won't apply. Just use the damn random number generator.
> 
>   Barry
> 
> 
> 
> 
> 
>  On May 17, 2016 5:11:42 PM PDT, Mark Adams <mfadams at lbl.gov> wrote:<
>  
>  br />
> OK, I thought you were suggesting that:
> 
>  
>  unsigned int hash(unsigned int x) {
>  
>      x 
>  = ((x >> 16) ^ x) * 0x45d9f3b;
>  
>      x 
>  = ((x >> 16) ^ x) * 0x45d9f3b;
>  
>      x 
>  = ((x >> 16) ^ x);
>  
>      
>  return x;
>  }
>  But, Barry is vetoing this.
>  
>  On Tue, May 17, 2016 at 4:18 PM, Jed Brown <jed at jedbrown.org> wrote:
>  Mark Adams <mfadams at lbl.gov> writes:
>  
>  Why not just set each index with hash(i) = (i >> 32)^i and forget
>  VecSetRandom in here?
>  
>  Because if your vertices are numbered lexicographically on a Cartesian
>  grid, this gives you a plane.  But just put in the legit hash (the one I
>  linked is pretty good) and then you don't have to worry about
>  accidentally stumbling upon
> pathological cases.
> 
>  
>