On Tue, Jan 6, 2015 at 1:41 PM, Jed Brown <[email protected]> wrote: > Mark Adams <[email protected]> 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.
