Ah, sorry. I guess I was confused: I missed the fact that -ksp_error_if_not_converged turns on mat->erroriffpe.
On Tue, Jun 2, 2015 at 3:23 PM Barry Smith <[email protected]> wrote: > > > 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. > > > > > > >
