> On Jun 2, 2015, at 4:11 PM, Dmitry Karpeyev <[email protected]> wrote:
>
> -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).
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.
If MatLUFactorSymbolic/Numeric() is not obeying the MatSetErrorIfFPE() then
that needs to be fixed.
> 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.
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.
Barry
> Of course, I only have a single data point right now :-)
>
> On Tue, Jun 2, 2015 at 2:58 PM Barry Smith <[email protected]> wrote:
>
> > On Jun 2, 2015, at 3:29 PM, Dmitry Karpeyev <[email protected]> wrote:
> >
> > 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
> > to do it is erroriffpe. KSP_DIVERGED_NANORINF is too generic. What if
> > the user wants to verify there is a zero pivot?
>
>
> -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).
>
> 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
>
> >
> > Also, irrespective of the use case, if we have a XXXSetYYY(), isn't our
> > policy to have a command-line way of doing it?
>
> 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
>
> Convince me.
>
> Barry
>
>
>
> >
> > On Tue, Jun 2, 2015 at 2:21 PM Barry Smith <[email protected]> wrote:
> >
> > > On Jun 2, 2015, at 3:02 PM, Dmitry Karpeyev <[email protected]> wrote:
> > >
> > > Should we have a way to turn on/off MatErrorIfFPE() on the command line?
> >
> > 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.
> >
> > What user case do think there is for a -mat_error_if_fpe ?
> >
> > Barry
> >
> >
> >
> > > It is now turned off by default to allow Inf/NaNs to propagate and
> > > currently the only way to toggle it is programmatic.
> >
> >
> > >
> > > Dmitry.
> >
>
