[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