[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