[petsc-dev] GAMG coarsening in-place
Mark Adams
mfadams at lbl.gov
Tue Jan 6 13:51:39 CST 2015
On Tue, Jan 6, 2015 at 1:41 PM, Jed Brown <jed at jedbrown.org> wrote:
> Mark Adams <mfadams at lbl.gov> writes:
>
> > The only reason that I can think of that you would want to use more than
> > one proc on the coarse grid is if you want to use a non-default coarse
> grid
> > solver (bjacobi/lu). Perhaps I could *not* go to one proc if the coarse
> > grid solver pc type is set (more below). I don't like adding yet another
> > switch for this if possible.
>
> What about checking whether the coarse grid has fewer dofs than the
> requested max per process? If the problem is that small, it should be
> no harm to ensure that it ends up on one process, otherwise it's
> probably a bad idea. The problems I care about have Green's functions
> that decay sufficiently rapidly that I don't want to continue
> coarsening.
>
This sound good actually. I'll make the default coarse grid target size
tiny, that will bring it down to 1 proc. and get rid of this slam to one
proc stuff.
And I guess we can just live with a fake GMRES on the coarse grid, if
Setup_MG still clobbers the KSP type. People can always set the coarse KSP
to preonly if it is a problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150106/89592dda/attachment.html>
More information about the petsc-dev
mailing list