[petsc-dev] strangness in Chebyshev estimate of eigenvalues

[Satish Balay]

Mark,

petsc 'next' doesn't build for complex due to error in cheby.c

$ git branch -r --contains d5742a2a619a688a61daaaef5bdde3042d32f41a
  origin/next

$ git branch -r --contains eb041292
  origin/mark/snes-ex56c
  origin/next

Perhaps you have merged mark/snes-ex56c to next pushed next - but not pushed mark/snes-ex56c?

I was going to push the following fix to mark/snes-ex56c.

diff --git a/src/ksp/ksp/impls/cheby/cheby.c b/src/ksp/ksp/impls/cheby/cheby.c
index f2a26bf..722d32d 100644
--- a/src/ksp/ksp/impls/cheby/cheby.c
+++ b/src/ksp/ksp/impls/cheby/cheby.c
@@ -369,7 +369,7 @@ static PetscErrorCode KSPSolve_Chebyshev(KSP ksp)
           ierr = VecGetLocalSize(B,&n);CHKERRQ(ierr);
           ierr = VecGetArray(B,&xx);CHKERRQ(ierr);
           for (i=0; i<n; i++) {
-            PetscReal v = chebyhash(i+istart);
+            PetscScalar v = chebyhash(i+istart);
             xx[i] = v;
           }
           ierr = VecRestoreArray(B,&xx);CHKERRQ(ierr);

Satish

On Thu, 19 May 2016, Barry Smith wrote:

> 
> > On May 19, 2016, at 10:03 AM, Mark Adams <mfadams at lbl.gov> wrote:
> > 
> > 
> > 
> > On Tue, May 17, 2016 at 10:55 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > 
> >   Mark,
> > 
> >    So it sounds like the right fix is to change the "random" option name to "noisy" and replace the use of the random number generator with Jed's hash and make it the default. (Where if you turn off the noisy it uses the right hand side which is useful for debugging the solvers)
> > 
> > So this means removing "PetscRandom      random;" from Cheby, I assume.
> 
>    Yes
> 
> >  
> > If you make a pull request we'll move it through,
> > 
> >    Thanks for bringing up the problem,
> > 
> >   Barry
> > 
> > > On May 17, 2016, at 9:44 PM, Jed Brown <jed at jedbrown.org> wrote:
> > >
> > > Barry Smith <bsmith at mcs.anl.gov> writes:
> > >>  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?
> > >
> > > Bag random for sure.
> > >
> > >>  or bagging also the right hand side and always just use the hash
> > >>  scheme?
> > >
> > > I wouldn't have a problem with that.  The only nice thing about using
> > > the RHS is that it doesn't depend on the ordering.
> > >
> > >>  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.
> > >
> > > Yes.
> > 
> > 
> 
>