<div dir="ltr">Ah, sorry. I guess I was confused: I missed the fact that -ksp_error_if_not_converged turns on mat->erroriffpe.<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 2, 2015 at 3:23 PM Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Jun 2, 2015, at 4:11 PM, Dmitry Karpeyev <<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@mcs.anl.gov</a>> wrote:<br>
><br>
> -ksp_error_if_not_converged will not return immediately (it's easy to generate cases that will generate a lot of nans before getting anywhere close to returning -- use a pmat full of zeros, for example; it is actually a real use case (a MOOSE phasefield test) where -snes_mf_operator with a finite-differencing produces a zero pmat).<br>
<br>
I am totally confused. The flag -ksp_error_if_not_converged just turns on the MatSetErrorIfFPE() so how could having an option -mat_error_if_fpe which would just turn on MatSetErrorIfFPE() result in any different kind of behavior.<br>
<br>
If MatLUFactorSymbolic/Numeric() is not obeying the MatSetErrorIfFPE() then that needs to be fixed.<br>
<br>
<br>
> When the solver returns with KSP_DIVERGED_INFORNAN, it provides only indirect information about what went wrong. At the same time MatCheckPivot_none() will give you the row and the tolerance that triggered the zero pivot detection. Currently, however, that behavior is turned on only by erroriffpe with no easy way to toggle. Maybe we need a separate, more descriptive flag to error out on a zero pivot? I would expect that users are used to the old behavior and occasionally rely on it for finding zero pivots. They will be perplexed by this newfound inability to turn it back on.<br>
<br>
They are suppose to turn it on with -ksp_error_if_not_converged does that not work? Send me an example or point me to an example where that does not work.<br>
<br>
Barry<br>
<br>
<br>
> Of course, I only have a single data point right now :-)<br>
><br>
> On Tue, Jun 2, 2015 at 2:58 PM Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> > On Jun 2, 2015, at 3:29 PM, Dmitry Karpeyev <<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@mcs.anl.gov</a>> wrote:<br>
> ><br>
> > Currently -pc_type lu will not detect a zero pivot (it will happily produce an Inf or a NaN) and the flag it checks whether to see whether<br>
> > to do it is erroriffpe. KSP_DIVERGED_NANORINF is too generic. What if the user wants to verify there is a zero pivot?<br>
><br>
><br>
> -ksp_error_if_not_converged will cause an immediate stack trace when the zero pivot occurs (as would the user calling MatSetErrorIfFPE() on the matrix or the use of -mat_error_if_fpe if it existed).<br>
><br>
> There is no way currently to get back programatically anything more specific than KSP_DIVERGED_NANORINF on a zero pivot, we can start adding more that has nothing to do with -mat_error_if_fpe<br>
><br>
> ><br>
> > Also, irrespective of the use case, if we have a XXXSetYYY(), isn't our policy to have a command-line way of doing it?<br>
><br>
> No, only when it makes sense and doesn't duplicate other functionality. I don't see -mat_error_if_fpe in this case adding anything more helpful then the already existing -ksp_error_if_not_converged<br>
><br>
> Convince me.<br>
><br>
> Barry<br>
><br>
><br>
><br>
> ><br>
> > On Tue, Jun 2, 2015 at 2:21 PM Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
> ><br>
> > > On Jun 2, 2015, at 3:02 PM, Dmitry Karpeyev <<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@mcs.anl.gov</a>> wrote:<br>
> > ><br>
> > > Should we have a way to turn on/off MatErrorIfFPE() on the command line?<br>
> ><br>
> > Sure, one does it with -ksp_error_if_not_converged or -snes_error_if_not_converged It only adds to user confusion, but no user benefit, to have a -mat_error_if_fpe thing.<br>
> ><br>
> > What user case do think there is for a -mat_error_if_fpe ?<br>
> ><br>
> > Barry<br>
> ><br>
> ><br>
> ><br>
> > > It is now turned off by default to allow Inf/NaNs to propagate and currently the only way to toggle it is programmatic.<br>
> ><br>
> ><br>
> > ><br>
> > > Dmitry.<br>
> ><br>
><br>
<br>
</blockquote></div>