<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 3, 2014 at 1:51 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On Feb 3, 2014, at 12:58 PM, James MBewu <<a href="mailto:james.mbewu@gmail.com">james.mbewu@gmail.com</a>> wrote:<br>
<br>
> Hi all petsc gurus,<br>
><br>
> I am solving Navier Stokes equations using Q2-Q1 elements via libmesh and using petsc fieldsplit schur complement etc for the solving I was wondering whether it was possible to abort the outer iterations of the solver if the inner solver reached a set maximum iterations. At the moment if I set the maximum iterations of the inner solver, then once that is reached, the outer iterations continue and another inner solve is performed. Essentially I would like to say "I can't solve the inner problem so let's just give up on the whole thing". Is there any (easy) way to do this?<br>

<br>
   When the outer and inner iterations are linear we don’t currently have any way of handling. We call KSPSolve() on any inner solve (from the outer solve) and then blindly continue after that solve is “complete” regardless of the “quality” of the “inner” solver.<br>

<br>
   One way we could handle this is to always call KSPGetConvergedReason() after the “inner” solver and based on that value decide if the “outer” solve should be short circuited and marked as “did not converge”.   What makes this nontrivial is that depending on the circumstances one may which to continue the “outer” solver or not and we need to leave flexibility of what to do in this situation and also propagate (or not depending on the circumstance) this “short circuit” business through several layers of “inner solvers”.<br>

<br>
   This is a great question, PETSc gurus what do you think?<br></blockquote><div><br></div><div>Okay, I was not thinking before. However, it shows how we handle this for Newton. We make the enclosing</div><div>solver keep track of the failure of its subsolver and decide what to do. This does allow you to fail a certain</div>
<div>number of times before signaling failure above.</div><div><br></div><div>I don't like this for nested solvers since it seems to make every solver more complex. I would rather that there</div><div>was a generic solver switch that caused non-convergence to be reported as a non-failure. This does not allow</div>
<div>us to keep track of how many happen, but it seems much simpler than making all solvers reproduce the Newton</div><div>behavior. Also, I don't think there are any compelling reasons that you want K failures.</div>
<div><br></div><div>  Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
   Barry<br>
<br>
<br>
<br>
><br>
> Please advise, thanks,<br>
> James<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>