[petsc-dev] synchronized printing, singletons, and jumbled GAMG/BJacobi output

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> 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.  Instead, it
uses block Jacobi in which all blocks but one are empty.

>   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() */

>   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.  We have to be careful to summarize in
a scalable way.