On 20/06/10 16:21, Stephan Kramer wrote: > On 20/06/10 05:07, Barry Smith wrote: >> >> >> Hmm, this is a good question. There are tons of places where some sort >> of "inner solve" is imbedded in an "outer solver", in fact many levels of >> nesting. We should handle this in a systematic way which likely means >> carefully checks put in various places in the code. >> >> We could instead (or in addition) add an option to have KSPSolve() >> generate an error on "not-convergence" instead of returning with a negative >> converged reason. The drawback to this is that you cannot "handle" the error >> and continue running, it just ends. Would this be useful? >> >> Barry > > I can see the logistical nightmare of having to check return values of every > PCApply, MatMult, etc. in petsc code. I guess this is where exception > handling would be a great thing to have. > > I think for our own purposes, we will follow Matt's suggestion of wrapping > KSPDefaultConverged() and set a global flag that can be checked afterwards. > Our code checks successful completion convergence > of every solve afterwards. It always handles solver failures as a fatal > error, but the the code continues for a bit (end of timestep) to ensure final > diagnostics, mesh and fields are written out - it > is an adaptive mesh model, so users may not have even seen the mesh that was > used to solve on. > > For simpler applications a petsc error generated on the spot would be a > useful option, yes, but a more robust general way of handling nested solver > failures would be greatly appreciated. I was > slightly surprised to be honest to discover petsc happily continuing its ksp > solve even though the MatSchurComplement solves were silently failing. A > drawback of the suggested workaround, is that even > if the MatSchurComplement solve fails in the first iteration (for instance > reaching max iterations), the outer solve will still continue, trying and > failing to solve the MatSchurComplement inner solve > each iteration, until it finally hits the maximum number of outer iterations. > > Cheers > Stephan
Actually, looking a little closer, I see a lot of negative KSPConvergedReasons are not actually raised by KSPDefaultConvergence(). In particular I still won't be able to trap KSP_DIVERGED_ITS this way, except for me adding an extra n < ksp->max_it check of course, but that still leaves out a lot of krylov method-specific reasons... > > > >> >> On Jun 18, 2010, at 11:35 AM, Stephan Kramer wrote: >> >>> Dear all, >>> >>> Is there a way in petsc, when performing inner solves like PCKSP or >>> MatSchurComplementGetKSP, to make the outer solve stop immediately and >>> report back a negative convergence reason? I find that often when such >>> "inner solves" fail, the outer solve happily continues and sometimes >>> falsely reports convergence due to the preconditioner becoming rank >>> deficient. I'd like our code, using petsc, to be able to trap that sort of >>> situations and give a suitable error message. >>> >>> Cheers >>> Stephan >> >> > -- Stephan Kramer <s.kramer at imperial.ac.uk> Applied Modelling and Computation Group, Department of Earth Science and Engineering, Imperial College London
