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

[Cea, Stephen M]

Thanks for the quick responses!  

For the short time I am pretty sure that we can just treat the error from KSP_Solve like non convergence.  Long term what you propose sounds good.  

Thanks again,
steve

-----Original Message-----
From: Barry Smith [mailto:bsmith at mcs.anl.gov] 
Sent: Friday, February 22, 2013 4:20 PM
To: petsc-maint at mcs.anl.gov; Jed Brown
Cc: For users of the development version of PETSc; Cea, Stephen M
Subject: Re: [petsc-dev] [petsc-maint #154101] clarification of FP error thrown in VECNORM in 3.3 PETSc


On Feb 22, 2013, at 6:02 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Fri, Feb 22, 2013 at 5:57 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
>>    We will figure out a way to manage this. I am thinking a global 
>> flag you can set indicating you don't want these checks performed; 
>> then you will get back the previous behavior.
> 
> 
> 
> Would it be enough to have a flag per-object?

   Ok, I did a search through the code to see where we are checking it.

   1) VecNorm, VecDot, VecMDot  -- and generate an error

   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).

      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 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.

   

  Barry


> 
> I don't like a global flag because it would have to be set 
> collectively (this isn't nice if you subproblems on subcomms and not 
> everyone wants to tolerate NaNs.) Note that to tolerate NaNs and bail 
> out cleanly, a reduction is required in places where it would otherwise not be.
>