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

[Mark Adams]

On Mon, Feb 23, 2015 at 7:19 AM, Tobin Isaac <tisaac at ices.utexas.edu> wrote:

> On Sun, Feb 22, 2015 at 07:48:51PM -0700, Jed Brown wrote:
> > Barry Smith <bsmith at mcs.anl.gov> writes:
> > >   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.
> >
> > Okay, yes.
> >
> > >    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.
> >
> > Yeah. It would be nice to avoid repeating the estimate when the smoother
> > matches the AMG smoothing.
>
> If we just keep the part that calls KSPChebyshevSetEigenvalues()
> (gamg.c:801) when the smoother PC is Jacobi or SOR, that would
> accomplish this.  The used would have to recognize what's happening
> and not call -mg_levels_ksp_chebysev_estimate_eigenvalues, which would
> recompute/override the values that gamg sets.
>

That is a reasonable approach.


>
> As for crazy matrices, I think the most general solution is for
> KSPChebyshev to try a MatProjectDirichlet(Mat,Vec) method on the rhs
> it uses for estimation.
>
>
That sounds promising.  Is that basically the same code that I have?



>   Toby
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150225/1e50937f/attachment.html>