<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 6, 2015 at 1:41 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Mark Adams <<a href="mailto:mfadams@lbl.gov">mfadams@lbl.gov</a>> writes:<br>
<br>
> The only reason that I can think of that you would want to use more than<br>
> one proc on the coarse grid is if you want to use a non-default coarse grid<br>
> solver (bjacobi/lu).  Perhaps I could *not* go to one proc if the coarse<br>
> grid solver pc type is set (more below).  I don't like adding yet another<br>
> switch for this if possible.<br>
<br>
</span>What about checking whether the coarse grid has fewer dofs than the<br>
requested max per process?  If the problem is that small, it should be<br>
no harm to ensure that it ends up on one process, otherwise it's<br>
probably a bad idea.  The problems I care about have Green's functions<br>
that decay sufficiently rapidly that I don't want to continue<br>
coarsening.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div></div></div>