[petsc-dev] [petsc-maint #154101] clarification of FP error thrown in VECNORM in 3.3 PETSc

[Jed Brown]

I would use the same flag, just error earlier so that the trace is more
useful. We know that the NaN won't turn into something useful after it is
computed.
On Feb 22, 2013 9:08 PM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:

>
> On Feb 22, 2013, at 8:40 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> >
> > On Fri, Feb 22, 2013 at 6:19 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >
> >    Ok, I did a search through the code to see where we are checking it.
> >
> >    1) VecNorm, VecDot, VecMDot  -- and generate an error
> >
> > Yeah, I never liked this.
> >
> >
> >    2) Many of the Krylov solvers and nonlinear solvers check the results
> of (most - should be all) norms and dots and either
> >
> >         a)  generate a not converged KSP or SNES converged reason (good)
> >
> >         b) generate an error (bad, most do this).
> >
> > We want the solvers to have an option to raise an error because it helps
> users track down where they made a mistake (especially if they're running
> in a shitty environment where -fp_trap and gdb doesn't work nicely). I'm
> not sure which should be the default.
>
>    Currently KSPSetErrorIfNotConverged() will trigger an error at the end
> of the KSPSolve() routine if not converged (including NaN). If this is not
> close enough to the problem for you we could use the same flag to stop the
> code with a SETERRQ() as soon as the norm, dot, mdot problem is detected?
> Or we could add yet another flag?
>
>    Barry
>
>
> >
> >
> >       Note that currently the checks in the solvers are redundant
> because an error was already generated in the VecNorm, Dot or MDot so NaN
> never
> >       gets to the iterative solver
> >
> >    3) Few other irrelevant places.
> >
> >   The simplest thing would be to simply remove the checks in 1).  Then,
> eventually, update all the solvers to NOT generate an error but instead
> return with
> > an appropriate diverged reason. The drawback is that other code using
> dots and norms will always chug along without generating an error if users
> don't
> > check the results themselves.
> >
> > I think this is an event that the caller should deal with since only
> they have enough context to return cleanly. Yes, it's more code, but it's
> the right thing.
> >
> >    I vote we just make a patch in 3.3 to remove the checks in norm, dot,
> mdot and Jed adds another project to the bitbucket list saying upgrade the
> checks in the solvers to return with appropriate diverged reason instead of
> generating an error. Then the whole flag business goes away.
> >
> > That's fine with me.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130222/b55db97f/attachment.html>