<p dir="ltr">Handling this at the KSP level (I actually think the Mat level is more appropriate, since the operator, not the solver, knows its domain), we have to fix MatMFFD, I would think. Yes, that thing has the concept of a nonlinear function, but it doesn't have any clue about or access to a SNES. I did, however, like the earlier idea of having the Vec itself carry a "valid" flag. That's generic and useful enough, I think.</p>

<p dir="ltr">Dmitry.</p>
<div class="gmail_quote">On Aug 31, 2014 10:57 PM, "Jed Brown" <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Derek Gaston <<a href="mailto:friedmud@gmail.com">friedmud@gmail.com</a>> writes:<br>
> As a workaround I have tried returning various "diverged" statuses in my<br>
> linear and nonlinear convergence checks... but it still has a pesky problem<br>
> where there are a couple more residual evaluations at the "end" of the<br>
> nonlinear solve.<br>
<br>
I think this is something that we should fix.<br>
<br>
The SNESMF evaluator has access to the SNES and we could have the SNES<br>
refuse to re-evaluate if the diverged reason has already been set.<br>
<br>
Perhaps we can also mark the matrix as being invalid so that KSP_MatMult<br>
and friends could decide that KSP has failed.  Semantically, we are<br>
discovering that the Mat does not actually act in the full linear space,<br>
but in some subspace with inequalities.  Semantically, I would rather<br>
the KSP decide whether it makes sense to do further evaluations because<br>
in some cases, the domain violations could be handled gracefully.<br>
</blockquote></div>