[petsc-dev] Mark, what's the rational for keeping the Chebyshev tuning inside GAMG?

Barry Smith bsmith at mcs.anl.gov
Sun Feb 22 20:40:08 CST 2015


> On Feb 22, 2015, at 9:32 AM, Jed Brown <jed at jedbrown.org> wrote:
> 
> Barry Smith <bsmith at mcs.anl.gov> writes:
>>   Huhh? 
> 
> The smoothed interpolation satisfies
> 
>  P_{smoothed} = (1 - w D^{-1} A) P_{tentative}
> 
> where D^{-1} is Jacobi (could be point-block Jacobi), but cannot be SOR.
> GAMG is computing the estimate in order to choose w.

  Jed,

   Wrong, wrong, wrong. You are looking at the wrong place in the code. (Yes, this is a problem with duplicate code in THREE! places). I am referring to the code around line 795 in gamg.c  /* do my own cheby */ which I actually cut and pasted into my previous email. You are referring to the code in agg.c around line 1209 which does what you said. The code I am referring to computes the estimates used by the smoother on each level and thus forces a bypass of the code in Chebyshev.c it seems completely unneeded to me (aside from maybe the hack for crazy matrices) since Chebyshev.c will do it next automatically anyways.

  Barry


> 
>>   But anyways, even if GAMG turns on Cheby/Jacobi as the smoother
>>   there is not reason the Chebyshev estimator you wrote cannot be
>>   used since it just uses whatever PC has been set. So your response
>>   seems completely orthogonal to my question. Can we merge and just
>>   have one Chebyshev estimator?
> 
> I think yes, after adding KSPChebyshevGetEigenvalues().




More information about the petsc-dev mailing list