On May 25, 2013, at 8:58 PM, Jed Brown <[email protected]> wrote:
> Barry Smith <[email protected]> writes: > >> Why is gamg using bjacobi as the course solver? > > I swear we've been talked about this several times, but I can't find a > definitive email thread. Redundant is slower except possibly when > coarsening entirely in-place, and even then, usually not. GAMG > restricts the active set incrementally, so that once it reaches the > coarse grid, all dofs are on one process. At that point, it would be > crazy to broadcast all that data and do a redundant solve. True > Instead, it > uses block Jacobi in which all blocks but one are empty. This seems a rather ad hoc way of handling it. Why not have a proper mechanism for telescoping solvers rather than an ad hoc block Jacobi with 0 sizes on most blocks? > >> And why does it have different solvers on each process? > > It doesn't, but it calls PCBJacobiGetSubKSP() so as to configure the > inner PC to be PCLU, but PCBJacobiGetSubKSP conservatively sets this > flag: > > jac->same_local_solves = PETSC_FALSE; /* Assume that local solves are > now different; > not necessarily true though! > This flag is > used only for > PCView_BJacobi() */ Why not just fix this instead. Fix it so it doesn't set the flag in this situation. > >> Seems more a problem with GAMG then with viewing. > > If the user does a custom configuration on each process, like maybe a > different Chebyshev estimate, I still don't think it's acceptable for > -ksp_view to create O(P) output. I am not arguing about that > We have to be careful to summarize in > a scalable way.
